STE DAC FPGA issues

Super ST Project. Lets create a awesome new ST! Fix all the bugs and add more cool stuff!
ijor
Posts: 92
Joined: Fri Nov 30, 2018 8:45 pm

Re: STE DAC FPGA issues

Post by ijor » Sat May 18, 2019 5:16 pm

exxos wrote:
Sat May 18, 2019 11:15 am
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 see. No, MMU can't perform sound DMA, not with a standard motherboard design. It can't because it is not connected to the RAM data bus (MMU only controls RAM, it doesn't read or write to RAM). Only Shifter is connected directly to RAM, and this is why the task is assigned to Shifter in the first place. You can, of course, redesign the board and connect MMU to RAM data. But that would mean bringing 16 extra signals and adding 16 extra pins to MMU. I don't know why Wolfgang told you it is possible. May be there was some kind of misunderstanding.

But honestly, I'm not sure it is a good idea to implement STE sound DMA on a system without a full STE Shifter. You are building a configuration that would create compatibility problems and most software won't use sound DMA in such an hybrid anyway.

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.

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.
Not sure fixing Suska code is a realistic goal. Cycle accuracy needs to be an integral part of the design since day one. Now it might require redoing the cores from scratch.

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.
That shouldn't be a big problem.

I will reply to the next message later :)
http://github.com/ijor/fx68k 68000 cycle exact FPGA core
FX CAST Cycle Accurate Atari ST core
http://pasti.fxatari.com

User avatar
exxos
Site Admin
Site Admin
Posts: 7643
Joined: Wed Aug 16, 2017 11:19 pm
Location: UK
Contact:

Re: STE DAC FPGA issues

Post by exxos » Sat May 18, 2019 5:45 pm

ijor wrote:
Sat May 18, 2019 5:16 pm
But honestly, I'm not sure it is a good idea to implement STE sound DMA on a system without a full STE Shifter. You are building a configuration that would create compatibility problems and most software won't use sound DMA in such an hybrid anyway.
You will have to explain what the shifter has to do with the DMA audio...

Granted we would need more lines to the FPGA... this is easily solvable as we are designing a new motherboard anyway. But we need some sort of plan and direction to go in and the right people to help.
ijor wrote:
Sat May 18, 2019 5:16 pm
You are building a configuration that would create compatibility problems and most software won't use sound DMA in such an hybrid anyway.
Its a step to bring a better sound system to the remake board. I did consider DSP, but nobody codes for it, and its to complicated.

The STE DMA audio is well known, and I already talked to some demo coders about the software side of things. Basically they say if I can create the hardware, they can implement a sound playback routine for it. It may not be 100% compatible with a STE initially ( I already talked about that, and the missing microwire and volume control circuit etc missing is a issue, but its solvable ) , but this is only the first step.. of likely many. We have to start somewhere.
4MB STFM 1.44 FD- VELOCE+ 020 STE - 4MB STE 32MHz - STFM 16MHz - STM - MEGA ST - Falcon 030 CT60 - Atari 2600 - Atari 7800 - Gigafile - SD Floppy Emulator - PeST - HxC - CosmosEx - Ultrasatan - various clutter

https://www.exxoshost.co.uk/atari/ All my hardware guides - mods - games - STOS
https://www.exxoshost.co.uk/atari/last/storenew/ - All my hardware mods for sale - Please help support by making a purchase.

ijor
Posts: 92
Joined: Fri Nov 30, 2018 8:45 pm

Re: STE DAC FPGA issues

Post by ijor » Sat May 18, 2019 6:11 pm

exxos wrote:
Sat May 18, 2019 5:45 pm
You will have to explain what the shifter has to do with the DMA audio...
Nothing at all. What I meant is that I'm not sure it is a good idea to implement STE DMA audio in a non STE system. If it is not an STE system, then most software would not detect it as STE and won't use STE sound DMA. It is also possible that some software will, wrongly, think it is a standard STE and then it will misbehave. But see below ...
Granted we would need more lines to the FPGA... this is easily solvable as we are designing a new motherboard anyway. But we need some sort of plan and direction to go in and the right people to help.
I just give you my opinion about the complications involved and the possible incompatibilities. I thought it is not worth. If you consider it is not a big problem to add 16 extra signals and you think it is worth, then it is definitely possible. I have no problem whatsoever in helping with that.
The STE DMA audio is well known, and I already talked to some demo coders about the software side of things. Basically they say if I can create the hardware, they can implement a sound playback routine for it. It may not be 100% compatible with a STE initially ( I already talked about that, and the missing microwire and volume control circuit etc missing is a issue, but its solvable )
Ok, but this would mean that the system won't be 100% compatible, not with a plain ST, not with a stock STE either. And I'm not talking about the DMA audio itself. Anything you add or change it is a potential incompatibility. As long as you don't mind, and you think it is worth, then it is ok.

A possible solution is to add a dip switch, a jumper, or something similar. In one position you disable all the "extras" and bring the system to a stock configuration. This is the only way to guarantee 100% compatibility.
http://github.com/ijor/fx68k 68000 cycle exact FPGA core
FX CAST Cycle Accurate Atari ST core
http://pasti.fxatari.com

User avatar
exxos
Site Admin
Site Admin
Posts: 7643
Joined: Wed Aug 16, 2017 11:19 pm
Location: UK
Contact:

Re: STE DAC FPGA issues

Post by exxos » Sat May 18, 2019 6:23 pm

ijor wrote:
Sat May 18, 2019 6:11 pm
A possible solution is to add a dip switch, a jumper, or something similar. In one position you disable all the "extras" and bring the system to a stock configuration. This is the only way to guarantee 100% compatibility.
That can be done with switches or even controlled via a register. I am not aware of any issues in adding hardware to the memory map.. if software doesn't use the hardware, it shouldn't care its there. Though there may be detection issues as you say, if we try running STE only software on it.. when its not a real STE.. but those are problems for another day.. FPGA cores can always disable the "Extra" hardware so its solvable.

Initially its just to get something running, and there are software guys willing to help. So the remake can basically have DMA playback.. I hope some demo coders will code for the remake eventually.. We already have a 16MHz machine, so with some good audio playback, its already a pretty powerful machine which I hope will spark some coding interest ultimately.
4MB STFM 1.44 FD- VELOCE+ 020 STE - 4MB STE 32MHz - STFM 16MHz - STM - MEGA ST - Falcon 030 CT60 - Atari 2600 - Atari 7800 - Gigafile - SD Floppy Emulator - PeST - HxC - CosmosEx - Ultrasatan - various clutter

https://www.exxoshost.co.uk/atari/ All my hardware guides - mods - games - STOS
https://www.exxoshost.co.uk/atari/last/storenew/ - All my hardware mods for sale - Please help support by making a purchase.

ijor
Posts: 92
Joined: Fri Nov 30, 2018 8:45 pm

Re: STE DAC FPGA issues

Post by ijor » Sat May 18, 2019 10:19 pm

exxos wrote:
Sat May 18, 2019 1:15 pm
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.
I see, sounds good. From my point of view it is much easier to go straight ahead with a single FPGA implementation. But I guess you might have your reasons to choose a different path.
Also Suska GLUE decodes TOS206, but I imagine that would be trivial to add to your core anyway.
...
Though maybe you could port the suska DMA code to your MMU core ?
Yes, supporting 256K TOS is trivial. Adding sound DMA is, perhaps, not trivial, but not big deal either.
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.
How much Alt Ram you want? SRAM is much simpler and has much lower latency, but it is much more expensive. 16 MB SRAM costs around U$20, while SDRAM costs less than U$2.
We already replaced the clocks on the remake during our 16MHz mod ... So basically it wouldn't be a problem.
Nice! :)
http://github.com/ijor/fx68k 68000 cycle exact FPGA core
FX CAST Cycle Accurate Atari ST core
http://pasti.fxatari.com

ijor
Posts: 92
Joined: Fri Nov 30, 2018 8:45 pm

Re: STE DAC FPGA issues

Post by ijor » Sat May 18, 2019 10:33 pm

exxos wrote:
Sat May 18, 2019 6:23 pm
That can be done with switches or even controlled via a register.
A software switch is not good enough, it is not foolproof. Anything that can be controlled via software is yet another potential incompatibility. At least unless the switch is one way only. If you can enable "full compatible mode" via software, but you can't go back without a power cycle, that would be foolproof.
I am not aware of any issues in adding hardware to the memory map.. if software doesn't use the hardware, it shouldn't care its there.
That line of thinking, relying (or not) on what software should not do, is the difference between something like Suska (with all due respect for Wolfgang) and my core. Software performs all sort of crazy stuff that you wouldn't imagine. Sometimes it is by design to save a byte or a cycle, sometimes for protection and code obfuscation purposes. But most of the time is by mistake.

A piece of software has a bug that provokes an expected crazy behavior. But, just by chance, and because of the exact way the hardware (or the operating system) reacts, the bug happens to be harmless. If the bug is harmless it is not exposed and might never be fixed. Trust me. I've seen many cases that you wouldn't believe.

When I targeted my cores for full compatibility my design goal was that it wouldn't be possible to detect the core. That is, even if somebody will, intentionally, attempt to distinguish between the core and a real ST, it wouldn't be able. Furthermore, the goal was that even if myself, fully aware of the core limitations, would try to detect my own core, I still wouldn't be able.

It might sound crazy. But such design goal is that what let the core run such things as Closure.
http://github.com/ijor/fx68k 68000 cycle exact FPGA core
FX CAST Cycle Accurate Atari ST core
http://pasti.fxatari.com

User avatar
exxos
Site Admin
Site Admin
Posts: 7643
Joined: Wed Aug 16, 2017 11:19 pm
Location: UK
Contact:

Re: STE DAC FPGA issues

Post by exxos » Sun May 19, 2019 1:25 pm

A lot of very good points.

Once we get the blitter board working with suska, we can try out your blitter core as well. Once we get that all tested, which will likely end up taking several months, we will start a new project for replacing the MMU and test out suska and your code. This is assuming you want to take your cores to a "drop in replacement" for the original chips and not fully intergrated like MiST is etc. Though that is of course up to you.

I think it's important to have drop in replacement chips, you can't exactly buy replacements easily anymore. Take the blitters, I know they are impossible to find other than BEST, and are high priced. Though a drop in replacement blitter will help existing machines upgrade in the future. It also builds a way forward to integrating the blitter onto future remake boards. So hopefully this gives you a bit of reasoning why I want to do this.

Someone also wants to tinker with the blitter, I think to many add more features etc (can't remember who sorry!) But dedicated boards like the blitter allow people to experiment and possibly improve or add features. I already talked to Wolfgang last year about adding a feature into the MMU core. If we can generate some hardware interest by a few people doing that, then great. If nobody is bothered, then we won't produce the boards.

Of course as long as the remake project can get some interest, we will keep developing it, we need hardware and software developers. For me personally the remake is building a revised STF with many needed fixes etc . Plus one that is easy to upgrade for people etc. I won't go into all that again. As long as there is 20 people wanting a motherboard, then I can keep developing it and moving forward whatever direction that may be.

Though the FPGA stuff is taking the board to the next level. It will become its own machine with its own features. As for backwards compatibility, we may have to develop 2 motherboards, a original and a improved FPGA based board. If we can do both on one board, then great. If there is no interested in a faster FPGA based system with more hardware features, and no software programmers willing to code for it, then the project will get shelved indefinitely.

I don't want to go fully FPGA, we already have MiST, Firebee, Suska etc , re-doing this work again is a little pointless. But if we can take the classic STF and improve on it a little with FPGA (Basically faster ST-RAM which is the main bottleneck with boosters) , then that is all I am basically doing at the moment (but are of course thinking ahead with STE DMA DAC audio etc ) . We won't know of any compatibility issues until we start testing the stuff out. Again, it depends on support from the community as to how much work is done. Its possible in a couple years time the whole project gets abandoned if there isn't interest.

Though the "classic STF remake" will still go ahead. Again It depends on interest and support from the community ultimately. I will keep developing the motherboard as long as there is enough people willing to help with the project. We are not huge here, we don't have a huge base like MiST, Firebee etc, but if we can at least help test replicate FPGA ST chipsets then that is still something IMO.

I hope it gives you a better picture of how things will be moving forward.
4MB STFM 1.44 FD- VELOCE+ 020 STE - 4MB STE 32MHz - STFM 16MHz - STM - MEGA ST - Falcon 030 CT60 - Atari 2600 - Atari 7800 - Gigafile - SD Floppy Emulator - PeST - HxC - CosmosEx - Ultrasatan - various clutter

https://www.exxoshost.co.uk/atari/ All my hardware guides - mods - games - STOS
https://www.exxoshost.co.uk/atari/last/storenew/ - All my hardware mods for sale - Please help support by making a purchase.

Post Reply