"Exception "Line 1111 Emulator" ($2c) Error at $1004" when exiting game

[demolition]

I get the "Line 1111 Emulator" error quite often when I exit a WHDload game. The specific error in topic was from CannonFodderCD32. Not always, but maybe 50% of the time. It doesn't happen mid-game, and savegames are also written as they should, so it isn't really a problem, except it's not right to look at.

Any idea what causes this?

Using A1200+ACA1232+IndyAGAMkII+4GB CF.

[Amiga1992]

I used to get these all the time. Could be a maxtransfer problemwith your drive.

Read here:
http://eab.abime.net/showthread.php?t=55425
http://eab.abime.net/showthread.php?t=17165

I fixed the maxstransfer of my ddrive and still go some of them. I never figured out what is going on. i don't know if it is WHDLoad's fault or what. I just gave up and now play my games on my CD32.

[PeterK]

Edit: Forget about this posting, it's completely wrong !! Sorry for my misinformation.

Line 1111 = Line F (EDIT: like the F in floatingpoint or FPU means) could mean that an FPU is missing !!

However, even the latest, so called FINAL WHDLoad 17.1 is still very buggy. Enforcer still throws lots of hits. It seems that the author of WHDLoad has never heard of Enforcer and other debugging tools. But I don't care, because I will never play any (EDIT silly) games.

[StingRay]

Originally Posted by PeterK

However, even the latest, so called FINAL WHDLoad 17.1 is still very buggy. Enforcer still throws lots of hits. It seems that the author of WHDLoad has never heard of Enforcer and other debugging tools. But I don't care, because I will never play any silly games.

I'm sorry but this is complete and utter nonsense. It's OK that you don't play "silly games" but you should at least not bash something without any reason. WHDLoad surely isn't "very buggy" as you claim and Wepl definitely does know Enforcer. If you think a little bit about how a program such as WHDLoad works you'd come to the conclusion that it isn't possible to make it run without (harmless) Enforcer hits!

[matthey]

Originally Posted by PeterK

Line 1111 = Line F like the F in floatingpoint or FPU means that an FPU is missing !!

The "F" does not really stand for floating point of course. Instructions starting with $F are general co-processor instructions which includes FPU, MMU and MOVE16. It's possible that the processor and co-processor settings are identified incorrectly and the incorrect code executed or that non-code is executed that happens to start with $F. It's almost certainly a bug in WHDload or whatever code is used for co-processor identification.

[StingRay]

Originally Posted by matthey

It's almost certainly a bug in WHDload or whatever code is used for co-processor identification.

Not necessarily, it can have many reasons, my bet is that either the slave is buggy (wrong keyboard/interrupt handling maybe) so that "corrupted" code is executed or a problem with the maxtransfer settings.

[Galahad/FLT]

Originally Posted by PeterK

Line 1111 = Line F like the F in floatingpoint or FPU means that an FPU is missing !!

However, even the latest, so called FINAL WHDLoad 17.1 is still very buggy. Enforcer still throws lots of hits. It seems that the author of WHDLoad has never heard of Enforcer and other debugging tools. But I don't care, because I will never play any silly games.

Award season for most misinformed post is officially over!

[PeterK]

Alright, there are some things wrong in my statement.

Matthey is right, the "Line F emulator" can be caused by other coprocessor instructions too. My mistake.

And yes, as StingRay says, I better should not blame the author of WHDLoad without knowing the real reason for the Enforcer hits.

Removed the rest. It was wrong, too.

[Retrofan]

Originally Posted by PeterK

Alright, there are some things wrong in my statement.

Matthey is right, the "Line F emulator" can be caused by other coprocessor instructions too. My mistake.

And yes, as StingRay says, I better should not blame the author of WHDLoad without knowing the real reason for the Enforcer hits.

But the author of WHDLoad should really start to analyze these problems, even if his program is not directly causing the Enforcer hits. Who else would fix that? I was just wondering about a "final version 17.1" in the latest AmiKit which has still the same bugs as before.

At least in my version for real miggy I don't have hits but when I start Workbench 2000 as I was having before (just booting). But it has the same enforcer hits running WB2000 in CWB39, so I guess there are programs that although "run", have those hits. That doesn't mean that it has to show an error the kind of "Line 1111", that doesn't let you but to quit the program.

Anyway, perhaps his error isn't a problem of WHDLoad, but of any other library that hasn't the right version for no FPU if he hasn't.

[matthey]

Originally Posted by StingRay

Not necessarily, it can have many reasons, my bet is that either the slave is buggy (wrong keyboard/interrupt handling maybe) so that "corrupted" code is executed or a problem with the maxtransfer settings.

My point was that the problem is likely WHDload related as maxtransfer or other system problems would probably show up using other software.

@PeterK
It's frustrating when a low level program like WHDload does not behave as it's not easy to debug and patch. Your frustration shows that you realize the importance of WHDload to the Amiga even if you don't play games.

[StingRay]

Originally Posted by matthey

My point was that the problem is likely WHDload related as maxtransfer or other system problems would probably show up using other software.

It's not necessarily WHDLoad's fault. Problems like these can have many reasons.

[Gordon]

Originally Posted by StingRay

It's not necessarily WHDLoad's fault. Problems like these can have many reasons.

Yep. I used to get them when I installed WB3.1 myself. When I changed to classicwb3.1 it stopped. No hardware changes. Same WHDLOAD version

[demolition]

Originally Posted by StingRay

Not necessarily, it can have many reasons, my bet is that either the slave is buggy (wrong keyboard/interrupt handling maybe) so that "corrupted" code is executed or a problem with the maxtransfer settings.

Maxtransfer is set to 0x1fe00, however, as the games will start and run just fine, it doesn't seem likely to me that maxtransfer would be the problem. The error occurs after I press the quitkey.
MMU is disabled, and the ACA1232 has no FPU.

Is there any way to list what WHDload detects about my system?

[Retrofan]

This is the best post about how to know exactly what happens:

http://eab.abime.net/showpost.php?p=832698&postcount=3

Run it in WinUAE and better windowed.

You can later leave commented winuaeenforcer in the s-s and the rest working forever.

Edit: Or better comment them all as for the following post of PeterK.

[PeterK]

Sorry for my assumption or imputation that the author of WHDLoad doesn't know and care about the Enforcer hits.

I've just read a few lines in the WHDLoad documentation and now I must admit that these Enforcer hits which I always get with AmiKit are obviously no bugs in WHDLoad (I'm not talking about the Line 1111 emulator now). The author of this program says that Enforcer or MuForce or similar tools should not be used together with WHDLoad or you will get lots of these hits. So, StingRay's comment was correct.

[Retrofan]

I hadn't try enforcer with the real Amikit, and it's true. I've tried to open a game; in this case Advantage Tennis and it was showing a lot of hits.

But I've tried with enforcer and CWB39 and I've got the same enforcer hits trying to open the same game.

Edit: Sorry it seems I didn't undertand your post at all, PeterK. Now I do: you can't run enforcer with Whdload.

But it's also true that I was having hits with Amikit just booting that I don't have in my version.