exxos's Atari, Amiga & retro forum

agranlund wrote: 24 Jul 2022 18:23 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.

Ohhh a challenge , I accept :lol: :hide:

"50MHz DFB1 Falcon + 33MB/s AltRAM @50Hz RGB mode: ~4160 frames."

I suspect I'm going to need to somehow up the ST-RAM write speeds to beat it though..
Casually building up courage for that Stefan 16mhz bus mod :lol:

@agranlund you're only like 50 frames behind ? Can't remember, but didn't you have one of my rso clock modules ? Ramp up to 55mhz take the lead ;)

The 16mhz mod, yeah fickle nightmare that is.. One day we will have a better MMU ;)

agranlund wrote: 24 Jul 2022 18:22

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.

Cool. I think that was @ijor's suggestion too. I thought it sounded complicated. What do I know? :D

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 :)

So the IRQ is when you decide the transfer is finished and start probing for the endpoint and then trigger the copy?

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.

I did a special version of Frontbench for someone (sorry, I forget who) that did all screen writes to TT-RAM and only blitted the end result to ST-RAM.

It turned out to be slower on the Falcon, but on the ST where writes are sub-4MB/s the overhead may be worth it? I wonder if I can find it.

Idea: a CPLD-enabled simple-blit function. Not a full blitter implementation, but a hardware memcpy that could dump a block of TT-RAM to ST-RAM. Start address, end address, target address, status reg. Without the instruction overhead, would that be worth it?

Not sure it'd fit in a 144XL, mind. ;)

BW

exxos wrote: 24 Jul 2022 18:43 @agranlund your only like 50 frames behind ? Can't remember, but didn't you have one of my rso clock modules ? Ramp up to 55mhz take the lead ;)

Grr! Then I'd have to finally get around to sorting out my TT-RAM speeds, they're well below Anders'.

The 16mhz mod, yeah fickle nightmare that is.. One day we will have a better MMU ;)

I believe @12-MHz developed a compromise bus accelerator between 8 and 16MHz. You can probably guess exactly which frequency. ;)

BW

Badwolf wrote: 24 Jul 2022 20:55 Not sure it'd fit in a 144XL, mind. ;)

Indeed not. But I have a plan ;)

Badwolf wrote: 24 Jul 2022 20:55 Idea: a CPLD-enabled simple-blit function. Not a full blitter implementation, but a hardware memcpy that could dump a block of TT-RAM to ST-RAM. Start address, end address, target address, status reg. Without the instruction overhead, would that be worth it?

that sounds interesting. especially if this CPLD could do a copy combined with C2P .

Badwolf wrote: 24 Jul 2022 20:55 So the IRQ is when you decide the transfer is finished and start probing for the endpoint and then trigger the copy?

Yep, vector $11C. The operating system does everything by polling so that interrupt is normally unallocated.
It has to identify and filter out false triggers from non-DMA devices wired to the DMA interrupt pin (Ie; most IDE adapters) but otherwise it's pretty straightforward.

I did a special version of Frontbench for someone (sorry, I forget who) that did all screen writes to TT-RAM and only blitted the end result to ST-RAM.
It turned out to be slower on the Falcon, but on the ST where writes are sub-4MB/s the overhead may be worth it? I wonder if I can find it.

Oooh, that would be interesting to test on the ST.
I suppose it would avoid hitting ST-RAM for the read part of read-modify-write, at the expense of potentially doing more writes (if Frontier cleverly updates only changed parts, and that end-blit always does the entire screen.. I don't know how Frontier works internally :) )
It'll probably end up slower on my setup with L2 and already very fast reads, but maybe worth is when there is none?

Now if that end-blit only wrote changed data to ST-RAM... that extra code overhead may be worth it to avoid slow writes :)

Ahh.. if only we had an opposite of the CAS instruction!

Idea: a CPLD-enabled simple-blit function. Not a full blitter implementation, but a hardware memcpy that could dump a block of TT-RAM to ST-RAM. Start address, end address, target address, status reg. Without the instruction overhead, would that be worth it?

I'm really just guessing now but I'm not convinced it would be worth the effort?
Unless maybe if it could also ignore blitting unchanged data (or perform c2p as @Cyprian suggested). But even so, it would only be useful to new software programmed to take advantage of it?


Wonder if it would be worth it to try and make the L2 cache more clever and only write-through to ST-RAM on changed data?
I suppose that would make necessary writes even slightly slower but unnecessary ones would be very fast indeed.
Maybe that's a dumb idea and it would make it overall slower.. and I don't think my skills are up to par for something like that either :)

agranlund wrote: 25 Jul 2022 10:17 Wonder if it would be worth it to try and make the L2 cache more clever and only write-through to ST-RAM on changed data?
I suppose that would make necessary writes even slightly slower but unnecessary ones would be very fast indeed.
Maybe that's a dumb idea and it would make it overall slower.. and I don't think my skills are up to par for something like that either :)

Interesting thought. I would make a guess that games like frontbench which have a lot of the same colour background could possibly benefit from such a system. Maybe games like Xenon with a scrolling background which is always changing may not show much speed improvement. Only a guess of course.

If the screen was constantly black then it would probably be blazingly fast :lol:

Why does this sort of sound like video encoding :lol:

agranlund wrote: 25 Jul 2022 10:17

I did a special version of Frontbench for someone (sorry, I forget who) that did all screen writes to TT-RAM and only blitted the end result to ST-RAM.
It turned out to be slower on the Falcon, but on the ST where writes are sub-4MB/s the overhead may be worth it? I wonder if I can find it.

Oooh, that would be interesting to test on the ST.
I suppose it would avoid hitting ST-RAM for the read part of read-modify-write, at the expense of potentially doing more writes (if Frontier cleverly updates only changed parts, and that end-blit always does the entire screen.. I don't know how Frontier works internally :) )
It'll probably end up slower on my setup with L2 and already very fast reads, but maybe worth is when there is none?

No, it's fairly dumb. It clears the screen to blue every frame and then builds up the whole composition from primitives again.

My change just allocates the screen buffer (single one now) in the program code itself (so AltRAM if available) then movems the 32k to ST-RAM when flipping would normally take place to see what difference it makes.

Now if that end-blit only wrote changed data to ST-RAM... that extra code overhead may be worth it to avoid slow writes :)

I have no idea how it'd know what's changed and not! Getting into too advanced techniques for me there ;)

Idea: a CPLD-enabled simple-blit function. Not a full blitter implementation, but a hardware memcpy that could dump a block of TT-RAM to ST-RAM. Start address, end address, target address, status reg. Without the instruction overhead, would that be worth it?

I'm really just guessing now but I'm not convinced it would be worth the effort?
Unless maybe if it could also ignore blitting unchanged data (or perform c2p as @Cyprian suggested). But even so, it would only be useful to new software programmed to take advantage of it?

I was just thinking it was a pity I couldn't use the blitter to dump the screen, which then got me thinking what would actually make that faster. To which the conclusion was instruction overhead, to which the next step was 'well what about all that nice hardware there' ;)

And yes, it'd only be of any use to TT-RAM aware applications that also happened to know what hardware they were running on and wanted to blit an image into ST-RAM where all the instruction didn't alreadty fit into the 030's cache.

It's at the niche end of ideas. ;)

Wonder if it would be worth it to try and make the L2 cache more clever and only write-through to ST-RAM on changed data?

I think the overhead would kill you, but an interesting experiment if you could make the hardware do it.

Cheers,

BW.