DFB1 BadMooD issues

[Badwolf]

Apologies - that binary required a FPU fitted for no good reason.

Link to the fixed version: https://www.dropbox.com/s/0qy30bovf2ew9 ... p.zip?dl=1

Why might this even be useful? Because it might help detect when some piece of software has changed the CACR but hasn't put all the flags back - especially the ones nobody notices on a base Falcon, which in turn could quietly affect the performance of your DFB1. If any such software is noticed, it could then be cautioned in your notes.

Hopefully that doesn't actually happen though :)

Interestingly whilst these work on the stock Falcon (although me fondling the burst flags doesn't seem to be preserved -- perhaps TOS resets them?) this only returns

Code: Select all

CACR: ::::: (00000002)

under DFB1!

BW

[Badwolf]

Hi @dml,

Finally got around to testing a particular theory. Probably not relevant now you've proved the new VGA logic works, but running DFB1 without clock switching (ie. at 16MHz) works fine. I can't test that with TT-RAM, though, as it doesn't like the slow access.

BW

[dml]

Interestingly whilst these work on the stock Falcon (although me fondling the burst flags doesn't seem to be preserved -- perhaps TOS resets them?) this only returns

CACR: ::::: (00000002)

under DFB1!

That's curious. Let me think about it...

[dml]

So what that tells me...

All of the cache flags are disabled (via 68030's internal CACR register) ...except IFRZ (freeze instruction cache).

IFRZ is CACR bit #1. I didn't bother pretty-printing the token for IFRZ or DFRZ in the program, mainly because I wasn't expecting it to be set ever. But here we are :) I'll update the program to include the freeze bits and link it later. There are other bits such as ICLR/DCLR but they are brief, write-only state.

Now WHY the freeze bit would be set, I have no idea. What other software do you have running from AUTO or CPX maybe? Or do you have a modified TOS?

Or perhaps the detection of FastRAM is involved and the cache has been deliberately disabled until something is expected to manually configure it during or after boot.

Something is certainly clearing the CACR because TOS normally sets this up from ROM.

[Badwolf]

So what that tells me...

All of the cache flags are disabled (via 68030's internal CACR register) ...except IFRZ (freeze instruction cache).

I actually think it's the other possiblity: sadly, it's returning nonsense. The caches are most definitely on and reported as such by other programs.

Now *why* it should return nonsense by just enabling DFB1..? That's intersesting!

Auto folder is FASTRAM.PRG and NVDI under TOS404.

BW

[dml]

I actually think it's the other possiblity: sadly, it's returning nonsense. The caches are most definitely on and reported as such by other programs.

Well that's the other possibility, and maybe that's correct. Does it always return the same thing or does it look erratic?

This was a compiled program (did it in a hurry!) and the compiler may be shoving extra machine detection and init code in front of my code. While I would not expect it to change the cache or cause anything like this, I should probably just make a simpler version in 68k to remove any doubt...

[Badwolf]

Well that's the other possibility, and maybe that's correct. Does it always return the same thing or does it look erratic?

Every time I've run it it's said that, although I admit it's only been a handful of times.

I'll alter my little CACR fondling program (below) to dump the before and after as well and see what that says.

BW

EDIT: actually, I suppose it could be FASTRAM.PRG, but I didn't think that did anything clever (as opposed to MAPROM.PRG, which does)


burstfondle.S:

Code: Select all

  TEXT 
Begin:
  ;supexec
  pea       mycode         ; Offset 2
  move.w    #38,-(sp)    ; Offset 0
  trap      #14          ; Call XBIOS
  addq.l    #6,sp        ; Correct stack


; PTERM0
  move.w    #0,-(sp)     ; Offset 0
  trap      #1           ; GEMDOS
  addq.l    #2,sp        ; Correct stack
  rts                   ; ET go home

mycode:
  movec CACR,D0
  ;unset bit 12 and bit 4
  and.w #$EFEF,d0
  movec d0,CACR  
  rts

[dml]

Here is a simplified 68k version of the same tool, without any nonsense.

https://www.dropbox.com/s/l6fnjsf8xcmeg ... k.tos?dl=1

I think I had also packed the C version with an executable packer and perhaps that can fiddle with CACR under some circumstances. Why it would treat DFB1 differently I'm not sure, maybe the FastRAM?

Anyway this version is clean, quite similar to the code you posted above. Lets see if it looks more sensible.

[dml]

Source for this: https://www.dropbox.com/s/xb5vm29pgrgsp ... k.zip?dl=1

[EDIT] corrected the link - was missing a file. should have stayed in bed this morning!

[Badwolf]

Here is a simplified 68k version of the same tool, without any nonsense.

https://www.dropbox.com/s/l6fnjsf8xcmeg ... k.tos?dl=1

I think I had also packed the C version with an executable packer and perhaps that can fiddle with CACR under some circumstances. Why it would treat DFB1 differently I'm not sure, maybe the FastRAM?

Anyway this version is clean, quite similar to the code you posted above. Lets see if it looks more sensible.

That one works nicely: $3111 going to $2101 when I run my burst disabler from the command line.

However, it looks like GEM resets the CACR after each program as when run from the desktop it does nothing.

Interesting (if ultimately pointless!) results, though. Looks like your old CACRDUMP program is the one messing up the CACR itself, but only when run under DFB1!

IMG_0384.JPG

Same thing on the Falcon with DFB1's disable jumper set:

IMG_0385.JPG

What about in 16MHz DFB1 mode?

IMG_0386.JPG

Bizarre! Utterly bizarre!

BW