I am looking for some way to add a display controller (with either composite or VGA output) to my 6502 retro computer design. My basic requirement is to do not use any modern microcontrollers or FPGAs doing the job. Only classic, retro chips. It would be also nice, if it wouldn't be required do use any of the "mystery pins" of the 6502. I already created my CPU board some time ago, with serial terminal operation in mind. So pins like SYNC or RDY are not present on system bus connector.
Is there any "simple" chip, that I can use? I do not need any sophisticated features. Most basic text interface will be fine.
Display controller
Re: Display controller
Many people have interfaced the Texas Instruments TMS9918 to 6502, 6809, and Z80 systems. As a bonus it uses its own memory which simplifies integration with existing systems. While it can use DRAM's, many people have interfaced it with SRAM as well. See this page: https://hackaday.io/project/160851-tms9 ... deo-memory
It was used on the Ti 99/4a and MSX systems during the eight bit era, so it's definitely an authentic VDP.
It was used on the Ti 99/4a and MSX systems during the eight bit era, so it's definitely an authentic VDP.
Re: Display controller
Atlantis wrote:
I am looking for some way to add a display controller (with either composite or VGA output) to my 6502 retro computer design. My basic requirement is to do not use any modern microcontrollers or FPGAs doing the job. Only classic, retro chips.
http://mirrors.apple2.org.za/Apple%20II ... n%20Cards/
The "standard" is the Videx Videoterm. The Videx Ultraterm has more RAM and better resolution.
Regards
Ralf
Re: Display controller
The SYNC and RDY pins aren't normally needed for operating a display controller. You might only need RDY as a wait-state while accessing the registers of a slow I/O chip.
You should probably look at Ben Eater's "World's Worst VGA" project to nail down the basics of generating vsync, hsync, and pixel outputs. Then I would recommend you make use of the 6502's quirk of only performing RAM access during the Phi2 phase of each clock cycle, and use the remaining Phi1 phase to pull video data out of RAM. This means, trivially, you can pull 1 byte per CPU clock cycle to generate pixels with. This is an authentic technique used by, for example, the BBC Micro and the C64.
As a point of reference, if you're happy with roughly QVGA resolution (320x256) and 50Hz refresh rate, you can generate that with an 8MHz pixel clock - that's what the BBC Micro did in Modes 1 and 4. Such a signal is PAL TV compatible, so you can feed it to a Composite output. At 1 bit per pixel (enough for text), you will need to feed it with 1MB/s, and you will need to reserve 10KB for the display bitmap. If you reserve 20KB and increase the dot clock to 16MHz, feeding it with 2MB/s of data, you can have 640x256, enough for 80-column text with a typical 8x8 font. Reserving 40KB and turning on interlacing, you can push it to 640x512, though this will then flicker noticeably on a CRT; LCDs probably won't care, as long as they will actually sync to such an archaic signal.
If you can source a 6845 CRTC, that will give you a lot of help in generating sync signals and address sequencing, or you can build a sufficient replacement with discrete logic as Ben Eater does. Combine that with a parallel-to-serial shift register to turn bytes into pixels, and some glue logic to switch the memory bus between "display" and "CPU" modes for each phase of the CPU clock, and you'll be golden.
You have a lot of flexibility in how you map that RAM into your address space, and in how you generate pixels from each byte of video data. If you don't want to permanently give up 10 or 20KB of address space, you can attach a separate RAM chip with a toggle to overlay it in place of some of your conventional RAM, and thus map it in only when actively updating the display. I recommend you make it a straight bitmap, and do all text rendering in software; this not only simplifies the hardware, but will also make it relatively easy to add simple graphics capabilities.
However, if you want to strictly minimise RAM consumption, you could instead store one character code per cell. This requires you to read each row of characters multiple times, once for each video scanline it covers, and pass the character data through a character generator on its way to the pixel shift register. The character generator could itself be a 2KB RAM, ie. 256 character codes each with 8 rows of 1-byte pixel groups, and you can then store an 80x32 character matrix in 2.5KB of RAM. With some mildly clever glue logic, you can conveniently map that onto a 4MHz CPU clock.
You should probably look at Ben Eater's "World's Worst VGA" project to nail down the basics of generating vsync, hsync, and pixel outputs. Then I would recommend you make use of the 6502's quirk of only performing RAM access during the Phi2 phase of each clock cycle, and use the remaining Phi1 phase to pull video data out of RAM. This means, trivially, you can pull 1 byte per CPU clock cycle to generate pixels with. This is an authentic technique used by, for example, the BBC Micro and the C64.
As a point of reference, if you're happy with roughly QVGA resolution (320x256) and 50Hz refresh rate, you can generate that with an 8MHz pixel clock - that's what the BBC Micro did in Modes 1 and 4. Such a signal is PAL TV compatible, so you can feed it to a Composite output. At 1 bit per pixel (enough for text), you will need to feed it with 1MB/s, and you will need to reserve 10KB for the display bitmap. If you reserve 20KB and increase the dot clock to 16MHz, feeding it with 2MB/s of data, you can have 640x256, enough for 80-column text with a typical 8x8 font. Reserving 40KB and turning on interlacing, you can push it to 640x512, though this will then flicker noticeably on a CRT; LCDs probably won't care, as long as they will actually sync to such an archaic signal.
If you can source a 6845 CRTC, that will give you a lot of help in generating sync signals and address sequencing, or you can build a sufficient replacement with discrete logic as Ben Eater does. Combine that with a parallel-to-serial shift register to turn bytes into pixels, and some glue logic to switch the memory bus between "display" and "CPU" modes for each phase of the CPU clock, and you'll be golden.
You have a lot of flexibility in how you map that RAM into your address space, and in how you generate pixels from each byte of video data. If you don't want to permanently give up 10 or 20KB of address space, you can attach a separate RAM chip with a toggle to overlay it in place of some of your conventional RAM, and thus map it in only when actively updating the display. I recommend you make it a straight bitmap, and do all text rendering in software; this not only simplifies the hardware, but will also make it relatively easy to add simple graphics capabilities.
However, if you want to strictly minimise RAM consumption, you could instead store one character code per cell. This requires you to read each row of characters multiple times, once for each video scanline it covers, and pass the character data through a character generator on its way to the pixel shift register. The character generator could itself be a 2KB RAM, ie. 256 character codes each with 8 rows of 1-byte pixel groups, and you can then store an 80x32 character matrix in 2.5KB of RAM. With some mildly clever glue logic, you can conveniently map that onto a 4MHz CPU clock.
Re: Display controller
ttlworks wrote:
EF9345 can do 40*25 and 80*25 text in color.
This is the board:
Code: Select all
Broken external image link
http://www.ralf-kiefer.de/VME/ELTEC/E1VIC1BSklein.JPGRalf
Re: Display controller
Ralf, thanks for digging this out, nice picture of the PCB.
EF9364, now this reminds me to the NKC (NDR Klein Computer). //No 6502, only Z80 and 68K, sorry.
Module 'CRT' was EF9364 based.
Some documentation about NKC text\graphics video hardware is here.
Since we are at it, something about displaying graphics:
I remember to have had built a EF9367 based "graphics card" for a 6502 system back in 1987, inspired by the GDP64K graphics module of the NKC.
Of course, EF9367 is more interesting for CAD than for implementing video games, and scrolling text with that sort of chip certainly is an issue.
//SN74F538 seems to be a replacement for the exotic AM25LS2538 used in the GDP64k.
EF9364, now this reminds me to the NKC (NDR Klein Computer). //No 6502, only Z80 and 68K, sorry.
Module 'CRT' was EF9364 based.
Some documentation about NKC text\graphics video hardware is here.
Since we are at it, something about displaying graphics:
I remember to have had built a EF9367 based "graphics card" for a 6502 system back in 1987, inspired by the GDP64K graphics module of the NKC.
Of course, EF9367 is more interesting for CAD than for implementing video games, and scrolling text with that sort of chip certainly is an issue.
//SN74F538 seems to be a replacement for the exotic AM25LS2538 used in the GDP64k.
Re: Display controller
Martin_H wrote:
Many people have interfaced the Texas Instruments TMS9918 to 6502, 6809, and Z80 systems. As a bonus it uses its own memory which simplifies integration with existing systems. While it can use DRAM's, many people have interfaced it with SRAM as well. See this page: https://hackaday.io/project/160851-tms9 ... deo-memory
It was used on the Ti 99/4a and MSX systems during the eight bit era, so it's definitely an authentic VDP.
It was used on the Ti 99/4a and MSX systems during the eight bit era, so it's definitely an authentic VDP.
I see there TMS9918 is a NTSC only chip. There is an another version - TMS9929 - which requires additional circuitry to generate either PAL or SECAM signal. Will it be difficult task to make it into PAL composite output?
BTW, ppeaking 6809... Is there some easy to implement version of BASIC for Motorola MC68xx CPUs? I was able to get some MC6802 chips and I consider using them to make another 8bit computer. It is almost pin compatible with 6502, so it will need only minor changes to the existing design of CPU board and should be compatible with existing peripheral boards. Is there something like EhBasic fot this CPU family?
Re: Display controller
(although OT) you may look at AnyCPU.org and look for 6800 / 6802 and MiniFlex what was an FDOS for 6800 and most likely offers a BASIC (TSC I think).
There may be somewhere an MiniFlex archive like there is (was?) a Flex archieve (for 6809).
There may be somewhere an MiniFlex archive like there is (was?) a Flex archieve (for 6809).
Re: Display controller
The 'Matra Alice' (sold in France beginning in 1983) had a 6803 and Microsoft BASIC.
There is an emulator with ROM images in the internet, but I'm not sure if a disassembly listing of the ROMs does exist.
Compared to the 6800, the 6802 and 6803 had some on chip peripherals and 10 additional instructions.
BTW: 6809 is not binary compatible to the 6800, some of the OpCodes went to a different place in the instruction map, take care.
There is an emulator with ROM images in the internet, but I'm not sure if a disassembly listing of the ROMs does exist.
Compared to the 6800, the 6802 and 6803 had some on chip peripherals and 10 additional instructions.
BTW: 6809 is not binary compatible to the 6800, some of the OpCodes went to a different place in the instruction map, take care.
Re: Display controller
Atlantis wrote:
I see there TMS9918 is a NTSC only chip. There is an another version - TMS9929 - which requires additional circuitry to generate either PAL or SECAM signal. Will it be difficult task to make it into PAL composite output?
Re: Display controller
For what it's worth, I have collected a lot of documentation on the TMS9918 series chips.
I highly recommend this chip if you are looking for that vintage, CRT goodness.
https://github.com/cbmeeks/TMS9918
I highly recommend this chip if you are looking for that vintage, CRT goodness.
https://github.com/cbmeeks/TMS9918
Cat; the other white meat.
Re: Display controller
Martin_H wrote:
I don't know that much about the TMS9929, but a google search shows that other people have built adapters for RGB monitors.
If it will be possible maybe I will try to generate both signals. But for as for now, composite is a priority for me.
Re: Display controller
For initial testing at least, you could just go with the Y luminance output.
The 9918A outputs sync at 2v, black at 2.3v and white at 3v. The 9928/29A output sync slightly lower at 1.8v but the same for black to white levels.
If you subtract 2v from 9928/29 output levels you have a 1v peak to peak composite output.
Exactly how to do that is another google search away, but I might be tempted to try using a voltage divider to put 2v on the "ground" and leave the Y signal as is.
The 9918A outputs sync at 2v, black at 2.3v and white at 3v. The 9928/29A output sync slightly lower at 1.8v but the same for black to white levels.
If you subtract 2v from 9928/29 output levels you have a 1v peak to peak composite output.
Exactly how to do that is another google search away, but I might be tempted to try using a voltage divider to put 2v on the "ground" and leave the Y signal as is.
Re: Display controller
It should be sufficient to just AC-couple the signal to the output. You do that by inserting an unpolarised capacitor in series with the signal, plus a high-value resistor in parallel with the capacitor to ensure it drains harmlessly when not actively connected to anything.