STE DAC FPGA issues

[exxos]

I have been contemplating when the FPGA MMU core etc gets tested with that with it being a STE core, a updated audio DAC circuit will be pretty simple in theory to add to the remake...BUT... When I started looking at the code, part of the DAC code is integrated into the video shifter

Technically we could replace the video shifter, but we was already thinking about using Smonson's FPGA shifter With hopefully the possibility of being able to add more resolutions etc. Which basically means a whole new can of worms with integrating the audio stuff as well.

I'm somewhat reluctant to change a lot of original chips all at once. But my current thoughts, if we started replacing half the system with Suska cores, that we are pretty much locking ourselves into basically rebuilding the suska itself. Basically we would end up with a STE machine based on suska, where we already know there are compatibility issues with the MMU core. All these course need to be tested thoroughly one by one by the community first.

I really would like to get the remake project as a STE machine, or at least get the DAC playback working, though it is looking like it would have to be a whole different motherboard. Of course the remake board we are already working on the FPGA blitter, and replacing the MMU & GLUE with the suska core so we can use SRAM and run the core at 32MHz or higher. This in itself will have issues in terms of compatibility when running at stock speeds, as the cores are not totally accurate yet, but Wolfgang would update the cores with the changes if we could tell him what to do and what to fix etc But that turns into a possible brick wall if Wolfgang is slow in making updates.

What really concerns me is this project is heading down the road that all other clones or emulators do, in that we lose original compatibility at stock speeds. I want to keep the STF as a fully backwards compatible machine, but of course we should be able to add enhancements without totally breaking the system..Which is slightly ironic as running high speeds basically does that anyway.. But at least currently we can turn these accelerations off and run at stock speeds and we can run all original software without issues.

So if any of you FPGA experts out there, can figure out if it is possible we can avoid replacing the shifter at this point, And keep all the DAC stuff internally on the "MMU" core (of course I know GLUE needs to be there as well)...

EDIT:

I emailed Wolfgang, he said it is possible to fully integrate the DAC system into the MMU... So at least that is one question answered.. Next problem is we need someone who can actually figure this out with the FPGA code...

[mikro]

Personally, I don't find the possibility of breaking the system so terrible if it would be possible to always reuse the original ICs (to gain 100% compatibility). If you decide to use FPGA alternatives then yes, one gain is the ability to run the ST(E) on higher speeds but the far more important gain is that Wolfgang's work gets finally properly (and widely) tested. He will receive feedback, that will perhaps motivate him more and so on and so on.

EDIT: On the other hand, I totally get your "Am I building another Suska here?" dilemma. I guess that is something you, as the creator, have to figure out, how far you want to go.

[exxos]

Yeah, I think it would help Wolfgang if we could help him test the cores out.

The Bug I was talking about in the MMU, is because Wait states are not detectable, so Troed's closure demo doesn't run on suska. I am sure this could be fixed, though I think Wolfgang would be too busy to make any changes any time soon.

But of course, if we want higher speeds, then sacrifices have to be made somewhere along the line. The wait states issue isn't really a problem with higher speeds, as those demos would likely not run anyway.

Though as said before, I want to keep the motherboard fully backwards compatible.. Which without the original chips, is going to be a problem. But of course things can be fixed in the FPGA cores, it just needs someone willing to do the necessary tweaks.

We are running a real CPU, and with running a 8MHz clock, things should pretty much work out okay with the FPGA cores. I know suska CPU as some tweaks/optimisations, so it is not emulating a 68000 100%.

Overall, we really need as many people as possible to try these things and try as much software as possible to see where the bugs are.

[chlu600]

I think it’s good to aim for 100% compability in 8mhz mode. Hopefully doable with FPGA cores without spending too much time...

Have you concidered this 68k implementation?
https://github.com/ijor/fx68k

[exxos]

I am aware of Ijors work on the cores. Ultimately it could used to replace the CPU. I do not know if the FPGA cores can even clock higher than 50MHz. Though for the time being I will just use a real CPU. We can get 50MHz out of it, and I think for a 68000 thats plenty. I do plan a 020 and going 32bit, but that is a long way off. Of course it does not stop anyone else from developing a compatible CPU for the remake board anyway..

IIRC he is doing MMU etc as well, so these could be used on the remake board, but I really do not know how far along he is with all this work (99% of the time I never visit any other forums, And I don't think he has been here for some time either, So I really have no idea about his projects, unless he has a personal blog somewhere ?) . But also it would need to be 50MHz capable with SRAM, and as we are talking about the DAC also.. I think it is a lot of work.. Suska may well be good enough for the remake, but it needs testing and bugs fixing as we find them.. I think Wolfgang will do this,But I am not really sure he has much time or interest in the ST chipset anymore. is why we really need a FPGA programmer who knows what they are doing, and has some time to invest in the project.

Ijor knows the internals of these chips, and of course knows FPGA programming, but I don't really know if he's much interested in the remake project, not many people really are. I think most people ( again I am assuming Ijor being one) Is aiming for his cores to be used in the MiST etc more than anything.

For the moment I am just using the Suska code. There is a ready blitter which myself and Icky are working on, and Wolfgang is given me permission to use the cores. I don't think the blitter would be a problem compatibility wise, is why I decided to start with that project first.. also the shortages of the real blitter chips, so we do need a alternative for the remake anyway.

For myself and Icky etc . at the moment, we have no idea about FPGA stuff, so it is going to take is a while to get the hang of even programming the stuff. But initially the Suska cores are just a step forward more than anything. Of course if something better comes along with any cores (like Ijors cores for example) , then sure we can use that no problem. But this really depends on Ijor and how much he does or does not want to get involved with this project. I will give him a ping if he doesn't appear for a while and see what he thinks of it all.

[ijor]

Sorry for the delay. Very busy lately, not much time for Atari, I'm afraid

... have been contemplating when the FPGA MMU core etc gets tested with that with it being a STE core, a updated audio DAC circuit will be pretty simple in theory to add to the remake...BUT... When I started looking at the code, part of the DAC code is integrated into the video shifter

There is no audio DAC in SHIFTER. I assume you are talking about STE DMA sound, because that's what STE SHIFTER does. The DAC itself is implemented with discrete components, and even if would be integrated into SHIFTER, you woudn't be able to implement in a FPGA because most FPGAs don't have a DAC anyway.

Are you talking about STE sound DMA, or about the Microwire? I'm not sure I understand why you would want to implement either on a non STE system. Or are you talking about something else?

The Bug I was talking about in the MMU, is because Wait states are not detectable, so Troed's closure demo doesn't run on suska. I am sure this could be fixed, though I think Wolfgang would be too busy to make any changes any time soon.

I'm not so familiar with Suska, but I suspect it not an issue with MMU, but with GLUE, or may be both. Note that for running certain demos a very accurate Shifter is also needed, and this can be even more tricky than MMU and GLUE. Check, for instance, Alien's 4-bit sync scroll at the Punish Your Machine demo, the relevant screen is called "Let's Do The Twist Again". Chances that Suska doesn't run that screen correctly.

[ijor]

I am aware of Ijors work on the cores. Ultimately it could used to replace the CPU. I do not know if the FPGA cores can even clock higher than 50MHz. Though for the time being I will just use a real CPU. We can get 50MHz out of it, and I think for a 68000 thats plenty.

My 68K core currently has a max frequency around 40 MHz. It is certainly possible to implement some optimizations and increase the max freq. I didn't try because currently I don't need anything faster than 32 MHz. It might be possible to reach 50 MHz depending on the FPGA, can't say for sure. But there is a trade off between maximum speed and maximum accuracy. You can't get both, not at the same time. A core that doesn't try to be 100% accurate can be much faster and not only in terms of clock frequency, but also use less cycles for certain instructions.

Note that you could perfectly use two different cores. One cycle accurate for stock 8 MHz speed, and another not so accurate but faster that you would run in turbo mode. Of course that this will take more FPGA space and potentially might require a bigger and more expensive one. But I agree that you could perfectly use a real CPU.

The other cores should be able to run with a much higher frequency. Certainly 50 MHz shouldn't be a problem.

[ijor]

IIRC he is doing MMU etc as well, so these could be used on the remake board, but I really do not know how far along he is with all this work ...

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:

Ijor knows the internals of these chips, and of course knows FPGA programming, but I don't really know if he's much interested in the remake project, not many people really are. I think most people ( again I am assuming Ijor being one) Is aiming for his cores to be used in the MiST etc more than anything.

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.

But I don't want to go off topic and it really doesn't matter for this purpose. I welcome every single Atari related project, even if it is not exactly done the way I would prefer. Sometimes it is just a matter of personal preference. And regardless, certainly the remake is an important project. 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.

If you do decide to use my cores be aware of some limitations:

The cores are ST only. No STE functionality whatsoever so far.

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.

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. 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.

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.

[exxos]

Are you talking about STE sound DMA, or about the Microwire? I'm not sure I understand why you would want to implement either on a non STE system. Or are you talking about something else?

STE DAC & DMA initially. The suska is essentially a STE. So if I start using the suska cores on the remake project, we are essentially building a STE.

The digital side of the DMA is all done in the FPGA core. the DAC side is output by the FPGA via a serial interface to a external DAC chip, which replaces all the "clutter" in the STE's DAC circuit.

I'm not so familiar with Suska, but I suspect it not an issue with MMU, but with GLUE, or may be both.

This needs looking into as Wolfgang is not aware of wait states, so it would need someone like yourself to work out how to patch the cores.

Note that for running certain demos a very accurate Shifter is also needed,

Of course. Though at this point in time we are not replacing the shifter yet.

and this can be even more tricky than MMU and GLUE. Check, for instance, Alien's 4-bit sync scroll at the Punish Your Machine demo, the relevant screen is called "Let's Do The Twist Again". Chances that Suska doesn't run that screen correctly.

Suska Isn't a accurate core, the CPU is not cycle accurate, so the timings are already off. It doesn't run Troeds Closure demo, as it cannot work out the wait states on the suska core. But we have no idea where this problem is.

My 68K core currently has a max frequency around 40 MHz. It is certainly possible to implement some optimizations and increase the max freq. I didn't try because currently I don't need anything faster than 32 MHz. It might be possible to reach 50 MHz depending on the FPGA, can't say for sure. But there is a trade off between maximum speed and maximum accuracy. You can't get both, not at the same time. A core that doesn't try to be 100% accurate can be much faster and not only in terms of clock frequency, but also use less cycles for certain instructions.

Of course any hardware changes, like boosting the CPU like my accelerators do, it already breaks a lot of time in critical demos etc. What I am talking about is having a FPGA based MMU,GLUE,BLITTER, which will emulate a stock system 100% at 8Mhz. Then we can run them faster at say 32MHz at the flick of a switch, and the system will of course be massively faster. Of course this will break some software, but that is just a trade-off speed. The bottom line is, I want the remake project to remain always 100% backwards compatible with a stock machine. This is why I always add a "off switch" to my accelerators, so you can turn off speed boost, and you are back to a 8MHz machine.

Essentially I want to accelerate the ST-RAM as well. While we are overclocking the MMU at the moment and getting a true 16MHz system, I doubt we can clock the original chips to in effect a 32MHz system. we need faster MMU,GLUE,BLITTER etc and can only be done in FPGA.

Note that you could perfectly use two different cores. One cycle accurate for stock 8 MHz speed, and another not so accurate but faster that you would run in turbo mode. Of course that this will take more FPGA space and potentially might require a bigger and more expensive one. But I agree that you could perfectly use a real CPU.

That could be possible yes, but for the moment, I think that would be greatly over complicating things. We need to start off with a accurate FPGA system which can just basically be "over clocked". We already did this with 16MHz ST, so there should be no problems in a 32MHz system.. But of course we need new "ST" chips which can run at those speeds.



...And the some reason my second half of replies I just wrote that is just vanished So I will have to reply again.

[exxos]

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.

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.

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.

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.

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.

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..

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.

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.