Jump to content

FPGA as graphics card?


Mutz03 Zockt
 Share

Recommended Posts

On 12/29/2021 at 8:47 AM, Mutz03 Zockt said:

... so i may have maybe not used the right term here.
what i tried more to say, is, that i think the goal was to build a computer with 5V ASIC chips, not depending if they were avaiable in the 80s.

but still i do beleve, that if commodore made his in the 80s, they would at least have had the Vram seperately and some other capabilities wich the Vera chip now has would have been seperately. ...

In the 80s, sure, it would have been separate VRAM just like the MOS 8563 in the C128, for exactly the same reasons. An integrated RAM component would have been prohibitively expensive. It would have been DRAM, for cost reasons.
Today, the integrated RAM comes with the commodity priced FPGA part, so that's the cheaper approach.

Whether it would have all been that integrated ... I guess it depends on whether it was TED philosophy Commodore or Commodore 128 philosophy Commodore.

Link to comment
Share on other sites

On 12/29/2021 at 5:55 AM, Mutz03 Zockt said:

im gonna leak a bit here, because the developement of my proect is technicly still unnanounced and secretive.

but i and a couple of friends of mine are right now developing on a CX16 Graphics solution with only ASIC chips.
the main idea is to use CPU driven graphics. A circuit witch displays the content of a deticated Vram out onto a VGA port (ben eather made a excelent Video about that) and with a bit of enhancing you can use that circuit fairly well.

then we are planning on using a Motorola 68K CPU because it has a 24bit adressbus, wich means support to up to 16Mbyte ram, witch we gonna use almost nothing of it, because 256Kbytes are enough for the simple prototype first.
(ideas of supporting higher resolutions and so on more ram are existing, we just dont want to bite more than we can chew.)
this CPU should then make all the Tilelogic, sprites and look up of two character sets, one is hardcoded in rom, and the other one is loadeable...

as i said, it is still in early developement, but i have high hopes that it may work fairly well.
(I do not expect or even hope that it gets added to the CX16 stock, but maybe it will be a fun addon card)
 

I think that's going to require much more than a bit of enhancing. I don't want to discourage you, but I would encourage you to focus on crawling before flying. How will communication between your card's CPU and 6502 take place? The 6502 bus has strict timing constraints that are extremely difficult to meet via software implementation on a microcontroller. It's pretty much impossible to handle 6502 bus IO using interrupts on the 68K because that CPU has a 44 clock cycle minimum latency to service interrupts. An 8MHz 6502 bus read has an allowance of about 50ns from the rising edge of PHI2 until the data needs to be stable on the data bus to meet the data setup time constraint (tDSR in the datasheet, I think). If you're using all discrete logic, the fastest discrete 7400 series logic chips have a propagation delay of 4-8ns under ideal circumstances. The problem could probably be solved if you're sufficiently clever, but it would be quite the labor of love compared to just sticking a low cost FPGA in there for interfacing with the 6502 bus.

Link to comment
Share on other sites

On 12/29/2021 at 9:28 AM, Ed Minchau said:

Like on the X16, VERA would have been a daughter board, in much the same way Soundblaster was. Those edge connectors can have lots of pins.

The original VERA looked much like a video chip in an odd package, containing only pins. The video ports were on the X16 board. Regardless that doesn't address the issue raised with regard to the necessary bus widths to meet VRAM latency requirements. I don't follow the relevance of the edge connector width.

Link to comment
Share on other sites

On 12/30/2021 at 2:22 PM, Wavicle said:

The original VERA looked much like a video chip in an odd package, containing only pins. The video ports were on the X16 board. Regardless that doesn't address the issue raised with regard to the necessary bus widths to meet VRAM latency requirements. I don't follow the relevance of the edge connector width.

The idea of an edge connector is that you can have as many pins as you want. If you need 72 conductors for data/address/control, that's only 36 on each side of the edge connector, 3.6 inches long.

Link to comment
Share on other sites

On 12/30/2021 at 8:48 PM, Ed Minchau said:

The idea of an edge connector is that you can have as many pins as you want. If you need 72 conductors for data/address/control, that's only 36 on each side of the edge connector, 3.6 inches long.

The problem is the number of pins needed by the component that ultimately composes the line buffer. It must be able to perform 32 bits worth of access to a 128K VRAM space every 40ns. Using 1980s era tech, one could only hope to do this by making the data and address paths wide. Making the data bus 32 bits and using a non-multiplexed 15 bit address bus might put the goal within reach, but that is 47 pins taken up just for the basic address and data bus. The chip will also need power, ground, clock, reset, data direction, video out signals, and some sort of interface to the host.  I'm not aware of any 8 bit system that had a DIP component larger than 40 pins; nor any DIP component larger than 64 before everything went SMT.

Compare this to the C128D (probably the Apex of real 8 bit systems) which used the 8563 VDC with an 8 bit wide data bus to DRAM chips with a multiplexed address bus. The best case transfer rate for those chips was 8 bits every 230ns (~0.035 bits per nanosecond). VERA requires a bandwidth of 0.8 bits per nanosecond, 23 times faster than what the 40 pin VDC could achieve.

That's the fundamental problem that would have to be solved to make a 1980s era VERA.

Incidentally, the largest package Commodore was capable of manufacturing was 84 pins. This is what constrained Fat Agnus on the Amiga line. They could make that a PGA or PLCC, not DIP.

  • Like 1
Link to comment
Share on other sites

On 12/30/2021 at 10:09 PM, Wavicle said:

I think that's going to require much more than a bit of enhancing. I don't want to discourage you, but I would encourage you to focus on crawling before flying. How will communication between your card's CPU and 6502 take place? The 6502 bus has strict timing constraints that are extremely difficult to meet via software implementation on a microcontroller. It's pretty much impossible to handle 6502 bus IO using interrupts on the 68K because that CPU has a 44 clock cycle minimum latency to service interrupts. An 8MHz 6502 bus read has an allowance of about 50ns from the rising edge of PHI2 until the data needs to be stable on the data bus to meet the data setup time constraint (tDSR in the datasheet, I think). If you're using all discrete logic, the fastest discrete 7400 series logic chips have a propagation delay of 4-8ns under ideal circumstances. The problem could probably be solved if you're sufficiently clever, but it would be quite the labor of love compared to just sticking a low cost FPGA in there for interfacing with the 6502 bus.

so, communitcation i guess could be done with a coupld of registers, so the 6502 writes the GPU command into the registers, and the 68K fetches the instruction from the register.
i have not thought out everything completely, but i am trying, and not really confident that it will work well.

just the idea and the proof of concept would be cool.

  • Like 1
Link to comment
Share on other sites

On 12/31/2021 at 9:30 AM, Mutz03 Zockt said:

so, communitcation i guess could be done with a coupld of registers, so the 6502 writes the GPU command into the registers, and the 68K fetches the instruction from the register. ...

Yes, you can use a register to buffer a write from the 65C02 bus and buffer the five address lines to know where the write is going.

The bottleneck is the read from the 65C02 bus. A Vera register is read in a single clock cycle, so you might need a register file for some of the Vera registers.

Edited by BruceMcF
Link to comment
Share on other sites

On 12/31/2021 at 5:32 PM, BruceMcF said:

Yes, you can use a register to buffer a write from the 65C02 bus and buffer the five address lines to know where the write is going.

The bottleneck is the read from the 65C02 bus. A Vera register is read in a single clock cycle, so you might need a register file for some of the Vera registers.

thats fine though, it doesnt have to be extremely fast and accurate, i just want to build something wich is not a FPGA

 

Link to comment
Share on other sites

On 12/31/2021 at 1:20 PM, Mutz03 Zockt said:

thats fine though, it doesnt have to be extremely fast and accurate, i just want to build something wich is not a FPGA

If you are just building something which isn't an FPGA, then a mix of the way the 80-column chip from the C128 and the way the Vera interfaces could be used.

Two registers, one is the address register for the other. The "address" register is just a register, which allows for up to 256 register addresses for the second, which is a normal 65C02 register. But if you limit it to 128 register addresses, the top bit can specify whether it is going to be a read or a write, and if a read, it can pre-fetch the value for the data register location.

And VRAM data port, and two address registers, with the bottom two or three bits implied $00 when the low address register is set, and incrementing after a read or write of the data port. Then a counter provides the bottom bits, with the reset for the counter set to the write of the bottom address register. That allows for 256K or 512K of VRAM.

That whole approach is quite different from the strategy that was used for the VIC-20, C64, C128 etc., with an FPGA being the closest feasible hobbyist equivalent to the CBM approach of building a dedicated ASIC video chip. But there's obviously no rule about sticking closely to that approach ... building the display from discrete electronic components is more like the Apple I approach, though I take it that you are aiming at a substantially more capable display.

Edited by BruceMcF
Link to comment
Share on other sites

On 12/31/2021 at 6:30 AM, Mutz03 Zockt said:

so, communitcation i guess could be done with a coupld of registers, so the 6502 writes the GPU command into the registers, and the 68K fetches the instruction from the register.
i have not thought out everything completely, but i am trying, and not really confident that it will work well.

just the idea and the proof of concept would be cool.

There are (or were) logic chips specifically for mailbox registers. E.g. 74xx172 (which I cannot find a source for) provides multi-ported access to eight 2-bit registers or 74xx670 (which has a long 45ns propagation delay) has four 4-bit registers @ $2/each. You could create your own using discrete components; if you do so and meet the bus timing constraints, then my hat's off to you.

Link to comment
Share on other sites

On 12/31/2021 at 3:38 PM, Wavicle said:

There are (or were) logic chips specifically for mailbox registers. E.g. 74xx172 (which I cannot find a source for) provides multi-ported access to eight 2-bit registers or 74xx670 (which has a long 45ns propagation delay) has four 4-bit registers @ $2/each. You could create your own using discrete components; if you do so and meet the bus timing constraints, then my hat's off to you.

If you want a mailbox, and have active processing on both sides, you can use dual ported SRAM, though that might not be period specific enough.

Link to comment
Share on other sites

On 12/25/2021 at 5:23 PM, Ed Minchau said:

Look at it this way: in the 1980s, Commodore had their own chip fabrication plant.  That's how they produced things like the VIC chip and VIA chips for audio and video for the VIC-20.

The VERA daughterboard is definitely something Commodore could have done in the 80s, though it would be a much bigger board.  And of course we're already using 512kb RAM ICs, which for Commodore would have been an enormous PCB flooded with 2kb RAM chips.  Point is, Commodore could have produced VERA, and all the rest of the Commander X16.  Their only real obstacle would be the RAM, and SD storage was just a dream back then.  An FPGA like VERA would have been a factory-programmed gate array rather than field programmable, or several such ICs.

The ATtiny used for Reset and power on wouldn't have been present on Commodores because of the external power box feeding a single voltage to the computer, but if they had needed something like that it would have probably been done with a special-purpose chip that they fabricated themselves as well.  It isn't doing a whole bunch of 16 bit or higher math, and might have been implemented with a bunch of TTL logic gates instead.  If they were putting 2Mb of banked RAM in a machine, the case would already be big and would contain lots of PCBs, so what's one more?

Then again, there are a few "crochet hook" ideas that in hindsight, should have been dope slap obvious, but back in the day no one ever thought of.

Take stacked RAM.  The idea of stacking four to eight DRAM dies using through-silicon vias, plus DRAM refresh logic and possibly a DMA and/or MMU on a package no larger than a then-typical DIP should have been blindingly obvious, but it didn't happen.  Done right, a 64K Pseudo-SRAM version should have drawn no more power and/or generated no more heat than an 8K SRAM on the same package, and massively reduced the chip count of, say, the Commodore 64 and subsequent follow-up motherboards.

Unity Semiconductor, creators of CMOx Flash, was poised to turn the nonvolatile RAM market upside-down, but then they were bought out by Rambus, which scared all possible potential licensees off, due to Rambus' reputation as sharks.  They had white papers that it could have been produced on conventional CMOS tools, and tested the concept at a five micron node.

Edited by Kalvan
Link to comment
Share on other sites

I will point out that VERA has been recently cloned (re-implemented) for the Roscoe 68000 based retro computer.

https://www.tindie.com/products/rosco/xosera-fpga-video-r1/

Doesn't look like it re-uses any of Frank's work, but rather the same features have been implemented on an upduino and modified. Same 120K video memory, etc.

I really like the 16:9 aspect ratio option that was added for those that do not have an old monitor hanging around.

No mention of sprites here, which makes me wonder if they are implemented. 

They did add an Amiga style co-processor (copper).

It is nice that it is already open sourced.

Edited by Lasagna
  • Like 1
Link to comment
Share on other sites

On 1/6/2022 at 1:43 PM, Lasagna said:

I will point out that VERA has been recently cloned (re-implemented) for the Roscoe 68000 based retro computer.

https://www.tindie.com/products/rosco/xosera-fpga-video-r1/

Doesn't look like it re-uses any of Frank's work, but rather the same features have been implemented on an upduino and modified. Same 120K video memory, etc.

I really like the 16:9 aspect ratio option that was added for those that do not have an old monitor hanging around.

No mention of sprites here, which makes me wonder if they are implemented. 

They did add an Amiga style co-processor (copper).

It is nice that it is already open sourced.

I like that they based it around the Upduino and Icebreaker which are relatively easy to get.

That said, this looks more like a VERA-inspired project and not a clone. It has a few features that VERA does not, but if I'm reading the RTL correctly, there is no space available for sprites. The VRAM data path is 16 bits wide, clocked at the dot clock frequency, and playfields have priority. Since the effective memory bandwidth is 2 bytes per dot clock, there are no spare cycles for anything else (e.g. sprites, host VRAM access) with two playfields active. Reading or writing to memory during active display may only take place during blanking periods. It looks like software needs to check a VRAM read/write address register to make sure that VRAM access goes to the intended location. While only allowing access during HBLANK or VBLANK was a common limitation for several early computers and consoles, it was not for the C64 and is not for VERA.

I know widening the VRAM data path is listed as a TODO item, but the Upduino+VGA version's FPGA has used 100% of the BRAM and 83% of the LCs. Sprites are a pretty big deal on retro hardware. I think the design would be vastly improved by completely dropping the second playfield in favor of sprites.

  • Like 1
Link to comment
Share on other sites

On 1/7/2022 at 2:06 PM, Wavicle said:

I like that they based it around the Upduino and Icebreaker which are relatively easy to get.

That said, this looks more like a VERA-inspired project and not a clone. It has a few features that VERA does not, but if I'm reading the RTL correctly, there is no space available for sprites. The VRAM data path is 16 bits wide, clocked at the dot clock frequency, and playfields have priority. Since the effective memory bandwidth is 2 bytes per dot clock, there are no spare cycles for anything else (e.g. sprites, host VRAM access) with two playfields active. Reading or writing to memory during active display may only take place during blanking periods. It looks like software needs to check a VRAM read/write address register to make sure that VRAM access goes to the intended location. While only allowing access during HBLANK or VBLANK was a common limitation for several early computers and consoles, it was not for the C64 and is not for VERA.

I know widening the VRAM data path is listed as a TODO item, but the Upduino+VGA version's FPGA has used 100% of the BRAM and 83% of the LCs. Sprites are a pretty big deal on retro hardware. I think the design would be vastly improved by completely dropping the second playfield in favor of sprites.

Well, maybe for the Xosera II, they could use a bigger FPGA to implement hardware sprites.  Since this version doesn't seem to include the sound channels and FIFO, presumably that should leave some room in the FPGA for more features.

Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

 Share

×
×
  • Create New...

Important Information

Please review our Terms of Use