Speedball 2: does it work with more than 4 megs of ram?

[emuola]

Ok, a few more bits of info... Tried with the second latest version of whdload. Result is the same, but the Resload address which was $4010 always with the latest whdload, is now always $3DB0.

I really don't know if this leads to anything, but this is definitely the only thing that changes when I downgrade whdload for testing.

I'll report this also to the bug tracker.

[Wepl]

please try attached whdload and tell what error it gives then.

[emuola]

Thank you wepl for this test-version The error I get is this (always the same, tried with dozen of different whdload options just to be sure):

"Exception "TRAP #0" ($80) at $14F8E occured."

The error occurs exactly at the same point as the earlier error "Resload..."

[Wepl]

fine, Galahad: can you please check why ($80).l contains $167f at this point?

[Galahad/FLT]

Originally Posted by Wepl

fine, Galahad: can you please check why ($80).l contains $167f at this point?

Its part of the Bitmap Bros exception handler that wasn't fully removed from the game.

The only time Speedball 2 uses a TRAP #0 is to go into supervisor mode on bootup, and then this TRAP #0 is activated if there is an internal error in the game, specifically

CHK Exception
TRAPV Exception
PRIVILEGE VIOLATION


Obviously at one time, the address at $80.w would direct to a proper onscreen error handler.

This isn't what causes Emuloas error though, something is generating an error to go through that TRAP #0 in the first place, and WHDLoad 'should' intercept it before Speedball 2 does.

Are all three of those exceptions captured by WHDLoad?

[Wepl]

because there are no special flags set in the slave, all these three exceptions should quit the game immediately

on the stackframe I see that there was a level 5 interrupt ($74), and this vector points to trap #0 too

but these interrupts are not enabled in intena, therefore I assume it's broken hardware which creates spurious interrupts

clearing the interrupt vectors not used, or better leave them as by whdload set will very probably solve the problem
I generally can recommend to remove all unnecessary interrupts setup by the games

can you adapt the slave?
in the end I think broken hw is reason.

[emuola]

in the end I think broken hw is reason.

I just wish, I 'd understand more about the internals of my Miggy. Is there anyway to find out, what's broken (if something indeed is)? It has to be something very special, because the problems only occur with Speedball 2

I cannot make any conclusions, because I'm no pro here. Is there any way to track down the "device" that causes those "spurious interrupts"?

Like late Randy Castillo used to say: "I just wanna play..."

[Galahad/FLT]

Originally Posted by Wepl

because there are no special flags set in the slave, all these three exceptions should quit the game immediately

on the stackframe I see that there was a level 5 interrupt ($74), and this vector points to trap #0 too

but these interrupts are not enabled in intena, therefore I assume it's broken hardware which creates spurious interrupts

clearing the interrupt vectors not used, or better leave them as by whdload set will very probably solve the problem
I generally can recommend to remove all unnecessary interrupts setup by the games

can you adapt the slave?
in the end I think broken hw is reason.

I didn't even think to check the interrupt address space, that is quite possible why its doing it.

I'll modify the slave now to clear these parts which might fix Emuolas problem.

[Wepl]

Originally Posted by emuola

I just wish, I 'd understand more about the internals of my Miggy. Is there anyway to find out, what's broken (if something indeed is)? It has to be something very special, because the problems only occur with Speedball 2

I cannot make any conclusions, because I'm no pro here. Is there any way to track down the "device" that causes those "spurious interrupts"?

I cannot say what's the reason for the problems, only see that there are interrupts where none should be.
AFAIR also some GVP boards had such problems.
The WHDLoad option NoAutoVec/S only exists because of these problems.

AmigaOS simply ignores these interrupts. So you will never have problems there. But hardware banging software like games may not be so tolerant.

There may be more whdload games which have problems with it, but I assume less than 2%.

[Galahad/FLT]

BETA Slave in the zone that modfies all supported versions to stop Speedball 2 setting up any interrupts beyond Level 4+, and also clears Level 4, 5 and 6.

Lets see if this fixes it for Emuola, but, if it does fix it, there is still a problem with your machine, but, this is probably a rare case where a game setups up more interrupts than it actually needs.

[emuola]

Thank you guys for your support I *really* appreciate this! I'll try the BETA later this evening

[emuola]

Ok, tested the beta... Unfortunately it's a no-go... I don't even get to the title screen. I get this error:

"Exception "Illegal Instruction" ($10) at $14F36 occured.

Tried with many different options one at a time (and without any options also)

I know this is much to ask, but do you guys have any more ideas? (other than dump that Miggy

Whatever happens, I'm truly grateful to you

[Galahad/FLT]

Leave it with me, i'll take a look now

[Galahad/FLT]

Ha, my mistake, didn't even bother to check my own code, just assumed I was 'mega leet' and well, it appears I'm not!

New BETA slave in the zone, try that one, the crash is now fixed.

[emuola]

I am so sorry to report, that the second BETA slave causes the same error as the original "Resload... $4010"

at least with initial testing. Tried with noautovector and nomemreverse options.

Thank you Galahad once again for trying to help me

[Galahad/FLT]

So we're back to the same bug as before?

[Galahad/FLT]

Right, going to try something else, check back in 5 minutes

[Galahad/FLT]

Right, another BETA in the zone, this sets a new exception handler to see if your machine acidentally is trying to activate Interrupt Levels 4, 5, and 6.

So, either it will crash as per normal and its nothing to do with the interrupts, or the screen will turn green.

Report back

[andreas]

Originally Posted by Wepl

can you adapt the slave?
in the end I think broken hw is reason.

Me too ... AND ...

I think another reason why emuola didn't find anything suspicious when testing the hardware (i. e. the actual mem chips) could be that the mem testing tool was just not testing thoroughly enough!
This is AMIGA; and it's not 100% sure that the mem testing tools available for Amiga have the quality of, say, memtest86.
I once had a very RARE write inconsistency error on my 256M SDRAMs (old PC) which never showed up with quick memory test. I ran a thorough test with all bells and whistles, which took 14 HOURS to complete and actually did manage to unveil something utterly fishy in my RAMs. Other tools would probably have innocently reported "All O.K."

If only there was a way to make emuola's SIMMs work in an (older?) desktop PC, maybe memtest86 might be able to find something eventually. I would not be surprised if...

[emuola]

So, either it will crash as per normal and its nothing to do with the interrupts, or the screen will turn green.

Ok, tested the 3rd BETA and it's the same... "Resload... $4010" So apparently it has nothing to do with the interrupts.

I really cannot make any conclusions Does this mean that a hw problem is more likely to exist or not?

If only there was a way to make emuola's SIMMs work in an (older?) desktop PC, maybe memtest86 might be able to find something eventually. I would not be surprised if...

But is it possible that this is a mem fault, because I got SpeedBall2 working with my (not so appreciated/valued?) Apollo 1230 Mk3 and a 16Mb simm and the (very much appreciated/valued?) MB1230XA gives the dreaded Resloads even with that simm

I guess, I'll send the MB1230XA to someone in Finland to test it in another Miggy just to be completely sure. This is kinda getting waayy too complicated.

Sorry for being a total PITA here