exxos's Atari, Amiga & retro forum

Just a quick test with the blitter in to see what happens.. Is pretty bonkers that the CPU can run piles of code which emulates the blitter and still actually beats the blitter in some cases. Actual blitting test which copies memory runs a lot faster when using the blitter!

I had to use the BLITFIX.PRG otherwise crazy things start happening which is to be expected. There is some random corruption which appears now and then, so likely something needs a tweak somewhere.


Without Blitter:




With Blitter:


I guess in terms of desktop usage, simply not using the blitter and using NVDI is still the best way to go. However if running games which specifically use the blitter for copying memory about, the blitter still clearly wins. Though it may not be so simple as games would need the BLITFIX.PRG running I guess as well. So likely original games on floppies will probably not run If using the blitter, but games running from hard drive where you can run the fix will probably run fine.

What does BLITFIX.PRG actually do?

stephen_usher wrote: 16 Apr 2021 11:16 What does BLITFIX.PRG actually do?

----------------------------------------------------------------------------
BLITFIX.PRG
----------------------------------------------------------------------------
Fixes Blitter issues for machines that has TT-RAM, while still allowing
programs and TOS to use the blitter.
The program does nothing unless TT-RAM is available, the CPU is 32bit,
and a blitter is actually installed - so it's safe to leave the program
in the AUTO folder even if you toggle off the accelerator,
remove the blitter, etc.

This program should run after MAPROM.PRG.


* Mainly for TOS 2.06/3.06 & EmuTOS. Limited use for other versions.


NVDI / WARP9:
- These programs are tricked into thinking that the blitter is not
present, thus preventing them from crashing.

Atari TOS 2.06 / 3.06:
- VDI/LineA blitter routines are patched to be able to fall back
to software routines when addresses are outside of blitter range.

EmuTOS:
- Allows programs running in ST-RAM to know the real status
of the blitter.
(EmuTOS will by default hide the blitter if TT-RAM is present)

- If you have a custom build of EmuTOS which is not lying about
the blitter, then this program does nothing.


Other TOS versions:
- TOS is made to believe the blitter is not present
- Only programs running in ST-RAM will be told that blitter is present

I guess that the issue is that the Blitter is both 24 bit and not able to access the TT-RAM? Does it cause a bus error or any other error the CPU can catch if it tries to access RAM outside of the valid range?

What I'm wondering is if the CPU can catch an exception automatically.

As said in the text.. The blitter would be active on any address above 16MB as it does not decode the full 32 bit address bus.. I only tested it once and it just locked up with corruption on screen.

Gets worse on the Falcon too. You can't disable the blitter on TOS4 so I've been able to produce some pretty funky effects blitting absolute nonsense onto the screen. :D

The biggest issue I think you'll see, exxos, is that once ROM is on the 536 board, the blitter will be reading a different ROM to the CPU (it will read from the motherboard ROM). I'm not sure Blitfix can help with that unless MAPROM has already taken it into the non-blittable address space.

I've solved that by simply compiling EmuTOS without Blitter. Off-motherboard TOS4 doesn't seem to be an option.

BW

Badwolf wrote: 16 Apr 2021 13:55 The biggest issue I think you'll see, exxos, is that once ROM is on the 536 board, the blitter will be reading a different ROM to the CPU (it will read from the motherboard ROM).

Blitter can also access TF536 ROM.. the motherboard ROM is actually disabled. If it could not access ROM then all the graphics would be black squares.

exxos wrote: 16 Apr 2021 14:04 Blitter can also access TF536 ROM.. the motherboard ROM is actually disabled. If it could not access ROM then all the graphics would be black squares.

Aaaah, ok. You've something funky going on on the mobo and are servicing requests from mobo AS as well as AS30?

The only way I could think of doing that was if I pulled my onboard ROM chip, but then I don't have a snazzy custom motherboard. :P

BW

Badwolf wrote: 16 Apr 2021 20:07 Aaaah, ok. You've something funky going on on the mobo and are servicing requests from mobo AS as well as AS30?

AS and AS30 will decode ROM. I don't have to worry about anything like the GLUE decoding the ROM as it does not decode 206 space anyway.

The TF536 ROM is wired in pretty much exactly the same as the motherboard ROM.. There is practically no difference other than just physically moved from one end of the board to the other..

You might not have seen my early test where I literally run a wire from the TF536 to the MB ROM ? https://www.exxosforum.co.uk/forum/viewt ... 418#p60418

Badwolf wrote: 16 Apr 2021 20:07 The only way I could think of doing that was if I pulled my onboard ROM chip, but then I don't have a snazzy custom motherboard. :P

Actually has nothing to do with the motherboard... Be simple to remove the Falcon ROM anyway ?

For example my V2.2 booster Is pretty much the same thing.. Just pull out the motherboard ROM and you don't really have to worry about it then..

GLUE will still decode TOS104 space.. but one good thing about the GLUE is it releases DTACK about 20ns after AS goes high.. So technically while the PLD issues DTACK, is pretty much all in sync with the GLUE anyway.. The PLD can decode ROM slightly faster than the GLUE, but as glue is switching the motherboard ROMs, which are not plugged in, whatever the GLUE does is totally irrelevant anyway.

I don't know the speed of the Falcon logic, but with some small wait states you should still be able to access the on-board ROM at around 32Mhz. Though I guess copying ROM into TTRAM (like the TF536 does now) is the way to max out ROM speed anyway.. At least in TTRAM it is accessing at 32 bit, whereas the motherboard is of course only 16 bit. In either case, I don't think it's worth the effort of doing a actual 32bit ROM IC... it would of course be double speed than the motherboard ROM, but it would still be bottlenecked at around 32 MHz anyway.

If the Falcon logic is a bit dumb like the ST is, it might decode the motherboard ROM within like 20ns of AS going low anyway.. You would have to check the AS to ROM_CE delays there.. but if it pretty much happens at the same time.. Then you can reuse the Falcon's decoding for ROM access... assuming it is dumb for DTACK as well, and goes low at the same time as AS, then your CPU could pretty much access it "as is". Depending on the speed of your CPU, if you are running at 50MHz like me, then you need to add a couple of CPU clocks delays before you let the CPU see DTACK.

That method was how the previous 16MHz V1.5 booster worked. That just reused the GLUE's logic and ran the CPU at 16MHz access to MB ROM. Not so simple when using TOS206, as you need to do your own decoding.. ROM itself can be on the booster or the motherboard it really does not matter. I just put it on the booster to save people having to buy and fit a dual tos board as well.. Of course the H4 / H5 motherboards have the faster PLCC ROM built on a standard anyway.. Though I guess it may be better using the ROM on the booster board anyway so signals will be less noisy to the CPU.

exxos wrote: 16 Apr 2021 20:55 AS and AS30 will decode ROM. I don't have to worry about anything like the GLUE decoding the ROM as it does not decode 206 space anyway.
...
< snip detailed run-down of method and options >

Thanks for that. I hadn't quite twigged exactly what you were up to in that earlier pic & of course I'd forgotten the different ROM addresses.

Lots of good information in there. I wanted to leave my on-board ROM in place because a) it is actually a complete bastard to remove (it's under the RAM board which is harder to pry off than a dog that's taken a liking to your leg) and b) my expansion's designed to be switched off entirely as it's going to be ages until compatibility is decent enough to even think about having it always on. *cough* bloody DSP *cough*.

In fact, my 'off' mode is really a slave mode where my (flash) ROM can be reprogrammed. It appears in a different address range that you can write to with a special program. It takes about a minute to reflash 512k and if you flash something unbeatable, you just drop back to 'off' mode with its own ROM.

But at least now some of your answers when we were trying to get that low-byte decode working make a lot more sense to me! :lol:

BW