ijor wrote: ↑Sat May 18, 2019 4:19 am
All the cores are done and complete. Not just MMU and not just the custom chipset, but also MFP, FDC, IKBD, etc. A complete ST system that runs everything we tried so far, including demos and copy protected games. A couple of user recorded some videos on youtube. This is Troed's Closure:
Impressive work.
Suska doesn't run Closure, it can't detect the waitstates.
ijor wrote: ↑Sat May 18, 2019 4:19 am
As I believe I already mentioned in other thread, I think that once you decide to include some FPGA cores, it is much better in every sense to concentrate all cores in a single FPGA device. I think that multiple FPGAs or a single once is not what makes the difference between a clone or a remake. Other things like the level of compatibility and which peripherals are supported, are much more relevant, IMHO.
Initially we are testing each core one by one starting with the blitter. Once all cores are tested as working how we want (IE 100% compatible) then those cores will be integrated into a single FPGA.
The STE was basically the same, as in integrating GLUE,SHIFTER,MMU "all in one chip" so doing the same in FPGA isnt any different IMO.
ijor wrote: ↑Sat May 18, 2019 4:19 am
You are, of course, very welcome to use my cores if you want. And time permitting I'll help as much as I can. Or you can use Suska ones if you prefer, I don't take any offense. Conceivable, it might be even possible to use a mix.
Suska is interesting as its a STE machine , which is ultimately the direction I want to go in. Though I want 100% backwards compatibility. So I am basically "stuck" which direction to go in.
Also Suska GLUE decodes TOS206, but I imagine that would be trivial to add to your core anyway.
I would much rather use your cores as your working for maximum compatibility, Wolfgang isn't AFAIK.
ijor wrote: ↑Sat May 18, 2019 4:19 am
If you do decide to use my cores be aware of some limitations:
The cores are ST only. No STE functionality whatsoever so far.
I understand that yes. Though maybe you could port the suska DMA code to your MMU core ?
If we can basically take suska's STE features (I am just talking DMA audio currently, but may well add microware etc later anyway) and integrate them into your cores, then we get the best of both worlds. The Suska code and hardware is already built and tested so it literally just needs adding to your FPGA code.
ijor wrote: ↑Sat May 18, 2019 4:19 am
Most cores, except the 68000 CPU, are currently closed source. I will open source them at some point, but not yet. You can still use them if you want as long as you don't mind them not being open source yet.
Open source or not isn't a issue. Its if "we" can get some changes made as mentioned above. Suska we could do this as its open, but we don't have a FPGA programming person, so its a bit irrelevant really.
ijor wrote: ↑Sat May 18, 2019 4:19 am
The cores were never tested standalone as replacement for actual chips. Some work and testing would be needed but I don't expect this to be a major problem.
The remake project can probably help with that. Once we get the blitter FPGA working, we can try your blitter code. Same goes with any other chips (but we only working on the blitter currently) . I think its important to make a 100% compatible stand alone ST chipset replacement. So we can help you with that..
ijor wrote: ↑Sat May 18, 2019 4:19 am
Currently MMU is coded to use synchronous DRAM because that's what FPGA boards usually have. But shouldn't be a problem at all to adapt it to static ram, or to whatever memory you would like to use. It is actually much easier to use SRAM than synchronous DRAM. OTOH SRAM is more expensive.
I was looking at SRAM as I was intending running alt-ram at 50MHz with the CPU. So SRAM was the only real option. Though if we go with 32MHz, then it doesn't really matter which RAM is used.. Something I need to look into more another time.
ijor wrote: ↑Sat May 18, 2019 4:19 am
The cores are currently designed to work with a single 32 MHz monolithic clock. Again, some work would be needed to use the clock that they originally have in a real ST (GLUE and DMA at 8 MHz, MMU at 16 MHZ, etc). But please note that FPGAs are much more sensitive to clock skew. If you plan to go with FPGAs, it might be worth to invest some thinking and consider using some alternate clocking scheme.
We already replaced the clocks on the remake during our 16MHz mod.I am just waiting for the mod PCBs to come so others can try it also. We took the 32MHz and ran it via a F161, so we get 32,16,8,4mhz outputs. MMU is driven from 32MHz with the shifter. CPU,Blitter get 16MHz from the 161. Glue gets 8MHz from the 161 ( we cant use the MMU 8mhz and 4mhz as the MMU is double clocked, and so do the clock outputs)... but replacing the clocks is already done and once more testing is done, the next remake board will use its own clock gen. So basically it wouldn't be a problem.