To call [Glen Kleinschmidt] a vintage computing enthusiast would be an understatement. Who else would add the ability to control and address multiple VGA monitors to a rack-mounted TRS-80 Model 1? Multiple 64-color 640×480 monitors might not be considered particularly amazing by today’s standards, but for 70s-era computing, it’s a different story.
How does a TRS-80 even manage to output anything useful to these monitors? [Glen] wrote his own low-level driver in machine code to handle that. The driver even has useful routines that are callable from within BASIC, meaning that programs written on the TRS-80 are granted powerful drawing abilities. Oh, and did we mention that the VGA graphics cards themselves were designed and made by [Glen]?
Interested in making your own? [Glen] provides all the resources you’ll need to re-create his work, including machine code drivers and demonstration BASIC programs as downloadable audio files, just as they would have been on original cassette tapes.
Watch things in action in the videos embedded below. The first draws a Land Rover, and the second plots a simple Moiré pattern star. Not bad for 70s-era hardware and 74xx logic!
This makes me think there were graphic upgrades back then. I can’t think if anything specific, but it feels like something that existed. There were lots of small 3rd party companies. Just look at issues of 80 Microcomputing when it was large.
But no VGA back then.
I recall seeing ads in Kilobaud (around 1980) for S-100 graphics cards that did something like 640×480 monochrome. Also I believe there was a TRS80 compatible called the LNW80 that had some extra graphics over the stock TRS’s 128×48 mono.
So yeah it was possible to put the pixels on the screen. The bugaboo though is finding room enough in those 64K address spaces for the frame buffer. Consider the original Mac’s 512×352 mono for example. The 6809 in the prototype had a 64K address space, and that frame buffer ate 22K, basically a third of the map. Your choices were three: 1) map it all and make do with less program RAM/ROM, 2) bank switch the frame buffer, or the program memory, or both, and take the hit on access speed, or 3) use a CPU with a legit larger address space. The latter option helped drive the Mac to the 68K.
“Consider the original Mac’s 512×352 mono for example.”
Indeed. On IBM PC platform, the popular Hercules Graphics Card did offer 720×348 resolution with the original MDA monitor. The later released Hercules InColor added 16 colours to that. Too bad there were no Macintosh emulator for x86 PCs, as there were for m68k home computers Atari ST/Amiga. The higher Hercules resolution would have been great for Macintosh applications. A hack also allowed for 640×400 resolution, if memory serves. Some games like ‘Korean Dungeon Boy’ or the Hercules BIOS (Public Domain) used it. And an early C64 emulator.
Apple’s “Star Trek” project in the early 90’s ported System 7.1 to PC hardware. https://en.wikipedia.org/wiki/Star_Trek_project
Wasn’t the Mac prototype’s resolution originally 384×256? Still needs 12KB of address space, but it’s not quite as restrictive for an 8 bit processor as nearly double that. (Although 512×352 would be easier to page in, given that its lines are aligned on 2^n-byte boundaries; if a 4KB window were used, painting a screen in strips of 512×64 wouldn’t be pleasant, but would be doable… especially if that window could be floated in increments of 4 lines.)
Something I’m surprised almost no 8-bit machine did (I think the CPC464 did, but I can’t think of any others) is put the screen RAM underneath the BASIC ROM in the address space. Sure, it’d complicate reading back from the screen – you’d probably have to use I/O or a floating window – but given that you’d mostly only write to the screen and necessarily only ever read from ROM, it seems like a neat way to get some address space back for (almost) free.
But you need to read video ram to manipulate it.
Actually that was a very common thing on the C64. Hires bitmap mode used 8000 bytes and you could place it at the same address as the 8K Basic or Kernel ROM. The VIC-II would only see the RAM at those addresses and writes to the Basic or Kernel ROM area would write to the underlying RAM. If you needed to read the bitmap data you would have to bank switch out the ROM.
You’d MOSTLY only write to the screen – except for things like, you know, scrolling.
I got inspired by Don Lancaster’s _TV Typewriter Cookbook_ and built a video outrigger for my Mod I. A few dozen 74LS parts, a couple of static RAMs (one for screen data, one for font definition – sorry, no bitmap mode, I wasn’t MADE of money). It ended up with 4K of frame buffer SHADOWING internal RAM. Reads came from the internal RAM, writes hit both internal and frame memory. That way, the timing could be more lax – and this was a sea of solderless breadboards spaghettied to the already-marginal Expansion Interface, so that was an important feature.
It worked. I wrote a driver for it that emulated a VT52, well enough to use EDT on the campus VMS systems. I used it for a year or two. Wish I’d documented it.
The Model I is out in the garage, in its original boxes. I still intend to dust it off one day and see if it still runs, or can be made to. Its 50th anniversary will come right around retirement time…
The TI99 did use Video RAM as main memory, afaik.
Every access had to get through the video processor, afaik.
Later versions of that PC did fix this bottleneck, I vaguely remember.
640X240 monochrome was from Tandy for the model III, and a number of other sources for similar resolution for both mod I and III. All of the ones I used were port mapped, so system RAM wasn’t a consideration, but speed was. There were a few tricks for the Tandy one, though, that used side effects of the Z80 port instructions.
I never used a color capable board, though I did use a model II with an AED512 using FORTRAN (Ratfor, really). I probably have the driver code (library) somewhere in a folder (manilla, in a file cabinet), though the tapes (1200ft 9track) are long gone. A lot of money back in the day, so I wiped my archive tapes and sold them to another grad student when I moved on.
There were various graphics boards available, with the main one being an official high resolution graphics board for the Model III. The Model I of course didn’t have any space inside, but there were some external boards.
http://www.trs-80.org/high-resolution-graphics-for-the-trs-80/
Some of the graphics cards of the era used a local CPU on the card to drive the graphics so the bitmap wouldn’t eat up all of the address space. A couple examples:
https://archive.org/details/biotechcgs808hardwaremanual
https://archive.org/details/MicroangeloUsersManual
If they wanted ‘highres’ graphics, they should have just bought a Crapple ][+ (last apple product I’ve owned). Saved 40 years.
What can you say about Trash-80 people? Stubborn.
I used a models 3 and 4. Spent a lot of time with a soldering iron because I couldn’t afford off the shelf. The Apple II was out of my range.
Something not mentioned is the speed of these machines. The III was 2.2MHz and the the VI was 4MHz. I would have loved a color high res kit, out of my price range. Instead, I printed results to a MX-80 dot matrix printer. A single peak surface plot written in BASIC could take a few hours. More complex with 3-4 hours, 12-24 hours.
I only knew BASIC at the time. C was available but $$$.
I owned a Model 4 with the high rez option. Can’t remember the resolution but quite a step above the character-based games. I wrote interpreted BASIC versions of the 3D waveforms as well. The library included capturing a sprite from the screen to display later. I wrote a lunar lander, where I drew a NASA lander, captured it to a sprite, and drew a random mountain over which you had to navigate. Wish I’d kept a printout of the code.
The first graphics upgrade everyone did was to add lowercase characters as the original Model 1 had only uppercase.
I had an add-on board in my Model I called “The Patch” that was the LC mod that also patched the LII ROM so that a LC driver didn’t have to be loaded. It did it all in hardware. It also debounced the keyboard, added a block cursor and did a few other things I’ve forgotten.
Hmmm… I just added lowercase to the video circuit and it just worked. No changes in the ROM needed. Maybe there were very different ROMs.
Yeah, but the lowercase already in the ROM was funky, with levitating p’s and q’s and y’s (no descenders), and lots of other weird stuff. I did the piggyback-chip mod, too.
The C64 lower case had those horrible floaty-looking g j p q y chars due to using an 8×8 pixel character cell, but I thought the TRS80 had an 8×12 character cell. Certainly it had 12 scan lines per row .. but .. if you only had an 8-line character ROM it’d only take a couple of gates to feed 0s into the pixel shifter to blank out the extra four scan lines.
Another mod I did was to replace the character generator ROM with an aftermarket that had the LC descenders. Amazing how many mods got stuffed inside my MI keyboard.
The 64×16 character display took 1024 addresses (3c00-3cff), and was implemented with seven 2102 RAM chips. Apparently it was a cost/space savings thing to omit data but 6 and leave out the 8th chip, but stuck the machine with no lower case. IIRC it was pretty easy to piggy back another 2102 onto one of the existing ones, if you bent up the pin/s for the data line and white-wired it to the D6 somewhere on the main board. That’d give you 128 more glyphs from the character ROM.
There were official monochrome high resolution graphics add ons for the model III, IV, 4P and the 2/12/16/6000. I don’t think any of them broke six 40 x 4 80.
The model 2000 was remarkable in its day because it had 12bit graphics at fairly high resolution long before the PC did. supported digital research GEM, an early window based GUI
SepTandy!
Converted the Maurer Rose to run on CP/M:MBASIC after seeing this. Just the kind of interesting fun I was looking for. Thanks and great project!