BBC Model B implementatation for myStorm BlackIce

[RetepV]

Ahem, good spot. They’re 82 ohm, not 82k! I’ll fix it when home.

*Fixed

[wbvreeuwijk]

Hi All,

Have there been any attempts to get this running on an BlackIce MX? Or should it just work?

Bas

[lawrie]

No, it won't work.

It is quite hard to convert it to use SDRAM, because of the way it uses video ram.

[wbvreeuwijk]

That's a bit of a shame as that was the main reason for me to get into the blackice platform, it appears I should have investigated more. Would adding an external module for the RAM be an option? or are there other ways (other then getting an blackice II or looking at other FPGA solutions) to make this work?

[BigEd]

It is quite hard to convert it to use SDRAM, because of the way it uses video ram.

Just to check - is this still the state of play:

Blackice Mx SDRAM access

Here is a much simpler SDRAM implementation from the Mist/Mister project. It is the Gameboy variant that has a 64Mhz clock and accesses the ram (both reads and writes) in a fixed 8 cycles to simulate 8MHz asynchronous DRAM.

It relies of there being frequent, predictable periods where the RAM is not being accessed and refresh can be done, so refresh never interrupts reads and writes.

[lawrie]

I think so. I used that SDRAM controller for the Blackice Mx Atom and NES implementations, but I think it is harder for BBC, which uses a lot of video ram and does not have it at a fixed address.

There is a discussion with @hoglet about this somewhere on the forum.

[BigEd]

I've got a feeling Dave has rejigged his clocking story this year, so it might be worth a new look.

[r.miller]

It is quite hard to convert it to use SDRAM, because of the way it uses video ram.

What exactly is the requirement? does it just need reads to complete in a fixed amount of time? Since video scanning order is predictable, would it be possible to introduce a sneaky readahead cache to hide the page-switching and refresh delays?

[lawrie]

What exactly is the requirement?

I found the comment from @hoglet on this - https://forum.mystorm.uk/t/apple-one-on-blackice-mx/675/3

The problem seems to be that the Beeb core currently requires the SDRAM to run at 32Mhz. With an SDRAM implementation that uses 8 cycles for reads and writes, that would need a 256MHz sd ram clock. So changes to the Beeb core would be needed and I have never looked at that. I do have the Beeb running on a Ulx3s board but that uses BRAM for everything.

[hoglet]

I've done a lot of work to the main version of BeebFPGA recently, and one of thie things that I fixed was the RAM timing:

Clock rework: rework memory timing (work in progress)

Memory timing rework: support slower SRAMs

This reduced the memory bandwidth from 32MHz to 8MHz, and it could be reduced further to 4MHz if the 65C02 Co Processor is not included.

I don't currently have any plans to port this (or any of the many other improvements) to Ice40Beeb.

Dave

[r.miller]

Is it the case that the SDRAM controller doesn't need to do any refresh operations itself, because the video scan will be touching (opening and precharging) every memory row sufficiently often?

[lawrie]

The sdram controllers I have used on retro computer projects just do an auto refresh when no requests are active. The design just needs to have sufficient clock cycles when there are no requests. Most retro computer projects run the CPU at low clock rates so there are plenty of spare cycles. At least that is my understanding.

Here is an example of such a controller that I am using the 68000 CPU projects at the moment - https://github.com/lawrie/ulx3s_68k/blob/master/src/sdram.v

[r.miller]

Most retro computer projects run the CPU at low clock rates so there are plenty of spare cycles.

So in the current ice40 BBC B implementation, "requires the SDRAM to run at 32Mhz" actually doesn't mean a sustained bandwidth of 32MByte/sec, but means a latency of no more than 1/32000000 sec or 31.25 nsec for each memory fetch?

[lawrie]

Yes, I believe what David Banks meant was that when a request is made from a clock running at 32MHz, the data must be available on the next clock cycle.

The Mist/Mister SDRAM implementation can do a read in exactly 8 clock cycles of the sdram clock, so that needs to be 8 times as fast as the clock that makes the request.

Now that David has reduced the requirement of the clock that makes the request to 8MHz, an sdram clock of 64MHz could be used, which I have successfully used on a Blackice Mx board.

[wbvreeuwijk]

So does this mean that there is hope of getting the BeebFpga running on the Blackie MX?

Coming from a time when I was soldering piggyback SDRAM in my Acorn Atom I have only a few weeks ago discovered the wonderful world of FPGA and I have yet to start exploring coding.

[lawrie]

There is hope, but there would still be work to do applying @hoglet's changes to the ice40 version. I do plan to spend some time getting various other retro computers running on the Mx, and have started looking at the MSX. But I am also working on the Ulx3s board, and am working on 68000 CPU machines on that at the moment.

@r.miller may be interested in one of our 68k projects for the Ulx3s board, as it is a precursor of Plan9 - http://doc.cat-v.org/bell_labs/blit

[r.miller]

@r.miller may be interested in one of our 68k projects for the Ulx3s board, as it is a precursor of Plan9 - http://doc.cat-v.org/bell_labs/blit

Indeed I would be very interested in the resurrection of the Blit. A Plan 9 kernel is available for a successor of that machine (the 68020-based Gnot), but I don't know about availablity of the Blit terminal firmware.

[wbvreeuwijk]

As I'm also awaiting the delivery of my ULX3S board your work is much appreciated @lawrie.
Once I have a better understanding of what is involved I will look forward to be able to contribute.

[lawrie]

Paul Ruiz on the Ulx3s gitter wrote:

Later this Summer, I'd be interested in that - doing a model for the 1981/2 "Blit" has been on my to-do list for a long time (http://doc.cat-v.org/bell_labs/blit/). The hardware is simple (68K, ROM, RAM and a straightforward b/w bitmap video circuit), and the source code survived, including for the tool chain (assembler, C compiler, etc.) This sounds a lot like the base circuit that you mentioned.

We have been working together (along with emard from ulx3s) on 68k computers, and have an M68K SBC and a machine with video modes similar to a Sinclair QL and VGA/HDMI output.

I believe Paul has all the source and has tried out the compiler for the Blit.

[lawrie]

There is a nice video on the Blit - http://doc.cat-v.org/bell_labs/blit/

I suspect that a lot of the 68k stuff with work on the Blackice Mx with some modification. It is now all Verilog. The CPU was converted from System Verilog.

The SBC uses SDRAM and should work with the Blackice Mx SDRAM.- https://gitlab.com/pnru/ulx3s-misc/-/tree/master/M68K, but the memory model would need to be changed to use less BRAM.