Correct way to hard reset in the bootblock on 1.3-3.1?

[Photon]

I've updated a boot block which works correctly on 1.3-3.1. However, a hard reset consistently puts a PAL 1.3 A500 in NTSC mode until I've booted to CLI once and soft reset manually.

What can I do to prevent this?

The bootdisk is found here, and here's the relevant portion of code:

;a6=execbase, -$1e=Supervisor()
HardReset:
	clr.l $26(a6)
SoftReset:
	lea RCont(PC),a5
	JSR -$1e(a6)
RCont:	lea 2.w,a0
	RESET
	JMP (a0)

[Thomas Richter]

The correct way is to use exec/ColdReboot() whenever it is available, because this call does some additional services compared to the code above, and your system may need such services.

Even under 1.3, the above code is not correct, problem being that your code may be in chip mem or expansion ram, and then the "reset" "pulls the rug" under the CPU. You can make it "somewhat working" by using the prefetch feature of the 68k, though then the reset and the JMP need to be on the same LW.

[a/b]

Hmm, are you sure this works in 100% cases? E.g. KS 3.0 exec ColdReset jumps to a second reset at $f800d0, while you jump to $f800d2.
You took a shortcut (exec goes through the ROM end address) since ROM gets mapped to $0 and at $2 there's a jmp $f800d2, but you also don't have a decrement by 2 before taking a post-reset jmp (a0), and overshoot the 2nd reset by 2 bytes.
Not sure if related or intended, just in case...

[a/b]

Originally Posted by Thomas Richter

though then the reset and the JMP need to be on the same LW.

Wasn't that debunked? I'm sure there was a discussion or at least a mention on these forums about it. I think it was some discussion with Toni about emulation...

[Toni Wilen]

Sounds like you trigger KS 1.3 bug, there is always 1/227 chance of NTSC misdetection.

68000/010 prefetch is fully word based, long word alignment won't make any difference whatsoever.

68020+ prefetch long words. If unaligned, it still prefetches full long from aligned address (=address - 2).

[Photon]

Originally Posted by Toni Wilen

Sounds like you trigger KS 1.3 bug, there is always 1/227 chance of NTSC misdetection.

Thx Toni

This piece of code seems to trigger it 227/227 times (on 1.3 only)

Originally Posted by Thomas Richter

The correct way is to use exec/ColdReboot() whenever it is available, because this call does some additional services compared to the code above, and your system may need such services.

Even under 1.3, the above code is not correct, problem being that your code may be in chip mem or expansion ram, and then the "reset" "pulls the rug" under the CPU. You can make it "somewhat working" by using the prefetch feature of the 68k, though then the reset and the JMP need to be on the same LW.

Thx Thomas o/

It was not aligned to longword, but I fixed that and still the same behavior.

So no software in RAM can use the RESET instruction for anything? What about MapROM and resident stuff? Certainly they use this instruction.

I'd be happy to use ColdReboot(), so what would the use of it look like, is it consistent across OS1.3-3.1, and is there a WarmReboot()?

[Thomas Richter]

Originally Posted by a/b

Hmm, are you sure this works in 100% cases? E.g. KS 3.0 exec ColdReset jumps to a second reset at $f800d0, while you jump to $f800d2.

Offset 2 of the kickstart is supposed to contain a JMP ABS.L opcode, and offset 4 is the initial PC vector of the 68k, so that could possibly be fine. There is indeed a second reset instruction just below the actual init code you can use if you want to. It is another option you can take, i.e. check whether it is present, and you call supervisor with target address of this reset. This would make the code independent of the ROM mirror. But, again, note that exec/ColdReboot() is really really the recommended way of doing this.

[ross]

		
		cmpi.w	#36,lib_Version(a6)
		blo.b	.v1x
		jmp	_LVOColdReboot(a6)
.v1x		jsr	_LVOSuperState(a6)
		lea	$01000002,a0
		suba.l	-22(a0),a0
		reset
		jmp	(a0)

[Thomas Richter]

Precisely.

[Photon]

Ross's code works, and for a soft reset I would go

jsr	_LVOSuperState(a6)
lea.w 2,a0
reset
jmp (a0)

(correct?) But this doesn't work on >1.3?

[Thomas Richter]

See Ross' code. That's the better choice. Again, if exec/ColdReboot() exists, use it!

[Photon]

Thomas, I'm using it, I'm just wondering if the code in my last comment is a correct SoftReset. I need that also in my bootblock.

My existing SoftReset code works fine on all systems, I just want to know if it's correct.

[Thomas Richter]

Well, as stated, not always, and exactly not if ColdReboot() has something else to do. In many, but no all cases, the two snippets work identical. I'd go for Ross' code, still.

[Photon]

I actually just checked ColdReboot() in two ways: resident vectors and cleared memory. Ross's code for 1.3 does that, but ColdReboot() under 2.0+ keeps resident vectors (e.g. from 3.1 early boot menu/"boot without s-seq") and does not clear memory. (!)

Sheesh...

Let's define a hard reset then: resident vectors are killed, and (at least pertinent) memory is cleared. (This is the only way for a bootblock to kill a (in-RAM) virus before booting.)

Now I'm in a dilemma, because I can use only the 1.3 part of Ross's code in this use case. I hoped to get this mammagamma done...

Edit: So it could be a difference in expectations, hence my definition. Is there documentation on what ColdReboot() does?

[ross]

So you want the system to rebuild execbase and company?
There are several ways (such as clearing the exec checksum).

But if you want to be brutal:

.v1x		jsr	_LVOSuperState(a6)
		jsr	_LVODisable(a6)
		lea	$01000002,a0
		suba.l	-22(a0),a0
		st	7.w
		reset
		jmp	(a0)

[Photon]

Regarding clearing Exec checksum: Is this what existing old code does in OP? (clr.l $26(a6)) this doesn't clear RAM or resident vectors on 3.1 at least. This is the definition and what it does on 1.3 (with <=512KB Chip RAM, I just found out)

I can try your brutal code. I've already spent 7h on this, what's an hour more on a Saturday. *makes Scooby-Doo sound*

Edit: just to be clear the only goal left is code to make hardresets clear RAM and kill resident vectors on 2.0+. SlightlyBelowRoomTemperatureMaybeAThinSweaterIsCalledForBoot() in Exec V36+ does... less.

Edit 2: Nope, brutal code did not clear memory at $7e000 under 3.1 seems to clear resident vectors tho!

[ross]

Originally Posted by Photon

Regarding clearing Exec checksum: Is this what existing old code does in OP? (clr.l $26(a6)) this doesn't clear RAM or resident vectors on 3.1 at least. This is the definition and what it does on 1.3 (with <=512KB Chip RAM, I just found out)

I can try your brutal code. I've already spent 7h on this, what's an hour more on a Saturday. *makes Scooby-Doo sound*

Edit: just to be clear the only goal left is code to make hardresets clear RAM and kill resident vectors on 2.0+. SlightlyBelowRoomTemperatureMaybeAThinSweaterIsCalledForBoot() in Exec V36+ does... less.

No, 'brutal code' do not clear RAM, it only destroy execbase so system is constrained to rebuild all from scratch.
But I think there is no clear-ram code in KS3.x, you have to do it manually..

[Photon]

OK, primary goal is to kill viruses, so I will let go of secondary purpose of clearing RAM on >1.3. Thanks again Ross. You know so much OS stuff!

I mean I could feed the Amiga users who dare boot a floppy on a 3.1 machine to the sharks WRT viruses. They might have valid resident vectors like Blizzard accelerator stuff. Then again those users can opt to not hardreset because they know. It would be nice for an antivirus boot block to actually work on >1.3.

[malko]

Originally Posted by Photon

[...] Thanks again Ross. You know so much OS stuff! [...]

[admiral]

Originally Posted by Photon

OK, primary goal is to kill viruses, so I will let go of secondary purpose of clearing RAM on >1.3.

I seem ignorant: What is this ram-clearing on v36+? What significance does 0x7e000 have?