Print

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

[SamuraiCrow]

So a set of floppies to install to a hard drive is what I'm building.

What's wrong with an ISO image for CD-ROM?  I suppose it would be mostly empty.  How many disks are you up to so far?

[SamuraiCrow]

Nice ! I hope you find the time to complete Amos Aga it'll be a dream for me, between I dont know if I can help in any task because dont know really how you made this miracle.

Have you installed the Games Master System users' archive and GMS developers' archive so you can try out the Games Extension?  You'll have to use the GMS environment's features using custom commands that resemble the original AmosPro versions, but it supports AGA quite well.  If you run into trouble, post back here and I can see if the GMS manual has any solutions for you.

[bruceuncle]

So a set of floppies to install to a hard drive is what I'm building.

What's wrong with an ISO image for CD-ROM?  I suppose it would be mostly empty.  How many disks are you up to so far?

I stuck with floppies as being the easiest way to install for anyone who doesn't already have AMOS Pro installed.  Just boot the first floppy.  If AMOS V2.00 is already installed, the install program can run quite happily with those libraries so the user can just run the install program straight off the floppy having already booted from their hard drive.  It looks like around eight floppies.  Apart from the bootable disk, which has just enough support for the AMOS install program itself, they no longer represent a floppy-only AMOS Pro though.

So I suppose a CD version could do the same.  It would mean modifying the install program and I'm already up to my neck getting everything together for a floppy install.  I don't have any Amiga hardware experience except my A2000 many years ago.  Can the CD32 boot from a floppy?  If it can't, then I'd have to do a CD version, but later...  A *.lha version would also be possible, but would create problems with cleaning up the hard drive if anything failed during the install.

Just for fun, I've attached a cut-down of the install program I'm working on with only the modified intro anim for everyone's amusement (hopefully ).  The original was using 16 colour bobs on a 32 colour background giving an unwanted masking effect (you probably never noticed!).  The original explosions animation seems to have started out as a series of bobs from tiny to massive.  It was then changed to screen flipping as more memory efficient, but someone forgot to remove the bobs from the bank...  A set of bobs was also splatted directly into the sprite bank from a data bank for reasons unknown.  So I couldn't resist cleaning it up and modifying it a bit to emphasise the 'AMOS Pro cleaned up' nature of the release.  (Well, I love actually programming in AMOS so forgive the distractions.)  I also substituted Say for the voice to incorporate the release version.  The idea being to continue this animation for future release versions.  The version number is yet to go on the screen and into the dialogues.

This is a very quick and dirty chop out of the testbed program in which I'm developing the installation, so excuse the messy.  I haven't tidied anything up yet.  It also has the banks embedded rather than loading them at run time as you'd have to modify the code otherwise.  This is probably about as 'messy work in progress' as it gets  .

[SamuraiCrow]

CDTV and CD32 don't boot from floppy by default since it was an optional add-on for those models to have floppy drives at all.  They typically would boot from the CD-ROM.  Normally one wouldn't program with those models in their stock configuration anyway because neither of them came standard with a hard-drive either.  They were upgradable to computers using expansion decks like the Paravision SX-1 and SX-32.

[bruceuncle]

... Normally one wouldn't program with those models in their stock configuration anyway because neither of them came standard with a hard-drive either. ...

Thanks SamuraiCrow.  From my limited practical knowledge of the machines, I don't see anyone developing in AMOS Pro on much less than an A1200 upwards.  I'll go on with a floppy install then, mainly for the nostalgia and partly as a universal currency. 

[Lonewolf10]

This is a very quick and dirty chop out of the testbed program in which I'm developing the installation, so excuse the messy.  I haven't tidied anything up yet.  It also has the banks embedded rather than loading them at run time as you'd have to modify the code otherwise.  This is probably about as 'messy work in progress' as it gets  .

Yeah... not sure if my current AMOS configuration is at fault but...

 - Sam Stop causes a syntax error (twice!) at lines 670 and 725
 - Once they are commented out it runs, but then crashes! (8000 0004 error)

The animation itself is pretty cool and did make me smile. The explosion is fine, then the other stuff is good. After that thing stops being lowered it crashes...

[bruceuncle]

Yeah... not sure if my current AMOS configuration is at fault but...

 - Sam Stop causes a syntax error (twice!) at lines 670 and 725
 - Once they are commented out it runs, but then crashes! (8000 0004 error)

The animation itself is pretty cool and did make me smile. The explosion is fine, then the other stuff is good. After that thing stops being lowered it crashes...

Thanks for the feedback (I think  ) Lonewolf10.

That's a bit worrying as I thought there was only one version of AMOSPro_Music.Lib out there.  Looks like you may have another!
The AMOS program I posted is stored tokenised (as they all are).  So it's essential that the tokens don't change in an AMOS installation.  Each token is just a 16-bit number, which is the number of bytes from the start of a token table to the start of that token's details.  So the Sam Stop instruction in the source +Music.s:

   dc.w    L_InSamStop0,L_Nul
   dc.b   "!sam sto","p"+$80,"I",-2
   dc.w   L_InSamStop1,L_Nul
   dc.b   $80,"I0",-1


would have a token representing the number of bytes to the start of that code fragment above (=$246).

A set of tokens for a library looks like this (from +Equ.s, the tokens at the start of AMOSPro.Lib):

_TkVar          equ     $00000006
_TkLab          equ     $0000000C
_TkPro          equ     $00000012
_TkLGo          equ     $00000018
_TkBin          equ     $0000001E
_TkCh1          equ     $00000026
_TkCh2          equ     $0000002E

Not to be confused with the Instruction Numbers used when you're calling a library's code from your own asm code.  I.e. they're not just 1, 2, 3, ...

Any change to a library's token table that changes the length of an entry will mean that an existing (i.e. already tokenised) AMOS program using that library won't find some of the tokens.

For example, just one of the bugs in the +Music.s token table is this one (there are others):

   dc.w   L_InSamLoopOff0,L_Nul
   dc.b   "sam loop of","f"+$80,"I",-2
   dc.w   L_InSamLoopOff1,L_Nul
   dc.b   $80,"I0",-1

It's missing the exclamation mark "!" at the start to indicate it's got multiple parameter formats.  Inserting the missing "!" and reassembling would work okay for all tokens up to that point, but any following tokens would be one byte out.  Any existing program (i.e. any saved before the change) using those tokens would fail at the Test stage when it was run.  Note that any new programs typed in and saved would be fine as they would be tokenised with the new token values.  The same goes for any existing programs saved in ASCII - AMOS tokenises them fresh as it loads them.

Which is a nightmare for AMOSPro_Music.Lib's bugs as fixing them does affect its token table.  The solution I've been working on is an AMOS program that will examine the files in a directory picking up any *.AMOS ones.  It then hunts through the tokens looking for calls to extension libraries (token $004E) that use AMOSPro_Music.Lib (extension 1).  Having found one, I can then substitute new for old (see, I knew all that work on tokens wasn't wasted  ).  I can find them okay, but I haven't decided how best (= fastest) to do the substitution check yet to prevent trying to retokenise a file twice (in theory, shouldn't matter as long as I check each possible token value (= slowest)).   Life wasn't meant to be easy...

Anyway, that's a possible cause, as the verification code throws Syntax Error for most things it doesn't understand when checking.

The guru 8000 0004 is a CPU trap for the illegal instruction.  The AMOS team used it extensively for debugging.  The +Lib.s source has one that someone left behind by mistake after a debugging session.  It was only in the source though, not the binary.  There are some others in the source in some bug traps, so I'll check those out and also check for the instruction in the V2.00 binaries.

In the sources distribution, the file +Debug.s also has:

Debug      set   2

which puts a load of these traps into the binaries if the sources are just assembled 'as is'.

In the meantime, could I ask you to post your copies of:

• AMOSPro:AMOSPro
• AMOSPro:AMOSPro_Interpreter_Config
• AMOSPro:APSystem/AMOSPro.Lib
• AMOSPro:APSystem/AMOSPro_Music.Lib

so I can do a compare of the binaries against the AMOS Pro V2.00 versions?

If your AMOSPro_Interpreter_Config isn't in the directory above, the one in S: will be the one AMOS's using.

[SamuraiCrow]

@bruceuncle

re: tokenization errors
How hard would it be to create a "forwarder" for obsolete tokens?  That way you could start a fresh token at the end of the list with the same name as the old token and just have an AmosPro routine in the loader update to the new token entry.

[bruceuncle]

@bruceuncle

re: tokenization errors
How hard would it be to create a "forwarder" for obsolete tokens?  That way you could start a fresh token at the end of the list with the same name as the old token and just have an AmosPro routine in the loader update to the new token entry.

Thanks SamuraiCrow.  Just to put this into perspective:

• This token problem only arises for the core AMOS libraries.
• Any other extensions are SEP (Someone Else's Problem).
• The only core library affected is AMOSPRO_Music.Lib.

Unfortunately, one of the errors in AMOSPro_Music.Lib's token table is the one I quoted - the missing "!".  As this is effectively an "invisible" character, a substitute instruction cannot simply be tacked onto the end of the token table and "forwarded" from the original.

AMOS uses the token table in two ways:

• The text part of the entry is used in Tokenising each line of a program when the user hits the [Enter] key, or when an ASCII program file is loaded.
• The Token Number is used in Verifying a program (the Test before Run phase) and in converting the tokens back into something readable for the screen (it just jumps straight to the token entry using the Token Number offset and pulls out the text).

(Before any pedantic peoples post, I'm over simplifying here to keep the explanations short(ish)).

So "!sam loop off" and "sam loop off" both look the same to the Tokeniser.

I'd rather go with a one-off retokeniser program, as that fixes the problem once only.  AMOS Pro already does some Instruction Number substitution for old libraries when it loads them.  I really don't want to add to that if I can avoid it as there's a big difference between Instruction Number substitution (easy) and Token Number substitution (harder). 

There was a retokeniser program with the AMOS Pro release (in the Tutorial directory) used to fix single-to-double-precision problem differences between V2.00 and earlier versions.  That could "cheat" as the tokens are identical - the token routines for maths instructions are swapped so single- and double- precision look identical.  All that retokeniser had to do was convert each line into text (detokenise) and back again (tokenise).  The theory behind that simple statement is a bit more complex than that!  So I won't go into it here (I've forgotten the details anyway - it was a while ago that I "understood" it  .)  My point being that this process of a bit of retokenising for a new version of AMOS Pro is already in "the culture".

I've got so many balls in the air at the moment that the retokeniser is only a minor concern.  The Tokenise, Detokenise and Verify code is a hard-coded wilderness in the original code.  It makes extensive use of the AMOSPro.Lib tokens being known and unchangeable.  I don't fancy adding more to that!  I've had to do it to cope with a couple of bugs in the Editor (numeric overflow and incorrect numeric conversion).  It took me ages to work out how to exit from the middle of that code to handle the error messages.  I gave up on a logical solution and cache the stack pointer at the start instead.  So I can jump out of it anywhere, restore the original stack pointer, and handle the error messages.  The original code makes extensive use of the stack for temporary storage and tracking where it is at any given point is a real headache  .

[SamuraiCrow]

UGH! I see what you mean!

[Lonewolf10]

Yeah... not sure if my current AMOS configuration is at fault but...

 - Sam Stop causes a syntax error (twice!) at lines 670 and 725
 - Once they are commented out it runs, but then crashes! (8000 0004 error)

The animation itself is pretty cool and did make me smile. The explosion is fine, then the other stuff is good. After that thing stops being lowered it crashes...

Thanks for the feedback (I think  ) Lonewolf10.

That's a bit worrying as I thought there was only one version of AMOSPro_Music.Lib out there.  Looks like you may have another!

I'm completely confused now.

First I checked to see if I was using the Enhanced Music Extension (EME) and no I wasn't, then I pressed F2 - no errors! So I decided to run it and it worked without crashing.

I was working on other things the first occasion I ran it, but a reset (or crash) would fix memory issues (e.g. cake slices, as I believe it was described as somewhere) right? It crashed on me several times before I posted about my issue, but now it is working flawlessly straight from starting WinUAE and I haven't changed any configuration files or anything.

Would you still like me to post the requested files?

[bruceuncle]

I'm completely confused now.

First I checked to see if I was using the Enhanced Music Extension (EME) and no I wasn't, then I pressed F2 - no errors! So I decided to run it and it worked without crashing.

I was working on other things the first occasion I ran it, but a reset (or crash) would fix memory issues (e.g. cake slices, as I believe it was described as somewhere) right? It crashed on me several times before I posted about my issue, but now it is working flawlessly straight from starting WinUAE and I haven't changed any configuration files or anything.

Would you still like me to post the requested files?

Thanks Lonewolf10.  Don't worry about posting those libraries.  My only concern was that there may have been an AMOSPro_Music.Lib out there different to the one originally distributed.  From all my waffle on token tables, you probably gathered that my retokeniser has to match against one, and only one, version of the token table.  So I can breathe a sigh of relief on that score at least 

As to why the problems arose in the first place, I'm far from an expert in WINUAE.  However, I have crashed it twice, and on the second occasion my desktop gadgets disappeared.  Which should be just about impossible in Windows 7!  So maybe WINUAE got corrupted or the loaded config file got corrupted.  Or maybe even that session of Windows was flaky (happens sometimes).  I'd put it down to "just one of those things".  Happy to hear it's working fine now.  Thanks again for your feedback.

All the AMOS Pro V2.10 assembler and AMOS Basic sources, and all binaries that will allow it, have a version number embedded.  So we can quickly check which version we're talking about in the future.   (And hopefully pave the way for installed version checking and backup for the Installer program.)

[Lonewolf10]

Thanks Lonewolf10.  Don't worry about posting those libraries.  My only concern was that there may have been an AMOSPro_Music.Lib out there different to the one originally distributed.  From all my waffle on token tables, you probably gathered that my retokeniser has to match against one, and only one, version of the token table.  So I can breathe a sigh of relief on that score at least 

Yeah, I totally understand

As to why the problems arose in the first place, I'm far from an expert in WINUAE.  However, I have crashed it twice, and on the second occasion my desktop gadgets disappeared.  Which should be just about impossible in Windows 7!  So maybe WINUAE got corrupted or the loaded config file got corrupted.  Or maybe even that session of Windows was flaky (happens sometimes).  I'd put it down to "just one of those things".  Happy to hear it's working fine now.  Thanks again for your feedback.

Yeah, it seems something was off that day. I have crashed the WinUAE debugger several times before 

[Umpal]

This release is a work-in-progress for a V2.10 release of AMOS Pro (...)

I know it's an old topic but no doubts still very important. Uncle Brcue, are you able to make another fix? I just found a critical bug:

I have a text file with different numbers. Some of them are negative. In my program I do:
1. Read the string, e.g. "-22.0176"
2. Pass that number to a variable# using Val() instruction
3. Display it on the screen

Under AMOS editor it works correctly displaying -22.0176 but after I compile it and run it changes the negative to positive 22.0176!

Try this both in Editor and compiled:

Code: [Select]

Screen Open 0,320,256,16,Lowres : Flash Off : Curs Off

LINE$="-22.0176"
N#=Val(LINE$)
Print "N#="+Str$(N#)
Print
Wait Key 

[SamuraiCrow]

Sounds like a compiler bug, not a problem with AmosPro itself.