MNT VA2000 graphics card in a Mega ST

General discussions or ideas about hardware.
keli
Posts: 62
Joined: Tue Aug 22, 2017 1:34 pm

MNT VA2000 graphics card in a Mega ST

Post by keli » Mon Nov 20, 2017 5:28 pm

I recently found this open source FPGA graphics card made for the Amiga ZORRO II/III expansion bus. After studying the inner workings of the ZORRO II expansion bus, I noticed it was pretty close to the bare m68000 CPU bus.

Feeling brave, I ordered a card from his web shop and now I have a shiny Spartan 6 based card in a nice little cardboard box lying on my desktop.
IMG_20171120_181218.jpg
IMG_20171120_181218.jpg (2.87 MiB) Viewed 906 times
After studying the Verilog source, I realized creating a fully compatible Zorro adapter is out of my reach, but probably also an overkill, as due to the openness of the firmware, I can just change the firmware to talk directly to the CPU bus. This means I only need a physical adapter from the 100 pin Zorro II card edge connector to the 64 pin DIN type B connector on the Mega ST motherboard.

There was a slight hitch with the /DTACK pin on the VA2000. The level converter it is wired through is set to always drive the pin, whereas on the 68k bus it must be an open collector. I think I solved it by connecting the pin to the enable pin on a 74125 buffer, with it's input wired to GND and output to the expansion pin. Here's the final schematic showing the almost 1-1 wiring. Extra pins I won't be using, I wired to a pin header, useful for some future experiments:
2017-11-20 (1).png
2017-11-20 (1).png (224.93 KiB) Viewed 906 times
... and the PCB ended up looking like this:
2017-11-20 (3).png
2017-11-20 (3).png (50.59 KiB) Viewed 906 times
Now I just need to get a prototype pcb ordered, solder everything together, and rewrite the FPGA firmware. Piece of cake, eh?

User avatar
exxos
Site Admin
Posts: 2924
Joined: Wed Aug 16, 2017 11:19 pm
Location: UK
Contact:

Re: MNT VA2000 graphics card in a Mega ST

Post by exxos » Mon Nov 20, 2017 5:43 pm

Looks interesting! What are the actual specs for the card ? Though assume there will also need to be drivers done for the ST..
4MB STFM 1.44 FD- VELOCE+ 020 STE - 4MB STE 32MHz - STFM 16MHz - STM - MEGA ST - Falcon 030 CT60 - Atari 2600 - Atari 7800 - Gigafile - SD Floppy Emulator - PeST - HxC - CosmosEx - Ultrasatan - various clutter

https://www.exxoshost.co.uk/atari/ All my hardware guides - mods - games - STOS
https://www.exxoshost.co.uk/atari/last/storenew/ - All my hardware mods for sale - Please help support by making a purchase.

User avatar
arf
Posts: 58
Joined: Sun Oct 29, 2017 9:30 am

Re: MNT VA2000 graphics card in a Mega ST

Post by arf » Mon Nov 20, 2017 6:03 pm

exxos wrote:
Mon Nov 20, 2017 5:43 pm
Looks interesting! What are the actual specs for the card ? Though assume there will also need to be drivers done for the ST..
http://mntshop.bigcartel.com/product/mn ... 2-preorder --

• Up to 1280x720p HD screen resolution at 8bit 256-colors "Chunky", 16bit or 32bit color depths.
• Experimental 1920x1080 Full HD screen resolution if your monitor supports 30Hz.
• Other supported resolutions: 320x200, 320x240, 640x480, 800x600, 1024x768

And some making-of
--
Against signature spam!

keli
Posts: 62
Joined: Tue Aug 22, 2017 1:34 pm

Re: MNT VA2000 graphics card in a Mega ST

Post by keli » Mon Nov 20, 2017 6:26 pm

exxos wrote:
Mon Nov 20, 2017 5:43 pm
Looks interesting! What are the actual specs for the card ? Though assume there will also need to be drivers done for the ST..
It's based on the MiniSpartan6+ and he originally just made an adapter board with just the level converters and sockets for that board. It has later evolved into a board on its own, presumably with some help from the makers of the MiniSpartan.

The specs are going to depend on the firmware running on the card, but it should be fairly powerful. -- It also has 32Mb of SDRAM, a USB port for updating the firmware, and an SDCard socket.

... And yes drivers... I plan on writing one for FVDI, once I get the hardware part going. ;) (Initially while debugging the bus interface I'll probably be writing test code that accesses the hardware directly.)

User avatar
Icky
Posts: 116
Joined: Sun Sep 03, 2017 10:57 am
Location: UK

Re: MNT VA2000 graphics card in a Mega ST

Post by Icky » Wed Nov 22, 2017 7:37 am

Great to see someone taking the Atart ST graphics card upgrade by both horns. I know it has been talked about on other forums of a FPGA graphics card for the ST and there has been an attempt in the past of a VME card https://www.exxoshost.co.uk/atari/mirro ... galaxy.htm.

I do believe these are exciting times with Exxos, yourself and many others that are pushing the boundaries of the old Atari and bringing it into this century.

With all these add-ons of boosters, ram, ide, graphics we should in the future have one amazing system to use.

keli
Posts: 62
Joined: Tue Aug 22, 2017 1:34 pm

Re: MNT VA2000 graphics card in a Mega ST

Post by keli » Wed Nov 29, 2017 6:25 pm

I just received the PCB for my adapter. I used ALLPCB and ordered 5 copies for USD 16.00. (Actually received 7)

I have all the components, so as soon as I have a few spare clock cycles, I will have to start soldering.
pcb 1.jpg
pcb 1.jpg (263.28 KiB) Viewed 803 times
I used the footprint for a straight DIN connector for the MegaBus, but am actually using a 90 degree one. That's why the holes are not lining up.
pcb 2.jpg
pcb 2.jpg (540.53 KiB) Viewed 803 times

keli
Posts: 62
Joined: Tue Aug 22, 2017 1:34 pm

Re: MNT VA2000 graphics card in a Mega ST

Post by keli » Thu Dec 07, 2017 3:53 pm

A small status update.

I managed to solder the sockets on to the adapter board and have done some testing.

First the bad news:
The bidirectional voltage converters/buffers on the VA2000 all have their /OE pins hardwired to ground. This means that while the FPGA is powering up, its outputs have an undefined state, which means that the buffers may end up driving random data on the address and data pins, preventing the machine from cold-booting. Hitting reset after the FPGA is configured will allow the machine to boot however.

This probably works okay on the Amiga, as the Zorro II bus is buffered. The recommendation for the level converters to add a weak pullup on /OE and then drive it low once everything is powered up should have been followed IMO.

Then the good news:
I converted a small test pattern generator to react to writes on the m68k bus and can get it to change patterns from a small GFA basic program. It originally used dip switches to change the pattern generated, but I had it react to a write to address $C00000 from the ST side instead. I'm still having problems with sending /DTACK back though, so I do get a bus error from the GLUE after a timeout. Hopefully I can get that part solved in the HDL source.
gfa.jpg
gfa.jpg (211.35 KiB) Viewed 755 times
The end result is that while I probably will be able to create a graphics card in Verilog and get it to work, some design differences will require me to use a different FPGA board and implement my own voltage level conversion. Since the VA2000 is closely built on Scarab hardware's Minispartan6+, it is a close contender for an alternative.

keli
Posts: 62
Joined: Tue Aug 22, 2017 1:34 pm

Re: MNT VA2000 graphics card in a Mega ST

Post by keli » Thu Dec 21, 2017 2:51 pm

Update as of 12/21/2017:

I started a new HDL project from scratch instead of trying to understand all of the original VA2000 sources, as almost all of the logic was in the top file... most of it in a huge state machine.

Instead I've divided everything into small modules talking to each other using the wishbone bus. This also means I can reuse a lot of open IP that conforms to the Wishbone specification.

I created a module that supports a subset of the 68000 bus interface and converts it to Wishbone, which is then routed to a bus arbiter and some address translation. Getting the states running smoothly and crossing the clock domains from the external bus to the internal logic was fairly easy... after reading 100s of online resources on clock domain crossing, of course :)
The biggest problem was getting the /DTACK signal sent back upon successful read and writes. I originally thought that my 74xx logic for converting the signal to open collector was faulty... turned out I just had missed that the /UDS and /LDS data strobes where active low and not active high, making me assert /DTACK at the wrong moment. (Meaning the faulty logic was in the brain of the author and not in silicon :P)

Currently I have access to the SDRAM on the board. It can even handle silently mirroring writes to ST-RAM (more about that later)

For now it recognizes the following address ranges: (I do not play well with other extensions... as I use up most of the address space ;) )
  • $000008 - $3FFFFF: ST ram, writes are mirrored to the SDRAM.
  • $400000 - $4FFFFF: Nothing. - I had to put a hole here, as otherwise TOS thought it had more ST-ram and failed to boot.
  • $500000 - $CFFFFF: 8MB of Alt-ram.
  • $D00000 - $DFFFFF: 1MB window of remappable RAM (can be set to point to any 1MB-aligned offset in the 32MB SDRAM)
  • $F00201 : 5 bit register to set the offset of the remappable buffer at $D00000
I spent a lot of headscratching why memory reads weren't reliable, until I realized I had tuned the latency settings for 50MHz, but was clocking everything at 100MHz... DOH!

No graphics output yet, except for a dummy checkerboard raster at 1280*800, but I have plans of reading the SDRAM in bursts, feeding the data into a FIFO, and outputting them from a video generator running at the pixel clock rate. Since I can mirror writes to ST-RAM, I should be able to emulate the standard ST resolutions until custom drivers have been loaded (and I mean standard, timing will be completely off, so any raster effects and the like will be off-limits.)

User avatar
exxos
Site Admin
Posts: 2924
Joined: Wed Aug 16, 2017 11:19 pm
Location: UK
Contact:

Re: MNT VA2000 graphics card in a Mega ST

Post by exxos » Thu Dec 21, 2017 3:38 pm

Really interesting stuff :bravo:

/DTACK with the clock domain crossing can be more complicated than it seems.. The problem with /DTACK with a lot of the Atari chips is that it can arrive at any time, but, it generally arrives a fraction too early before the data is actually ready to read.

In terms of ROM access for example, /DTACK basically follows /AS. But in terms of ram access, when /DTACK arrives, it is somewhere around the nanoseconds to early and data from the RAM is not actually ready yet..

I mention this because it clock domain switching normally syncs to a clock edge, but in the case of /DTACK, data is actually ready in the middle of the 8 MHz clock low cycle.. Of course if you read this a fraction too late it is generally not a problem.. But as I found with my boosters, you can start to lose speed even though it should not really matter exactly when data is latched..

It is just one of those really strange things that can have you scratching your head for a really long time.. May or may not help with your work :)
4MB STFM 1.44 FD- VELOCE+ 020 STE - 4MB STE 32MHz - STFM 16MHz - STM - MEGA ST - Falcon 030 CT60 - Atari 2600 - Atari 7800 - Gigafile - SD Floppy Emulator - PeST - HxC - CosmosEx - Ultrasatan - various clutter

https://www.exxoshost.co.uk/atari/ All my hardware guides - mods - games - STOS
https://www.exxoshost.co.uk/atari/last/storenew/ - All my hardware mods for sale - Please help support by making a purchase.

keli
Posts: 62
Joined: Tue Aug 22, 2017 1:34 pm

Re: MNT VA2000 graphics card in a Mega ST

Post by keli » Thu Dec 21, 2017 4:01 pm

exxos wrote:
Thu Dec 21, 2017 3:38 pm
/DTACK with the clock domain crossing can be more complicated than it seems.. The problem with /DTACK with a lot of the Atari chips is that it can arrive at any time, but, it generally arrives a fraction too early before the data is actually ready to read.
Yes all that /DTACK is imo a design flaw with the 68000 bus, the bus is nominally asynchronous, but since the CPU latches the data minimum one clock cycle after /DTACK is asserted (iff it's asserted during S4 or later, if /DTACK is asserted earlier, the CPU will behave as if /DTACK was asserted on S4 and latch the data on S6 anyway), the peripheral needs to know the speed of the processor if it wants to assert /DTACK ahead of time.

Luckily for me, I'm running a bit faster, so both data and /DTACK are ready much sooner.

When going from the external bus, I only sync on /AS, /UDS and /LDS. I ignore the clock completely

Post Reply