Hello again, I am currently restoring a Tandy 200 I acquired off eBay. It came with two TPDD drives, maxed out on ram, cables and documentation. It had a problem booting caused by a bad internal battery and improperly installed TS-dos eeprom (someone put it in backwards and upside down, version 4.00). I have everything working except the LCD appears unevenly dim. Likely a polarizer. I’d like to replace the lcd as a module rather than attempt a polarizer replacement without parts on hand should I fail.
Also, I had installed a super cap in my NEC in place of the internal memory battery (5F 5V) and have been using that successfully for years but opted to install a battery from Birt in the 200 in case I sell it. Does anyone know where I can buy a replacement LCD? The club100 site says none in stock. Thanks in advance. -Will Kibler > On Oct 22, 2026, at 12:00 PM, [email protected] wrote: > Send M100 mailing list submissions to > [email protected] > > To subscribe or unsubscribe via the World Wide Web, visit > http://lists.bitchin100.com/listinfo/m100 > or, via email, send a message with subject or body 'help' to > [email protected] > > You can reach the person managing the list at > [email protected] > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of M100 digest..." > > > Today's Topics: > > 1. Re: Fuzix compiler for 8085 (B 9) > 2. Re: Fuzix compiler for 8085 (Alan Cox) > 3. Re: Fuzix compiler for 8085 (B 9) > 4. Drawing The Largest Circle or Polygon on a Model-T Screen > (David Szasz) > 5. Re: Fuzix compiler for 8085 (Alan Cox) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Wed, 21 Oct 2026 10:01:07 -0700 > From: B 9 <[email protected]> > To: M100 <[email protected]> > Subject: Re: [M100] Fuzix compiler for 8085 > Message-ID: > <CAG1tPescCO_XxwrhDdOE7AbMgTffD=Vn1pfHKcxS=dqmkgy...@mail.gmail.com> > Content-Type: text/plain; charset="utf-8" > > Ooh! That looks awesome, Alan! I've been using asmx for assembly as it is > Free Software, light weight, and forgiving. By forgiving, I mean, I can > usually toss in code formatted for the dialects spoken by the ancient Model > T assemblers of yore without having to pipe it through awk. But it has some > deficiencies and quirks of its own. > > When you say Fuzix does "8085 syntax", does that include the Intel ISIS II > macros for assembly? > > ?B9 > > On Wed, Oct 21, 2026 at 3:04?AM Alan Cox <[email protected]> wrote: > >> If it's useful my assembler/linker tools and C compiler can do 8085 and >> support linking and relocations as well as using all the undocumented 8085 >> operations and 8085 syntax >> >> https://codeberg.org/EtchedPixels/Fuzix-Compiler-Kit >> https://codeberg.org/EtchedPixels/Fuzix-Bintools >> >> >> >> On Wed, 21 Oct 2026 at 01:31, John R. Hogerhuis <[email protected]> wrote: >> >>> On Tue, Oct 20, 2026 at 5:19?PM Joshua O'Keefe <[email protected]> >>> wrote: >>>>> On Oct 20, 2026, at 4:22?PM, John R. Hogerhuis <[email protected]> >>>> wrote: >>>>> Yeah everyone's got their opinions on this. >>>>> For whatever reason the Telemark TASM assembler is my favorite. >>>> Simple. But yeah it's DOS + linux basically abandonware. But it's table >>>> driven IIRC and supports our undocumented instructions and doesn't really >>>> change. >>>> I'm personally more or less OK with z88dk for what little I do, but it's >>>> heavy and clearly not seamless for everyone to get up and running. The idea >>>> of Telemark appealed to me but the black box closed source and the >>>> difficulty of getting it up running made it a dead end for me when I tried. >>>> Modulo the wide range of surely divergent opinions, what are folks' take on >>>> assemblers like a85 and asm85? They seem like nice, lightweight, >>>> straightforward options, often in the operating system's repo and fairly >>>> portable/cross-platform. >>>> If we were to tell someone to "assemble this real quick and >>>> try...[thing]" what would we point them to so that a dev environment >>>> becomes the very least of their problems? >>> No idea. I always end up solving my own problems. Probably over again >>> from the last time I solved it and forgot. >>> I guess what we should all probably do if we're sharing source is >>> document the toolchain and how to put it in place in the README, etc >>> There are common tools we all end up needing like things to make a .CO or >>> to build a BASIC-as-DO injector. And we all need C and assembly header >>> files with entry points and variable memory addresses. We should probably >>> be organizing that stuff for discoverablity and reuse. >>> Assemblers and compilers relevant to us... probably a wiki page would be >>> nice with a table listing the known tools and their pluses and minuses, >>> examples of public projects making use of them. If any. >>> The actual value there would be provided by someone willing to take >>> ownership and curate and maintain such a list. >>> -- John. > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: > <http://lists.bitchin100.com/private/m100/attachments/20261021/d48575d8/attachment-0001.htm> > > ------------------------------ > > Message: 2 > Date: Wed, 21 Oct 2026 22:00:12 +0100 > From: Alan Cox <[email protected]> > To: [email protected] > Subject: Re: [M100] Fuzix compiler for 8085 > Message-ID: > <CAK9X0+tAxk04uhF+NubakWaup4E4NCgJB3+tZ5=yogr80ke...@mail.gmail.com> > Content-Type: text/plain; charset="utf-8" > > On Wed, 21 Oct 2026 at 18:01, B 9 <[email protected]> wrote: > >> Ooh! That looks awesome, Alan! I've been using asmx for assembly as it is >> Free Software, light weight, and forgiving. By forgiving, I mean, I can >> usually toss in code formatted for the dialects spoken by the ancient Model >> T assemblers of yore without having to pipe it through awk. But it has some >> deficiencies and quirks of its own. >> >> When you say Fuzix does "8085 syntax", does that include the Intel ISIS II >> macros for assembly? > > No just 8085 syntax not macros and the like. > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: > <http://lists.bitchin100.com/private/m100/attachments/20261021/b502cd7d/attachment-0001.htm> > > ------------------------------ > > Message: 3 > Date: Wed, 21 Oct 2026 20:19:19 -0700 > From: B 9 <[email protected]> > To: [email protected], Alan Cox <[email protected]> > Subject: Re: [M100] Fuzix compiler for 8085 > Message-ID: > <cag1tpetnrt3qkuvs-f+jtj3vc8fga7wj44qeppamotfx6g4...@mail.gmail.com> > Content-Type: text/plain; charset="UTF-8" > > On October 21, 2026 2:00:12 PM PDT, Alan Cox [email protected] wrote: > > On Wed, 21 Oct 2026 at 18:01, B 9 [email protected] wrote: > > Ooh! That looks awesome, Alan! > When you say Fuzix does ?8085 syntax?, does that include the Intel ISIS II > macros for assembly? > > No just 8085 syntax not macros and the like. > > Okay, thanks. Sorry for the ignorant question. I only just now learned > that some 8085 assemblers do not use 8085 syntax. (Zasm uses Z80 > syntax, for anyone as confused as I was.) > > I?m intrigued by Fuzix OS. Am I understanding correctly that you are > running a custom-built 8085 machine with a self-hosting OS that is > comparable to UN*X circa 1983? Would I be wrong to presume running > Fuzix on a stock Model T is out of the question due to the lack of a > Memory Management Unit? And am I right in thinking that the circuit > surgery needed to add an MMU to a Model T is prohibitively invasive? I > haven?t thought about MMUs since college, but I recall them being > deeply intertwingled with the fundamental design of the system. (Then > again, I?m pretty sure the professor also never taught us that you > could make an MMU from just a latch, a MUX, and an AND gate.) > > You mentioned the Fuzix assembler might be useful for the Model T > community. What about the Fuzix C Compiler? The webpage mentions that > the compiler?s 8085 code runs several times faster on than the 8080 > and that the 8085?s undocumented instructions ?make a huge difference > when executing high level languages.? That sounds nifty. When John > makes his list of development environments and their pros and cons, is > fcc one that should be considered as a cross-compiler? > > One last question: It looks like you already have fcc running on an > 8085 system. How reasonable would it be to try to port it to run on a > Model T? (Okay, perhaps ?reasonableness? isn?t the right metric as the > fact that I want to compile C on my Tandy 200 already demonstrates a > lack of sound judgment. :-) > > ?b9 > > > ------------------------------ > > Message: 4 > Date: Thu, 22 Oct 2026 11:02:04 -0400 > From: David Szasz <[email protected]> > To: Model 100 Discussion <[email protected]> > Subject: [M100] Drawing The Largest Circle or Polygon on a Model-T > Screen > Message-ID: > <ca++pp3eonhapd6crjhq3_r5gs6pmgze-lcdmfwtmrxtpkiv...@mail.gmail.com> > Content-Type: text/plain; charset="utf-8" > > Hi Again: > > Here is a subroutine to draw the largest polygon or "circle" on a m200 > screen: (This relates to the m100 discussion list on 10/16/26 regarding > a CIRCLE() command for the Model-T computers.) > > 10 'DRAW REG POLYGON OR "CIRCLE" > 20 CLS > 35 XC=120:YC=63 'SET SCREEN CTR > 40 R=63 'SET RADIUS IN PIXELS > 50 N=24 'SET NO. OF SIDES > 60 PI=4*ATN(1) 'SET SINGLE PRECISION PI > 70 DA=(2*PI)/N 'ANGLE STEP PER VERTEX > 90 X1=XC+R*COS(0):Y1=YC+R*SIN(0) 'CALC 1ST VERTEX > 110 X0=X1 'SAVE START POINT > 120 FOR I=1TON 'STEP > 130 A=I*DA > 140 X2=XC+R*COS(A):Y2=YC+R*SIN(A) > 160 LINE (X1,Y1)-(X2,Y2) > 170 X1=X2:Y1=Y2 > 180 NEXTI > 190 END > > I am a "novice" m100-BASIC programmer so you will forgive any violation of > your sensibilities. The code works well when drawing a figure with a low > number of corners or "vertices", like a triangle or petagon. But you will > see if you draw a polygon with a low radius value (like 10) with a high > number of sides (like 24) it starts to look like a piece of "popcorn". I > wrote it originally in GWBasic and there it takes on an elongated > appearance due to the aspect ratio of GWbasic for an early PC screen. Hence > the ability of the CIRCLE() command in GWBasic to change the aspect ratio > to make the circle look better. On the m200 I'm guessing that the pixels > are more square so it looks OK as is. > > 1.) In the real world (whatever that is?) I would add code to save the > coordinates of the vertices to an array. Then take the coordinates and draw > a polygon from that. It would take less code and save processing time. But > for just "playing" around this is OK. > > 2.) In books relating to the Model-T computers they always plot the > individual points of a circle, which looks better but takes an eternity to > draw. > > 3.) For the m100 screen size one will have to reduce the values of YC in > line 35 and R in line 40 accordingly. > > 4.) As expected, values exceeding screen size will cause an error. > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: > <http://lists.bitchin100.com/private/m100/attachments/20261022/98dc0597/attachment-0001.htm> > -------------- next part -------------- > A non-text attachment was scrubbed... > Name: POLY01A.pdf > Type: application/pdf > Size: 100208 bytes > Desc: not available > URL: > <http://lists.bitchin100.com/private/m100/attachments/20261022/98dc0597/attachment-0001.pdf> > > ------------------------------ > > Message: 5 > Date: Thu, 22 Oct 2026 16:04:37 +0100 > From: Alan Cox <[email protected]> > To: B 9 <[email protected]> > Cc: [email protected] > Subject: Re: [M100] Fuzix compiler for 8085 > Message-ID: > <cak9x0+tks-vrracndsnpwohthraprnwoco6rrnouduqgsfg...@mail.gmail.com> > Content-Type: text/plain; charset="utf-8" > >> Okay, thanks. Sorry for the ignorant question. I only just now learned >> that some 8085 assemblers do not use 8085 syntax. (Zasm uses Z80 >> syntax, for anyone as confused as I was.) > > A lot of people used to Z80 seem to prefer Z80 syntax > >> >> I?m intrigued by Fuzix OS. Am I understanding correctly that you are >> running a custom-built 8085 machine with a self-hosting OS that is >> comparable to UN*X circa 1983? Would I be wrong to presume running > > It's not self hosting yet but that is the goal - the compiler will indeed > run on > the machine itself but I need to improve make, clean up and simplify the > build > system and a load of other stuff to finally get it self hosting. > > Fuzix on a stock Model T is out of the question due to the lack of a >> Memory Management Unit? And am I right in thinking that the circuit >> surgery needed to add an MMU to a Model T is prohibitively invasive? I >> haven?t thought about MMUs since college, but I recall them being >> deeply intertwingled with the fundamental design of the system. (Then >> again, I?m pretty sure the professor also never taught us that you >> could make an MMU from just a latch, a MUX, and an AND gate.) > > It needs memory banking. It's possible that with sufficient donuts someone > could > persuade it to run on some banked Rex type device that also had a fast disk > device > (SD card or similar in it). At that point though I'm not really sure it's > a model T any > more ! An MMU is not needed - in fact there were a bunch of ports to > machines > without an MMU in the early days (eg PC/IX on 8086) and if you got it badly > wrong > a user crashed the machine. That was considered acceptable back then. > > >> >> You mentioned the Fuzix assembler might be useful for the Model T >> community. What about the Fuzix C Compiler? The webpage mentions that >> the compiler?s 8085 code runs several times faster on than the 8080 >> and that the 8085?s undocumented instructions ?make a huge difference >> when executing high level languages.? That sounds nifty. When John >> makes his list of development environments and their pros and cons, is >> fcc one that should be considered as a cross-compiler? > > Someone would need to write a crt0.S (the C runtime startup) and figure how > to > get from binary images to something useful on the model T, and you'd need to > put together some kind of minimal C library. 8085 output is a lot faster > and smaller > in the C case than 8080. Things like getting a value off the stack become > > ldsi #offset > lhlx > > not > lxi h,offset > dad sp > mov e,m > inx h > mov d,m > xchg > > for example > > > >> One last question: It looks like you already have fcc running on an >> 8085 system. How reasonable would it be to try to port it to run on a >> Model T? (Okay, perhaps ?reasonableness? isn?t the right metric as the >> fact that I want to compile C on my Tandy 200 already demonstrates a >> lack of sound judgment. :-) > > You need about a 48-56K memory area for the application and you need a > better disk device than a floppy. I think in theory you could run it under > CP/M > on some of the expansions but it would involve a fair bit of work. > > Probably you'd want to generate a C library for CP/M then compile it with > fcc to get an fcc to run on CP/M but there's a list of "except that..." > involved > in that CP/M has no nice way for a program to run another and pass a load > of arguments, then get control back, and disk I/O is 128 byte blocks, and > has no subdirectories and so on. > > So I suspect it's an RFC 1925 rule 3 item. > > (3) With sufficient thrust, pigs fly just fine. However, this is > not necessarily a good idea. It is hard to be sure where they > are going to land, and it could be dangerous sitting under them > as they fly overhead. > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: > <http://lists.bitchin100.com/private/m100/attachments/20261022/6a786220/attachment-0001.htm> > > ------------------------------ > > Subject: Digest Footer > > _______________________________________________ > M100 mailing list > [email protected] > http://lists.bitchin100.com/listinfo/m100 > > > ------------------------------ > > End of M100 Digest, Vol 190, Issue 20 > *************************************
