Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[rockersuke]

Hello there!

You see, I thought I had successfully tested this little thing I send to last Christmas comp on as many configurations I could, but it seems I was checking too many things simultaneously and missed some issues.

The game, both in the LHA file and on the bootable ADF linked at the bottom of the page, works OK on my A1200 with 68030 accelerator and 64 MBs. It also runs with no problem under certain WinUAE basic A500 configurations (it's just a tiny text adventure!)... but then crashes with the infamous 8000-0003 guru code under some others, as in my real A600 with 3.1 ROM, 2 MB Chip RAM and a standard 68000 processor.

That guru code is rather obscure, but has been ocassionally related with troubles concerning running code meant for 68020+ CPUs on a 68000. I tried installing Amos Pro in my A600 (all previous work had been done on the 1200) and the game executes fine inside the editor, but as soon as I compile It goes 8000-0003 again ^_^'

I see you have some compiler libraries updates at your downloads section, but as I don't know exactly what they are meant to patch, I feel shy to try with them.

Anyway, has some similar kind of bug been reported earlier or is this a known issue? Any clue will be appreciated!

Thanks!

--

[rockersuke]

Humpfs! I finally decided to substitute those libs, but that didn't make a difference 

--

[SamuraiCrow]

I see you are supporting Music with your game.  Sometimes the Music extension that AmosPro comes with crashes.  You might try installing the AMCAF extension and using its protracker playback routines instead of Track Play and friends.  Note that (IIRC) you load the music into bank -3 (negative) using imploader load if you want to use file imploader (the fimp program) to compress the mods.  There is a similar bank loading instruction in the AMCAF extension for loading uncompressed files into banks.

I hope this helps.

[rockersuke]

I see you are supporting Music with your game.  Sometimes the Music extension that AmosPro comes with crashes.  You might try installing the AMCAF extension and using its protracker playback routines instead of Track Play and friends.

Daaaamn! As a first check I removed the music bank and every music-related command... to no effect!
I've read in this forum some cases of program working inside the editor but not outside of it due to some sort of bank corruption. I'll consider that and also will install amcaf (nothing to loose with that!   )

I'll keep you updated if I make any progress... or come back crying for help if I don't  

--

[SamuraiCrow]

http://www.amigacoding.com/index.php/AMOS:Bugs should tell you some places to look for compiler bugs.  I guess the music bug only affects systems with Chip memory full and Fast RAM available.

[rockersuke]

Thanks, that link provides quite useful info!

I'm making a first suspects elimination roundup and results are... confusing, to say the least. I wrote a simple "Hello World!" Amos program on the A600. As expected, It worked nice both in the editor and as a standalone compiled program. Then I just added the memory banks from my game... and their mere presence made the compiled program go 80000003 again.

My adventure has 3 banks. One icon bank for the tree picture, one sample bank for a couple of sounds, and a music one for the silly tune. I tried one by one. Sample bank seems to be totally innocent. But any of the other two will make the whole thing craaash!. The icon bank will give the 80000003 error message, the music one freezes my A600 as good as dead.

I guess I've got some work now tracking down what's so messed with these banks and why it only manifests under some configs. My A1200 is unaffected either with its 68030+64 MB Fast expansion or at its basic unexpanded state. There is no way the game will work on my A600-68000-2MB Chip-KS 3.1 machine. Under WinUAE results seem to be unpredictable, sometimes It works and sometimes doesn't. I know for sure there is a pattern, but can't still discern it! ^_^'

Going to scratch my head for a while XDD... and thanks for beeing helpful!

--

[Lonewolf10]

Hi,

Banks do present problems sometimes. I have been meaning to write a program (or procedure) to examine bank data. There are two occasions when they definately cause crashes:

 - Bank header data (and possibly other data) corrupt somehow. Try reloading in the data from the source files.

 - Bank data loaded into too small a space and overflowing into following banks and/or important code areas.


Regards,
Lonewolf10

[rockersuke]

Hello Lonewolf10, and thanks to you too!

I've been googling for info about the 80000003 guru code and found this bit:

Guru #80000003 DeadEnd alert
SubSystem : Processor
ErrorGroup : Not specified
Specification: Unaligned Address Error

On 68000 this is caused by using WORD or LONG access on odd address or by jumping to odd address or by odd supervisor stackpointer on exception.

Intel doesn't enforce integral boundaries. Motorola 68000 did, but only on 16 bit boundaries (because that was it's bus width). Then 68020 had 32 bit bus, and it had to be ok with non-aligned integers or programs written for the 68000 wouldn't work, so it stopped enforcing them as well. As an Amiga owner, I had problems with programs written for 68020 trying to access 16 bit values on 8 bit boundaries, which would work on 68020 but not on 68000. Guru meditation 80000003 - CPU unaligned access error.

...and considering this note from the compiler buglist at AMCAF documentation:

3. Programs cannot be compiled: The compiler prints out the error 'Not an AMOS program'. If you use memory banks, all bank lengths must be even. If this is not the case, the programs do work from the editor but not compiled.
Conclusion: - Extend odd banks by one byte using Bank Stretch.

...I thought I was before some fuzzy aproximation to the pattern I was looking for... then I checked my banks and all of them happen to have an even lenght (the theorical right one), so the problem isn't likely to be there ^_^'

As you suggest, I'll try now making them again from start. I'll tell you if it works!

--

[Lonewolf10]

Thanks for the AMCAF quote. I'm sure I have read that before but had forgotten all about it. I'll see about adding it to the AMOS buglist on AmigaCoding if it's not already up there (assuming noone else beats me to it).


Regards,
Lonewolf10

[Lonewolf10]

This is annoying now...

I am unable to get the "Not an AMOS program" error to occur, despite knowing that I have had it before. I have also found an AMOS program that has 8 banks, each with an even length, compiles fine, but crashes when you try to run the compiled program. Yet it works fine in the editor!!


Regards,
Lonewolf10

[rockersuke]

This is annoying now...
I am unable to get the "Not an AMOS program" error to occur, despite knowing that I have had it before. I have also found an AMOS program that has 8 banks, each with an even length, compiles fine, but crashes when you try to run the compiled program. Yet it works fine in the editor!!

Sure! Making the icon bank again from the original picture made no effect. In fact, if I add any icon bank to my test program with any picture it seems to go 80000003 when executing compiled in my A600. It will work both in the editor and in compiled form in my A1200.

Now I'll try using that image either as an IFF screen or even as a Bob just to see if it makes any difference.

--

[rockersuke]

Now I'll try using that image either as an IFF screen or even as a Bob just to see if it makes any difference.

Well, it did make a difference! I put the christmas tree picture as a compressed iff screen in a bank... and now it all works properly, music included, on 68000 based Amigas as intended, or at least it does so on my A600 and on emulated basic A500s.

I guess that means it was the icon bank who was doing nasty things. Exactly which and why they only manifested under compiled programs on 68000 machines remains a bit of a mystery! 

I even considered switching to Bltz or Hisoft Basic for my adventure projected following chapters, but having a working alternative means I'll keep with AMOS for a while  . I'll tell you if I happen to catch any more clue about this crashing affairs.

--

[Lonewolf10]

I guess that means it was the icon bank who was doing nasty things. Exactly which and why they only manifested under compiled programs on 68000 machines remains a bit of a mystery!

Actually, the icon bank being the cause makes perfect sense! Let me explain:

Unlike normal banks, where each bank is contained in the specified area, icon banks exist all over the place in memory - even if you only have the one icon bank. This is because each image in the icon bank is stored in it's own location. So icon 1 is located (I believe) at the start of the bank and includes a pointer to icon 2 (if it exists), aswell as the number of icons that are in the bank. Icon 2 then has a pointer to icon 3 and so on. When an AMOS file is saved the icon bank is saved along with it, but all those individual icons are now clumped together and somewhere (either when saving, or compiling) that information gets corrupted and causes the 80000003 error we keep seeing.


Thanks for that. I will add this information onto Amiga Coding when I get the chance.


Regards,
Lonewolf10

[HonestFlames]

Resurrecting this...

I'm experiencing same/similar. Brand new install of Amos Pro 2.0. Had 1 Sprite bank and 1 icon bank. 3 sprites, 1 icon. Compiled version crashes out on 68000 Amigas with 800...03 guru.

I've removed the icon bank and recompiled. Now I get 8000...0B.

No other banks in use. Crash manifests as soon as the program is loaded and before any screen appears, which leads me to think it's right as AMOS.library is allocating RAM and setting up structures. I can't remember this ever happening back when I had an A1200 and A600 set up.

Works fine on my stock A1200. Breaks under WinUAE emulating a classic A500 or A500+ with either Kickstart 1.3 or 2.04. I'm inclined that this is a odd word boundary issue, but I can't see how.

[SamuraiCrow]

The stock A1200 can't take odd boundaries anyway.  That feature was introduced with the 68030 microprocessor.  The A1200 came with a 68EC020.