• Please review our updated Terms and Rules here

TRS-80 Model 4 128K Upgrade

tempest

Veteran Member
Joined
Sep 16, 2014
Messages
930
Location
SE Michigan
Is there any real reason to upgrade a Model 4 from 64K to 128K? I have the non-gate array version so it's a bit trickier to do this. Also, are the needed memory chips and PAL (or GAL) readily available?
 
Honestly I'm just going to be playing games on it. Something tells me there are no games that require 128K.
 
Disk-loading games usually needed 32k... but, yeah, outside of a few games written for the high-res board were there any games for the Model 4 that didn't run in Model III mode? Maybe a text adventure or two?
 
Disk-loading games usually needed 32k... but, yeah, outside of a few games written for the high-res board were there any games for the Model 4 that didn't run in Model III mode? Maybe a text adventure or two?

I believe a problem with the Model 4 is that the "pixels" in the 2x3 block characters aren't the same size (the 3rd row is a different height) like they are on the Model I/III . This would make anything moving around on the screen look unusual. However it didn't stop Tetris from being written for the Model 4 (http://www.classiccmp.org/cpmarchives/trs80/Software/Model 4/T/), and I can't see a Model I/III version on that web site.
 
Last edited:
Montezuma's CP/M works with 128K OOTB, a 64KB ramdisk is great to have all the OS running from it. IIRC, someone posted some scripts to setup this. It's in my ToDo list...

I also upgraded mine (a NGA model too) and it was a real PITA. No GAL worked for me and it didn't worked until I switched to use a real PAL IC.
 
I believe a problem with the Model 4 is that the "pixels" in the 2x3 block characters aren't the same size (the 3rd row is a different height) like they are on the Model I/III . This would make anything moving around on the screen look unusual. However it didn't stop Tetris from being written for the Model 4 (http://www.classiccmp.org/cpmarchives/trs80/Software/Model 4/T/), and I can't see a Model I/III version on that web site.

Really? I remember playing a bunch of classic TRS-80 games on a Model 4 at a show years ago (a bunch of Big Five stuff) and didn't see anything unusual. I'd be interested in seeing a comparison though, as now I'm kind of curious.


I also upgraded mine (a NGA model too) and it was a real PITA. No GAL worked for me and it didn't worked until I switched to use a real PAL IC.

Yeah that's what I was afraid of. If there's nothing that really uses it and nothing that actually needs it I think I'll stick with 64K. :)
 
Really? I remember playing a bunch of classic TRS-80 games on a Model 4 at a show years ago (a bunch of Big Five stuff) and didn't see anything unusual. I'd be interested in seeing a comparison though, as now I'm kind of curious.

That's because classic TRS-80 games run in Model I/III mode, with 64x16 text and equal size graphics blocks. It's the Model 4-exclusive 80x24 text mode that has the unequal size graphics blocks.
 
That's because classic TRS-80 games run in Model I/III mode, with 64x16 text and equal size graphics blocks. It's the Model 4-exclusive 80x24 text mode that has the unequal size graphics blocks.

So Model I/III games will run in the regular 64x16 mode on a 4? That's what I figured, otherwise people would have complained.
 
However it didn't stop Tetris from being written for the Model 4 (http://www.classiccmp.org/cpmarchives/trs80/Software/Model 4/T/), and I can't see a Model I/III version on that web site.

A standard Tetris grid is 10x20 so a Model 4 version of Tetris would probably just use the solid white character to represent a block so the shaved-off low pixels wouldn't matter. This would be one very rare edge case where the Model 4's video system makes writing an "action game" easier than the Model I/III's layout. ;)

I suppose you could argue that being limited to text characters actually makes your version of Tetris more "authentic", really, given its Soviet-era origins:

Tetris-VeryFirstVersion.png
 
So Model I/III games will run in the regular 64x16 mode on a 4? That's what I figured, otherwise people would have complained.

Yeah sorry, I was only referring to Model 4 mode.

A standard Tetris grid is 10x20 so a Model 4 version of Tetris would probably just use the solid white character to represent a block so the shaved-off low pixels wouldn't matter. This would be one very rare edge case where the Model 4's video system makes writing an "action game" easier than the Model I/III's layout. ;)

Yeah you're right, the blocks just move one full line at a time so there isn't any weirdness as it moves down the screen, although it does use hollowed blocks so you can see the different pixel heights. See attached.

m4tetris.jpg
 
Last edited:
Yeah you're right, the blocks just move one full line at a time so there isn't any weirdness as it moves down the screen, although it does use hollowed blocks so you can see the different pixel heights. See attached.

I remember sort of wondering why Tandy didn't tweak the system to even that out a bit; you know, maybe make it so in Model 4 mode the upper and lower blocks were 3 pixels tall and the middle row 4. And then of course the obvious answer pops up: It's Tandy we're talking about here. ;)

And now for some reason I'm sort of stuck on pondering if you could use BASIC string packing techniques ala Leo Christopherson to do a Model I/III version of Tetris that would run fast enough even if the game engine ran on the interpreter.
 
I remember sort of wondering why Tandy didn't tweak the system to even that out a bit; you know, maybe make it so in Model 4 mode the upper and lower blocks were 3 pixels tall and the middle row 4.

Just a wild guess, but maybe the Model III and Model 4 modes share the same character generator ROM. The Model III mode would use the full 12 vertical pixel lines for each character, and the Model 4 mode would just use the first 10 pixel lines.
 
... The Model III mode would use the full 12 vertical pixel lines for each character, and the Model 4 mode would just use the first 10 pixel lines.

Of course, yeah. It's just given Tandy's rather notorious reputation for penny-pinching quite natural that they wouldn't bother tweaking it for the two different modes. ;)

I'm *pretty* sure on the I and III at least the graphics "characters" are actually generated with logic, not stored in a ROM. Checking the "theory of operations" manual confirms that's also true on the 4. One difference between the Model I and both the III and 4 is on the former character codes 192-255 return the same graphics blocks as 128-191 while the III and 4 have additional "special characters" in that space, so the III/4 only use the "hardwire" block for 64 of the possible 256 characters. Granted comparison with the I is sort of complicated by the fact the I also originally had 7 bit video RAM...

Interestingly the 4 tech manual notes that it's in principle possible to have 2 video pages of the 64x16 mode thanks to it only using half of the 2k video SRAM. I wonder if *anything* leveraged that functionality. (It's not clear to me, however, if it's possible to write to that second page if the 4 is in III mode... so you'd have to have the system set for the 4 memory map with the III's screen layout?!)
 
...
Interestingly the 4 tech manual notes that it's in principle possible to have 2 video pages of the 64x16 mode thanks to it only using half of the 2k video SRAM. I wonder if *anything* leveraged that functionality. (It's not clear to me, however, if it's possible to write to that second page if the 4 is in III mode... so you'd have to have the system set for the 4 memory map with the III's screen layout?!)

The page bit in port 84H does this. See page 6 (PDF page 10) in the m4tech.pdf available on the archive sites; the table at the bottom is the Model III Mode memory map, and the notation for addresses 3C00H-3FFFH says that the Page bit selects 1K of 2K. Note that the Page bit impacts the CPU's addressing, but not the CRTC's addressing (as far as my study of the schematic shows, that is).

As far as I know, this was most useful for using the Model III memory map with an 80x24 screen, although in principle you could run the 64x16 screen and change the CRTC starting character offset to position the display to the second 'page' of VRAM.

Wasn't there one version of MultiDOS for Model 4 that did an 80x24 screen but was Model III memory-map compatible? It would have used this functionality.

EDIT: On the subject of the screen geometry and the pixels-per-character business, it should be noted that the Model 4 used the same exact CRTC part used for the Model III high-resolution graphics board (26-1125) which drives the Model III's CRT at 640x240 pixels. Now, it's a bit of a dilemma as to which came first, 26-1125 or Project R (aka Model 4), but it's very likely that they were being developed around the same time, and that there was a desire to amortize the mask setup fee for the CRTC across something with a higher volume potential than 26-1125. Now, while the monitor might possibly have been able to do a 640x288 display, this would have definitely upped the dot clock, which was already pushing some limits as I recall.
 
Last edited:
Wasn't there one version of MultiDOS for Model 4 that did an 80x24 screen but was Model III memory-map compatible? It would have used this functionality.

You know, now that you mention it I remember reading an ad for that in an '80 Micro but I've never seen it in the flesh. I wonder how well it actually worked. (Maybe I need to get off my rear and make a floppy disk imaging station so I can try it, assuming not every copy of it was lost to history before ending up as a disk image.)

EDIT: On the subject of the screen geometry and the pixels-per-character business, it should be noted that the Model 4 used the same exact CRTC part used for the Model III high-resolution graphics board (26-1125) which drives the Model III's CRT at 640x240 pixels. Now, it's a bit of a dilemma as to which came first, 26-1125 or Project R (aka Model 4), but it's very likely that they were being developed around the same time, and that there was a desire to amortize the mask setup fee for the CRTC across something with a higher volume potential than 26-1125. Now, while the monitor might possibly have been able to do a 640x288 display, this would have definitely upped the dot clock, which was already pushing some limits as I recall.

I'd forgotten about how the 4 used that funky masked version of the CRTC instead of a plain 6845. I imagine that would at least partially rule out the possibility of writing funky demoware that abuses the CRTC ala "No Pets Allowed", wouldn't it. Darn.
 
You know, now that you mention it I remember reading an ad for that in an '80 Micro but I've never seen it in the flesh. I wonder how well it actually worked. (Maybe I need to get off my rear and make a floppy disk imaging station so I can try it, assuming not every copy of it was lost to history before ending up as a disk image.)
A couple of links for you: The TRS-80.ORG page on it: http://www.trs-80.org/multidos/ and the TRS-80.COM page for it: http://www.trs-80.com/wordpress/multidos/ There are disk images available for download from the trs-80.com pages.

I'd forgotten about how the 4 used that funky masked version of the CRTC instead of a plain 6845. I imagine that would at least partially rule out the possibility of writing funky demoware that abuses the CRTC ala "No Pets Allowed", wouldn't it. Darn.
Tandy's motivation was a bit more mundane; at least on the Model II it is possible to cause the monitor board to self-destruct with improper video timings (a real 'halt-and-catch-fire' mode!), and it might be possible on the III/4 as well. But the 80/64 mode switching is implemented with the 6835/68045's masked registers directly, using an input on the CRTC and without needing to reprogram the CRTC when you wanted to switch between modes. Using a straight 6845 is possible, but you need a bit of support for it in both the ROM and the DOS. MAD Software's XROM/XDROM products do a proper CRTC program for 6845, and LS-DOS does a proper 6845 init for 80x24 mode as far as I recall.

Using the masked parts killed two birds with one stone, so to speak, in that the danger of potentially fatal to the monitor video timings was removed and a single port bit activation of the 80/64 column switching for a fully-compatible (well, mostly compatible) Model III mode was doable.
 
While we're on the subject of Model III mode graphics issues on the Model 4, I have an issue I'm running into.

In TRSWiki, I display lo-res and hi-res images. When I run on LSDOS 5.3.1 on the Model III the images display correctly. However, when I run the same program with LSDOS 5.3.1 on the Model 4, my images get squished vertically.

attachment.php
attachment.php



If I then quit the program and run GRON it displays the hi-res image that I just displayed in TRSWiki but it is not squished! GRON, as you may know, simply turns on hi res mode and then ends.

attachment.php


I'm thinking there is some weird Model III mode screen adjusting going on when running a program, but I'm still not sure what is going on.
 

Attachments

  • IMG_1202.jpg
    IMG_1202.jpg
    97.6 KB · Views: 5
  • IMG_1201.jpg
    IMG_1201.jpg
    91.3 KB · Views: 5
  • IMG_1203.jpg
    IMG_1203.jpg
    97.1 KB · Views: 6
Back
Top