Admiral, we are sort of jabbing from different perspective to reach a goal, bootblock code that works on all OS versions that can kill resident viruses (as a shorthand). It started as weird behavior (so that's what I reported in OP), now it turns out my code was mostly correct and we have some code that partially helps with killing viruses on 2.0+. I understand that you're confused, because the entire thread must be read as context. A 'spurt session' to try to solve the problem, with some great info. :great

Perhaps someday there will be universal code for this utility work, but for now I just need to optimize 36 bytes. Send 36 bytes pls. :D

w/o your bootblock's full sources, I can only suggest crunching your bootblock :cheese

I've just replaced a legacy piece of code with shorter code, so I have bytes to spare! I'm now in the process of testing on all systems and cleaning up the source. Then it will be shared with source here :great

Wouldn't rebuilding execbase effectively destroy any virus' connection to the system, regardless of if its code is still in memory or not? I would think so.

Coldreboot() doesn't clear vectors or RAM, so Ross's second code is used.

Clearing RAM is useful only for tests outside your dev env where all code works. If junk in bitplanes, hardreset to clear RAM and if it works you found the bug (relying on some memory being cleared) in five seconds. This can only be done on 1.3, unless I manually clear it first on 2.0+.

(Side note: And Ctrl-Amiga-Amiga or code softreset clears all RAM on one specific setup, ECS machine with KS1.3... it's a mess. It would be very nice if somehow this could be fixed, but...)

ColdCapture() runs before execbase checksum is even checked, so you'd have to explicitly wipe that one.

The bootblock is now feature complete and I'm prettifying it without going over 1K.

My question in OP was based on emulation behavior, so it is answered by this:

I sent it to Toni and he replied emulation is always started with fixed data - regarding this KS1.3 bug, in a real Amiga there's always some randomness. WinUAE, too, can get this randomness. It's enough to boot without the disk and insert it after the disk picture is show to introduce some, and then the bug triggers, not every time, but likely 1/227 times.


I also wanted to ask about these two comments seen together:

Is it settled by Toni's comment? I.e. reset;jmp (a0) combo must be aligned by CNOP 0,4 to not fail on 68020+?

It can happen but don't depend it. Any version update can change it. Almost anything can change it :)

I didn't say it would fail. 68020 will always prefetch at least 1 word (if unaligned), jmp (a0) fits in single word: it will work even if unaligned. (at least as long as jmp(a0) is not located at the very end of memory space, where next address is some read sensitive IO..)

As I see it, current emulation behavior will cause every Quickstart A500 configuration saved with a bootable floppy image in DF0:, to always boot in NTSC mode. I just detect it, I can change nothing :)

Anyway, the cause is known now, so for me it's answered. But it was good that I asked because my boot block is in better shape.

AFAIK it's the reset instruction that has to be aligned, so that the jmp instruction is prefetched with it? And then the jmp instruction is always unaligned, so even if that's OK, that's not the test case where it could fail?

I.e. The case to be debunked is when the reset instruction is unaligned?

I would like there to be no chance for a virus to thwart my Execbase-destroying efforts. :) Do I need to explicitly wipe it before destroying Execbase and resetting, then?

If so, what is the correct way to wipe ColdCapture() before reset?

clr.l $2a(a6)

EDIT: but if execbase is destroyed there is no need to clear it..
I explicitly used

st 7.w

because in any ROM there is a check for an odd execbase address (which of course cannot be accepted),
therefore nothing can be executed from resident vectors or pass the checksum checks.

I just tested. It works.

Unaligned RESET followed by JMP (A0) in next long word. Cache disable and flush followed by dozens of NOPs before RESET/JMP (A0) to guarantee flushed pipeline. (JMP instruction executing confirmed by testing with odd A0. It crashed.)

Sh*t. I just re-checked the HRM example and the RESET instruction is actually unaligned. (Because it's preceded by a lea.l 2,a0.) Sorry. I just don't exactly how prefetch works in exact detail.

This has to be the most confusing section in the entire book, not least because of calling a normal soft reset a "Cold Reboot". :nuts

The 'why' question remains interesting. It seems to be the jmp (a0) instruction that should be aligned. Could it fail to prefetch jmp (a0) under some circumstances? That section only mentions as reason that the RAM will disappear when the reset instruction is executed. Could DMA interfere? The example doesn't turn off DMA. Could it be required from an early A1000 hardware bug?

I'll change my code to follow HRM of course, so maybe it's best pursued in a dedicated thread. Annoying as hell :rolleyes

I'm not sure what a/b meant, maybe something like
1. Your code destroys (actually not, asks ROM to later destroy) Exec and resets
2. Reset invokes ColdCapture()
3. ROM notices Exec is bad and rebuilds it, clearing ColdCapture()

...and that because of 2, if ColdCapture() has virus code it could be prepared and nonetheless "re-inject itself"/restore Exec values it saved when first injecting itself? Then Exec wouldn't be rebuilt.

I highly doubt that reset code executes from resident vectors without checking checksums first, so if you have IRQs disabled and cleared the vector or checksum and you do a reset, for any virus it is impossible to reinject itself.
But someone could have patched _LVOColdReboot()..
Well, destroying execbase sure do the job :)

Ahem. Sorry again. :o The HRM section about resetting actually doesn't say anything about jmp (a0) having to be aligned. It aligns the Supervisor() target address. Must all code invoked by supervisor state be 4-aligned? SuperState() on 2.0+ doesn't.

Also if things can be patched and monitored maybe it's best to do as much as possible with hardware code. TRAP into supervisor instead of using Exec etc. If we're turning off ints anyway, I mean...

Can you link the reset code you are looking at? I just checked elowar http://amigadev.elowar.com/read/ADCD.../node02E3.html, PDF and the actual book, and they have the same code: reset is longword aligned and shares the same longword with jmp (a0) (which is the idea).
What I'm concerned about is jumping to a RAM address (too soon) after reset. Reset takes 132 cycles so there is plenty to time to fetch the next opcode, but at what point within those cycles is RAM replaced by ROM? Immediatelly, after the next opcode fetch, ...? If you jump into RAM (e.g. lea 2.w,a0 + jmp (a0)) does that work with all hardware profiles? So I consider jumping into ROM ($0fxxxxxx) safer.

About the reboot vectors. Yeah, manual exec nuke from the orbit (e.g. nuke exec base or one of checksumed vectors so the checksum doesn't match) is the only way to be sure. Or fix them and redo the checksum (well, as long as you assume the virus didn't take over your MMU). For example:

Shoulda checked my black HRM I guess. It just sounded like this code was final. In this example (see attachment), the reset instruction is unaligned.

I'm assuming the hardware makes sure the "zeropage" has something in it (even from a poweron) so that the CPU can function. Like providing a jump into ROM at the a0 target address.

There's no hope of fitting anything together with some elaborate antivirus on a bootblock. It's mostly for stopping relatively simple early viruses when testing old, unknown disks. If it prevents a resident virus from staying in memory, that's a good enough hard reset.

Ah, ok... It must be one of the earlier editions (mine is 3rd edition from 1991). Just checked my PDF collection, it's probably the revised&updated edition from 1989 (I was still in the c64 waters at the time).
One way to explain it is that they probably used an optimizing assembler that changed 2 to 2.W, in which case everything fits together nicely. A few lines underneath is move.l 4,a6, and you typically don't write that in your size constrainted ROM code (it's move.l 4.W,a6), which supports this explanation.

Note that while ColdCapture is checksummed, it runs before the checksum check does, so it needs to be nuked explicitly. Furthermore, if set to non-zero (to nuke checksum), it will be called, which is not the intended effect.

So you'd need to clear ColdCapture _and_ nuke one of the other two with a non-zero value.

Furthermore, clearing the vectors and recalculating checksum is not good enough, as the kept ExecBase could have a hook elsewhere.

a/b, it's more likely that a mistake was left in the code, and that this was corrected. (And despite the unaligned RESET, it might not have been a mistake at the time. One of my absolute thoughts is: "You can never be future-compatible, you can only be backwards compatible or not".) And when KS2+ released, a function to do it was added, even though the old code from 1989 works fine on KS2+ (for a soft reset).

For a hard reset, you could say that I need to reset without using the OS, since the OS could be compromised. (Disable, Supervisor/SuperState, ColdReboot could all be "hacked".)

But I don't want some overthought, overwrought antivirus code that may fail on some system.

I could take over the hardware, nuke Exec, hardware reset and prevent most of it and that's fine. For the soft reset I'll use the only allowed code, 2nd edition. :)

If I am to do this, I need a non-Supervisor() way to read VBR.

This wall of code replaces the code in OP. It's tested in WinUAE on A1200-060 3.1, stock A1200 3.1, A500 3.1 and A500 1.3, and on real A500-ACAPlus-3.1 and A500 1.3.

The code can be run from assembler/CLI/WB as is, but ADF is also attached. If something is resident (such as invoked Early Boot menu, accelerator stuff, or virus), it will report a red color else green, and then wait for LMB=Soft Reset or RMB=Hard Reset. If RMB, it must report green on next bootblock run, or report green on next run from assembler/CLI/WB as long as nothing installs itself resident in s-seq before.

I'm looking for feedback on reliability before I commit. (Edit: Please see the ;** and must be comments.) Cheers. :great