Print

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

[james666]

Having managed to re-create amos.library from the source, I thought I'd take a look at my old nemesis - the Dual Playfield horizontal scrolling bug. 

AmosPro's hardware scrolling is programmed rather oddly.  ddfstart and the bitplane modulos are changed when the finescroll (blpcon1) values are zero.  This creates a big problem with 2 playfields because there is only 1 ddfstart register and it can't compensate if both bitplane modulos need to be changed at the same time.  The workaround was to round the x screen offsets to the nearest 16 pixels whenever a conflict arose, creating an awful random juddering.   

The correct way to program horizontal hardware scrolling is to leave ddfstart and the modulos constant, but to reduce the bitplane pointers by 2 bytes when the playfield's finescroll is zero.  It took about 15 lines of code to fix this for lowres DP mode so that 2 playfields can be scrolled completely independently.  My source code (with edits prefixed by "*** edit") is attached.

As a general remark, I think it would quite feasible to modify amos.library to handle AGA parameters from the existing command set (e.g. Screen Open in 256 colours, Dual Playfield with 16 colour screens).  It's much easier to do things like 64 bit bitmap alignment by putting 3.0 system calls directly in the core library than by patching A500-oriented code with extensions.

[james666]

My assembled replacement amos.library is also attached below.

[bruceuncle]

Many thanks james666.     Good to see someone getting stuck in at the coal face.

I'll start grabbing these source changes and collate them with my own and any others.  At this stage, the objective is an AMOS Pro V2.x release that just fixes current bugs. 

Enhancements would ideally come later and be separate.  So, if you're thinking of dabbling in AGA ideas, just keep them separate from bug fixes. 

As a general remark, I think it would quite feasible to modify amos.library to handle AGA parameters from the existing command set (e.g. Screen Open in 256 colours, Dual Playfield with 16 colour screens).  It's much easier to do things like 64 bit bitmap alignment by putting 3.0 system calls directly in the core library than by patching A500-oriented code with extensions.

Now I'm more familiar with the overall AMOS architecture, I completely agree.  The AGA enhancements should go into amos.library.  It would require a little bit of adjustment in AMOSPro.Lib to accept the different parameter limits (and can easily cope with alternative parameter formats for instructions if necessary).

Our main problem will be getting amos.library to behave differently depending on whether it detects AGA chipset or not.  Also, during tokenisation, the interpreter would need to detect whether it should report an error depending on chipset.  Similar to the way it currently detects and flags AMOS 1.3 compatibility.  And, of course, the compiler will have to know about it too.

It will need careful planning and coordination.

I published some very naïve AMOS Pro overview diagrams a while back.  I'll get those revised and re-published a.s.a.p. now I know what it's doing from the sources.  We've got to keep the overall picture in view - AMOS Pro's partitioning is reasonable but it is still very tightly coupled in some places.

[james666]

Our main problem will be getting amos.library to behave differently depending on whether it detects AGA chipset or not.  Also, during tokenisation, the interpreter would need to detect whether it should report an error depending on chipset.  Similar to the way it currently detects and flags AMOS 1.3 compatibility.  And, of course, the compiler will have to know about it too.

I don't think the interpreter should report an error during tokenisation if the user creates AGA-legal code on a non-AGA machine.  After all, back in the day, one might have used an A3000 to develop code for newer machines.  The check should be left to amos.library, which would return an error at run-time if the hardware isn't available, exactly the same as an "out of memory" error.  (That doesn't mean that the editor couldn't also have a "Check AGA compatibility" feature analogous to the existing "Check 1.3" but it would be for information, not an error per se.)  Of course, we would need to create a new CheckAGA function so that a well-written Amos program can exit gracefully before triggering an amos.library error.

If we modify amospro.lib and amos.library, shouldn't the compiler work automatically, just like with any other extension?

[bruceuncle]

Our main problem will be getting amos.library to behave differently depending on whether it detects AGA chipset or not.  Also, during tokenisation, the interpreter would need to detect whether it should report an error depending on chipset.  Similar to the way it currently detects and flags AMOS 1.3 compatibility.  And, of course, the compiler will have to know about it too.

I don't think the interpreter should report an error during tokenisation if the user creates AGA-legal code on a non-AGA machine.  After all, back in the day, one might have used an A3000 to develop code for newer machines.  The check should be left to amos.library, which would return an error at run-time if the hardware isn't available, exactly the same as an "out of memory" error.  (That doesn't mean that the editor couldn't also have a "Check AGA compatibility" feature analogous to the existing "Check 1.3" but it would be for information, not an error per se.)  Of course, we would need to create a new CheckAGA function so that a well-written Amos program can exit gracefully before triggering an amos.library error.

You're quite right.  It's the difference between a 'syntax error' (which is the tokeniser's responsibility) and 'illegal function call' (which is the interpreter/compiler's responsibility).

We should continue further discussion here:
     http://www.ultimateamiga.co.uk/index.php/topic,9604.msg45323.html#msg45323
before we raise MadAngus's ire for posting off topic!   

And how do I stop myself using Amiga shortcut keys on my PC?   

[HonestFlames]

My assembled replacement amos.library is also attached below.

Thanks for this. Now my Flappy Bird port can go ahead