Open mbo77 opened 3 months ago
Yes this is the Serena CPU exception screen. I'm assuming that this immediately appears at boot time and you never see any other text message appear?
It's interesting that everything is 0xff. Even the CPU status register (SR). This is completely unexpected because you'd never get this on a real CPU where for example bits 5 to 7 always read as 0. The SR, PC, etc are read from the exception stack frame which the CPU stores on the stack before it invokes the exception handler. That all those values are 0xff suggests that either we never get a correctly formatted exception stack frame or the stack pointer got corrupted somehow.
I looked a bit at the Emu68 project. It looks like that this is JIT-based and that it doesn't do a full emulation of the Amiga hardware. This might be the cause of this. But it could also be a bug in the Serena startup code that gets exposed by Emu68k and the way it behaves compared to real hardware/faithful hardware emulation.
I don't have the hardware and emulator here. If you're interested in looking into this to try and figure out where things are going off the rails then the first step would be to try and narrow down how far into the boot sequence we get. You could do this by sticking calls to the cpu_non_recoverable_error() function into various places. If the CPU reaches this function then the screen will turn yellow and the machine will halt. So this would be a good sign. If you get the exception screen again then this would mean that the bug is somewhere between _Reset (in kernel/hal/cpu_vectors/asm.s) and the place from which you are calling cpu_non_recoverable_error().
Places to look at would be:
OnMain is the first place where the console is available and where you can use the print() function to print to the screen.
I suspect that we either crash in SystemDescription_Init while we are scanning for available chip and fast RAM (this checks motherboard only RAM), or that we crash when we switch from the initial chip RAM stack to the fast RAM stack. This happens at the end of onBoot() when we call VirtualProcessorScheduler_SwitchToBootVirtualProcessor().
Emu68 is only an CPU emulator. It's attached as a CPU card to a real Amiga 1200.
I will look into your ideas later and I will try to give them a try.
I see now that the build environment is meant for Windows. So I'm out of the game for now.
Most of the build environment should work out of the box on a POSIX (Linux, macOS, etc) platform because non of the relevant makefile and source code is specific to Windows. One of the reasons why Serena even comes with its own set of build tools (libtool, makerom, diskimage) is to make it easier to support a wide range of build platforms and to avoid having to drag in and install a ton of external dependencies just to get off the ground.
The biggest and only external dependency is the vbcc tool chain.
Here are the areas of the build system that would need some adoption to make them work on POSIX systems:
Everything else should compile as is on a POSIX platform because the code is really just using standard C functions.
I'll plan to eventually add official support for building on POSIX to the project, but it isn't a priority for me right now. However, if someone wants to look into this and make it work then I'd welcome and appreciate that effort very much.
I tried current Serena ROM 0.2 on an Amiga 1200 with Emu68 (Emu68_1.0.1).
I assume the exception thrown is from Serena and not from Emu68 having difficulties loading the ROM.