REV 3 - REV 5 - The beginning (ST536)

[Badwolf]

EDIT:
A random thought that maybe the blitter still trying to access the on-board ROM. So I let the blitter access that and now the floppy icons are back..

So I think for some reason the blitter cannot access the full ROM range when its in alt-ram.. @agranlund ?

If you have motherboard ROM and 536 ROM and MAPROM, things are going to get confusing fast.

MAPROM has nothing to do with the blitter - it's in TT-RAM and it won't work. Shouldn't be an issue in and of itself, but best to turn it off for testing before you wrap your brain in knots.

GLUE will trigger on board ROM for the blitter if it's fitted and issue a DTACK to the blitter whether it is or isn't. You need to work with this.

You CPLD may or may not trigger 536 ROM on a blitter ROM demand (depends if you're going on AS, AS30 or both). This will be the hardest bit to get right. You should not respond to blitter requests if you have a motherboard ROM still in place. You must respond to requests but not drive DTACK if you don't.

If you can guarantee the 536 ROM and the onboard ROM are identical, then the easiest thing to do is to ignore motherboard requests for ROM and let the motherboard do its own thing.

If you can't guarantee the above the you should insist the onboard ROM is removed, code the CPLD to open the bufers and drive the 536 ROM when AS is low and the range is correct, but not issue DTACK.

Or you could code your CPLD to react to the blitter configuration registers in the same way an ST without blitter does (dunno if that's isolate the buffers so you get an FF, or chuck a bus error) and therefore convince TOS you don't have one fitted. :P

Blitter is a bother.

BW

[exxos]

GLUE will trigger on board ROM for the blitter if it's fitted and issue a DTACK to the blitter whether it is or isn't. You need to work with this.

Indeed. GLUE will issue DTACK. Now I think about it, alt-ram is using STERM.. The TF536 isn't actually issuing DTACK to the MB DTACK on ROM access (in alt-ram). So it depending on the GLUE DTACK there.

BUT.. with all that screwy SDRAM timing crap.. is the ROM (in alt-ram) actually being served when the blitter is accessing it..

I don't know what BLITFIX is doing with all this. But I assume it should not allow ROM access to bus masters in alt-ram. It must be a mixed bag as it partly works :shrug:

[Badwolf]

GLUE will trigger on board ROM for the blitter if it's fitted and issue a DTACK to the blitter whether it is or isn't. You need to work with this.

Indeed. GLUE will issue DTACK. Now I think about it, alt-ram is using STERM.. The TF536 isn't actually issuing DTACK to the MB DTACK on ROM access (in alt-ram). So it depending on the GLUE DTACK there.

BUT.. with all that screwy SDRAM timing crap.. is the ROM (in alt-ram) actually being served when the blitter is accessing it..

I don't know what BLITFIX is doing with all this. But I assume it should not allow ROM access to bus masters in alt-ram. It must be a mixed bag as it partly works :shrug:

AltRAM is not involved at any point.

Blitter is asking for something in the (perfectly non-AltRAM) 0x00Exxxxx range.

Whether you wish to handle that by asserting ROMCE and opening the buffers when the ROM is decoded and (motherboard) AS goes low depends on whether you have a ROM chip on the motherboard or not.

BW

[exxos]

AltRAM is not involved at any point.

Blitter is asking for something in the (perfectly non-AltRAM) 0x00Exxxxx range.

Whether you wish to handle that by asserting ROMCE and opening the buffers when the ROM is decoded and (motherboard) AS goes low depends on whether you have a ROM chip on the motherboard or not.

That can't be the case as MAPROM remaps ROM access to alt-ram. So I assume it would do the same for any ROM access, blitter included. So when blitter is asking for ROM, MAPROM is redirecting that access to alt-ram, not physical ROM. In that case as altram uses STERM to the CPU, "DTACK" isn't involved at all there. So it depends on GLUE DTACK. But again, alt-ram data isn't valid all the time like it is in ROM. So IMO its "hit and miss" if the blitter latches ROM data while the SDRAM is actually pushing the data.

[Badwolf]

That can't be the case as MAPROM remaps ROM access to alt-ram.

MMU remapping ONLY affects CPU accesses. AltRAM is not involved with the blitter at any stage at all. The CPU is dormant whilst blitter is working.

Blitter is asking for 0x00Exxxxx -- it's a normal ROM request.

BW

PS. Seriously: don't use MAPROM whilst you're testing this. It has no material affect on the outcome but it's screwing with your brain! I told you so! :P

[exxos]

MMU remapping ONLY affects CPU accesses. AltRAM is not involved with the blitter at any stage at all. The CPU is dormant whilst blitter is working.

Ah yep yes you're right. I kinda assumed the case as blitter couldn't access physical ROM.. and yet it basically worked. So not sure how the blitter is getting ROM data at all.. In any case, I will just let bus masters access the physical ROM. It seems to work fine that way anyway.

PS. Seriously: don't use MAPROM whilst you're testing this. It has no material affect on the outcome but it's screwing with your brain! I told you so! :P

Yeah, it does not take much these days. :stars: :chairsmack:

I did the same GB6 test without BLITFIX and now the missing icons are back. So BLITFIX must be doing what its supposed to be doing I guess :shrug:

[Badwolf]

In any case, I will just let bus masters access the physical ROM. It seems to work fine that way anyway.

It's the easiest if your on-board ROM and your off-board ROM are the same. If you put EmuTOS in one and TOS2.06 in the other, you'll get interesting things blitted to the screen.

Been there. Done that. :lol:

BW

[exxos]

It's the easiest if your on-board ROM and your off-board ROM are the same. If you put EmuTOS in one and TOS2.06 in the other, you'll get interesting things blitted to the screen.

Been there. Done that. :lol:

Yep me too :lol:

Yeah MB ROM needs removing when using the ST536..

But wait a second.. GLUE won't be issuing DTACK as its TOS206.. ST536 DTACK is STERM.. So nothing is actually issuing DTACK.. hmmm... I think I had this type of problem before with the SEC booster.. It is something odd like it times out somehow finishes the cycle without DTACK, but does not seem to cause a BERR... I saw a huge slowdown in doing that...But the blitter actually functioned as it should otherwise.

So I will have to see if I can fit DTACK code in for ROM access on bus masters.. Is possible the blitter is running a lot slower than it should be currently..

[Badwolf]

Yeah MB ROM needs removing when using the ST536..

OK...

But wait a second.. GLUE won't be issuing DTACK as its TOS206.

Ah, good point. STF.

ST536 DTACK is STERM.

What? No. Don't say things like that! Grr. :chairsmack:

So nothing is actually issuing DTACK.. hmmm... I think I had this type of problem before with the SEC booster.. It is something odd like times out somehow finishes the cycle without DTACK, but does not seem to cause a BERR... I saw a huge slowdown in doing that...

So I will have to see if I can fit DTACK code in for ROM access on bus masters.. Is possible the blitter is running a lot slower than it should be currently..

So what happens on the STE if nothing issues DTACK after (I think it's about) 100 cycles, BERR is issued.

Blitter doesn't care whether it's DTACK or BERR it just sees end of cycle and carries on. So ends up running ~50x slower than normal. I presume it's the same on the STF chipset.

So, you'll either need to (A):-

Decode ROM when accessed by motherboard AS.
Enable the buffers when this happens.
Make DTACK bidirectional and assert it ~ one cycle after teh above happens.
Fit all that in your CPLD.

or (B):-

Chuck a bus error on the blitter registers and the users can lump it.
Fit that in your CPLD.

or (C):-

We sort out blitfix to block ROM blitting.


Now, bear in mind if you go down the route of (A), your card won't be STE compatible (fighting DTACKs).

I know which route I would choose to avoid, at least. :P

BW

[exxos]

So I managed to get DTACK in .

Basically:

Code: Select all

assign DTACK = ROM_DTACK | BGACK  ? 1'bz : 1'b0;

And I changed DTACK to "inout" in the topfile.

But nothing seems to have changed speed wise. Oddly I have to run MAPROM BEFORE BLITFIX otherwise the icons disappear again in the first GB6 test. :shrug: If I just run MAPROM on its own, icons are missing. So BLITFIX is needed, but can't be run first as @agranlund suggests it should be :shrug: