Auto-setting chipset to "original" on AGA startup

[MethodGit]

Pardon me if this is a silly thing to ask, but if the following code below is equivalent to automatically disabling CPU caches on startup:

CMPI.W #24,22(A6)            0C 6E 00 24 00 22   < check if Kick version is v36
BLT (8)                      6D 08               < skip to end if older version
MOVEQ #0,D0                  70 00               < set appropriate registers
MOVEQ #FFFFFFFF,D1           72 FF               < before initiating
JSR -288(A6)                 4E AE FD 78         < the routine to kill caches (forget the proper name)

What's the equivalent/appropriate routine to automatically setting the chipset to "original" when starting up an AGA system?

[jotd]

move.l	(_GfxBase),a6
	cmp.l	#39,(LIB_VERSION,a6)
	blo	.noaga
	btst	#GFXB_AA_ALICE,(gb_ChipRevBits0,a6)
	beq	.noaga
	
	move.b	(gb_MemType,a6),oldbandwidth
	move.b	#BANDWIDTH_1X,(gb_MemType,a6)	;auf ECS Wert setzen
	move.l	#SETCHIPREV_A,D0
	JSRLIB	SetChipRev
	move.l	D0,oldchiprev

.noaga

[MethodGit]

Originally Posted by jotd

move.l	(_GfxBase),a6
	cmp.l	#39,(LIB_VERSION,a6)
	blo	.noaga
	btst	#GFXB_AA_ALICE,(gb_ChipRevBits0,a6)
	beq	.noaga
	
	move.b	(gb_MemType,a6),oldbandwidth
	move.b	#BANDWIDTH_1X,(gb_MemType,a6)	;auf ECS Wert setzen
	move.l	#SETCHIPREV_A,D0
	JSRLIB	SetChipRev
	move.l	D0,oldchiprev

.noaga

Thank you, but ummm, could you care to translate that into a version I can understand? Like how I wrote the code in my post for instance? The custom tags don't really mean anything to someone like me who hasn't inhaled the contents of the MC68000/Amiga instruction manual.

[Vot]

Originally Posted by MethodGit

Thank you, but ummm, could you care to translate that into a version I can understand? Like how I wrote the code in my post for instance? The custom tags don't really mean anything to someone like me who hasn't inhaled the contents of the MC68000/Amiga instruction manual.

Probably from the commodore amiga ndk includes I'm guessing.

I.e http://amigadev.elowar.com/read/ADCD.../node0612.html contains a number of the gfx related defines

[MethodGit]

Originally Posted by Vot

Probably from the commodore amiga ndk includes I'm guessing.

I.e http://amigadev.elowar.com/read/ADCD.../node0612.html contains a number of the gfx related defines

Well googling around it would appear that I need to find a way to load GfxBase first before I can do the version comparison. I can feed a graphics.library reference into A1 similar to how dos.library is loaded for AmigaDOS-formatted disks, but then how do I know which JSR command to use? Using the one for dos.library (JSR -60(A6)) will conveniently leave A1 pointing at the version information for graphics.library but otherwise does not at all match the position that JOTD is evidently referring to with his CMP.L start.

I look at all the technical jargon and see tons and tons of tags but no mention in layman's terms of how best to translate all of this into hex code and make sure pointers are pointing at the right things.

[hooverphonique]

Does SetChipRev do anything else than modifying ChipRevBits0?

[Vot]

Originally Posted by MethodGit

Well googling around it would appear that I need to find a way to load GfxBase first before I can do the version comparison. I can feed a graphics.library reference into A1 similar to how dos.library is loaded for AmigaDOS-formatted disks, but then how do I know which JSR command to use? Using the one for dos.library (JSR -60(A6)) will conveniently leave A1 pointing at the version information for graphics.library but otherwise does not at all match the position that JOTD is evidently referring to with his CMP.L start.



I look at all the technical jargon and see tons and tons of tags but no mention in layman's terms of how best to translate all of this into hex code and make sure pointers are pointing at the right things.

You don't convert it to hex. You include the defines and your compiler does the conversion.. The link i showed your was the c includes there asm includes also. Do yourself a favour and download the amiga developer cd.

[MethodGit]

Originally Posted by Vot

You don't convert it to hex. You include the defines and your compiler does the conversion.. The link i showed your was the c includes there asm includes also. Do yourself a favour and download the amiga developer cd.

Ummm, whoa whoa whoa. I'm not doing this for source compiling. All I'm trying to do is make a quick bootblock that does this for me on startup. I do all my work through hex and the WinUAE debugger.

[Vot]

Originally Posted by MethodGit

Ummm, whoa whoa whoa. I'm not doing this for source compiling. All I'm trying to do is make a quick bootblock that does this for me on startup. I do all my work through hex and the WinUAE debugger.

You rebel you... Just look them up in the ndk then.

[MethodGit]

Originally Posted by Vot

You rebel you... Just look them up in the ndk then.

*Sigh*

Well I looked through v2.1 of the Developer CD and spotted some structure files for LVOs and Offsets in the 1.3 NDK. Still doesn't really tell me in what way I should be loading graphics.library to match JOTD's starting code. I also couldn't find any information regarding LVOs in the 3.1 NDK.

So there you go. I'm not an "includes" person. I learnt to code/hack through Flashtro's tutorials and most of them did not involve installing the NDK and recompiling magic out of thin air. I'll freely admit that "my way" differs from "everyone's way". I just don't want to be spending several hours slowly combing through every .i file on the disc just to determine what little thing does what for one miniscule purpose.

[Leffmann]

You have to call OpenLibrary to get the base address of graphics.library. You pass a pointer to a null-terminated string for the library name in A1, and the version number you require in D0.

For the symbols, you can use f.ex. ASM-One to include the header file and a few lines of

printv gb_ChipRevBits0

etc. to get the actual values. The library vector offsets are not in the NDK, it's always been a mess like this, but you can find them as separate include files in a few posts here in the Coders forum.

But while you have ASM-One running... why not just paste the code and a bootblock header into the editor, assemble it, and use the 'ws' and 'cc' commands to write the working bootblock to disk and have it done with?

[MethodGit]

Originally Posted by jotd

move.l	(_GfxBase),a6
	cmp.l	#39,(LIB_VERSION,a6)
	blo	.noaga
	btst	#GFXB_AA_ALICE,(gb_ChipRevBits0,a6)
	beq	.noaga
	
	move.b	(gb_MemType,a6),oldbandwidth
	move.b	#BANDWIDTH_1X,(gb_MemType,a6)	;auf ECS Wert setzen
	move.l	#SETCHIPREV_A,D0
	JSRLIB	SetChipRev
	move.l	D0,oldchiprev

.noaga

Right, after more hours that could've been better spent elsewhere, I've somehow managed to come up with this so far:

MOVE.L A1,-(A7)                                               < move original A1 pointer to stack
LEA (graphics.library)(PC),A1                                 < point A1 to "graphics.library" reference (which is at the end of my boot code)
JSR -228(A6)                                                  < call OpenLibrary
MOVEA.L (A7)+,A1                                              < restore original A1 pointer
MOVEA.L D0,A6                                                 < move GfxBase address from D0 to A6
CMPI.W #27,14(A6)                                             < check for v39 of graphics.library
BCS (noaga)                                                   < branch to end if less than or equal to expected result)
BTST #2,EC(A6)                                                < check if bit for AGA chipset is active
BEQ (noaga)                                                   < branch if not the case
move.b	(gb_MemType,a6),oldbandwidthp                         > ummm, what the hell?
move.b	#BANDWIDTH_1X,(gb_MemType,a6)	;auf ECS Wert setzen  > again, what???
MOVEQ #1,D0                                                   < hopefully this is the correct bit for OCS, can never translate bits from bytes
JSR -378(A6)                                                  < hopefully the right call address for SetChipRev
move.l	D0,oldchiprev                                         > seriously, what is this?  Is this meant to be ChipRevBits0 still?
MOVEA.L 4.S,A6                                                < point A6 back to ExecBase

So really, the only parts I'm still stuck with are the ones I highlighted in italics. Aside from already working out what MemType is actually pointing to, "oldbandwidthp" and "oldchiprev" are not any kind of references that Google can churn up results for, and "BANDWIDTH_1X" from what I can tell equals 0, but MemType (which if I'm correct is immediately after ChipRevBits0) already reads 0 judging by the offset.

And yet it doesn't seem to work for what I'm trying to run under AGA. I'm starting to wonder if BTST #2,EC(A6) is somehow wrong, since the routine to change the chipset is skipped as it is. Without knowing how to handle the highlighted bits of code, I thought I could get by with just the MOVEQ and the JSR, but no dice.

Again, I've done the best with what I could muster from a combination of consulting the LVO and Offset lists and more tedious googling, so could someone just quickly fix my inevitable mistake already and translate the remaining parts so this little saga can be brought to an end? Pretty please? Go on, I'll give you my last Rolo.

UPDATE: Hmmm, maybe the bit for AGA was wrong? I set it to 2 judging by this page and since JOTD said GFXB_AA_ALICE, but I decided to set it to 4 after reading this page even though it's for GFXF_AA_ALICE, and now it won't skip the routine anymore. :--) That said, the target still won't run, so there's something else that needs to be done.

[meynaf]

If your code is running on the bootblock then AGA is already disabled (more precisely it has not been enabled yet).
Your target doesn't run SetPatch, does it ? Does it have a startup-sequence at all anyway ?
And have you checked that it works fine if setting the chipset in the bootmenu ?

Perhaps you need to add this line to your startup, especially if it kills the OS :

 clr.w $dff1fc

[hooverphonique]

Originally Posted by MethodGit

UPDATE: Hmmm, maybe the bit for AGA was wrong? I set it to 2 judging by this page and since JOTD said GFXB_AA_ALICE, but I decided to set it to 4 after reading this page even though it's for GFXF_AA_ALICE, and now it won't skip the routine anymore. :--) That said, the target still won't run, so there's something else that needs to be done.

GFXB_x refers to the bit number corresponding to the value in GFXF_x, so if GFXB_x is 2, GFXF_x will be 2^2=4

[Vot]

Originally Posted by Leffmann

You have to call OpenLibrary to get the base address of graphics.library. You pass a pointer to a null-terminated string for the library name in A1, and the version number you require in D0.

For the symbols, you can use f.ex. ASM-One to include the header file and a few lines of

printv gb_ChipRevBits0

etc. to get the actual values. The library vector offsets are not in the NDK, it's always been a mess like this, but you can find them as separate include files in a few posts here in the Coders forum.

But while you have ASM-One running... why not just paste the code and a bootblock header into the editor, assemble it, and use the 'ws' and 'cc' commands to write the working bootblock to disk and have it done with?

Aren't the lvo,s generated from the sfd files in the ndk. I think someone had a tool to do it (http://www.dstoecker.eu/programs.html#fd2pragma).

[MethodGit]

Originally Posted by meynaf

If your code is running on the bootblock then AGA is already disabled (more precisely it has not been enabled yet).
Your target doesn't run SetPatch, does it ? Does it have a startup-sequence at all anyway ?
And have you checked that it works fine if setting the chipset in the bootmenu ?

It's an NDOS disk so there's no SetPatch or anything of the sort involved. And yes, it works after I manually disable caches and set chipset to Original through the hidden boot menu.

[meynaf]

OS killing stuff, huh ?
Does it also work if you set the chipset to ECS rather than Original ?