Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Exception on PiStorm32 Amiga 1200 #4

Open
mbo77 opened this issue Aug 15, 2024 · 4 comments
Open

Exception on PiStorm32 Amiga 1200 #4

mbo77 opened this issue Aug 15, 2024 · 4 comments

Comments

@mbo77
Copy link

mbo77 commented Aug 15, 2024

PXL_20240815_143338937
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.

@dplanitzer
Copy link
Owner

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:

  • _Reset, before it invokes SystemDescription_Init
  • _Reset, before it invokes OnBoot
  • OnBoot (kernel/startup.c)
  • OnStartup (kernel/startup.c)
  • OnMain (kernel/startup.c)

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().

@mbo77
Copy link
Author

mbo77 commented Aug 16, 2024

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.

@mbo77
Copy link
Author

mbo77 commented Aug 18, 2024

I see now that the build environment is meant for Windows. So I'm out of the game for now.

@dplanitzer
Copy link
Owner

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:

  • Tools/Makefile: need to write a POSIX version of this. There's nothing complicated in there. So it should be easy to do this.
  • Tools/diskimage/diskimage_win32.c: this needs to be ported to POSIX. This file just iterates a directory on the build machine. So porting this should be straight forward too.

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants