The test program is 4K of initialization data for the block of memory from 0xA000-0xAFFF where 0xA000-0xABFF are screen texts and 0xAC00-0xAFFF are font tables for the 128 characters; each character is 8x8 pixels so each character requires 8 bytes of fonts. Attached is the initialization data file; and the attached picture shows what is displayed when the initialization data is loaded into memory. At first glance it looks good; the lines of text are displayed correctly, BUT look at the texts closely, they are all gibberish. I know from previous designs that the font tables are correct so the gibberish texts must be because of wiring mistakes. However, after looking at the connections under inspection microscope carefully, I can not find any wiring mistakes.

After digging around a bit more, I realized RAM data connections on ZRCC SBC are scrambled to make them easier to route. RAM's data and addresses pins can be reassigned to simplify board layout but that'll mess up the VGA display unless I also reassign the CPLD's address/data pins to match. This is an interesting wrinkle in the piggyback VGA design where signal assignments of the RAM expansion socket must be clearly defined. Changing the CPLD pin assignments are do-able, except the JTAG programming signals are not connected on the prototype. So I'm going back to the bench trying to add 6 wires to the CPLD...except I have too much caffeine already; I'll rest up and let the caffeine wears off before tackling that task in the morning.

Bill

PS, @Dr. J, yes, the VGA socket is glued to the RAM chip with a few drops of super glue. It is holding for now, but I do hold on to the connector while inserting or extracting the VGA cable.

Attached 4 JTAG signals to the CPLD and I'm able to reprogram the CPLD with data bus pin assignments to match that of ZRCC RAM. With that fix, the display is working properly. I also attach the CPLD schematic.

My sprained ankle is also mostly fixed, so it is back to gardening.
Bill

Fitting the screen ram and the font tables into one memory device is brilliant space and cost saving idea.

So, I've been watching this with interest, and had a go at building one myself, though not in the "stacked" format.

I hesitated to post my "interpretation" as I too matched it to a Zilog CPU. In my case a Z180, as the 33mhz version is "perfect" for running off the VGA clock to reduce the component count. The Z180's built in MMU making it possible to move the display ram in and out of visible memory as required to allow 64K RAM for CPM.

With a 128 macrocell ATF1508AS CPLD dedicated to just handling the video, I was able to fit in colour and scroll registers as well as 8 bit RRRGGBBB output.



The VDHL is attached for anyone who wants to look at it. It's probably not the best code in the world, but it gets the job done

NB Version 1 was 6bit colour, I figured the 2 extra bits of output was worth a major version number upgrade .

Nice!

I'm more a Verilog user, but I've found either my Verilog skill is not very good or Quartus' Verilog compiler is lacking such that certain designs in Verilog won't fit, but will fit when they are entered in schematic form. I've pretty much abandoned design entry in Verilog, at least for CPLD designs.

Like W65C02, CMOS Z80 can be recklessly overclocked. I have a Z80 design overclocked to 25.175MHz that uses an Altera EPM7128S (ATF1508 equivalent) to drive a text-based VGA.
https://www.retrobrewcomputers.org/doku ... 80all_rev1
Bill

Before all design sketches and prototype are misplaced or buried, I've created a homepage for the piggyback VGA to archive all the design data.
https://www.retrobrewcomputers.org/doku ... ggybackvga
Bill

I designed a pc board for the piggybacked VGA prototype. Picture shows it plugged into ZRCC's 128KB RAM socket and drove a 9" VGA monitor. Design information for the pc board is here.
Bill

Very cool, indeed. That mess of wires that was your prototype cleaned up very nicely.

_________________
Michael A.

An user is interested in trying out VGA6448, but unable to manually wire the prototype design, so he requested a VGA6448 pc board. However, I want the PS2 keyboard interface included on VGA6448, yet I don't have a functioning design, so I cheated by dropping in a second CPLD and sent off the pcb design file. This is not optimal design, but CPLD is cheap and should have enough logic to hold a state machine handling the keyboard inputs. We'll see...
Bill

Looks interesting, looking forward to your build and "first light" as the amateur astronomers would say.
Have you had a chance to try out the video terminal software?

Yes, I did tried out the video terminal software. I'm impressed how compact the software is. It makes me rethink the way to interface to keyboard input which is why I added a CPLD instead of software bit bang the keyboard input. I think I finally has a clear path to a standalone 6502 computer with its own monitor, keyboard, mass storage, and robust communication channels.
Bill

_________________
x86?  We ain't got no x86.  We don't NEED no stinking x86!

This is a pretty awesome Project.

seeing this really makes me want to design my own Video Card (I already designed a basic VGA Controller, but no Schematic/PCB for it) but, while using Dual Port RAM is very straight forward and simple it's just way too expensive when you get to higher capacities.

for example a single 55ns 4kB Dual Port SRAM Chip on Mouser costs around 12 EUR, and the VGA Controller i designed requires atleast 8kB.
that would already be 24 EUR just for the Memory, then add 11 EUR for an ATF1508, and another ~10-15 EUR for the PCB and passive components. that comes out to around 50 EUR for the whole thing.
using Normal SRAM, 1.50 EUR (SOJ Package) or 3 EUR (DIP Package) would only be around 25-30 EUR total.

So i feel like there has to be a way around the DPRAM without adding an insane amount of extra components.

the only thing i could think of right now is doing it similarly to the TMS9918, where VRAM is only accessable to the CPU through Registers inside the Video Controller.
it can be implemented entirely inside the CPLD (minus the Decoding Logic for the IO Registers) and saves money on the RAM, but it would make accessing the Memory slower and obviously take up more Logic on the CPLD.

my current VGA Controller requires 104 Macrocells (55/128 Registers) so i'll try and see if i can fit an access Port into it.
no auto-incrementing or anything, just a simple write-only port.
you write into the Address (13 bits) and Data (8 bits) Registers, and after setting a bit in the Control Register the contents of the Data Register will be written into the Selected Address on the next available Cycle.

anyone else got an idea on how to work around the need for DPRAM (without a synced CPU/Video Controller Clock)? or is it a hopeless case? i really don't know.

Another option would be bus interleaving, but this gets complex with a text display if the font is in RAM. A font ROM would make that a lot easier, but less flexible. Adding a font ROM would require a few more CPLD pins too.

The actual interleaving of the RAM access would require faster RAM, but that's not much of a problem, and the additional CPLD resources would be small.

I thought Interleaving Access to the RAM would require some kind of synchronized clock between the CPU and Video Controller?
so how exactly would it work when the CPU's clock is completely different from the Video Controller's?

for example if your CPU is running at 1MHz, the Access time would be pretty slow and it could prevent the 25MHz/12.5MHz Video Controller from accessing Memory in time causing artifacts on the screen.
maybe it's possible to use RDY to stall the CPU when both try to access Memory at the same time?

All my graphics circuits so far have been based on interleaved clocks, with or without shared memory, but I might change soon as I'm looking to go for a more modular, pluggable design. It doesn't seem that hard if the CPU clock is not too much faster than the video RAM clock - I think all we need to do during writes is hold the address and data in flipflops, along with a "write pending" flag, and then the video circuit can pick it up when it's ready, when its own clock is low, just like it would if it were in lockstep with the CPU. The only catch is the CPU queuing a write at just the moment when the GPU is picking it up, but I think that is still not too hard to avoid.

It's a lot like what you're saying with registers, except it's just latching both buses in one go, and I imagine the complexity in your CPLD would be similar - I haven't used such complex ones though so don't really know. I guess you'll need at least one additional macrocell per address or data bit... Which sounds expensive to me. You could always use external flip flops.

If the CPU speed is very fast then it may need to wait before executing subsequent writes. Within reason that should be easy to do in software I think, or with a "busy" flag.

I have a plan for font RAM as well while still trying to keep the transceiver count low - however it's probably not so relevant to the CPLD discussion as I think transceivers are basically free on a CPLD?