TRS-80 Model I/III printer MMIO

[Jenz]

Latest TRS-80GP emulator introduces 0x37EA and 0x37EB as aliases (mirrors) for the TRS-80 Model I printer MMIO 0x37E8: is 0x37E9 also valid? 0x37E9 is documented for the Model III, but not Model I: David Keil's and Lawrence Kesteloot's TRS-80 emulator support 0x37E9 for the Model I ... so addresses from 0x37E8 to 0x37EB are valid printer MMIOs for the Model I (and the Model III)?

 

[gp2000]

That's correct. Matt Boytim was looking into this when doing some FPGA version of the TRS-80 and noted that the Model 1 aliased the 4 addresses while the Model 3 reduced that to two. I guess they figured it was enough for compatibility and didn't want to hide more ROM data than they needed.

 

[Jenz]

Thanks, George! Now also changed in SDL(2)TRS: Add TRS-80 Model I printer address aliases ...

 

[Jenz]

while the Model 3 reduced that to two.

In the TRS-80 Model III (and 4/4P) Technical Reference Manual addresses 0x37E8 and 0x37E9 are marked "read only" for the printer status: so they cannot be used for printer output?

 

[gp2000]

That has to be a mistake; there's be no point in supporting those addresses unless they were writable.

I took a look in the Model III Technical Reference manual and couldn't see where it says that. Do you have a page #? I'd like to note it as a correction.

 

[Eudimorphodon]

That has to be a mistake; there's be no point in supporting those addresses unless they were writable.

I took a look in the Model III Technical Reference manual and couldn't see where it says that. Do you have a page #? I'd like to note it as a correction.

FWIW, this contention that they're read only, not write-able, appeared in several 80 Micro articles. But... yeah, I never checked it.

Here's the exact text about this from the Model III tech manual:

It only mentions reads, not writes, but it says what part of the schematic to look at, so...

Looking at figure 8 there's a 74LS30 8-input NAND that takes massaged input from 10 address lines (A0 isn't one of them, IE, it can't tell the difference between 37E8 and E9) and ROMCs and turns them into an "LPEN" signal. This then goes to a 74LS32 that ORS it with RD, which is a memory read, and *then* this signal is AND'ed with the "LPIN" signal from the port decoding. So... yes. Unless I'm missing something this decoding isn't going to be satisfied on a write, it's *only* going to work on a read. (IE, the transaction being a read is a specific requirement of the signal generation to activate the port to read, and there's no provision there generating the counterpart "LP OUT" signal from a memory write.)

You're definitely correct that it doesn't make a ton of sense they didn't preserve that address as writable, but I'd just chalk it up as another entry on the list of kinda questionable compatibility breaks they made with the Model III. I think the justification was that Level II BASIC didn't actually have a command to read printer status so PEEKing the status address was SOP even if you were using LPRINT for the output.

 

[Jenz]

The TRS-80 Model 4/4P Technical Reference Manual also says:

 

[gp2000]

You're definitely correct that it doesn't make a ton of sense they didn't preserve that address as writable, but I'd just chalk it up as another entry on the list of kinda questionable compatibility breaks they made with the Model III. I think the justification was that Level II BASIC didn't actually have a command to read printer status so PEEKing the status address was SOP even if you were using LPRINT for the output.

That's a good explanation for why they took that approach. It also better explains how the Microsoft Editor Assembler for Model III line printer output works. Its "lprint" routine sends characters to both port $F8 and memory location $37E8. I fixed that by assuming that a real printer would immediately signal busy after the first character and would be ignoring data for at least a few microseconds. If $37E8 is read only it makes their coding choice more reasonable.

I'm guessing they figured that stuffing a OUT ($F8),A in there would give them code that works on both the Model 1 and 3. If only they'd changed the shift key polling. And shipped a high baud rate version on the cassette. At least it encouraged me and my brother to write our own COPYSYS that reads low baud system tapes and writes high baud versions.

Thanks for the info and Jenz for pointing it out. Now to fix trs80gp and (if I'm feeling especially energetic) write a regression test.