exxos's Atari, Amiga & retro forum

OK I'm fu**ing dumb. Needed to isolate the ST bus :roll:

Nice work!

exxos wrote: 12 Apr 2022 00:04 OK I'm fu**ing dumb. Needed to isolate the ST bus :roll:

:chairsmack: :chairsmack:
(You’ve not had one for a while and obviously needed it)

exxos wrote: 12 Apr 2022 00:04 OK I'm fu**ing dumb. Needed to isolate the ST bus :roll:

w00t! :cheer:

:D

BW

Next up is to try a cheap hack of @agranlund 's INTR "hack". Rather than hooking up the ACSI wire to pin 10 of the DMA port to enable auto booting, the TF536 issues the IRQ directly to the IRQ register. So rather than the MFP issuing the IRQ, we just "fake it" instead. End result is the same either way.

Problem there is I'm out of space in the PLD. :roll: so I'll have to do a more dirty hack and pull bit 5 for HDD IRQ when the DMA reg from the SD card is issued. Should only really need to decode the register address, and hopefully it will FIT. We shall see...

I will try @agranlund's new maprom soon which enables the ST RAM cache. Assuming I can FIT the code in the PLD for that as well. I'm really interested to test the speedups myself.

BTW @agranlund what is the reason copying low ram variables to alt-ram gives such a huge boost in speed ? Is TOS simply doing massive amounts of accessing in that ram area ?

OK, this is probably a very stupid question that would probably never work for various reasons, but could you just map the bottom of what would be ST-RAM to the onboard RAM via the CPLD? That way, no copying of variables would be needed and also things like the vector table which would be read around 10000 times a second in the case of HSYNC, wouldn't be read from ST-RAM. Obviously we sacrafice a bit of ALT-RAM here, but we're talking a few K.

Unless someone decides they absolutely need to DMA or BLIT to/from very low memory addresses or for some odd reason decides to locate screen RAM there, would it work? Looking at the memory map, it seems like everything up to 0x05B0 woulds be fair game?

Obviously you're getting to the point of introducing possible incompatibility with things like this, but if speed is the goal, it might be a fun thing to try if it was technically possible. Maybe get that extra 2% in Frontbench :D

Elethiomel wrote: 13 Apr 2022 02:21 OK, this is probably a very stupid question that would probably never work for various reasons, but could you just map the bottom of what would be ST-RAM to the onboard RAM via the CPLD?

That is what MAPROM kind of does. It uses the MMU to remap the lower ram variables to alr-ram.

exxos wrote: 13 Apr 2022 00:44 I will try @agranlund's new maprom soon which enables the ST RAM cache. Assuming I can FIT the code in the PLD for that as well. I'm really interested to test the speedups myself.

When I get around to it I'll update the maprom sourcecode on Github with the 1.9 change as well.
In a perfect world, it'd be nice if it had options in some control panel or whatnot.. probably different sets of options depending on OS.. but that's not for me, at least not at this point in time.

I now see that I wrote this for 1.8:
- In the interest of safety and ease-of-use, Maprom will now inhibit caching of the entire ST-RAM range. Plus the usual graphic card ranges (C00000-DFFFFF)
The upside of this change is that, well, the floppy drive works even if you have cache enabled in the Atari TOS options.


It feels a bit weird to me now if you can't have NiceThings(tm) with operating systems that are cache-aware, just to make it slightly more user-friendly for the ones that aren't.
I think it's fair enough if you have to remember to disable cache in Tos206 if you are using floppy disks, and maybe enable it only when it's possible depending on what you are going to run, your machine, luck, the phase of the moon :lol:

exxos wrote: 13 Apr 2022 00:44 BTW @agranlund what is the reason copying low ram variables to alt-ram gives such a huge boost in speed ? Is TOS simply doing massive amounts of accessing in that ram area ?

Yep exactly that, it has a lot of its work ram in the lower regions of ram, VDI variables and so on.
And there's the vector table which is accessed whenever there is an interrupt like @Elethiomel mentioned.
But as far as Gem/vdi speedup goes I think it's mostly because it's accessing its work ram a lot.

Would have been nice it that part was a runtime option, or a separate program though. It feels a bit dodgy to have that always enabled through maprom.prg

If I ever get a chance I'd really like to rewrite these tools in C so they are easier to add stuff to, and maybe split into separate tools, but I know it won't happen by me. At least not in the near future. I'm trying to be real careful not getting burned out in front of the computer nowadays.

@agranlund I did manage to compile the pak030 TOS changes a while back. They had the flush caches enabled but it didn't help :(

How do the TOSPATCH.PRG stuff work though. Could a flush cache PRG be done ?

I did half think CIIN = BGACK but don't think that would work. Shame the 030 doesn't have a flush cache pin on it :roll:

@agranlund I was wondering if MAPROM.PRG could check the OS version and use that to autoconfigure how to set the caching. TOS 2.06 would have the brain-dead setting, EmuTOS etc. could have the full-fat caching enabled.