Throwing a BusError in my target

[nk1g]

I have been using Moira (v 2.4) for some weeks now, simulating a single-board 68000 I intend to fabricate for a project. I recently had a bug in my code that led me to tie an address decoder to /BERR on the virtual 68000.

Grepping through the code, I got the hint to throw a BusErrorException() in the simulator. Hoorah! The simulated 68000 correctly picks up the exception vector from the vector table and calls the exception handler.

The fly in the ointment: The 68000 does not stack a complete BusError stack frame -- it is only a 'normal' six-word exception frame (PC, SR).

I am not by any stretch of the imagination a C++ programmer, so I am willing to stipulate that I am simply not creating the exception correctly.

I did grep through the code on both this project and vAmiga to see if I could find an example, but found no place that actually throws that exception.

To quote one of the Apple System-7 engineers I worked with 30 years ago, "You must be testing it wrong."

[dirkwhoffmann]

Hmm, you are right, Moira does not handle bus errors correctly. Moira has been testes throughly with everything an Amiga can do, but it is impossible to trigger a bus error on that machine. In fact, I never thought anybody would need bus error support on an emulated CPU.

Anyways, here is the code that writes the wrong frame format:

template <Core C> void
Moira::execException(ExceptionType exc, int nr)
{
    ...
    switch (exc) {

        case EXC_BUS_ERROR:

            // Write stack frame
            writeStackFrame1011<C>(status, reg.pc, reg.pc0, 2);

            // Branch to exception handler
            jumpToVector<C>(2);
            break;
    ...
}

Instead of writeStackFrame1011, function writeStackFrameAEBE(StackFrame &frame)has to be used. The StackFrame parameter contains the information that is written on the stack:

template <Core C> void
Moira::writeStackFrameAEBE(StackFrame &frame)
{
    // Push PC
    push<C, Word>((u16)frame.pc);
    push<C, Word>(frame.pc >> 16);

    // Push SR and IRD
    push<C, Word>(frame.sr);
    push<C, Word>(frame.ird);

    // Push address
    push<C, Word>((u16)frame.addr);
    push<C, Word>(frame.addr >> 16);

    // Push memory access type and function code
    push<C, Word>(frame.code);
}

However, I don't know which values to write as I only have Amigas which, as mentioned above, cannot generate bus errors. If only the stack format matters rather than the written values, the function could be called with an arbitrary StackFrame object.

[RR7]

how does this work in 3.0? because i when i need to cause a bus error i just did this:

` // Mask 24bit Address - BusAddressLocation is a global written on memory R/W
BusAddressLocation = STMemory_Mask24BitAddress(BusAddressLocation);

// Trigger the bus error exception
throw moira::BusErrorException();

`

which probably didn't do much useful but i was seemingly enough for what the emulator needed.

however, to do this on 3.0 requires a StackFrame to be passed in, but the function to generate the StackFrame is internal to moira, so it feels a bit wrong. presumably i'm going about this the wrong way? i couldn't see any example of bus error in the files.

[RR7]

okay so i kind of knew throwing the c++ exception was a bad idea.

i added a public function to try and handle this:

`void Moira::raiseBusError(u32 addr)
{
switch (cpuModel) {

case Model::M68000: {
	StackFrame frame = makeFrame(addr);
	execBusError<Core::C68000>(frame);
	break;
}

case Model::M68010: {
	StackFrame frame = makeFrame(addr);
	execBusError<Core::C68010>(frame);
	break;
}

default: {
	StackFrame frame = makeFrame(addr);
	execBusError<Core::C68020>(frame);
	break;
}
}

}`

and i call that in my code when i want to trigger a bus error:

// Trigger the bus error exception cpu.raiseBusError(BusAddressLocation);

but it crashes out at makeFrame. i can revert back to moira 2.4 its fine, but i'm really not quite sure how i'm supposed to work with these new Bus Errors

[nk1g]

Thanks a ton for your speedy reply. You have no idea how great it is to be able to develop software for a future product long before the real hardware is even finish being specified, and this has been critical in that.

TBH: Just knowing where the error happened is usually enough to visually examine the code and figure out where it is going off the reservation, but I am a stickler for details. I see in other places you use a function to create the stack frames for all of the myriad variations of AddressError, so I can probably use them as a guide to ScriptKiddie my way into putting something resembling "the right thing" in the BusError frame.

FYI: The details are in the 68000UM in Section 6.3.9.1

[dirkwhoffmann]

Sorry if it doesn’t work. With "Bus error support," I may have been a bit too bold. I introduced a Bus Error type to mirror the existing Address Error type and replicated the address error handling as closely as possible. In theory, the new code should behave much like version 2.4. If it doesn’t, it's due to a bug and insufficient testing on my part.

Bottom line: Moira is only "BusError ready", much like those "HD ready" TVs that were sold in Europe years ago as a TV that was "in theory" capable of displaying HD footage 🙄.

[RR7]

i'm not entirely convinced its a bus error problem. i took a step back and re-implemented Moira 3.0 as a separate abstraction much like 2.4. for the purposes of testing i just created a blank stackframe and pass it in for now

	 // Trigger the bus error exception
	StackFrame frame;

	throw moira::BusError(frame);

its not booting correctly for me, where 2.4 does. bus error isn't being called by emulator at this stage, and nor is it happening internally. so its something different between 2.4 and 3.0 in operation.

[RR7]

i finally got around to using Moira 3, bus error appears to be working, its a shame its not quite handled internally as it could as it looks like all it needs is a front facing pulseBusError(uint32_t address, bool isWrite) or something.

the way i got it working was to create a way to throw my own error such as:

// MoiraExample.h
enum class BusOp { Read, Write };
struct MoiraBusErrorJump {};

    void throwCapturedBusError(uint32_t address, BusOp operation) const;

// MoiraExample.cpp

void MoiraExample::throwCapturedBusError(uint32_t address, BusOp operation) const
{
	moira::StackFrame frame;
	bool isWrite = (operation == BusOp::Write);

	// Internal State 
	frame.sr = getSR();
	frame.pc = getPC(); 
	frame.ird = getIRD(); 

	// External State (passed in)
	frame.addr = address;

	// Build Code Word
	u16 info = (readFC() & 0x7);
	info |= (1 << 3); // Not Instruction
	if (!isWrite) info |= (1 << 4); // Read bit

	// set frame code
	frame.code = info;
	frame.fc = readFC();
	frame.ssw = 0;

	// Throw the Moira Exception
	throw moira::BusError(frame);
}

then make sure you throw this on your read/write operation

// Override memory read functions
u8 MoiraExample::read8(u32 address) const
{
	try {
		return Emulator::ReadByte(address);
	}
	catch (const MoiraBusErrorJump& e) {
		throwCapturedBusError(address, BusOp::Read); 
	}
}

and throw the error is the emulator code when needed such as:

// Emulator.cpp
uint8_t Emulator::ReadByte(uint32_t address)
{
if (address == 0xffffffff)
{
throw  MoiraBusErrorJump();
}
else
{
return EmuRam[address];
}

i'm sure this can be done better, but if it helps, this is pretty much how i have used it for Atari ST.

[dirkwhoffmann]

Great! I’ll take a closer look once I have more free time. I agree that Bus Error support should eventually be added, especially since I like the idea of Moira being capable enough to support Atari ST emulation as well.

[RR7]

it pretty much is added, i cannot verify how accurate the makeframe is for StackFrameAEBE but they are both group 0, named according to the fact they are the same, so they should work. so far it seems capable, i have had to make one change to when interrupts are fired to make it immediate, and i'm not certain if its accurate, uae core does it and it works, mushsahi doesn't and it causes issue. but i may have fixed a bug with making a new bug who knows. so far i only needed bus error for the vector jump and this seems to work okay. i have about 4 fringe cases left, one is a game that seems to freeze in a loop, doesn't do that win uae core, timing issue i'm sure, and a couple of copy protections that are failing, but i don't think this isa cpu issue, the other may be related to bus error, but too early to say. i'm really pleased with it so far, i look forward to helping you be able to stick an 'approved for Atari ST emulation' badge on your website :)