Worked on a video card design intended for use with the 65816 or 6502 chips. It is FPGA based and avoids the need for logic level translators by running everything at 3.3V. It supplies 8MB of ordinary DRAM for system memory. The FPGA generates the appropriate signals to drive the DRAM chip. Access to DRAM is during half cycles of the 4MHz phi02 clock.

There is no chip select line used for the video circuit since all 24 address lines are available to the circuit it can do its own internal decoding.

An issue to be resolved is how to connect it to a ‘816 system. One possibility is to use the PC ISA bus which has 24 address lines and 16 data bits. Only 8 data bits would be needed. However, 3.3V logic level would be on the bus instead of 5V TTL levels. Another possibility is to just use a big pin header.

A modified PC ISA bus may be used for my bench computer. I have toyed with the idea of developing an ‘816 computer using the ISA backplane. Basically because the bus has enough signals to accommodate the ‘816.

The video card outputs HMDI. HDMI requires fewer output pins than VGA.

Edit: Bus Available connected to RDY, RAMOE connected.

_________________
http://www.finitron.ca

HDMI also requires a much higher clock speed to run. a 25MHz Pixel clock requires you to push 10 bits within a single 25MHz Cycle, aka push them at 250MHz.
Generating the clock is not an issue thanks to FPGA's built in PLLs, but routing on the PCB would likely be a bit more difficult compared to VGA.

i'm also wondering what kind of resolution and color depth you'll be aiming for that can be handled by a 4MHz CPU, or are you planning on putting a small Co-Processor into the FPGA to help with certain graphical features like filling areas, drawing lines and basic shapes, or even manipulating textures (mirror, rotate, translate, scale)?

on a side note, you can have KiCad generate a PDF (in either Color or B&W) of your schematic which you can then directly upload to the forum. it's more convenient than an image since youcan zoom into a PDF without losing detail.
In the Schematic Editor, File -> Plot -> Output Format: PDF

Very cool, Rob! For my G76, I went with a big two-row pin-header, with all signals on one row and grounds on the other, and it works quite well (though I have fewer signals). One thing I have thought about for a future implementation is to try and see if the interface can be built on a PCB that has the same footprint as a 40-pin DIP package, which would make it trivial to install it in a regular socket. It seems kinda possible, especially with a mini-HDMI output.

HDMI output is also on my long-term radar, so I would love to hear more about your progress. I'm sure you've already looked at implementation details, but, just in case, I came across this handy FOSS implementation a while back, so I thought I'd pass it along in case it helps. Good luck!


—Marco

I was going to mirror the functionality of the VIC-II chip but at about 4x the resolution to keep the load on the processor relatively the same. 80x50 text, 640x400 bitmapped graphics two color settable from 80x50 color code bits. Maybe some additional lower res modes. Not planning any accelerator functions to begin with, but maybe at a later date. I have already done an Amiga like Blitter and Copper for another project along with roto-zoom so I may port some code.

Unlike the VIC-II chip, the row and column addressing for the DRAM is going to correspond so that FPM may be used. Rows using address bits A12 to A23 and columns from A0 to A11.

The boot ROM is going to be in the FPGA to allow easy reprogramming. The video circuit select will be decoded from the row address bits A12 to A23. I may include a second DRAM chip so a full complement of memory is available.


Where can I find more information on the G76?

_________________
http://www.finitron.ca

Here you go: Thread discussion, and Github page with schematics, source, and project details.

There is still a bug in the memory read logic, but the interface otherwise works great (in the latest iteration, I can drive it from my SBC at 20MHz with no problems). The biggest drawback is that the CPLD doesn't have enough gates to support the features that I eventually want to add, like sprites, text/tile mode, smarter auto-increment functionality, etc.—I called it the “mini” because I fully expected that I would want to build a more advanced version once I got my feet wet with Verilog.

I have recently started working on a new version based on the Lattice ICE40UP5K (very preliminary schematic attached to this post—right now I'm just working with one of their trainers), which comes with 5,000 LUTs, 128kiB of single-ported RAM, and 16kiB of dual-ported RAM for a very reasonable ~$12CAD in single units from Mouser. Most importantly, it's supported by a fully open-source toolchain, which saves me from having to deal with Quartus (mind you, I'm grateful that it's free, but I am not a Windows user, so it's pretty painful to use).


—Marco

Just working out some details. The physical hardware is not too bad, but what is going on in the FPGA is fairly complex.

The minimum cycle time for the DRAM is 110 ns, limiting the max access frequency to about 9MHz. Using a 25MHz base clock an 8.333MB/s bandwidth is used. 8MB/s bandwidth is shared between the display and CPU.

Note that a ph2 cycle time is six dot clocks giving a 4.167MHz CPU clock. The controller is complicated in that it reads RAM faster than it needs to, to output at a 25MHz dot clock. So, data is buffered for the scan line so that it may be read out at a 25 / 8 MHz rate.

There are 800 clocks in a scan line. Six clocks are required for every phi02 time, for a total of 133.333 phi02 clocks. Note that one-third of a phi02 cycle is needed to make the accesses in sync with the video timing. So, the first phi02 cycle is stretched to eight clocks (3 high, 5 low) instead of six (3 high, 3 low). This is like the ½ clock cycle added in the Apple II machine to make the horizontal timing come out to 63.5 us. It is the same kind of constraint.

80 phi02 clocks are needed to fetch character codes. The remaining 53 clocks are divided between sprite fetch and refresh. With two cycles of refresh, and 525 scan lines, 1050 rows can be scanned in 16.6ms. Four complete frames will refresh all 4096 rows of the DRAM. Since the DRAM has 64ms refresh requirements for 4096 rows, three refresh cycles per scan line was chosen; two is not quite fast enough. With 50 clocks available, 48 could be used for sprite access. Allowing three memory cycles for each sprite, thirty-two sprites can be supported. There are two idle cycles left over.

Unlike the VIC-II pointers to the sprite data are stored in the register file as opposed to the video memory. Storing the pointers in the register file makes for easier access by a Copper component.

Bad lines are in the design for character data fetch. They are relatively slightly less cumbersome because the dot clock is three times as fast meaning the bad line state is only about 2/3 as long for an 80-column display. The number of missed phi02 cycles doubles, but at the higher clock frequency the bad line is shorter in duration in terms of seconds.

I am finding out there will be a lot of registers in the design.

_________________
http://www.finitron.ca

I cannot find a source for the memory part. So, a 30-pin SIMM module may be used instead. 30-pin SIMM memory modules are available on ebay. These are typically 5V. I think I am correct in thinking that the 3.3V logic can drive 5V inputs. The only piece requiring level shifting is the data bus. The issue now is getting a footprint for the 30-pin SIMM socket. I have modified the schematic for the module.

_________________
http://www.finitron.ca

30pin SIMM modules are difficult to use due to the high power supply requirements.

Pls see here for my endeavors. http://www.6502.org/users/andre/csa/ramdisk/index.html
Also see the link in the side bar with a discussion with Bil Herd - hardware designer of the Commodore 128 - about how to design for dRAM.

_________________
Author of the GeckOS multitasking operating system, the usb65 stack, designer of the Micro-PET and many more 6502 content: http://6502.org/users/andre/

Thanks for writing down your conversations with Bil Herd about DRAM designs. Good discussions about delay taps and PCB design methodology for DRAM. I bookmark the link. I have not designed with SIMM30 but have worked with SIMM72 and individual DRAM chips implemented in 2-layer PCB with DRAM controller logic in CPLD. I have found it necessary to distribute multiple 10uF tantalum capacitors close to the DRAM. With SIMM72, I've found some brands are noisy causing memory diagnostic to fail. With falling price of 4-layer PCB, I'm migrating my designs with DRAM to 4-layer PCB which pretty much cured all the noise issues.
Bill

Thanks for the heads up on the SIMM modules. I have used DRAM before with great success. My first DRAM project was a 256kB bank switched RAM expander for the VIC-20. Way back when 256kB was a lot of memory. I remember buying the RAM chips one or two at a time when I could afford it, until I had enough chips.

5V power is coming from a PC power supply. There should be plenty of amps available.

I may switch the design to use Garth’s static RAM modules instead. It requires more chips though to latch the address signals. I may also be able to up the performance using SRAM. I think it should be possible to get at least 10MB/s out of the 10ns SRAM, once time through buffers is considered.
According to the RAM specs it should be possible to simply ground the output enable. A write enable signal will override the output enable. Access is chip enable, CE, controlled. The CAS signal is active high in this case, opposite to what it would be for DRAM, and it enables the ‘138 decoder. There is no CAS unless the RAM is going to be activated. This is controlled by decoding the row address lines.

To come up with a 3V supply I was thinking of just using two diode drops from a 5V supply instead of a regulator IC. The diodes drop about 1V or less. The logic is CMOS so, can operate between 2V and 6V.

Why don’t data sheets give timing specs for operation at 3.3V which is a common operating voltage?

Schematics using SRAM module

_________________
http://www.finitron.ca

With the availability of SRAM, the timing was modified to use a 33MHz base clock for memory access. The video base clock remains 25MHz. 3 memory clocks are used per access for an access rate of 11MHz. This works out to a 5.5MHz phi02 processor clock. When a 33MHz clock is used it turns out to be exactly 1056 clock cycles per 800 25MHz clocks. That means it is no longer necessary to stretch the phi02 clock. The circuitry in the FPGA is turning out to be complicated due to the different data fetch and display rates. Doubling up on counters and using fifos.

Since the display area is double the horizontal and vertical resolution of the VIC-II sprites are relatively much smaller objects. To compensate the vertical size of sprites has been doubled and sprites may be linked horizontally to double the horizontal size. The memory capacity is much larger than the 16kB limit of the VIC-II. There is enough room in memory to make the sprites larger in this case 24x42.

Each sprite requires 126 bytes of RAM. 2x the VIC-II requirements. Only 32 sprites are supported. There is enough room on the scanline to support up to 60 sprites, but the additional cycles are used as CPU processing cycles. Sprite data is fetched after character data on the scanline. The character data needs to be fetched before it is displayed.

Even, odd pairs of sprites can be linked such that the Y coordinate is in common, and the X coordinate of the odd sprite is automatically set to 24 greater than that of the even one. This can be used to create a 48x42 sprite whose coordinates can be manipulated using only one set of registers.
One option considered was simply using fewer larger sprites. I felt it was better to have more smaller sprites, as larger images can be built out of smaller ones.

_________________
http://www.finitron.ca

Planned register set for video controller. The video controller internally decodes the register set to address $D00xxx
Missing yet is possibly color palette control.

_________________
http://www.finitron.ca

Kids nowadays won't believe that we bought RAM in individual bit slices. Actual conversation at an electronics retailer:-

Seller: You know that's one bit RAM. It won't work on its own.
Buyer: If I can get this one working, I'll come back and buy another seven. There's no point buying eight if I can't the first one to work.



Smaller sprites are preferable, especially when they can be ganged.

Some systems are sprite only because sprites are sufficiently flexible. For example, sprites can be used to make a text display. Indeed, if you can extend your system to 80 sprites, you may have 80 column text as a corollary. It you weren't aiming for VIC-II compatibility, I would suggest a sprite only system where a double buffered line buffer is only populated with sprite data. If it is convenient in your implementation, this configuration could be offered as one of the extended modes.

I've briefly considered VIC-II compatibility within John West's C640 project. A quick win is to upscale 8*8 text (320*200 pixels) to 16*16 text (640*400 pixels) which is more suitable for VGA display. You are very brave to add sprites and maintain timing compatibility. I'd be much more inclined follow Atari's approach and use the legacy bitmaps and sprites as overlays. Either way, if the legacy display is decoupled and timings are maintained, there is scope to have a wider bus and, for example, 24 bit RGB polygon blitting. For memory map compatibility, the additional bus and memory do not have to be exposed to 6502. Only the blitter registers need to be accessible to 6502. From here, the next obvious step is a co-processor which feeds the polygon blitter. If bandwidth for display has migrated to a separate bus, 6502 low bus phase may be allocated to co-processor read operations. Co-processor writes may be restricted to a shadow set of polygon blitter registers using a separate write strobe. This averts the two sequential write problem on 65xx/68xx bus. Specifically, processor and co-processor can write to the same peripheral chip with abandon. Notably, this all works with low scale integration.

The general principle is that Commodore64 successors could have greatly exceeded the capability of Commodore Amiga systems. VIC and VIC-II have notoriously tight timing but there remain many ways to extend them. There is an argument that VIC-II systems have cruft. However, I counter that x86 displays invariably have cruft derived from 6845 - and even clean sheets designs, such as the Amiga shipped with cruft from the outset. Specifically, the Amiga's HAM [Hold And Modify] mode was intended for military style flight simulator games working in YUV color-space. After a decision was made to switch to RGB rather than YUV, the HAM circuitry was not removed.

_________________
Modules | Processors | Boards | Boxes | Beep, Beep! I'm a sheep!