Recreating the history of computers on open source FPGAs

lawrie 2019-09-10 17:44:37 UTC #1

If I ever give a talk at an open source hardware event like the recent OSHCamp, it will be on recreating the history of computers on open source FPGAs.

Here is a start:

github.com

lawrie/fpga-computer-history/blob/master/README.md

# Recreating the history of computers on open source FPGAs

## 1940s

### Manchester Baby

The first stored program computer was the Manchester Baby, which ran its first program on 21 June 1948

I recreated this on a Blackice II ice40 hx4k FPGA using an LED panel to simulate the cathode ray tube used for memory.

Click on the picture to play the video.

[![Manchester Baby](https://img.youtube.com/vi/effNf-3IUxI/maxresdefault.jpg)](https://youtu.be/effNf-3IUxI)

### EDSAC

This was shortly followed by the Cambridge University EDSAC computer that ran its first programs on 6 May 1949.

The EDSAC was recreated on a Blackice I at the Chiphack event in Hedben Bridge in 2017.

This file has been truncated. show original

AndyCap 2019-09-10 20:21:58 UTC #2

Nice Stuff, I'd like to get the CP/M going, what is it a 380z?

lawrie 2019-09-11 08:24:00 UTC #4

The next thing I should do to this is add source and forum references for all the implementations. And give credit to the authors.

The Z80 implementation was by David Banks (@hoglet or hoglet67) - https://github.com/hoglet67/Ice40CPMZ80

The SD card it uses is here - https://obsolescence.wixsite.com/obsolescence/multicomp-fpga-cpm-demo-disk

I did the changes from Blackice i to Blackice II - see https://forum.mystorm.uk/t/ice40cpmz80-on-blackice-ii/419/3

The original work, like a lot of work on the Z80, was by Grant Searle - http://searle.hostei.com/grant/Multicomp/cpm/fpgaCPM.html

I don't think it was based on a specific machine.

A Blackice Mx implementation would need an SDRAM controller.

I have one working in SpinalHDL but I would need to generate a controller with a simple interface in Verilog for it to be useful in retro computer projects. I will look at that some time, but it is currently tied to things like the Bmb bus in the SaxonSoc implementation.

Dan Gisselquist (Zipcpu) has one - https://github.com/ZipCPU/zipstormmx/blob/master/rtl/wbsdram.v

That uses a wishbone bus, which is not the easiest interface for retro computer implementations, so a version of that with a slightly simpler interface would be useful.

AndyCap 2019-09-11 08:33:55 UTC #5

Thanks for the info.

How is the display and keyboard being handled, is that a little HDMI monitor or is it all UART?

lawrie 2019-09-11 08:38:52 UTC #6

The display is VGA via the Digilent Pmod and the keyboard is PS/2, which again, I used a Digilent Pmod for.

AndyCap 2019-09-11 08:40:19 UTC #7

Thanks Laurie. I will have a look through the github stuff...

lawrie 2019-09-11 09:04:18 UTC #8

Another thing we would have to change for a Blackice Mx port (apart from SDRAM - see above) is the way that ROMs are dealt with.

They were usually included with the bitstream in the STM32 flash memory and then sent to the ice40 via SPI and written to the SRAM. That required changes to the iceboot firmware.

On the Blackice Mx, it would probably be easier to read them from the external SPI flash memory, or possible even to execute them from there.

It would be good to get @hoglet's projects working on the Blackice Mx. They include this one, the Acorn Atom, the BBC Micro, the Jupiter Ace, and the Dangerous Prototypes Logic Sniffer.

Elminster 2019-09-11 09:07:16 UTC #9

The SDRAM controller (or lack therefore of) is also why Dave (Hoglet) said it was tricky to move his BlackIce Acorn Atom implementation to BlackIce Mx. Would be good if the Atom could be ported to MX.

BigEd 2019-09-11 13:52:25 UTC #10

Nice meta-project Lawrie! I've reposted over on the retrocomputing forum:

Folknology 2019-09-16 07:23:28 UTC #11

The idea is to get Dan's implementation working and then optimised. This would provide a basis for other versions of the controller for other busses, WishBone is used initially as this is both popular and works well with existing peripherals like the flash controller. A lot of the hard stuff is now done (like calibrations and timing etc..) so it just needs someone familiar with the addressing and bus requirements of any new target..

lawrie 2019-09-16 07:56:34 UTC #12

Most retro-computer implementations don't use a standard bus interface. The mist and mister projects have collected together most of the retro computer projects and most of them use sdram. I think the sdram interface is slightly different for each target.

Here is the version for the Gameboy -

github.com

mist-devel/mist-board/blob/master/cores/gameboy/sdram.sv#L32


//
//
// This SDRAM module provides/writes the data in 8 cycles of clock.
// So, with 64MHz of system clock, it can emulate 8MHz asynchronous DRAM.
//
//


module sdram
(


	// interface to the MT48LC16M16 chip
	inout [15:0]  		sd_data,    // 16 bit bidirectional data bus
	output reg [12:0]	sd_addr,    // 13 bit multiplexed address bus
	output reg [1:0] 	sd_dqm,     // two byte masks
	output reg [1:0] 	sd_ba,      // two banks
	output 				sd_cs,      // a single chip select
	output 				sd_we,      // write enable
	output 				sd_ras,     // row address select
	output 				sd_cas,     // columns address select


	// cpu/chipset interface

And here is the version for the ZX Spectrum:

github.com

MiSTer-devel/ZX-Spectrum_MISTer/blob/master/sdram.sv#L31


// You should have received a copy of the GNU General Public License 
// along with this program.  If not, see <http://www.gnu.org/licenses/>.
//
// ------------------------------------------
//
// v2.1 - Add universal 8/16 bit mode.
//


module sdram
(
input             init,        // reset to initialize RAM
input             clk,         // clock ~100MHz
                               //
                               // SDRAM_* - signals to the MT48LC16M16 chip
inout  reg [15:0] SDRAM_DQ,    // 16 bit bidirectional data bus
output reg [12:0] SDRAM_A,     // 13 bit multiplexed address bus
output reg        SDRAM_DQML,  // two byte masks
output reg        SDRAM_DQMH,  // 
output reg  [1:0] SDRAM_BA,    // two banks
output            SDRAM_nCS,   // a single chip select
output            SDRAM_nWE,   // write enable

They seem to differ in the required clock speed and how it is indicated whether the data is ready. The Spectrum version has a ready flag, whereas the Gameboy version seem to assume it will be ready in 8 cycles.

They both have a 16-bit data bus and mode flags to say if the upper or lower bytes are being written. Both have read and write enable signals.

For the Blackice Mx version the address would presumably have to be reduced to 21 bits (2 Mb).

lawrie 2019-09-16 15:58:33 UTC #13

The SDRAM controller used by the MIST and MISTER projects is an order of magnitude simpler than either the SpinalHDL one or Dan's one, so I wonder if it will work on the Blackice Mx board.

One reason it is simpler seems to be that it is specifically tailored to the timing and layout of a specific SDRAM RAM chip.

Another reason seems to be that the refresh logic can be much simpler as the retro computers have regular periods when the RAM is not accessed and the refresh can be done during those periods.

The system I am currently most interested in is the Gameboy.

The Mist/Mister SDRAM implementation for that runs the clock at 64MHz and can read or write a 16-bit word in 8 clock cycles. It does the refresh when neither a read or write is active.

I plan to investigate and experiment to see if that will run on the Blackice Mx.

Folknology 2019-09-19 10:57:05 UTC #14

Yeah I noticed that, it would be interesting if you could make it work by changing the address range and bank usage..

lawrie 2019-09-19 11:15:21 UTC #15

Yes, I have started to try to do that. It also needs at least an SB_IO to set the direction for the data pins.

I have started another post on trying to understand the various implementations of SDRAM.

Dan's code is currently hard to use because of the way it is embedded in a whole complex implementation that uses zipcpu, the wishbone bus, formal verification, his auto-gen system, etc. I was thinking of trying to get it running but there is quite a bit of stuff to install, a steep learning curve, and it really needs some changes, for example to use the usb uart, which was not working when he wrote the code.

But then the SpinalHDL implementation probably has a steeper learning curve.

Folknology 2019-09-19 11:18:13 UTC #16

Yes I think dans normal approach is unified so it will probably lean on his DDRRAM Verilog and use IO attributes etc..

However I think a simpler implementation can be achieved with and without those IO attributes

lawrie 2019-09-19 11:29:31 UTC #17

I will probably try an implementation with just the tri-state SB_IO for the data as that is definitely need as it was for SRAM on the Blackice II.

But I doubt if it will work at the 64Mhz clock rate which would be necessary for the Gameboy implementation.