Simple, generic 80x24(25) display card

[cj7hawk]

I'm also thinking of ways to use the card and not have it consume system memory space.....

That's a good idea, but once you do that, you're basically doing it all from scratch anyway since you'll need to adapt the circuit.

Let me know if you would like to reuse any of my video circuitry - The offers always on the table -

I also found a whole lot of S100 video card manuals with schematics, some of which have even simpler schematics - eg, the Poly_VTI.
You can find them here: https://z88dk.org/forum/viewtopic.php?t=11458

They are at the end of the post. You might also find their architectures interesting.

I'm also still looking for a Matrox ALT2480 manual or details on it's architecture if you ever come across one -

David

 

[wperko]

Hi,

I'm looking to trade a "XITEX Dallas SCT-100 Composite Video + Original Manual (UnTested)" board for another S-100 board I might use or shift into my trade pile.



I want to trade or sell these boards and other stuff;
ADS PROM Blasters (UnTested)
IMSAI RAM-4A Rev2 Static RAM (Needs help)
Jade Computer Products Serial/Parallel Interrupt board (UnTested)
MITS 88-S4K (Bare Board)
XITEX Dallas SCT-100 Composite Video + Original Manual (UnTested)
CompuPro Interfacer II (UnTested)
TeleTek SBC-1 Z80 CPU Manual (UnTested)
Blank DAZZLER II boards (Bare Board)
SSM 4K Static RAM board (UnTested)


I'm looking for:
MITS Altair 88-MU1 Systhesizer Board
Morrow Thinker toys Disk Jockey II


.

 

[Hugo Holden]

I have a perfectly good working spare Processor Technology VDM-1 board and manual. I could put it up on ebay if there was any interest. THe VDM-1 was one of the most simple and easy to understand S-100 video boards.

 

[MykeLawson]

I've been doing more thinking on the video card part of the equation. The Flashwriter II is an 80 x 24 display board and the memory requires 11 address bits (A0 - A10). If I used an 8 bit latch for the column address bits (bits A0 - A6) and a 4 bit latch for the row address bits (A7 - A10), then I could effectively make an I/O mapped video card. No system memory would be needed. Cursor movement would be easy, subtract one from the row and move the cursor up, add on and cursor down. Likewise on moving the cursor left and right. If the column address gets to 80h, then reset it to 0 and add one to the row address..... A concept I'm going to do some more thinking on....

 

[Eudimorphodon]

Cursor movement would be easy, subtract one from the row and move the cursor up, add on and cursor down. Likewise on moving the cursor left and right. If the column address gets to 80h, then reset it to 0 and add one to the row address..... A concept I'm going to do some more thinking on....

Doesn't this result in a 128 character wide display, not 80 characters? I mean, it's not the end of the world if you want to structure it like that, but unless you either make it display 128 characters across or add a scroll register to move an 80 character window across the line you'll be wasting 48 bytes a line. That's effectively going to mean you'll need at least 3K of memory to do a (virtual) 128x24 display, not 2K. Although...

If I used an 8 bit latch for the column address bits (bits A0 - A6) and a 4 bit latch for the row address bits (A7 - A10)

4 bits for the address latch will only give you 16 lines of characters if the intent is that updating this latch will move the character up and down a line. You'll need a 5th bit to get your 24 lines. (Well, it'll have room for 32 lines, so you might as well use 4K of RAM for a virtual 128x32 display. FWIW, that's what the Osborne 1 had, although its was memory mapped between the 60-64K memory mark.)

You could just scrap the idea of not having to do somewhat more complicated math to figure out cursor position and linearly address 2K of memory with 11 bits of latch space distributed however you want, but I will chuck out there that using 128 bytes of memory to represent an 80 character line *does* actually simplify the address generation circuitry on the video output side a bit, so if you don't mind wasting the extra memory that's a plus.

Note of course that this is going to be a pretty inefficient thing to update compared to a memory-mapped solution because if you just use dumb latches you'll need to do two separate OUT's for every character written, one for the character itself and another to move the latch to the next character. As an optimization, instead of the latch for the line address you could use a pair of programmable 4-bit counters (74LS161 or similar). This would let you set where in the line you want an update to start with a single OUT, and then you just set up the data port so a read or write to it clocks this counter with every write. This would let you read or update a whole line of characters using a single Z80 I/O string command.

 

[Eudimorphodon]

(... per the above, I guess there are really gross ways you could get your 80x24 display addressed with 7-bit and 5-bit latches to fit in 2K, but you'd essentially have to do address translation for both the latch values and the video address circuitry. You can do this with adders and non-obvious bit-shuffling trickery, if you've ever looked at how the memory map for the Apple II's text display is set up this is why there are "memory holes" mixed into the text buffer, but with SRAM being dirt cheap there's really no reason to go there.)

 

[Hugo Holden]

I have attached a video system that was published as part 5 of an article series in Wireless World in 1978.

A few things I like about it (apart from being able to understand it reasonably well, like the VDM-1 or PT's video system in the SOL-20) it uses the MCM6576p character generator ROM and 8 x 2102 Video RAM IC's, and an assortment of TTL logic, so I could make this one just with the parts I already have in my stocks.

Its counter chain provides a 1, 2 or 4 MHz output for a CPU clock pulse and a clock for a UART.

The video output where the syncs and video are mixed requires an 82 Ohm resistor to ground. This output was Optionally fed into an RF modulator so that a typical TV could be used too.

As noted in the text, in this design the video is blanked during CPU access. And the memory behaves to the CPU as normal memory. There is more info in the article, so its worth a read.

This system though struck me a as a good possibility, to add to an existing computer to create video (and not nearly as complex as the RM-65 video card, which gifts video to an AIM-65). Before I found the RM-65 I was going to make this and attempt to interface it with an AIM-65.

Still, it would need monitor software for scrolling. I don't have the other parts of the article series and I'm not sure if they published their monitor software that was held in ROM.

It certainly would make for a good "period correct" design. I have been restoring vintage things like radios & TV's since the 1970's, I have always tried to make the restorations period correct and if I add parts or circuitry to a design, I try to use parts that were available at the time. Otherwise it makes me feel like I am putting a Datsun Bluebird engine into a model T Ford. It is just me I guess, and a lot of enthusiasts like to mix the modern and old and have no concerns about it which is fine too.

Another interesting video card, aside from the VDM-1, for S-100 is the Matrox ALTR 2480. It was designed to companion up with the ALT256 or ALT512 graphics cards, but can be used on its own, it has a very elaborate and well documented driver routine and made to drop into S-100 computers. The date codes on the IC's on my one (in the attached photo) suggest it was made in 1979.

 

[cj7hawk]

Note of course that this is going to be a pretty inefficient thing to update compared to a memory-mapped solution because if you just use dumb latches you'll need to do two separate OUT's for every character written, one for the character itself and another to move the latch to the next character.

Two out's is not a very high overhead for I/O mapped video - the BIOS calls would be the biggest delay per-character.

Also, he could carry the line position in B, and use out(c),A to hold the horizontal position in the upper address lines and the character value in the data lines. Then it's a single OUT on z80. Though I guess that would go against S100 bus objectives of compatability.

 

[cj7hawk]

I have attached a video system that was published as part 5 of an article series in Wireless World in 1978.

A few things I like about it (apart from being able to understand it reasonably well, like the VDM-1 or PT's video system in the SOL-20) it uses the MCM6576p character generator ROM and 8 x 2102 Video RAM IC's, and an assortment of TTL logic, so I could make this one just with the parts I already have in my stocks.

In your stocks? It sounds like you have a pretty cool set of stock. Thanks for posting the pictures.

Also thanl you for some of the articles and information you previously posted online on the Matrox series - It helped me out a lot when I was designing my own video card a few months back - I went for 256x192 and 512x192 and ended up making a card very similar to the Matrox series in which the pixel position was sent to two latches before the pixel was read or written. Though I was actually making it for a microcontroller to have a video display and just assembled it on a single sided PCB with 5 GALs and an 80's era 64k x 1 Static RAM.

 

[Hugo Holden]

In your stocks? It sounds like you have a pretty cool set of stock. Thanks for posting the pictures.

Also thanl you for some of the articles and information you previously posted online on the Matrox series - It helped me out a lot when I was designing my own video card a few months back - I went for 256x192 and 512x192 and ended up making a card very similar to the Matrox series in which the pixel position was sent to two latches before the pixel was read or written. Though I was actually making it for a microcontroller to have a video display and just assembled it on a single sided PCB with 5 GALs and an 80's era 64k x 1 Static RAM.

No worries, glad they helped.

My stocks are all very vintage parts. Which help, because most of the time when an IC dies in one of my vintage computers I have the spare right there.

One thing that appeared to me to be logical, with a graphics board at least (though I'm not sure about the timing overhead) is have the graphics memory behave as general computer memory when the card was not activated. Although it creates a duplicate memory over that range (if you already had it), making the existing general RAM there redundant, it seems like a good way to do it from the point of view of the card's internal circuitry. The Spectrum color graphics board does this I think. So essentially it gave the customer another bang for their buck as they got a general memory card and a graphics card all at once. On the other hand the Dazzler is not like this and hijacks existing memory space with DMA. There were so many IC's on the Dazzler board set, I guess they could not accommodate memory IC's as well and it would have needed a third board.

One other thing though, if the graphics information is in memory IC's on the graphic's board itself, ideally you need away to extract that and save to a file or general memory. Oddly, this was not possible with the Matrox ALT256, it was locked in there, only extracted by the parallel to serial shift register to make a composite video signal, so if you wanted a copy of it, you would have to send it (the graphics data) to general RAM at the same time it was created. They fixed this in the ALT512 and you can read the data back out of the video RAM card to elsewhere. Mind you, the ALT256 was one of the world's very first S-100 video graphics cards and they had not thought of everything then. Kind of adds to its charm. Also it didn't have a software method (via a simple XOR gate activation) to invert the video. So, if you wanted inverted video of a graphics image, you had to invert the whole image file.

 

[Eudimorphodon]

Though I guess that would go against S100 bus objectives of compatability.

Yes, playing games with the high address lines for I/O is likely a deal breaker for S100, or a lot of other Z80 computers with conventional decoding layouts...

Two out's is not a very high overhead for I/O mapped video - the BIOS calls would be the biggest delay per-character.

I mean, I guess it depends on how you're intending to use it. CP/M's BDOS function 9 takes a string, not a character at a time, so it would theoretically be an optimization (albeit an unnecessary one if you're comparing to serial I/O) to be able to do block moves, but... since this a "dumb" buffer you're probably going to need to run any string I/O through your terminal/ascii control code emulator before outputting it anyway. So I suppose being able to use the string functions would only really be useful for high-speed character graphics or whatever. (IE, literal "screen dumps".)

I have attached a video system that was published as part 5 of an article series in Wireless World in 1978.

FWIW, this appears to be the video system used by the NASCOM-1 computer. (See a bunch of manuals and full schematics for the computer at the NASCOM home page.) This is an interesting design because it's basically a "dumbed down" TRS-80.

The TRS-80 has a 64x16 video display in 1K of memory *and it fits all 1K on the screen* because the horizontal timing counting chain is based on dividing the pixel clock into lines around 112 characters long with the horizontal margins and hsync pulse happening in the "7'th bit" area of the count, IE, not actually addressing the RAM, and using circuitry to reset the counters back to zero at this "odd" number. In other words, there are extra moving parts in order to "frame" all the memory into just the active area of the screen...

By contrast, the NASCOM display as depicted here is set up in the 64x16 memory grid, but it only displays 48x16 characters, "wasting" 16 characters per line, because it uses a slower pixel clock that divides the *entire horizontal line* into 64 positions, with some of the memory locations corresponding with the blanked margins and the hsync pulse area. That saves parts (you don't need to watch the video addresses and reset the counters at odd numbers, you can just let the h-count roll over) but, yeah, it wastes a quarter of the RAM and results in a kind of weird video memory map with holes in it.
This is actually related to what I meant when I said that using 128 bytes of memory to hold your 80 character lines could simplify your video memory addressing somewhat; if you want to "tightly pack" 80 character lines, which of course are not an even power of two wide, into a memory array, then you essentially need to implement a binary adder to walk through RAM in these 80 character chunks. If you don't mind wasting that RAM then, well, I think you could actually copy the "just let it roll over" horizontal counter idea of the NASCOM and just do it with a 7 bit counter instead of six bit. Doing some quick math... if you're using either NTSC or PAL (doesn't really matter, they have similar line rates) a 12mhz clock will work for 6 bit wide characters, you'll need a 16mhz pixel clock for 8 bit. (You would have to modify this counter chain somewhat to use 6 bit wide characters, though.)

Anyway, yeah, there are other wrinkles here; if you want more than 16 lines then there's some other changes that have to happen to this timing chain, and unless you modify how the hsync is generated you'll also inherit the gross memory map where your lines are going to need to start 12 or 16 characters from the start of each "line", but, eh, if you want to do completely discrete video in the fewest number of parts this is certainly an idea.

 

[Hugo Holden]

FWIW, this appears to be the video system used by the NASCOM-1 computer. (See a bunch of manuals and full schematics for the computer at the NASCOM home page.) This is an interesting design because it's basically a "dumbed down" TRS-80.

It says "NASCO" on the document, so it is likely the same company. I had never seen the circuit before, never had a TRS-80.

Speaking of the TRS-80 though, it turns out that one of their versions used a power supply (wall wart) that was essentially the same as the difficult to get one for the Votrax Type 'N talk, it also has the DIN connector, but I think that needs to be re-wired to suit the TNT, but otherwise it is electrically compatible.

 

[MykeLawson]

Doesn't this result in a 128 character wide display, not 80 characters? I mean, it's not the end of the world if you want to structure it like that, but unless you either make it display 128 characters across or add a scroll register to move an 80 character window across the line you'll be wasting 48 bytes a line. That's effectively going to mean you'll need at least 3K of memory to do a (virtual) 128x24 display, not 2K. Although...



4 bits for the address latch will only give you 16 lines of characters if the intent is that updating this latch will move the character up and down a line. You'll need a 5th bit to get your 24 lines. (Well, it'll have room for 32 lines, so you might as well use 4K of RAM for a virtual 128x32 display. FWIW, that's what the Osborne 1 had, although its was memory mapped between the 60-64K memory mark.)

You could just scrap the idea of not having to do somewhat more complicated math to figure out cursor position and linearly address 2K of memory with 11 bits of latch space distributed however you want, but I will chuck out there that using 128 bytes of memory to represent an 80 character line *does* actually simplify the address generation circuitry on the video output side a bit, so if you don't mind wasting the extra memory that's a plus.

Note of course that this is going to be a pretty inefficient thing to update compared to a memory-mapped solution because if you just use dumb latches you'll need to do two separate OUT's for every character written, one for the character itself and another to move the latch to the next character. As an optimization, instead of the latch for the line address you could use a pair of programmable 4-bit counters (74LS161 or similar). This would let you set where in the line you want an update to start with a single OUT, and then you just set up the data port so a read or write to it clocks this counter with every write. This would let you read or update a whole line of characters using a single Z80 I/O string command.

Yes, you are correct. A counter that is capable of counting from 000 to 7FFh would work, since column 0, row 0, is also address 000. To move right or left, just add or subtract 1. to move up or down, subtract or add 50h. And every write to memory would cause the counter to count up by one. Still workable. Have to make sure that the left arrow key decrements the counter, and the backspace deletes the character and does a decrement. Probably by a count of 2 since writing the character will increment the counter by 1.... A bit convoluted, but workable, and easy enough to handle in hardware. Still, and interesting project.

 

[MykeLawson]

I have attached a video system that was published as part 5 of an article series in Wireless World in 1978.

A few things I like about it (apart from being able to understand it reasonably well, like the VDM-1 or PT's video system in the SOL-20) it uses the MCM6576p character generator ROM and 8 x 2102 Video RAM IC's, and an assortment of TTL logic, so I could make this one just with the parts I already have in my stocks.

Its counter chain provides a 1, 2 or 4 MHz output for a CPU clock pulse and a clock for a UART.

The video output where the syncs and video are mixed requires an 82 Ohm resistor to ground. This output was Optionally fed into an RF modulator so that a typical TV could be used too.

As noted in the text, in this design the video is blanked during CPU access. And the memory behaves to the CPU as normal memory. There is more info in the article, so its worth a read.

This system though struck me a as a good possibility, to add to an existing computer to create video (and not nearly as complex as the RM-65 video card, which gifts video to an AIM-65). Before I found the RM-65 I was going to make this and attempt to interface it with an AIM-65.

Still, it would need monitor software for scrolling. I don't have the other parts of the article series and I'm not sure if they published their monitor software that was held in ROM.

It certainly would make for a good "period correct" design. I have been restoring vintage things like radios & TV's since the 1970's, I have always tried to make the restorations period correct and if I add parts or circuitry to a design, I try to use parts that were available at the time. Otherwise it makes me feel like I am putting a Datsun Bluebird engine into a model T Ford. It is just me I guess, and a lot of enthusiasts like to mix the modern and old and have no concerns about it which is fine too.

Another interesting video card, aside from the VDM-1, for S-100 is the Matrox ALTR 2480. It was designed to companion up with the ALT256 or ALT512 graphics cards, but can be used on its own, it has a very elaborate and well documented driver routine and made to drop into S-100 computers. The date codes on the IC's on my one (in the attached photo) suggest it was made in 1979.

The Matrox ALTR-2480 would have been a good candidate, but I don't have the code to burn into the EPROM (I'm going to use a 2Kx8 NVRAM chip - maybe) and the documentation I have is barely legible. So, for the time being I'm going to stick with the Vector Flashwriter II.

 

[Eudimorphodon]

It says "NASCO" on the document, so it is likely the same company

It’s definitely the same thing; the construction manual for the NASCOM-1 has (almost) the same text as the magazine article in the theory of operations portion, and the schematic diagram is also the same, other than *not* having the part that allows the computer to read the memory as well as write it condensed out.

 

[Hugo Holden]

The Matrox ALTR-2480 would have been a good candidate, but I don't have the code to burn into the EPROM (I'm going to use a 2Kx8 NVRAM chip - maybe) and the documentation I have is barely legible. So, for the time being I'm going to stick with the Vector Flashwriter II.

I noticed that a lot of early computer cards get separated from their original paperwork. I got the original factory papers both for the ALTR2480 and the ALT256, especially because the online .pdf copies were very poor (missing pages too) typical of what I call the lazy scan effect, and I always insist on original manual & paperwork, because I hate online .pdf's. But admit they are better than nothing.

If I find a good .pdf manual though, and don't have the factory original, I take it to the printers and have it properly bound. Over many years of servicing boards, I like to have the real paper manual in my lap, not on a VDU. I have a large library with all the manuals for most things I own including Tek scopes, generators etc and would not have it any other way.

Recently I sold a Tek scope and I supplied the large manual, with double & triple sized fold out schematic pages, beautiful. The buyer said, don't bother sending the manual, I can get it online ! I said you can't be serious.

Many years ago I was given some sage advice : " Never get into bed with any piece of equipment, without the manual"

 

[cj7hawk]

Many years ago I was given some sage advice : " Never get into bed with any piece of equipment, without the manual"

This caused me problems with my wife. Fortunately she was user friendly and intuitive.

 

[Hugo Holden]

This caused me problems with my wife. Fortunately she was user friendly and intuitive.

Lucky you!

 

[Plasmo]

I've been doing more thinking on the video card part of the equation. The Flashwriter II is an 80 x 24 display board and the memory requires 11 address bits (A0 - A10). If I used an 8 bit latch for the column address bits (bits A0 - A6) and a 4 bit latch for the row address bits (A7 - A10), then I could effectively make an I/O mapped video card. No system memory would be needed. Cursor movement would be easy, subtract one from the row and move the cursor up, add on and cursor down. Likewise on moving the cursor left and right. If the column address gets to 80h, then reset it to 0 and add one to the row address..... A concept I'm going to do some more thinking on....

I used a scheme of 64 characters per row and 48 rows to pack into 3K of video memory. The last 1K is font tables of 128 characters with 8x8 pixels per character. It all fit in an economical 4K dual port RAM. The addressing is done using Z80’s extended IO addressing of “OUT (C),A” which access 64K IO addresses as pointed by registers BC. I also have hardware scroll to move text 1-47 lines in hardware, but software still need to fill lines vacated by the hardware scrolling. Because of dual port RAM, the video memory can be updated any time without screen ‘snow’.
Bill

 

[Eudimorphodon]

Have to make sure that the left arrow key decrements the counter, and the backspace deletes the character and does a decrement. Probably by a count of 2 since writing the character will increment the counter by 1.... A bit convoluted, but workable, and easy enough to handle in hardware. Still, and interesting project.

Per @cj7hawk's feedback, I think I'm convinced that the auto-increment is a waste of time. Assuming you're planning on using this primarily for character/TTY interaction with CP/M or whatever having to do an extra OUT (or two, if the line position needs to be updated) per character isn't the end of the world, because you're going to want to be stuffing every string through a "terminal emulation" layer anyway. (That's going to be doing things like processing character returns and cursor positioning codes.) In the grand scheme of things those additional OUTs aren't going to matter much, you're going to be spending more time looking for control codes than the actual write is going to take. Auto-increment would only really help even up the speed difference with a memory-mapped framebuffer in the case of block moves/fills. (I mean, it could speed up scrolling and clearing the screen significantly, but probably not really *noticeably*.)

One thing I guess needed to be asked: if you want a TTY that's accessed via port I/O, are you sure you're not going to be happier with a full terminal? Is the concern you have is you don't want to lose the 2K (or whatever) of memory space for the video card? One possible workaround for that might be to add an I/O latch that would instruct the card to pull or not pull the *PHANTOM line when the framebuffer memory is accessed; this would essentially let you "page out" the video buffer when you don't want it in the memory map.

I took a look at the Flashwriter II schematics, and FWIW, if you really wanted to get rid of that ROM that shuffles the video address counter outputs to handle the 80 column screen and do it with discrete hardware there are examples how to hardwire this sort of thing floating around out there. For instance, the 40 column PET (the ones with "hardwired" video pre-dating the CRTC-equipped ones) demonstrates a way to do it. TL;DR, it essentially breaks display memory into 8 byte pages that are incremented directly and "recirculates" the higher address bits through a latch that preloads the counters at the start of the active area of each line. For an 80 column screen you could duplicate this *almost* exactly; just move the addressing over 1 bit to use 16 byte pages. (*)

(* Just to clarify this, this technique relies on finding the highest power of 2 you can divide your number of characters per line into with no remainder. IE, 40/8 (three bits) = 5, 80/16 (four bits) = 5. The ROM programming on the Flashwriter II's control ROM would have essentially been hardcoding this (IE, "if you're at this row of dots you should increment through these addressess") instead of "dynamically" getting it at the last dot row of each line of characters and latching that to be recycled for the next 8 lines of character dots.

And this is why 64x16 was briefly super common for memory mapped video systems instead of 40/80x25; not only does it not waste any memory, fitting perfectly in 1K, being a power of 2 wide gets rid of the need to do these mickey mouse things. Just need a six bit counter for the active area of each line and a separate counter to increment for each row of characters for the higher address bits. Easy peasy.)