exxos's Atari, Amiga & retro forum

8 Bit Dreams wrote: 22 Oct 2019 07:59 What do You think, will this work on STe with Kludges plcc adapter?

Isn’t the CPU usually socketed on STe’s? I’ve never even seen an Atari IRL, so I could very well be wrong here 😂

No not always. Sometimes, especially in later versions, it is directly soldered to the board. You can of course remove it and solder in a PLCC SMT socket. A little fiddly but that's what I did :)

I agree with Agranlunds, there is no reason to turn the BLiTTER off.

It becomes a bit of a mess once you start running stuff from FastRAM. Of course you can force such programs to ST-RAM but the more you do this the more you're loosing the point of the accelerator in the first place.

I don't think it's a problem for 2D games since they probably run perfectly fine from ST-RAM anyway, but TOS and NVDI at least are the two main things I want in FastRAM for a speedy system, and both of them will crash because of the blitter when doing so.
Spending time and patching these is an option of course, but this is not a nice road to walk down.


But.. I did build that blitter expansion card for my ST and I am intent on using it to some extent together with my TF534 :)

So for the purpose of curiosity and testing I made some small changes to EmuTOS to have it allow the Blitter even in the presence of FastRAM. Additionally, I made it fall-back to software routines if source or destination was outside of ST-RAM.
This made it work really well. The desktop works fine, as well as the the blitter apps I have. Except for NVDI, which I consider a blocker.

Out of curiosity, are there other screen accelerators like NVDI out there that offers the same type of performance boost?
Also, any tips on blitter games/demos/apps that works on a non-STE machine would be greatly appreciated :)
I only have Gembench, BlitB and the blitter-enhanced version of "Hardn'Heavy" to test with.

Seeing as NVDI completely humiliates the blitter for GEM stuff on the 030, I am leaning on the best option being to have the TF firmware hide the blitter for the system. And then make some game launcher app that can tell TF to unhide the blitter as it launches the game.
The only real point of the blitter at this point is probably for running games that require or benefit from it..

TF53x optimised build of EmuTOS, in FastRAM using MAPROM. NVID, Blitter ON, Blitter OFF:
(actually, just 68030+FastRam optimised build. Should work fine on any 030 accelerator that has TT-RAM)

Standard build of EmuTOS, in FastRAM using MAPROM. NVDI, Blitter ON, Blitter OFF:

agranlund wrote: 25 Oct 2019 23:34 Out of curiosity, are there other screen accelerators like NVDI out there that offers the same type of performance boost?

"warp9" is similar to NVDI. But I don't think it was as compatible.. IIRC it was faster with some things than NVDI.

"warp9" is similar to NVDI. But I don't think it was as compatible.. IIRC it was faster with some things than NVDI.

Thanks Exxos! I will give this one a try :)

I submitted a bunch of Glitter related fixes to my Github, and fixed some nasty bugs in MAPROM.
Finally, I can leave the blitter inserted in my nice accelerator stack of TF534 + Blitter expansion :)


New TF53x firmware with Blitter timing fix (built binaries are in the bin folder)
https://github.com/agranlund/tf534

tftools has a bunch of bug fixes in all the programs, also adds BLITOFF.PRG:
https://github.com/agranlund/tftools


BLITOFF.PRG disables the blitter for programs running outside of ST-RAM. Put it second in the auto folder, after maprom.prg (or fastram.prg).
This will make TOS2.06 work fine from FastRAM, as well as NVDI.
Games and demos should still have access to the Blitter, as long as they run from ST-RAM (tested with Hard'n'Heavy + BlitB)

Even though EmuTos already disables the Blitter it's still worth running BLITOFF.PRG because it can actually allow more programs to use it than with just EmuTos default.

(This program just replaces the Blitmode XBIOS function so any program that ignores TOS and hits the blitter directly will still be able to do so)

Blitter is finally a success :)

I realise it's probably just me... but if you by any chance have an Atari, with Blitter & TF53x then you want to grab the latest stuff from here:
https://github.com/agranlund/tftools

Put BLITFIX.PRG after MAPROM.PRG in the AUTO folder to make TOS2.06 work even if you have a blitter is installed.
The program hooks into TOS internal blitter routines and enables them to fall back to software blits when addresses are outside of the blitters reach.

In addition to making TOS work, it can detect and trick NVDI into working by telling it the blitter is not present (NVDI uses the blitter on all machines except for Falcon). NVDI must be loaded after BLITFIX in this case.


BLITFIX *should* work also on TOS3.06.. Someone with a PAK68/3 may want to give this one a go if they previously had to remove the blitter.
But then again, perhaps the PAK version of 3.06 is too heavily patched for this program to work or make sense?


It's useful also for EmuTOS since it will allow programs that are running in ST-RAM to know the true status of the blitter.
(EmuTOS will not use the blitter if TT-RAM is present, and it will lie about it to any program that asks)


Now, that was quite fun and I did get a chance to learn a bunch about TOS in the process :)


TOS 2.06, blitter disabled: TOS 2.06, blitter enabled EmuTOS, blitter disabled by EmuTOS due to FastRAM EmuTOS, custom TF53x optimized build, blitter enabled All of them above pale in comparison with the custom EmuTOS build + NVDI though :)

agranlund wrote: 02 Nov 2019 22:51 All of them above pale in comparison with the custom EmuTOS build + NVDI though :)

So for us not keeping up, what exactly is different here ? Is blitter now working in fast-ram to get the speed boost ?

The blitter can’t blit to fast ram on the TF534... at least it can’t to all memory locations.

But the blitter speed is awful compared to the CPU just moving data in fast ram.

I build EmuTOS with -m68030 -DSTATIC_ALT_RAM_ADDRESS=0x01000000

The biggest performance boost comes from letting it know about fastram at compile time, this allows it to put a large chunk of its internal variables there instead of in ST-RAM (the Vampire V2 + V4 optimized builds do the same thing)


Additionally, my local build has changes to make it allow the Blitter even when fastram is present, and to make that not just crash and die it has some additional code to make it fall back to software blits if someone is trying to blit to or from 32bit address space.

But as can be seen from the benchmarks, the blitter really stands no chance in general desktop use compared to just using NVDI in fastram (in which case the blitter is not used by the desktop at all).

For me personally it's worth being able to use the blitter with the few legacy applications that require it to even function - and for using the blitter for fun in own code.

agranlund wrote: 03 Nov 2019 16:29 I build EmuTOS with -m68030 -DSTATIC_ALT_RAM_ADDRESS=0x01000000

The biggest performance boost comes from letting it know about fastram at compile time, this allows it to put a large chunk of its internal variables there instead of in ST-RAM (the Vampire V2 + V4 optimized builds do the same thing)

Hehe, as you can see, it is easy to do custom builds of EmuTOS 8-)