Page 2 of 12
Re: DFB1 BadMooD issues
Posted: 15 Oct 2022 19:10
by Badwolf
dml wrote: 15 Oct 2022 10:04
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
under DFB1!
BW
Re: DFB1 BadMooD issues
Posted: 15 Oct 2022 19:29
by 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
Re: DFB1 BadMooD issues
Posted: 17 Oct 2022 13:42
by dml
Badwolf wrote: 15 Oct 2022 19:10
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...
Re: DFB1 BadMooD issues
Posted: 17 Oct 2022 13:51
by 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.
Re: DFB1 BadMooD issues
Posted: 17 Oct 2022 13:56
by Badwolf
dml wrote: 17 Oct 2022 13:51
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
Re: DFB1 BadMooD issues
Posted: 17 Oct 2022 14:00
by dml
Badwolf wrote: 17 Oct 2022 13:56
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...
Re: DFB1 BadMooD issues
Posted: 17 Oct 2022 14:15
by Badwolf
dml wrote: 17 Oct 2022 14:00
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
Re: DFB1 BadMooD issues
Posted: 17 Oct 2022 14:56
by 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.
Re: DFB1 BadMooD issues
Posted: 17 Oct 2022 15:08
by 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!
Re: DFB1 BadMooD issues
Posted: 17 Oct 2022 19:38
by Badwolf
dml wrote: 17 Oct 2022 14:56
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