Me too. I've made a spreadsheet of the 100/NEC/200 roms, and added additional 200 entry points based on the disassembly from VirtualT
On Tue, May 5, 2026 at 7:44 AM Stephen Adolph <[email protected]> wrote: > I have spreadsheets to contribute. Happy to share those. > Steve > > On Monday, May 4, 2026, B9 <[email protected]> wrote: > >> Wow, great sleuthing. Which program are you referring to that operates at >> non-standard rates? >> >> In trying to decipher the old listings, I've repeatedly wondered if >> people had a different ROM disassembly available to them in the past. Of >> course, it's totally possible that folks were independently figuring things >> like this out and they simply didn't share the knowledge. >> >> By the way, I'm starting a side-project to gather all the known >> ROM/RAM/IO addresses for the Tandy 200 into a single machine and human >> readable file. The idea is to have a format that can be used for both >> disassembling existing code (for example, as "labels" in Ghidra) and as an >> equiv "library" for writing new assembly language programs. >> >> --b9 >> >> >> >> >> >> >> On May 4, 2026 1:20:19 PM PDT, Peter Noeth <[email protected]> wrote: >> >>> Group, >>> >>> I have been doing some work on a BASIC program I downloaded from the >>> old club100 library that uses the RS232 port at a non-standard baud rate. >>> >>> The BASIC program also POKES the value 31 into memory location 65421 >>> (FF8Dh). Since there is no documentation in the code or .DO file, I have >>> been researching this location. According to Ken Pettit's M100 ROM >>> disassembly (dated 2013), this memory location is only used twice, once in >>> the "UART config from text string" routine (17E6h) at 1832h and again at >>> the "RS232 Receive Interrupt" routine (6DACh) at location 6DB9h. >>> >>> The memory location FF8Dh is noted as "RS232 Control Byte" in both >>> locations in the disassembly, but in reality, is a "read data mask". >>> Microsoft included this ability, but who knows why. Without the original >>> commented ROM listing we will never know. >>> >>> In the "UART Config From Text String" routine, the value 255 (FFh) is >>> always written to memory at FF8Dh, which couldn't be a shadow of the RS232 >>> Control Byte (baud rate, parity, etc.). And in the "RS232 Receive >>> Interrupt" routine, after data is read from the UART Receive Data Register >>> (C8h), it is ANDED with the byte at FF8Dh before being stored in the C >>> Register. Definitely a "mask" operation. >>> >>> The BASIC program is putting a value of 31 (00011111b) in FF8Dh, >>> masking whatever data is received to a value between 0 and 31. This would >>> make sense to the BASIC program which is configuring the RS232 port for >>> 5-bit operation. But I would think it is not necessary. Unfortunately, I >>> can't contact the originator of the BASIC program, to find out why he did >>> this and how he found this memory location in RAM as I have found no Model >>> 100 documentation that references it (I own most all of the books written >>> about the Model 100). >>> >>> So, just a "word to the wise" about the function of memory location >>> 65421 (FF8Dh). Maybe Ken and others who have worked on commenting the >>> disassembly of the Model 100 ROM, will update their listings. >>> >>> Regards, >>> PeterN >>> >>
