Posts by erique

Quote

P96 is not there to ensure memory and IO access is actually working

Right - I see your point.

My perspective was that it used to do that (to some degree at least), and the (old) docs supported that.

In attempt to summarize :
In 3.2.4, as it now relies completely on mmu.library, the meaning of BIB_CACHEMODECHANGE has changed to merely be a hint/suggestion - never a guarantee.

With previous versions, and when mmu.library wasn't present, P96 would set the MMU flags directly. This mechanism isn't supported anymore.

Ok, I see you've now changed the documentation re re BIB_CACHEMODECHANGE; would've been a bit more honest to acknowledge that incorrect documentation up front.

I assume that's also why a missing mmu.library will silently fail?

Oh, I wasn't suggesting using trial-and-error as a basis for understanding the operation.

I was merely trying to confirm the operation based on what the docs suggest the operation actually is (or rather, supposed to be).

I'm referring to the currently available online documentation hosted by icomp.de - nothing else.

So if I understand you correctly BIB_CACHEMODECHANGE is

a) actually not guaranteed to change the memory page to IMPRECISE/NONSERIALIZED

b) only a hint/suggestion to P96; not a "requirement" as such

?

I'm still not sure what negative implications there would be if rtg.library simply also provided the MAPP_CACHEINHIBIT flag when calling mmu.lib/SetProperties.

To me this would actually make the operation in line with the documentation (linked above).

Is there any negative consequence of doing that?

Alright.

In order to actually verify what rtg.library did to the MMU table prior to v3.2.4 I dumped the MMU tables using mmulist, before and after loading my card driver.

The result looks like this:

The RTG memory area is between 01010000 and 0140F000, which is part of system fastram (01000000 - 03FFF000).

As expected the area goes from "copyback" to "imprecise" (which means non-cached imprecise).

To me this indicates that the contract for BIF_CACHEMODECHANGE is to actually change the memory area to "Noncachable, Imprecise".

If I do the same exercise with P96 v3.2.4 (obviously with mmu.lib installed this time):

i.e. in this case the MMU flags for the memory region used by the RTG card do not change.

Maybe another way to look at it:

With the old rtg.library (before the "introduction" of mmu.lib) the "contract" (from my perspective, at least) was that when the driver requested BIF_CACHEMODECHANGE, this meant the memory would switch to IMPRECISE and CACHEINHIBIT.

That's at least the observation I had at the time.

Granted - I have not explicitly confirmed this to be true (by disassembling the code, or looking at the MMU table afterwards).

I think you're suggesting that this wasn't (and still isn't) true, but the contract was/is to merely switch from PRECISE to IMPRECISE (if, and only if, the area was already marked CACHEINHIBIT)?

Quote

P96 behaviour with the mmu lib present has not changed

This is correct. What I'm saying is that the P96 behavior without having mmu.lib present has changed.

If you boot a system with an older rtg.library, without having installed mmu.lib, and the driver requests BIF_CACHEMODECHANGE, then the memory area reported via MemorySpaceBase/Size will be marked CACHEINHIBIT.

This is not what happens with the new rtg.library (when having mmu.lib installed); the area is not marked CACHEINHIBIT.

As outlined in the first post, there is also no warning/error shown if rtg.library cannot find mmu.library.

Quote

So unless you've created shared memory in your system that for some reason is in the freemem list, but can also be used as gfx mem, you're good. If you have such shared memory, you may need to take care of cache inhibit yourself.

This is exactly the situation I have; The memory used for RTG is "any" memory, which (if mmu.lib is installed) defaults to COPYBACK.

I already have the workaround you suggest in the CARD driver today, because it was required when using the older rtg.library together with mmu.lib.

But what I'm really confused about is "what does IMPRECISE w/o CACHEINHIBIT actually mean?".

Reading the 68060 manual I can't find any support for marking pages like that. Maybe I'm blind

To me there are only 4 modes : CACHED (copyback), CACHED (writethrough), CACHEINHIBIT (precise), CACHEINHIBIT (imprecise).

So what do you suggest this cache-enabled-but-imprecise mode actually is?

That's why I'm suggesting you need to also provide the CACHEINHIBIT flag together with IMPRECISE+NONSERIALIZED, when calling mmu.lib/SetProperties, because not doing that will be a no-op (as per mmu.lib documentation).

We're running a true 68060 rev6, no EC/LC model. But that's really beside the point.

If you're calling mmu.library/SetProperties() with only IMPRECISE+NONSERIALIZED (and not setting the CACHEINHIBIT bit) then the doc (and my observation) suggests that it's not doing what it's "supposed" to be doing.

Can you please double check the parameters passed?

This is the driver for the RTG board in Amiga core for the FPGAArcade Replay. A "virtual" graphics board, implemented in VHDL. It does have a blitter.

From my end I see a behavioral difference after the change to use mmu.library.

The old rtg.library would (seemingly) set the area imprecise/cacheinhibit.

The new rtg.library seemingly only sets the IMPRECISE+NONSERIALIZED bits when calling mmu.library/SetProperties().

Afaik there is no "imprecise+copyback" on the 060, but perhaps that's just me reading the 68060 manual incorrectly.

It sounds like you're confirming rtg.library is calling SetProperties() with only IMPRECISE+NONSERIALIZED and not CACHEINHIBIT?

The mmu.library documentation says that this will not produce a correct result.

From mmu.doc:

v3.2.4 comes with this change (among other things):

Quote

Removed the manual MMU hack. Any MMU table modifications require now the availability of the mmu.library.

This is really good; I can finally get rid of my workarounds in the driver!

But - It seems to me that there is no error check for a missing mmu.library; i.e. if the CARD driver asks for IMPRECISE/NONSERIAL (BIF_CACHEMODECHANGE) it looks like it's silently ignored in that case.

Also, it seems rtg.library only sets the MAPP_IMPRECISE + MAPP_NONSERIALIZED bits when calling SetProperties(), and not the MAPP_CACHEINHIBIT.

According to the mmu.library docs MAPP_CACHEINHIBIT is required for correct operation.

Ofc - it might just be me doing something silly

Oh well - it seems I spoke too fast: after power-cycling to connect the IDE drives and some other Z2/Z3 boards I'm now back where I started:

Black screen, that can be bypassed by removing the PLCC, but hot-inserting and trying to flash it yields the same output as in the first post.

Faulty PLCC perhaps?

Hah, after attempting this a 5th time, and trying all imaginable voodoo-maneuvers, the flash tool suddenly succeeded with a "ROM flashed" message.

And yes, now the card seems fully functional (I can see the contents of the DOM at least).

I guess I'll just leave this thread here in case anyone else happens to get a board with an "empty" PLCC.

Hi,

I have just taken a brand new Buddha Flash (20th version) out of its box to try it out in my A4000. (The Buddha was purchased in March 2021, but has been sitting in a box waiting for the A4000).

When the card is plugged in as-is (no jumpers changed, DOM inserted, J2 closed - basically "factory settings" - and no other IDE device attached to it) the A4000 will not boot up, but instead sit silently with a black screen.

As it was suggested in another thread that removing the PLCC would perhaps at least bypass the early hang, I removed it.

This made the A4000 boot-up, but the card is not visible autoconfig-wise (which makes sense).

But trying to flash the PLCC, by hot-inserting it, and running the BFlashTool ("initial") has so far been unsuccessful.

The tool outputs:

Any ideas what I could try next?

Cheers,