• Please review our updated Terms and Rules here

Simple, generic 80x24(25) display card

Eudi said:

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.


It is an interesting recirculating circuit, even impressive drawn on paper because it is a loop. In these cases it is a good thing that gates, flip flops etc have a data transmission delay, so the input data stays stable enough to be used, before it changes to a new value later after a change in state.

Though data latches help, and if a two phase clock is used, breaks up what amounts to read and write states into separate temporal events.

One of the more simple examples of a logic loop like this, is the D type flip flop, to get it to toggle you can connect its /Q output into its D input and usually, the data at the D input stays stable long enough for it to toggle reliably on each clock pulse. One way you can make it ignore multiple transitions on a clock signal (say from a poorly de-bounced switch) is to put an RC delay (or a logic gate delay) in the /Q to D link. Still, making a toggling flip flop this way is not nearly as reliable as using a JK flip flop with both J&K held high. The D flip flop wired to toggle with this short loop can sometimes give trouble near the high frequency end of the logic family's operating range.
 
Last edited:
and as many times as someone has brought up using a microprocessor in this thread
HE DOESN'T WANT TO DO THAT
so give it a rest, eh?
 
and as many times as someone has brought up using a microprocessor in this thread
HE DOESN'T WANT TO DO THAT
so give it a rest, eh?
yep, and no programmable logic, either. Although a second Z80 overclocked to 25.175Mhz beam racing the VGA maybe acceptable. Good thing S100 is a big pc board.
 
yep, and no programmable logic, either. Although a second Z80 overclocked to 25.175Mhz beam racing the VGA maybe acceptable. Good thing S100 is a big pc board.

You know, a 6502 clocked at around 2mhz (for NTSC/PAL, probably double that for VGA) wouldn’t make a terrible address generator counter if you could tinker up a way to feed it a jump to the start of desired line + 80 NOPs…
 
FWIW, those dirt cheap TL866 programmers from China can program GALs, and GALs can emulate most of the older PALs... but of course if you don't have the equations that's still an issue.

I think Myke would figure out the equations in about 2 minutes once he sat down with some example .PAL files and began writing his own.... They only really start to get complex once you create counters or tristate outputs and begin using feedback in both states. I think that would take him a few hours to figure out at most. He has a pretty good handle on glue logic.

I've been working on my own design for a memory mapped video card that uses all modern parts and should be reasonably easy to adapt to S-100, but it's still stuck in the "working model on a breadboard" stage so I don't suppose that's much help.

It is definitely worth clarifying what's desired here; if all you want is "terminal-like" text only video the single-chip MCU solutions like @Chuck(G) brings up are a dime a dozen, and should do the job perfectly well for CP/M. The design I was working on is specifically aimed at emulating early memory-mapped video systems like the Polymorphic Systems VTI or the TRS-80's built-in video because they were used for some of the first "computer games" and crude graphics, but this kind of design doesn't really offer much in the way of advantages for purely text applications. Back in the 1970's a memory-mapped system actually saved parts compared to a "full terminal", but with most modern MCUs able to emulate a VT-100 or better with one hand tied behind their backs it seems pretty tempting to go with that if running Wordstar is your priority.

Given Myke specifically hand wires his cards with wirewrap, I doubt that would be an issue at all - but the key element here is he doesn't want a video card ( I've even offered him mine ) - He is doing this as a project with the specific intent to figure it out himself and build it from scratch and work out what is and isn't working and only seek help where necessary. I actually really like reading his posts too because he started doing this at the same time as I did.

It's a bit like a crossword puzzle I think. He's stuck at times, but he figures it out himself rather than handing it around for others to complete.

It took a while but his ramdisk got finished. :)
 
You know, a 6502 clocked at around 2mhz (for NTSC/PAL, probably double that for VGA) wouldn’t make a terrible address generator counter if you could tinker up a way to feed it a jump to the start of desired line + 80 NOPs…
Last he posted, I think he had the timing counters down OK and was just working to figure out how to deal with the missing bipolar PROM which was doing the address counter translation, and is a pretty clever way to do it, but if he's just wasting the extra bytes and expanding the RAM I think he's decided to tackle that one differently.

I'd hazard a guess his video card will be working this side of Christmas :)
 
I think Myke would figure out the equations in about 2 minutes once he sat down with some example .PAL files and began writing his own.... They only really start to get complex once you create counters or tristate outputs and begin using feedback in both states. I think that would take him a few hours to figure out at most. He has a pretty good handle on glue logic.



Given Myke specifically hand wires his cards with wirewrap, I doubt that would be an issue at all - but the key element here is he doesn't want a video card ( I've even offered him mine ) - He is doing this as a project with the specific intent to figure it out himself and build it from scratch and work out what is and isn't working and only seek help where necessary. I actually really like reading his posts too because he started doing this at the same time as I did.

It's a bit like a crossword puzzle I think. He's stuck at times, but he figures it out himself rather than handing it around for others to complete.

It took a while but his ramdisk got finished. :)
Thank you. Yep, I'm trying to keep the 'vintage' feel to this. Plus I have bins upon bins of DIP ICs, as in thousands of chips, to use up. For me, this isn't about getting something up and running in the end, it is about the journey of learning and experimenting. After all, I have zero idea what in the world I will use this stuff for when I am done. Sure can't browse the internet, or handle email, or spreadsheets, or CAD work...... It is think, learn, do.... rinse & repeat....
 
Last he posted, I think he had the timing counters down OK and was just working to figure out how to deal with the missing bipolar PROM which was doing the address counter translation, and is a pretty clever way to do it, but if he's just wasting the extra bytes and expanding the RAM I think he's decided to tackle that one differently.

I'd hazard a guess his video card will be working this side of Christmas :)
Well, by Christmas may be getting a bit ahead of things. I still have to finish the code for the fileserver suite so my two Z-80 CP/M machines can communicate and save/load files from my PS/2 running DOS. Then finish up the conversion of the Osborne keyboard kit I bought from one of our members, to be a parallel ASCII keyboard, retro style. Then finish the wiring of the CPU card for the S-100. Wire up an S-100 serial & parallel I/O card using the design we all worked out for my current STD bussed CP/M machine. And then the CF/IDE card storage S-100 board so I can run CP/M on it. And lastly, the video card.

I did some noodling around in the CP/M and CBIOS code last night trying to see how I could add a printer driver into it, and maybe a video driver as well. More on that later. BTW, I found someone that burned me the stuff I need for that Flashwriter II, (http://eprompro.com/). Acceptable price, and good service. So.....
 
Last he posted, I think he had the timing counters down OK and was just working to figure out how to deal with the missing bipolar PROM which was doing the address counter translation, and is a pretty clever way to do it, but if he's just wasting the extra bytes and expanding the RAM I think he's decided to tackle that one differently

The 6502 comment was mostly a joke, but strictly speaking video solutions using microprocessors like that to cut chip count did exist. The Sinclair ZX-80/81 are well known for basically using the main Z80 CPU as the video address generator, and there’s an article floating around by Don Lancaster (of TV Typewriter fame) from 1977 or so describing a system using a 6502. It seems like the conversation had kind of wandered into techniques for minimizing chip count with technology that was around in the late 1970’s (IE, like the NASCOM design that throws 1/4th of its memory away to save chip count), so when it was reiterated that “mcus” and “programmable logic” were on the ”no” list for being “too modern”, well, you’d be surprised. I mean, strictly speaking that address prom on the Flashwriter II is ”programmable logic”, as I pointed out with the PET schematic you can do the same thing with TTL. What’s kind of impressive about the PET is its solution with the recirculating latch has a similar parts count.

Anyway, I don’t think there’s been any decision about expanding the ram or wasting part of it? What I gather is the intention is still to mostly build a design like the Flashwriter II but now apparently to add latches to make it I/O driven?

I think Myke would figure out the equations in about 2 minutes once he sat down with some example .PAL files and began writing his own.... They only really start to get complex once you create counters or tristate outputs and begin using feedback in both states. I think that would take him a few hours to figure out at most. He has a pretty good handle on glue logic.

I got the impression that the sheer complexity of the card in question was the main deal breaker. (it’s a card designed to emulate CGA, and CGA is gross; it has weird clocking to fetch two bytes per character without interleaved RAM, essentially three different pixel output chains in parallel to handle its various graphics and text modes, etc.) I wouldn’t be particularly enthusiastic about trying to reverse engineer a GAL CGA card, because it likely *will* be doing a lot of black magic, not just using the GALs for “glue”.

That said, it did seem like that decision essentially ruled out using a CRTC, which… I dunno, maybe a mistake if this was actually a fully from scratch exercise? You can make a plain monochrome text-only card *much* simpler than CGA. @MykeLawson seems to have settled back on the Flashwriter II because a few posts back it sounds like he got a lead on maybe getting the original PROM contents? But the cool thing about a CRTC is it eliminates having to deal with a lot of Mickey Mouse bits welded onto your counter chain to handle the non-power-of-two counts necessary for 80 column displays, the number of columns can be completely arbitrary. It’s also useful because if you want to tweak sync or position you can do it with a port write. It’s certainly not a “one stop shop” like some later video chips, you still need to build the memory arbitration system and pixel output chain yourself, but it takes care a lot of the brain-breakers that also tend to result in rapidly ballooning parts count with fully discrete designs.

(That’s why my project uses an MCU to *emulate* a CRTC; I specifically didn’t want to use out-of-production parts and I explicitly want to be able to handle a ton of different video modes and memory layouts and switch between them arbitrarily… while still keeping it old-school memory mapped to the host CPU, not spinning it off into essentially a “graphics terminal”.)

Anyway, the only reason I chucked out that comment about “are you sure you don’t want a terminal” a few posts back is because moving to I/O addressing *kinda* feels to me like it’s wasting the advantage of having a bus-connected video buffer? (I still think using PHANTOM might be a better idea.) Having direct fast access to the framebuffer is what enabled the first generation of computer graphics and games on cards like the Poly VTI, and I guess I kind of feel like doing stuff like that is the reason to bother building an S100 “video card”, but, yeah, different strokes for different folks!
 
I recently hooked up a Tamarack 8 bit ISA Hercules Graphic Card to my Microprofessor 1 Plus just for fun. Used a GAL 16V8 to generate the necessary ISA bus signals and a LS123 to delay and drive the /WAIT line of the Z80. Works quite nice but ofcourse it does not generate VGA, I use a Qtek MDA CRT monitor with it.
 

Attachments

  • MPF1_HGC_text.jpg
    MPF1_HGC_text.jpg
    94.8 KB · Views: 9
  • MPF1P_HGC_text.jpg
    MPF1P_HGC_text.jpg
    166.9 KB · Views: 9
  • MPF1P_HGC_setup.png
    MPF1P_HGC_setup.png
    991.3 KB · Views: 8
Well, I happened to be digging around yesterday and came across the manual for the SD Sales VDB-8024. This board may be closer to what I am looking at. It uses a single I/O port and has an on-board Z-80 to handle all of the cursor movements. And the manual has the complete code listing and code for the character generator. So, this one may be a bit more promising. I will have to re-do the schematic to make it legible and change the addressing a bit to fit my system. And of course a bit of code tweaking. But hey, that's what make this hobby fun and exciting.
 
I recently hooked up a Tamarack 8 bit ISA Hercules Graphic Card to my Microprofessor 1 Plus just for fun. Used a GAL 16V8 to generate the necessary ISA bus signals and a LS123 to delay and drive the /WAIT line of the Z80. Works quite nice but ofcourse it does not generate VGA, I use a Qtek MDA CRT monitor with it.


What code does a Hercules Card need to run it? I assume there's some registers to set up and the graphics modes would need to be switched into? I've never actually worked with a hercules card before. By the time I could afford to move up from CGA, VGA was inexpensive.
 
What code does a Hercules Card need to run it? I assume there's some registers to set up and the graphics modes would need to be switched into? I've never actually worked with a hercules card before. By the time I could afford to move up from CGA, VGA was inexpensive.
Not much: a couple of 6845 registers need to be set up, just like a MDA card (in fact exactly like an MDA card) and you can trigger some extra functions through specific IO ports to enable the graphic functions and RAM pages. After setup the card shows up as 4 k of video ram space with a 80x25 layout. In 'Hercules' mode the card enables up to 64k Byte of ram.
I squeezed in the 32 kByte page into the Microprofessor memory map at $4000 to $BFFF (roms are at $0000-$3fff). Since the ISA bus has a limited 10 bit IO space I used the pseudo 16 bit IO port functions of the Z80: presetting BC to the full port address and using IN A,(C) and OUT (C),A to get access to the $3B0-$3BF IO addresses of the HGC card.

I used this as a programming guide:

https://www.manualslib.com/manual/1637834/Hercules-Computer-Technology-Gb-100.html

Below an example of the initialization code for text mode:

Code:
text_table:
    db  61h     ; 00 total characters per row including sync minus 1
    db  50h     ; 01 number of visible characters per row
    db  52h     ; 02 position of first character during sync minus 1
    db  0fh     ; 03 number of characters during sync per row minus 1
    db  19h     ; 04 number of rows minus 1
    db  06h     ; 05 number of scans (row fractions) in addition to total number of rows
    db  19h     ; 06 number of visible rows
    db  18h     ; 07 row number to begin retrace minus 1 (modified for missing top line)
    db  02h     ; 08 set to 2, see datasheet 6845
    db  0dh     ; 09 number of scans per row minus 1
    db  0bh     ; 0A first scan where the cursor will overlay character
    db  0ch     ; 0B last scan where the cursor will overlay the character
    db  00h     ; 0C set to 0, see datasheet 6845
    db  00h     ; 0D set to 0, see datasheet 6845
    db  00h     ; 0E cursor offset H
    db  00h     ; 0F cursor offset L
    db  0ffh    ; end of table

init_text:
    ld bc,03b8h
    ld a,20h    ; set text mode, screen 'off'
    out (c),a
    
    ld hl,text_table
    ld bc,03b4h
    ld d,00h    ; register counter
init_loop:
    out (c),d   ; select register in 6845
    inc bc      ; advance to data register in 6845
    ld a,(hl)   ; get value from table
    cp 0ffh     ; end of table?
    jr z,init_done
    out (c),a   ; write value
    dec bc
    inc hl
    inc d
    jr init_loop
 
I wonder, is there a S-100 to ISA bus adapter project out there? Well, apparently there is: http://s100computers.com/My System Pages/ISA to S100 Bus/ISA To S-100 Bus Board.htm
Since you brought this up...

There is also an S100 8-bit VGA board project you can build up in two ways - either with an ISA connector on the board for use with with Sergey's ISA Super VGA board, or you solder the components used to build Sergey's board directly to the S100 board instead of using the ISA board:
 
That's pretty cool. I want to implement an ISA bus ( intially 8 bit ) in my current design instead of S100, but will make all the cards for it rather than reuse existing cards.

In that way, I'm very much like Myke - it's the journey and not the destination. I already have a video card I put together earlier this year and tested, but I still need to convert the design to ISA and at the moment it's like a serial terminal with a microcontroller latching X and Y addresses and drawing characters bit by bit as the Matrox did, with a serial input as the control mechanism. I too chose to generate the raster counts in hardware with counters, but I'm using GALs rather than discrete TTL chips.

Though long-term I still want to be able to plug in things like the Hercules adapter, or a VGA card, and be able to switch the video driver ( the CP/M support I built in supports replacing any external function with a new software defined driver )
 
The more I keep going back to the SD Systems VDB-8024, the more I like it. It has the 80 x 24 display I want, it has descenders, communication is via an I/O port, the driver code is in the manual, programmable Character Generator (with code in the manual), a commonly available oscillator, and I even found info on how to convert it to drive a VGA display. Almost like that thing was made to order...... If that is what I go with in the end, and it works, I have a set of the PROMs for the Flashwriter II that someone can have. Let me get something working first.....
 
Back
Top