VGA6448, text-based VGA in ATF1504AS CPLD

[plasmo]

I am a long time Altera Quartus user so I probably would use Cyclone for FPGA. However, beside the multi-voltage, voltage translators and configuration EPROM, it doesn't feel "right" to have 6502 assisted by a far more sophisticated hardware that's better off taking over the whole system. I guess I found it more interesting to stay within the constraints of 5V parts, warts and all.
Bill

[sark02]

plasmo wrote:

[...] it doesn't feel "right" to have 6502 assisted by a far more sophisticated hardware that's better off taking over the whole system.

I understand the hesitation with a retro project. The way I think of it is that the 6502 came out in '76 and Atari had it surrounded by custom chips by '79. I don't know if other companies were using ULAs or other custom chips with a 6502 before that, but I like the idea of using an FPGA in essentially the same role. Kind of like: What could I have built with era-appropriate levels of integration (only with vastly superior tools)?

Quote:

I guess I found it more interesting to stay within the constraints of 5V parts, warts and all.

That's perfect for you, then

[okwatts]

This has already been done, I'm sure you know, by Grant Searle with his Multicomp and the crew at retrobrew have come up with boards using the Altera chips as in this post https://www.retrobrewcomputers.org/doku ... comp:start . This can work quite well although the 6502 is not so well developed as the 6809 and Z80 projects. I have done some work using the Cyclone II-c board and borrowing code from Daryl Rictor and Meik Merten to create a platform for using this. I am an FPGA and CPLD novice so extending this is a challenge for me. It does have full VGA with PS2 keyboard and lots of RAM, but at the moment since it's using VHDL not Verilog I am only running 6502 but not 65C02. As I said my skills are not at the level to make much headway on the project. I can work on the 6502 coding and I would like to add an OS and extend this as has been done for the other 2 processors. I think that one of those FPGA versions would be worth doing to add to the great projects that are evidenced here using actual 6502 family processors and peripherals. Some love the hardware challenge of designing their own versions, some who retrofit to older hardware like the MC65+ and others who just like to use and program in the first assemble language that they learned.
I just happen to really like 6502 based systems and have tried many emulations and some of the newer designs like the CRC65 so I'm glad there are people like Bill, Daryl, Oscar Vermeulen and Gordon Henderson among many who are keeping me happy with the choices.

[cbscpe]

Very nice project, I like the small chip count. Would you mind sharing the CPDL design file? I have some 7134 and many ATF15xx laying around. My VGA controller also uses a DP-RAM but instead of a CPLD I used a AVR microcontroller. The MCU provided a character ROM in Flash and also included a PS/2 keyboard interface, it however required some glue logic: 1 x 74LS573, 1 x 74LS166 and I had to add some 74HC14 for the PS/2 interface as I used one of the MCU UART in SYNC mode which required clean CLOCK and DATA signals.

[plasmo]

Here is prototype board version of CPLD. It does not have PS2 keyboard interface. I'm distracted with several other projects so I'm not likely to finish PS2 keyboard interface for a while. I do plan to layout two pc boards, one is a daughterboard for RAM that adds VGA capability to existing DIP32 RAM device. The other board is daughterboard for 6502 to add VGA capability to existing DIP-40 6502.
Bill

[jds]

I was never sure how much logic you could fit in a CPLD, so as a test I tried a very standard VGA timing circuit (in Verilog) in Quartus for a EPM7128. This takes 15 macrocells, so even on the smaller CPLD's (ATF1504, EMP7032) you should be able to comfortably fit a VGA controller.

Text mode requires more resources than graphics, and I'm trying to do it without DP RAM, but the timing is getting complex.

[plasmo]

CPLD has limited macrocells, so you can always count the number of flip flops in you design and know the minimal number of macrocells it needs. Unfortunately, I/O pins also consume macrocells as well as complex combinatorial logic, so the minimal number of macrocells based on flip flop count will only grow.

VGA logic is 10 flip flops for horizontal sync and 10 flip flops for vertical sync. With a large and fast RAM, the 20 flip flops can theoretically be the RAM address lines and directly drive RAM output to VGA output. So yes, a 32-macrocell CPLD (EPM7032 or ATF1502) can drive a VGA display. The hard part, however, is dynamically filling the large RAM with changing data. The complexity of WRITING to video memory will rapidly overwhelm the simple VGA displaying logic.
Bill

[Sheep64]

It is wholly representative of the 6502 forum for topic #6502 to begin with a back of an envelope sketch, although I believe that it is traditional to include photography of a wooden table.

More seriously, this video system, with a 4:3 (or 3:2) aspect ratio and 3:1 allocation ratio, is a cheap, efficient and scalable design:-

• 48*32 tile references to 64 8*8 monochrome bitmaps is 384*256 pixels and requires 2KB exactly.
• 64*48 tile references to 128 8*8 monochrome bitmaps is 512*384 pixels and requires 4KB exactly.
• 96*64 tile references to 256 8*8 monochrome bitmaps is 768*512 pixels and requires 8KB exactly.
• 128*48 tile references to 128 8*16 monochrome bitmaps is 1024*768 pixels and requires 8KB exactly.
• 192*64 tile references to 256 8*16 monochrome bitmaps is 1536*1024 pixels and requires 16KB exactly.
• 128*96 tile references to 128 16*16 monochrome bitmaps is 2048*1536 pixels and requires 16KB exactly.
• 192*128 tile references to 256 16*16 monochrome bitmaps is 3072*2048 pixels and requires 32KB exactly.

It is possible to make color variations by reducing resolution by a factor of two and equally dividing the tile reference allocation. For example, 3KB for tile reference, 3KB for color and 2KB for character bitmaps. Color may be RGBI/RGBI for foreground/background, RRGGBBII for foreground or an entirely different scheme.

It is also possible to make a double buffered version without dual port RAM. Admittedly, that requires two RAM chips, six 8 bit buffers, a latch and possibly an inverter. Actually, the dual port version is eminently sensible.

plasmo on Sat 20 Feb 2021 wrote:

no hardware cursor

You under-sell your own work. Variants with 64 or 128 tiles may use the top bit as a reverse video flag. Now you have unlimited cursors.

plasmo on Wed 24 Feb 2021 wrote:

Multiple VGA6448 can be populated on a system

Dual screen! Triple screen!!!

plasmo on Wed 24 Feb 2021 wrote:

the others can shadow and display the activities of certain region of memory. Example, the first 2K of memory where zero page and stack are located is a region of interest.

Real-time zero page and stack debug!!!!! Oh, that's so useful. Transparently debug anything using an extra screen. At 64*48 character resolution, four rows are for zero page, four rows are for stack and the remaining 40 rows are for arbitrary program or data.

plasmo on Fri 12 Mar 2021 wrote:

I do plan to layout two pc boards, one is a daughterboard for RAM that adds VGA capability to existing DIP32 RAM device. The other board is daughterboard for 6502 to add VGA capability to existing DIP-40 6502.

Perhaps I should have read this before writing Expanding RAM Socket To A Full Expansion Bus on Sun 25 Apr 2021.

A RAM socket is the new expansion socket!

[plasmo]

plasmo wrote:

plasmo wrote:

A VGA6448 daughter board can be constructed that plugs into the system RAM socket; the daughter board is consists of the original system RAM, 4K dual port RAM, ATF1504AS CPLD, 25.175MHz osc, and VGA connector. The original system RAM is plugged back in on the daughterboard and the RAM's address, data, control, and power are now driving VGA circuits. This way a VGA capability is added by piggy backing on the existing RAM. Memory map can be programmed such that the top 1K memory is programmable font tables; the other 3K holds 64x48 character memory.

I twisted my ankle and can hardly walk, so I'm taking a few days off gardening to work on retrocomputing projects. I thought I'll tackle something I've been thinking about: a stacked VGA interface for RAM socket.

This is a follow up to my musing about using system RAM socket as a VGA interface. The 4K dual port video RAM is shadowing a 4K portion of the system RAM such that all write to the designated 4K portion of the RAM is also written to the dual port RAM. The VGA controller is reside on the CPLD which will display the content of the dual port RAM on a VGA monitor. The interesting part is the circuitry is implemented as collection of stacked ICs so CPLD, dual port RAM and 25.175MHz oscillator are all stacked on top of the system RAM. The first figure shows all the components of a stacked VGA interface. The 2nd picture shows the components of stacked VGA glued to the system RAM.

To be continued....

[plasmo]

The advantage of using CPLD is its pins can be reassigned to making routing easier. In this case it makes point-to-point hand soldering easier.
Bill

[plasmo]

The stacked VGA is all wired up. Here are the top, side, and bottom views. It is even smoked tested and no smoke are detected!

I'm looking for a test vehicle to check out this. I don't have a 6502 SBC with DIP 128K RAM, but since the VGA circuitry is invisible to normal RAM operation, any SBC with 128K RAM in DIP format is suitable for testing. The VGA video memory is mapped to 0xA000-0xAFFF in this particular implementation so writing to that block of memory will change the video display--that's the theory anyway.
Bill

[okwatts]

Hi Bill
Its not really what you would prefer but I have a few spare boards from the CycloneII multicomp (https://www.retrobrewcomputers.org/doku ... ii-c:start) version that have a socket or 2 for 32 pin Ram chips. The drawback is it needs a Cyclone II FPGA (https://www.ebay.ca/itm/183713814541) along with the code to emulate the 6502 (not 65C02).
At least you could compare the performance with an FPGA implementation of VGA code.
Larry

[plasmo]

I decided to use a Z80 SBC, ZRCC, as the test platform for the stacked VGA interface. The original 128KB RAM is replaced with the 128KB RAM with piggybacked VGA. The power consumption went from the nominal 125mA to 230mA. ZRCC boots normally, passes memory diagnostic, boots into CP/M and can run CP/M commands. So the piggybacked VGA has no impact on normal operation of the SBC, as expected. What I see on the VGA display is also expected--random noises because video memory and font tables contain random data. Each line is blanked out after 512 pixels because there are 64 texts (8x8pixels/character) per line. There are two lines of blank pixels separating each line of text and there are 48 lines of texts. The magenta color is because I've only hooked up red and blue color. This is all good! Now I need to write some test software...
Bill

[Dr Jefyll]

plasmo wrote:

Here are the top, side, and bottom views.

Whoa -- it's hideous and gorgeous at the same time! I'm watching your progress with interest.

Is the VGA socket simply glued onto the RAM chip? (Oops, earlier you mentioned that it is.) I'd be nervous about it getting pulled off.

-- Jeff

[floobydust]

Wow, nice progress in a short period of time.

The prototype reminds me of an old buddy from the 70's... Roger's design technique was to create "the ball of parts" all soldered together by component leads only. Frequently he would attempt to add, delete or swap a part out live... usually resulting is sparks and the occasional bang of a tantalum cap.

Do post some more once you have some code running and the display is showing some normal output. Great project!