TF536 - Atari firmware - Rev2 TF536

[agranlund]

Very nice! :) But why are you using an interrupt routine to copy the data? Can't you just write to fast RAM on the fly? Or you don't have enough CPLD resources to implement that?

Thanks! It's really cool to see that it's working. Especially knowing what goes on in the background :)

There is certainly a huge struggle fitting everything on the CPLD at the moment, but to be honest another big factor is my own lack of experience.

I'm quite comfortable around software and how to interact with and (ab)use hardware on a low level but I consider myself a bit of a beginner when it comes to making hardware.
The very first proof-of-concept was a rather convoluted full-software implementation using the MMU to write protect pages for trapping and emulating hardware writes.. The current cpld assisted solution is much less complicated, but being primarily a software guy actually took me longer to implement :)

Would be better to let the data into fastram on the fly as you said, and I think there's enough info available to let that happen (given more cpld resources).

[Badwolf]

PS. @Badwolf, I hope I am detecting the DFB1 correctly?
It doesn't do anything special for it, but it's nice if the card name shows up correctly :)
https://github.com/agranlund/tftools/bl ... ard_DFB1.c

Umm, I haven't actually thought about a 'correct' way to detect DFB1. In the past I've used that register for switching acceleration on/off, switching all the features on/off, switching the FPU speed and various things.

Most of my firmwares will respond on F20000 to F9FFFF as well (that's the Flash ROM map) and that may be safer, but I'd hate to tell you something now that I change completely next firmware! :oops:

BW

[agranlund]

Most of my firmwares will respond on F20000 to F9FFFF as well (that's the Flash ROM map) and that may be safer, but I'd hate to tell you something now that I change completely next firmware! :oops:

No big deal if something changes that breaks it either, worst case the name is wrong but that's only cosmetic..
The DFB1 handler doesn't do anything custom except for setting the name if it detect it.
So it'll end up in generic MMU-only code which behaves like old maprom either way.

TF536r2 is the only one which signals that it can do certain parts in hardware instead of MMU.

Screenshot 2022-07-27 at 15.56.46.png

[Badwolf]

Fancy! :thumbup:

BW

[ijor]

There is certainly a huge struggle fitting everything on the CPLD at the moment, but to be honest another big factor is my own lack of experience.

That's perfectly understandable. Note that it is possible to generate a DMA transfer without generating an interrupt request to the MFP at all. Guess you don't care for such cases. After all an accelerator might break stuff in many other ways. Just noting that this is possible.

[stephen_usher]

Surely the way around this is to trap access to the DMA hardware and trace through the code to work out the address range and stop caching that range.

[agranlund]

Surely the way around this is to trap access to the DMA hardware and trace through the code to work out the address range and stop caching that range.

I think there's many ways to skin this particular cat when it comes to implementation, but when going with trapping hardware access then yes you will absolutely be able to gather all the information you need as software is attempting to communicate with the hardware.

However, there is no way to finely control the L2. It's really basic.
- All CPU writes to ST-RAM always goes both in the L2 and to ST-RAM (this is never disabled)
- All CPU reads from ST-RAM will get from the L2 unless it's disabled.
- The CACR register and MMU cache-inhibit flags do nothing for the L2 cache, these only effect the L1

I have no doubt a bigger CPLD and a better guy behind the keyboard would be able to make something more advanced but for the purpose of this I think it's probably all that is needed?
Although we do need to get creative when DMA writes to ST-RAM and make sure that data is reflected into the L2 after DMA is done (or as Ijor suggested, done transparently by hardware during the DMA transfer)

And even if you could, you still wouldn't want to disable cache of the DMA'ed region though?
Ie; A game is transferred from disk to a memory region using DMA. If you disable that region then for the purpose of that game, it may as well have been running with L2 disabled and at ST-RAM speeds.

[stephen_usher]

Yeah, this wouldn’t be a CPLD thing, more a MAPROM software assist using the translation table.

e.g. trap writes to the DMA addresses, analyse the configuration of the DMA and determine the ST-RAM addresses into which the data is to be transferred. Then set up the translation table to trigger if any of those ST-RAM addresses are accessed, at which point the data is copied into ALT-RAM and the translation table changed so that the address points to the ALT-RAM, then the original program is restarted.

That should give a performance increase for programs which do DMA. Of course, this wouldn’t help if you want to run under MiNT or MAGiC or which meddle with the translation tables but that’s a very small sub-set of all programs.

[agranlund]

Yeah, this wouldn’t be a CPLD thing, more a MAPROM software assist using the translation table.

e.g. trap writes to the DMA addresses, analyse the configuration of the DMA and determine the ST-RAM addresses into which the data is to be transferred. Then set up the translation table to trigger if any of those ST-RAM addresses are accessed, at which point the data is copied into ALT-RAM and the translation table changed so that the address points to the ALT-RAM, then the original program is restarted.

That should give a performance increase for programs which do DMA. Of course, this wouldn’t help if you want to run under MiNT or MAGiC or which meddle with the translation tables but that’s a very small sub-set of all programs.

Aha ok! now I get you.
This is inline with how my very first implementation worked for detecting the DMA transfer, although your idea for triggering memory update is different and more clever than mine - more resilient and less easily broken by software compared to using the DMA irq for that purpose.

Now that the cpld is taking care of recording the DMA start address I ditched the HW trap completely.
The benefit is that it doesn't need the MMU (or any code at all) to register the transfer. The drawback is the less hidden way of dealing with the update after the transfer is done..

For now, I am still quite happy with how it deals with DMA but time will tell as I get a chance to test more stuff :)

That's not to say I may be interesting to bring back the MMU setup for further experimentation at some point.
Trapping HW access is really fun and interesting and you could do all kinds of neat, and very cheap, emulation related stuff with that on the 68030.
It's a pity they removed some of the things that made it so easy from the later processors.

[agranlund]

Ladies and gentlemen, I proudly present the most important update in the history of maprom!


This OCD inducing monstrosity:

Screenshot 2022-07-27 at 23.39.49.png

Now looks like this:

Screenshot 2022-07-27 at 23.39.19.png

We can all sleep well at night now! :lol: