Next on Mist?

Time to talk about what other machines can run on the Next hardware!
johey
Posts: 22
Joined: Wed May 31, 2017 7:33 pm

Next on Mist?

Post by johey » Thu Jun 01, 2017 7:32 pm

Will it be possible to make a port of the Next core to the Mist board? Of course you'd loose the expansion port etc, but it still would be quite nice to have the core running.

User avatar
mcleod_ideafix
Posts: 70
Joined: Mon May 29, 2017 9:38 pm
Location: Spain
Contact:

Re: Next on Mist?

Post by mcleod_ideafix » Thu Jun 01, 2017 9:34 pm

The type of RAM present in the MiST may possibly present some problems in order to implement some features.
http://www.zxuno.com
ZX-Uno · FPGA ZX Spectrum clone.

User avatar
NightShadowPT
Posts: 10
Joined: Tue May 30, 2017 1:45 pm

Re: Next on Mist?

Post by NightShadowPT » Fri Jun 09, 2017 1:23 pm

Can you elaborate a bit more? Why is the MiST memory a problem?

Thanks!
---------------------------------------------
ZX Spectrum 48K // ZX Spectrum + // ZX Spectrum 128 // ZX Spectrum +2 // Timex 2048 // Mist FPGA // ZX Spectrum Vega + (some day) // ZX Spectrum Next (on its way)

User avatar
mcleod_ideafix
Posts: 70
Joined: Mon May 29, 2017 9:38 pm
Location: Spain
Contact:

Re: Next on Mist?

Post by mcleod_ideafix » Sat Jun 10, 2017 12:53 am

NightShadowPT wrote:
Fri Jun 09, 2017 1:23 pm
Can you elaborate a bit more? Why is the MiST memory a problem?

Thanks!
MIST uses SDRAM for external memory. Even at 133 MHz, SRAM is a bottleneck when it comes to random accesses, as SDRAM/DDR/DDR2/etc memories are optimized for burst reads. This poses a problem when you want to implement a system that uses memory so that two masters (ULA and Z80) can share that memory WITHOUT having to halt the CPU. Remember that in the original Spectrum, not all the memory is contended. There were two different physical memory banks. MIST has only one physical bank.

When this happens, a solution is to interleave acess between ULA and Z80. For that to work, the RAM has to be fast enough to serve two bus masters one after the other so that none of them needs to wait for data. Both masters will ask for different chunks of data, not neccesarily contiguous, so a burst access won't be of much use here.

And that's the trouble: SDRAM, used for random access, is slow (about 70ns). Very slow compared to the SRAM used in the Next (10ns). This is because for every single memory access which is not part of a burst, a number of operations have to be carried out. See the following FSM, taken from http://www.yikes.com/~ptolemy/writings/verilog/
controllerfsm.jpg
controllerfsm.jpg (111.83 KiB) Viewed 2472 times
For any random read or write operation, a total of 8 cycles are required. If the clock speed is 133 MHz (MIST), that is, 7.5ns, this means that the SDRAM needs 8*7.5 = 60ns to complete a random read/write operation.

MIST developers are aware of this, and some times they need to implement small caches or buffers using internal FPGA memory to decouple memory accesses so that the system (the CPU) has not to wait for memory, but this complicates the design and waste precious internal FPGA RAM that the Next use to implement sprite memory. I know that MIST developers had some problems when porting my SAM Coupé core, originally intended to use fast SRAM to share memory between CPU and Sam Coupé ASIC.

In fact, this is why asynchronous SRAM is preferred to SDRAM or DDR when using FPGA to recreate ancient computers. Ancient computers, specially if they have had a long shelf life and used in demoscene productions and the like, have a lot of software that rely on precise CPU timings to implement various effects. Those timings must not be changed because of added wait states to cope with memory speed. So, either you use many different memory chips to increase bandwidth by implementing private buses (thus, wasting many pins from the FPGA) or you use a fast memory and implement a time sharing mechanism to emulate the behaviour of two or more different memories being used by different systems inside the recreated system.
http://www.zxuno.com
ZX-Uno · FPGA ZX Spectrum clone.

Sweeney
Posts: 27
Joined: Wed May 31, 2017 2:54 am

Re: Next on Mist?

Post by Sweeney » Wed Jun 28, 2017 1:54 pm

mcleod_ideafix wrote:
Sat Jun 10, 2017 12:53 am
NightShadowPT wrote:
Fri Jun 09, 2017 1:23 pm
Can you elaborate a bit more? Why is the MiST memory a problem?

Thanks!
In fact, this is why asynchronous SRAM is preferred to SDRAM or DDR when using FPGA to recreate ancient computers. Ancient computers, specially if they have had a long shelf life and used in demoscene productions and the like, have a lot of software that rely on precise CPU timings to implement various effects. Those timings must not be changed because of added wait states to cope with memory speed. So, either you use many different memory chips to increase bandwidth by implementing private buses (thus, wasting many pins from the FPGA) or you use a fast memory and implement a time sharing mechanism to emulate the behaviour of two or more different memories being used by different systems inside the recreated system.
That said, SDRAM is still far faster than the original DRAM in these machines. Worst case the time to access random data is 70ns (refresh time) plus 70ns read access, total 140ns. The Spectrum couldn't do anything faster than 280ns (one clock).

User avatar
mcleod_ideafix
Posts: 70
Joined: Mon May 29, 2017 9:38 pm
Location: Spain
Contact:

Re: Next on Mist?

Post by mcleod_ideafix » Mon Jul 03, 2017 8:46 pm

Sweeney wrote:
Wed Jun 28, 2017 1:54 pm
The Spectrum couldn't do anything faster than 280ns (one clock).
Actually, the CPU in the Spectrum couldn't do anything faster than 280ns. But remember that the ULA needs access to RAM as well, and it needs it a bit faster. And on top of that, the original Spectrum used two separate memory banks, which separated buses so that the CPU and the ULA could start a memory bus cycle at the same time without colliding. Now look at the MiST: it has only one bank of memory, so if there are two bus masters inside the FPGA (ULA and CPU) that need to access memory at the same time, and you cannot use an arbitrer to share memory, stopping one master or another (because you cannot just stop the ULA without disrupting screen generation), you'd better have a fast memory so that you can interleave memory bus cycles for completely different addresses as fast as possible so both masters "see" that the memory is owned by each one alone.

And that's why the Uno (and the Next and some others) use SRAM, and not SDRAM or DDR. Achieving the same on SDRAM is indeed possible, but you have to do more job, and possibly, add FIFO queues or some sort of caché, and deal with possible issues, such as self-modifying code that would need to write to data already in the FIFO. To me, a nightmare I can hopefully avoid if I just use SRAM.
http://www.zxuno.com
ZX-Uno · FPGA ZX Spectrum clone.

Sweeney
Posts: 27
Joined: Wed May 31, 2017 2:54 am

Re: Next on Mist?

Post by Sweeney » Mon Jul 03, 2017 10:48 pm

mcleod_ideafix wrote:
Mon Jul 03, 2017 8:46 pm
Sweeney wrote:
Wed Jun 28, 2017 1:54 pm
The Spectrum couldn't do anything faster than 280ns (one clock).
Actually, the CPU in the Spectrum couldn't do anything faster than 280ns. But remember that the ULA needs access to RAM as well, and it needs it a bit faster. And on top of that, the original Spectrum used two separate memory banks, which separated buses so that the CPU and the ULA could start a memory bus cycle at the same time without colliding. Now look at the MiST: it has only one bank of memory, so if there are two bus masters inside the FPGA (ULA and CPU) that need to access memory at the same time, and you cannot use an arbitrer to share memory, stopping one master or another (because you cannot just stop the ULA without disrupting screen generation), you'd better have a fast memory so that you can interleave memory bus cycles for completely different addresses as fast as possible so both masters "see" that the memory is owned by each one alone..
If, worst case and without any fancy extra logic, you can access SDRAM in 140ns, then you can have two bus masters running at 280ns per cycle and time interleave them. With a little extra thought you can hide the refresh cycles in the horizontal and vertical refresh periods of the ULA and bring the effective access time down to 70ns.
There are examples of people running a Z80 core on a SDRAM equipped FPGA at 128MHz, in which case FPGA resources were needed for caching, but with little effort you can run easily at twice the speed needed to support a Spectrum simulation.

User avatar
mcleod_ideafix
Posts: 70
Joined: Mon May 29, 2017 9:38 pm
Location: Spain
Contact:

Re: Next on Mist?

Post by mcleod_ideafix » Thu Jul 06, 2017 2:30 am

Sweeney wrote:
Mon Jul 03, 2017 10:48 pm
If, worst case and without any fancy extra logic, you can access SDRAM in 140ns, then you can have two bus masters running at 280ns per cycle and time interleave them. With a little extra thought you can hide the refresh cycles in the horizontal and vertical refresh periods of the ULA and bring the effective access time down to 70ns.
There are examples of people running a Z80 core on a SDRAM equipped FPGA at 128MHz, in which case FPGA resources were needed for caching, but with little effort you can run easily at twice the speed needed to support a Spectrum simulation.
Yes. I agree the TBBlue core can be implemented on a SDRAM system. I stated that this kind of RAM could present some issues for the implementation. I did not say it was impossible. That "extra thinking" is the issue. Should misbehaviour is observed, the system is harder to debug if we have to take into consideration FIFOs, caches, etc. I didn't buy a MiST already because of this.
http://www.zxuno.com
ZX-Uno · FPGA ZX Spectrum clone.

alfishe
Posts: 2
Joined: Fri Aug 04, 2017 1:02 am

Re: Next on Mist?

Post by alfishe » Fri Aug 04, 2017 1:07 am

There exist much more powerful MiST successor - MiSTer (Based on 110kLE Cyclone V SoC). Cores can utilize both embedded DDR3 RAM (up to 512MB) and SDRAM on expansion board. See more information here: https://github.com/MiSTer-devel/Main_MiSTer/wiki

No need to solve memory refresh and other low level issues there. Standard ZX-Spectrum core already ported from MiST. ZX Next potentially can be (if vhdl/verilog sources available for specific functionality)

Dual core ARM @925MHz can solve any supplementary tasks for disk/network/heavy CPU processing.

toromand
Posts: 9
Joined: Mon May 29, 2017 6:29 pm

Re: Next on Mist?

Post by toromand » Wed Aug 09, 2017 6:18 am

I actually have the MiSTer... Will be building the SDRAM module one of these days. It is a very powerful ARM/FPGA platform.

Post Reply