Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.

Messages - gyurco

Pages: [1]

Hardware / Re: Enterprise Deployment Attempt Over FPGA.

« on: 2022.November.14. 23:47:24 »

It's a very small core, synthesizes in less than a minute:

Fitter Status Successful - Mon Nov 14 21:11:22 2022 Quartus II 64-Bit Version 13.1.4 Build 182 03/12/2014 SJ Web Edition Revision Name enterprise Top-level Entity Name enterprise_mist Family Cyclone III Device EP3C25E144C8 Timing Models Final Total logic elements 5,966 / 24,624 ( 24 % ) Total combinational functions 5,279 / 24,624 ( 21 % ) Dedicated logic registers 2,345 / 24,624 ( 10 % ) Total registers 2404 Total pins 72 / 83 ( 87 % ) Total virtual pins 0 Total memory bits 43,008 / 608,256 ( 7 % ) Embedded Multiplier 9-bit elements 9 / 132 ( 7 % ) Total PLLs 1 / 4 ( 25 % )

Do you have Quartus 13 updates installed? The latest is 13.1.4.
Also I noticed that on very new Linux distros, the fitter simply hangs forever.

Hardware / Re: Enterprise Deployment Attempt Over FPGA.

« on: 2022.November.14. 18:41:18 »

Thanks for confirming.
As I suspected, the SDRAM has no problem with serving both the CPU and Nick (even without contention):
https://ibb.co/mvkLxJc
https://ibb.co/8YfsTpQ

Now it's time to learn about the machine

(My friend from elementary school had one, but I only saw playing Last Ninja II).

@Kyp: When I'll complete the port, I'll push my changes to your repo in a separate branch if it's OK to you. Then merging with master can be decided later on.

Hardware / Re: Enterprise Deployment Attempt Over FPGA.

« on: 2022.November.12. 16:36:10 »

From the schematics of the Dave chip, it looks like the WAIT_N generator only uses the port BF(?), and doesn't consider if it's VRAM page access or not. Is it true that the CPU throttling is applied to all RAM pages on the original machine?

BTW, it's interesting they choose a design with asynchronous CPU and video clocks. Even the Amiga was designed with synchronous clocks, as making them async can give serious headaches with synchronizing and timing checks (even today, with FPGA designs). Maybe it was one of the reasons why the machine was delayed? It would be more simple if they simply choose a 8MHz pixel clock (16 MHz master clock for the Nick).

Upd.: Seems I was wrong, and the design is even more complicated than I first anticipated: while WAIT_N is generated by Dave, the CPU clock itself is generated by Nick, which can simply disable it (hold at a level - similarly to ZX Spectrum) while it wants to access the VRAM.

Hardware / Re: Enterprise Deployment Attempt Over FPGA.

« on: 2022.November.12. 15:30:11 »

I already checked your sources, and the asynchronous clocks of NIC and the CPU are indeed a problem, but not unsolvable.
The original machine also shares the video RAM page (Dave generates the WAIT_N signal to the CPU - I see it's not implemented (yet), but not a big problem, except for cycle-accuracy).

The 4 MHz Z80 expects the RAM speed (without wait states) at most 2.6 MHz rate (M1 cycle is 1,5 cycles long), so it's no problem for the SDRAM controller.
Nick (should) not use a bigger rate also (as the original DRAMs are not faster). I didn't check the details of your Nick implementation yet, but if it requires the data available after the address setup in 1-2 master cycles, then it should be changed (the displaying pipeline will be longer, but also more faithful to the original). This one also a common problem with lot of cores, while the time between the address setups can be 8-16 pixel clock cycles, the data is expected to be returned in 1 cycle. It's clearly for BRAM, and not really how the original hardware worked.

Finally the Amstad CPC uses a similar display access rate, and it has no problem with the SDRAM controller @64MHz.

Hardware / Re: Enterprise Deployment Attempt Over FPGA.

« on: 2022.November.07. 00:11:21 »

Hi!

I noticed this core was not ported to MiST. I would try to do it, but can you open the source? Or just share with me on GitHub (I won't publish it if you don't want, I promise). BTW, I'm sure it's using some of my code, too, like the improved T80.

Pages: [1]