Close

SDRAM Working in a Different Context

A project log for Retro 68000 CPU in an FPGA

Making a Retrocomputer with a 68000 CPU in an FPGA

land-boardscomland-boards.com 09/05/2020 at 12:280 Comments

There's an interesting project from 2014 called TG68 Experiments at Retro Ramblings (AMR) to create a 68000 CPU that uses the SDRAM on these inexpensive FPGA cards. The project starts with the 68K same core (TG68) I've been using by Tobias Gubener and builds on it. It improves on the TG68 SDRAM design considerably. Here's the GitHub repository for the project.

This project has quite a few appealing features including a large frame buffer and the ability to load code from an SD Card. AMR has spent quite a bit of time building a fast SDRAM interface including a 2-way associative cache. He also does pixel dithering which I used to map the 16 bit graphics to the 6-bits of the RETRO-EP4CE15 card. 

It took a solid day of fumbling around to port it to my RETRO-EP4CE15 card with a Cyclone V FPGA card but it's now running. In the end I routed some of the obvious lines (resets. clocks) out to the FPGA's extra I/O pins and used my logic analyzer and scope to debug the problems. The project is pretty well documented but the following are my notes from the port.

Here's a picture of the screen on a VGA monitor.

Fits in Cyclone V FPGA

There's plenty of room on the Cyclone V FPGA. It should fit in a smaller FPGA just fine.

Started with Cyclone III Example

AMR chose a cheap Cyclone III card from flea bay. I chose to port the Cyclone III example thinking it might be closer to my Cyclone V FPGA card than the other board examples. That might not be the case, but it is what I did. The other boards had a lot more LEDs, switches, etc. The Cyclone III card had minimal resources.

The card had two SDRAMs so it took some effort to remove support for the second SDRAM. In fact, that was the last domino to fall since I still had VHDL fragments from the 2nd PLL which I had only partially removed so it was causing the 68K to stay in reset.

Serial Port Message

On the way to booting, this status message was printed to the serial port (at 115,200 baud) (several reboots shown below):

SD Card Contents

AMR's TG68 Experiments needs an SD card with some specific contents, namely an S-Record file with the boot code. AMR bootstraps directly from the SD card so the bootstrap code needs to be in the root folder with a specific file name.

If you want to try it out, just copy the file 
CFirmware/out.srec to the root of the SD card, 
and rename it to “boot.sre”. 

That seems to be working since I see a window on the VGA screen with S-Records. 

Here's one of the s-records from the VGA screen compared to the out.srec file contents. Not sure why there's less lines in the window but the one line does look right.

I wonder if this shouldn't be different code, namely the sdbootstrap.srec file.

I tried a few different sre files and they seemed to all work.

Replaced the PLL with a Cyclone V PLL

Quartus seems finicky with upgrading the PLL so I re-generated another one. The outputs are 100 MHz, 100 MHz, and 25 MHz in case someone tries to figure it out.

How the Top Looks in Quartus

This view of the hierarchy in Quartus might be helpful:

Building the Code

I copied the code to my Linux Virtual Machine (built earlier). However the code requires vasm which I don't have at the moemnt.

My GitHub Repo

The code for this project is in my Retro-Computers GitHub repository. The VHDL code for the build starts in here.

End of TS2 Series?

This could be the end of this TS2 series. I think I will shift over to getting the TG68 as implemented by AMR working.

Postscript

Rebuilt the EP4CE15 version of the card using the lessons learned from the Cyclone V build including the busstate signals and the External 1MB SRAM. Tested the build and it worked. Here in GitHub.

Discussions