Add an inaccurate, basic Archimedes.

[TomHarte]

Archimedes objective: a high-level CPU emulation with low-level emulated support components. At least as a first step.

Additionally cleans up several compiler warnings for CI platforms.

Included ARM fixes:

• only the lowest byte of a register affects shift-by-register quantities;
• a 0-size immediate rotation that sets carry copies the highest bit of the value [not] being rotated;
• flags are set properly for R15 destination data processing operations;
• LDR to an address register with writeback prefers the value read to the writeback;
• exceptions and BL include status bits in the value placed into R14;
• exceptions retain the proper mode in the value placed into R14 ad pick an appropriate PC offset based on the exception type*;
• block writes handle decrementing addresses properly, use the load PSR flag for user-register selection during STM and properly handle write back versus registers included in the transfer list (including not conflating registers of the same number from different modes).

* since I'm trying to maintain an implementation separation between my version of ARM operations and any specific ARM implementation I want this to be codified separately rather than flowing naturally from the ARM2's pipeline.

[TomHarte]

Noting that current CI failures appear to be a brew installation failure; taking them as transient for the time being.

[TomHarte]

Noting that I've reduced coverage of the scons/SDL build on macOS because brew seems no longer to succeed at installing the necessary dependencies. Since I don't really intend to support SDL build on the Mac I'm not too displeased about this.

[TomHarte]

This finally, finally seems to get across the line of the emulated machine setting up meaningful VIDC[/IOC] parameters — non-black colours and address bounds. So it's probably time to head into actual video output next.

[TomHarte]

Not what one might hope for from first screen output, but it's a start.

[TomHarte]

The emulator now proceeds to the command line, which on a real machine usually means the non-volatile RAM is misconfigured but I don't currently see any I2C reads so here probably means something else as well as that.

Regardless, the next step is probably to implement enough keyboard activity to get typing, hopefully allowing me to launch BASIC and the desktop.

[TomHarte]

Noting that even with a seemingly fully-working keyboard (i.e. empirically it never gets into a position where it requests a reset, and one is never requested of it) and some minor initial frame-synchronisation issues ironed out, I now seem to be stuck at:

i.e. none of the star commands actually seems to work.

[TomHarte]

With the MEMC changes just in, the Archimedes now passes its power-on self-test, i.e. it doesn't feel the need to report any of the following:

• Long RAM test failure;
• RAM control line failure;
• CMOS unreadable;
• VIDC Sirq (Sound Interrupt) timing failed;
• IOC register test failed;
• MEMC protection failed;
• MEMC CAM mapping failed;
• ROM failed checksum test;
• CMOS RAM checksum error.

Sadly boot still hangs; having wilfully corrupted the CMOS RAM in order to get the supervisor prompt and switched to RISC OS 3.11 because *BASIC works from there, I see a bunch of oddities that — best guess — suggest issues still lurking in my ARM.

[TomHarte]

Switching my guess about carry after use of an unshifted immediate means that the emulator — which currently has a bug causing slightly shimmering pixels in high-resolution mode (i.e. whenever it uses more than one pixel buffer in a line) that I've yet seriously to diagnose — now gets to:

German is my second language but I've no idea why what should be the default CMOS values are seemingly producing German, and it's a safe guess that's not the proper SWI number regardless.

[TomHarte]

Just the briefest bit of research reveals that RISC OS 3.19 was just the German-language version of RISC OS 3.11. Even though I read German moderately well, I've switched to English; at least I can say that there wasn't an invalid detection of locale or anything like that.

... and, as an aside: having a much more functional supervisor prompt allows me to perform a *COMMANDS and finally cause the machine to attempt to access the floppy drive. So I've an avenue to get that last piece of the original system into play, which will probably be my cut-off for merging — i.e. when remaining fixes are likely to be small and localised.

[TomHarte]

Without the time immediately to act on it, I think the meaningless-SWI issue is likely block data transfers:

• write back, if it occurs at all, should always occur to the register the address was taken from — in the case that user registers are being output instead of [supervisor/IRQ/FIQ] registers, the existing code may write to the same-numbered user register rather than the original; and
• write back shouldn't occur on an LDM that includes the register to be loaded in its list (again, probably subject to that actually being the same register, not just the one with the same number).

Combine that with the somewhat hacky way I've ensured STMs obey the rule that "write back affects what is output only if it isn't the first thing to be output" and it's not a surprise that the weird SWI looks currently like a simple improper jump. The immediately preceding code is:

ldm sp!, {r0, r1, r2, r3, r4, r5, r6, r7, r8, sb, sl, fp, ip, sp, lr} ^
mov r0, r0
ldm sp!, {pc} ^

So my current belief is: given that the processor is in supervisor mode, the first should load user registers r0–14 from the stack and then update the supervisor stack pointer; the mov r0, r0 is possibly a pipeline pause to allow for the register mode to switch back?, and then the final ldm should load the PC from the updated supervisor stack register.

As currently written, the initial stack pointer load will overwrite whatever was loaded into the user stack pointer with an improper write back of the modified supervisor stack pointer, then switch back to the previous pointer. So it's doing two things wrong.

[TomHarte]

... and that's a desktop:

Big todos:

• mouse support — both the hardware sprite and the input events; and
• floppy support, connecting up my WD177x.

[TomHarte]

Surprisingly, that seemed just to work:

So, off the top of my head, definite outstanding issues:

• the mouse cursor over the border both looks wrong and actually stops the left-hand 16 pixels of the display from being reachable in RISC OS; and
• sound isn't currently being output.

[TomHarte]

With the cursor still not appearing correctly over the borders but now always correctly positioned on the display, I think I'm happy to say that adding audio is the sole remaining item before I merge this to master and start dealing with dangling issues as follow-ups.