Print

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

[Hungry Horace]

ok, my compiler has stopped working once i reach a certain size in my AMOS code (i think).... the compiler just freezes up on the progress bar (?!!)

anway, i thought i'd try installiing a new copy, on a fresh partition.


i downloaded the AMOS 2.0 disks off that STOS site in another thread.  I mounted my new HDF in winuae, booted workbench 3.0 , formatted the drive, slapped in my AMOS disks in drives df1:-df3: , and went to the install icon.


firstly, when selecting the install destination i'm told "not enough space on drive" - well thats rubbish for a start. it's a 50 meg HDF, which has just been formatted.

so i hit "retry" and it begins to work.

it does a "reading director" process, then dumps me with an error  during "copying files" ? what am i doing wrong?

i'm usually very good with amiga HD stuff (i still have my a1200 030 set up)... but this is bugging the hell out of me.

anyone else got some working ADFs/ a Pre-installed HDF they could send me?

[Hungry Horace]

ok, scrap that.


i think it's that you have to boot from a regular workbench partitiion first.



i used Classic Workbench, but my program is still not compiling.

it's strnage becasue i've taken out what i added when it first started locking-up, but it's still doing it.

it's really very very very annoying.

[SamuraiCrow]

There may be a limitation on how big your code is or something like that.  I'm not a total expert (though I try to be) but you may have to get the patch upgrade from 2.0 to 2.x .  It lets you compile with more banks and so on.  I haven't used it but I hear it fixes some bugs in the compiler.

[Hungry Horace]

in the end i found my problem.

it's very strange.

it seems there must be some corruption within my code that is making the compiler fail.

the program runs ok from within AMOS, so i was fairly sure it wasnt my dogy coding at fault! (that just makes it run slow.. hehe)

if i commented out a certain couple of parts, and then re-typed the same bit of code, the program would compile just fine... not sure where the "dirty" data would have comefrom though :/

anyway, nevermind. i'm back on it now, and my program is certainly starting to fufil its role.

[Hungry Horace]

hmm.. found this old post, and know completely what that problem was now.

it seems there is no limit to the number of ELSE IF statements you can use on AMOS code, providing you only run it from the editor.

Compile it however, and it will crash if you use too many in one IF statement (honest!)

[skateblind]

Let me guess, the programming of Horace Boxing (plug ) made you realise that?
I remember you not being able to compile due to something that AMOS wasn't flagging, you also told me not to use too many when making the AI code, which was really hard(noob).
Would that be classed as an AMOS bug?

[SamuraiCrow]

I'd classify it as an Amos Compiler bug.  It can only recurse a fixed depth on the stack without overflowing it.  I'm guessing it uses the same type of stack extension support that AmosPro applications use.

-edit-
This thread was going way off-topic so I split it into a separate thread.

[Hungry Horace]

Let me guess, the programming of Horace Boxing (plug ) made you realise that?

actually, i first encountered it when i started the Bloodwych map-reader, (which has since spiralled out of control into the current editor/gui!) but i only realised what the problem was once i was coding HB+.


it was because of the piss-poor way i was converting the 2 wall bytes into graphics.

Code: [Select]

If abc1 - wall
   sub rules
elseif abc2 - woodwall
   sub rules
....
endif
and so on.

thankfully now, my brand new (TM) DRAWCODE[ab,cd] routine works much much better; calling a numbered GO SUB based on the number, then divding up other data with neat tricks like

Code: [Select]

B mod 4=0  : rule 1
B mod 4=1 : rule 2
...

which means that now every possibilty is interpretted a lot better, and is executed more efficiently.

[SamuraiCrow]

I assume you mean you are using "On N Gosub ..." for your numbers.  Also, you can do a faster modulo of a power of 2 by using a logical "AND" on one less than the number.  Eg.  "Z mod 4" becomes "Z And 3" .

[Hungry Horace]

I assume you mean you are using "On N Gosub ..." for your numbers. 

nope, i mean i have a thing that creates a string...

Code: [Select]

abcd = the location's walldata

fish$="WALL"+STR$(d)
gosub fish$

wall1:
stuff happens here


Also, you can do a faster modulo of a power of 2 by using a logical "AND" on one less than the number.  Eg.  "Z mod 4" becomes "Z And 3" .

is that just ON Z and 3 ....  ?

i'll be honest the ON command caused me alot of hassle when i last used it....

[SamuraiCrow]

"On N Proc" has bugs but "On N Gosub" should be okay.

The deal with the "Modulo" and "And" is just a property of binary place values.  It's really easy to divide and modulo powers of 2 in a binary number in the same way it is easy to divide and modulo powers of 10 in a decimal number.  All you're doing with the modulo is masking off the bits you're not using and coming up with a mathematical remainder as a result.

[Lonewolf10]

hmm.. found this old post, and know completely what that problem was now.

it seems there is no limit to the number of ELSE IF statements you can use on AMOS code, providing you only run it from the editor.

Compile it however, and it will crash if you use too many in one IF statement (honest!)

Funny you should mention that. I read about that recently in posts from 1998, or an issue of AMOSzine.

AMOS does not like more than 3 (or was it 10?) ELSE IF's.

Personally, I don't like using ELSE IF's. The way the tokenizing works, using ELSE IF's can be very dangerous (especially if the IF and End IF are miles apart).


I also came across a couple of corrupted programs the other week. They both had a line of about 100 spaces!!! AMOS wouldn't run the program and kept finding the line and giving an error message.
I deleted said line and the program worked fine. I tried to recreate the line, but couldn't! The file must have become corrupted somehow.

I also have a list of AMOS bugs somewhere. I'll try to find it and post it to the forum.


Regards,
Lonewolf10

[Lonewolf10]

Here's a bug that I apparently had 3 years ago (see AMOS-LIST message 7346) where I had loads of "Data" lines at the end of my program and it wouldn't compile.

It seems that the Compiler for AMOS: The Creator (1.2) can't handle momre than 64K of "Data" lines:

Data 235,484,276,373,1,29,383
Data 392,393,492,302,283,494


Shortly after I discovered that, I started using Banks to store my data


EDIT:

More bugs found tonight...


AMOS-LIST, msg


This is something I (Andrew D Burton) have seen posted to the group and have
confirmed it's still a bug in AMOS Pro 2.X, hence I don't use the Add command
anymore (I just don't trust it!)

A=2: B=0
Print A, B
A=A^2
Add B,2^2
Print A,B

I hope I got that right, it should show that A=4 and B=247463 (some useless and
completely incorrect value!). Simple put, you can't use ^ (power of) in the ADD
command.



AMOS-LIST msg 1468


Hi people

Today I renembered a bug in AMOSPro I discovered 5 years ago.
When you use

Input "text",WHATEVER$

And the text is so long that the textline almost reaches the right border of the
screen amos freezes.

Well amos is full of weird bugs like that I guess



AMOS-LIST msg 1473


About the On Break problem.... AMOSPro V1.x is really bugged, and the On Break
is one of this problem... since you (... now i don't remember who ) have the V1
the problem is explained. With AMOSPro 2 On Break works fine.


AMOS LIST,msg 1627


Question:

Today, I tried a small code on an Amiga with an Infinitiv keyboard interface to
use with the original keyboard of this machine. I tried this:

Do
A=0
If Key State(16) Then Add A,1
If Key State(17) Then Add A,2
Print A
Loop

On an AZERTY, pressing key A will print 1, B will print 2, and normally pressing
A and B together will print 3. But on this keyboard interface, it is only A or
B, no way to detect multi pressed keys.
Very bad for action games with keyboard. Is there a way to really test the
states of the keyboard (that was possible on my poor A500?

Answer:

On many amigas, (like A1200), it can't detect more then one keypress on the same
row eg. on a qwerty keyboard, these keys don't work together qwertyuiop[] etc.
You'll have to make sure you map the keyboard carefully. (The cursor keys are a
pain, each one conflicts with one of the main rows ;(


AMOS LIST, msg 1652


Change the default screen to less than four colours and your sound gets screwed
up. Sam Play won't work, and the built in sounds, Boom, Shoot and Bell will guru
the Amiga. Sam Loop Off gets switched to Sam Loop On after a run. The command
still works, but it gets shown on the screen improperly.



AMOS-LIST msg 1778


>> snip <<

I tried loading my newly-named programme only to receive the same disk error
message - which was becoming tiresome now. By trial and error, I eventually
worked out that the problem was caused by an apparently over-sized icon; once
that was deleted the programme then saved and re-loaded properly. Fortunately
for me I had not removed the sequence of instructions from my programme which
had drawn the icon I had created with the Get Icon command.

No maximum icon size is shown in my AMOS manual, and I was wondering whether
anyone knew what it was. (Mine was almost the width of a hi-res screen, but now
I use a packed screen to display the image).



Regards,
Lonewolf10

[SamuraiCrow]

AMOS LIST, msg 1652


Change the default screen to less than four colours and your sound gets screwed
up. Sam Play won't work, and the built in sounds, Boom, Shoot and Bell will guru
the Amiga. Sam Loop Off gets switched to Sam Loop On after a run. The command
still works, but it gets shown on the screen improperly.



AMOS-LIST msg 1778


>> snip <<

I tried loading my newly-named programme only to receive the same disk error
message - which was becoming tiresome now. By trial and error, I eventually
worked out that the problem was caused by an apparently over-sized icon; once
that was deleted the programme then saved and re-loaded properly. Fortunately
for me I had not removed the sequence of instructions from my programme which
had drawn the icon I had created with the Get Icon command.

No maximum icon size is shown in my AMOS manual, and I was wondering whether
anyone knew what it was. (Mine was almost the width of a hi-res screen, but now
I use a packed screen to display the image).

I think the maximum size supported by icon.library is only 128x128.

BTW, Sam Play and Sam Load are totally borked.  Sometimes Sam Load will load samples into Fast Ram and Track Load is the same way.  Always use the equivalent AMCAF instructions to do sound.  (Remember to use a negative bank number in the Imploder Load command for loading things into CHIP Ram.)

[Lonewolf10]

Samurai,

Icon.library may only support 128x128, but I have had larger icons on some of the game/software I have used over the years. Not many, but they do exist.

I believe Iconian (I have it somewhere, but not used ina year or so) can create large icons.


Back to bugs, I believe some of the Limit Mouse commands are bugged in AMOS Pro 2.X - I spent the day searching through the AMOS: TC sources to find the original code (by Francois Lionet) to add to a small extension I am trying to put together (based on the Colours extension by Jann Normann Nielson), which has about 30 different colours. Once finished, I'll talk more about it.


Regards,
Lonewolf10

PS. I have a list of more bugs somewhere, will post that up later this week.