TF536 - Atari firmware - Rev2 TF536

[stephen_usher]

Not having to use the MMU for the ROM copy is probably "A Good Thing(tm)" as it doesn't matter what else messes with the CPU memory tables.

I guess that it would help with patched kernels too by a program in the AUTO folder copying the ROM and patching it into the new location and then switching over to the new image and no risk of anything else overwriting the image once it's set. Would this is safe over hard resets etc.? I imagine so, which would be even better.

L2 caching the ROM should be totally safe and have a large effect on the performance, as we see with MAPROM.

[agranlund]

Not having to use the MMU for the ROM copy is probably "A Good Thing(tm)" as it doesn't matter what else messes with the CPU memory tables.

I guess that it would help with patched kernels too by a program in the AUTO folder copying the ROM and patching it into the new location and then switching over to the new image and no risk of anything else overwriting the image once it's set. Would this is safe over hard resets etc.? I imagine so, which would be even better.

L2 caching the ROM should be totally safe and have a large effect on the performance, as we see with MAPROM.

Yeah there could be multiple potential benefits. I had these two in mind:

1. An untouched MMU table allows Mint memory protection to be enabled.
2. I wanted to be able to load any ROM image from disk into to the shadow area, enable rom l2 and trigger a cold boot into it.
Then when the new OS sets up the MMU table it wouldn't interfere with the ROM->RAM mapping.
(The L2 setting is current being reset to OFF on reset but that could easily be changed/fixed/be made an option)

Thinking about these, it may be possible to achieve both of these to some limited degree with PMMU mapping a'la maprom too but I'm not 100% sure?
It's still probably A Good Thing(tm) :)

[Badwolf]

IMG_6371.jpg

"Adequate" ;)

BW

[agranlund]

"Adequate" ;)

Almost... I'm really tempted to try Stefan Nitschke's 16MHz bus mod to get those write speeds up a bit :)
Not sure I want to start cutting tracks on my STM just yet though, may need to get hold of another 520STM for experimentation.

[agranlund]

WIP tools for TF536r2 with the experimental firmware form a few posts back:

tf536.zip

tf536.prg
Installs fastram + FRB + standard Atari MMU table if needed (Atari TOS2.06 and earlier)
Puts ROM in Fastram
Puts first 2Kb RAM in Fastram

It's meant to become a replacement for maprom at some point in the future but it's a very early work in progress.
For now it's only useful with the experimental firmware.
- It can only map rom -> fastram if the ROM is at $E00000 (256Kb or larger TOS)
- It's going to be able to fallback to using the MMU a'la maprom if a supported card + firmware is not detected but this is not yet implemented.
- I want it to have settings at some point but for now it doesn't.

It has very basic testing with EmuTOS, TOS206, Mint and it appears to work with my Ultrasatan.
Mint is able to have memory protection enabled since the MMU table is kept completely standard.

tf536_l2.prg
Toggles L2 cache for the entire ST-RAM on/off.
Warning: Floppy and ACSI devices will not work with L2 enabled.
This could make some games very hard unless you have lightning reflexes.. Rolling Thunder is especially hilarious :lol:

[agranlund]

Inspired by discussions and ideas from @exxos we're now/soon(tm) able to do this:

(I apologise for my poor camera work :lol: )



L2 cache for ST-RAM is active and DMA is working(*) thanks to an unholy alliance of hardware assisted software hacks :)

(*) Very much experimental and still work-in-progress:
- Still needs much more testing before I'd be comfortable with exposing this option
- It could (should) do a better job of hiding and protecting itself from hardware-banging software.
- DMA transfers are slower. It can be optimised quite a bit but it'll never go full speed due to the extra copying of the data.
- Speed of IDE, or other interfaces, which hooks into the DMA interrupt by soldering a wire to it will be effected but not by much.
This fix/hack won't do any unnecessary work for these, but it still needs to find out if that DMA interrupt was fake or not.
(My own old IDE adapter went from 3300Kb/s to 3100Kb/s)

TF536.PRG is a do-it-all program. It maintains the same functionality as maprom did but has the ability to use card-specific features if they exist.
On the TF536r2 with the experimental firmware this means it will use card-features instead of MMU for some things. On other cards it'll do everything with the MMU like before.

It has settings for all of this but it still needs load/save and some simple config util. I'm thinking hold down SHIFT at bootup to bring up a simple interface like @Badwolf suggested some time back.


disclaimer:
The DMA-L2 "fix" isn't going to work for everything. It really depends on how much of the hardware that software takes over.
I have some stuff planned to better hide it from hardware banging stuff but there is always going to be a risk that some games or copy protections are going to "out-lowlevel" and break it.

I'm not too worried about those though..
1. These would for the most part be old unpatched ones and unlikely to work anyway due to the 68030 and/or TOS2+
2. So you're probably going to want to run the 68030 patched release, and they're usually patched to run from HDD too.
3. And if they run from HDD then you're probably going to want to do so, because the floppy is insanely slow.
4. Now that you decided to run them from HDD you probably want to use the TF536 IDE because it's many times faster than DMA or other IDE interfaces hooked up to the 68000 bus.

Problem solved and you've now reached the same conclusion as me that DMA is in fact pointless, except in TOS as a means to copy stuff to/from the TF536 IDE (until you get a ParCP-USB) :lol:
Nah I'm only half joking, I thoroughly enjoy trying to get this DMA + L2 working :)

[Badwolf]

Inspired by discussions and ideas from @exxos we're now/soon(tm) able to do this:

(I apologise for my poor camera work :lol: )

Woo! Excellent stuff + speedy as, too.

L2 cache for ST-RAM is active and DMA is working(*) thanks to an unholy alliance of hardware assisted software hacks :)

Cool. What are you doing? Intercepting writes to the DMA registers and then bulk copying anything you think might have been changed by it?

BW

[exxos]

More speed more speed :excited: :excited: :excited: :excited:

[agranlund]

Woo! Excellent stuff + speedy as, too.

I'm both happy and surprised it actually worked! :lol:

Intercepting writes to the DMA registers and then bulk copying anything you think might have been changed by it?

Yep exactly that!
I basically just bulk copy the DMA'ed data into the shadow on end-of-DMA.

The cpld helps by shadowing all writes to hardware registers (I had plenty of unused space in the reserved region anyway).
The interrupt handler gets hold of the start address by reading the shadowed DMA address counter, and the end address is gotten by reading the real DMA address counter. Then copy. It ended up being quite a small piece of code.

I did a full-software solution too but that ended up being a huge chunk of mmu + bus-error code to intercept register writes (+ perform the write and continuing, because they still need to happen :) )


There's always the risk something disables or overwrites the FDD/ACSI irq handler so I'm thinking the cpld could help by generating a new made-up irq.. Alternativly, go back and expand that register-write interceptor code to virtualise the MFP interrupts..
I really don't think either is necessary in practice to be honest, but this stuff is both interesting and fun :)

[agranlund]

More speed more speed :excited: :excited: :excited: :excited:

I know, right! I'm not going to be playing Frontier any time soon but I enjoy seeing bigger numbers, secretly hoping my humble 520ST is going to beat @Badwolf's accelerated Falcon one day.