Print

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

[bruceuncle]

This post is targeted at anyone with AMOS and 68k skills.  It contains "first-cut" Resource disassemblies of the AMOS Extension Libraries available in the Downloads section.  I've done this package in a hurry, so forgive any errors.

I'd done a lot of work with Resource a couple of years ago, before the AMOS Pro sources became available.  That included creating Resource Symbols Libraries for the most common AMOS symbols.

In the AMOS Pro V2.10 redevelopment, I needed to understand a version 2.21 of amos.library that the AMCAF extension uses.  Installing AMCAF replaces any existing amos.library with this version.  So when I release the new version, installing AMCAF would wipe the bug fixes and any enhancements.  This means also disassembling the AMCAF extension itself as it looks like it's using an extended AMOS data area...

If anyone's ever tried disassembling an AMOS extension, they'll realise that it's near impossible to get a sensible result due to the unique library structure that AMOS uses.  The worst part being the relocation tokens in the code, which throws a disassembler completely off the tracks.  So I started looking at Resource macros to see if they could be persuaded to do the job.  I'd done some work a while back on Resource's Help Files.  They contain some very useful documentation but are near useless when it comes to understanding Resource and its macro language.  They are also buggy and just won't display some critical topics correctly.  So I pulled the data into a database and massaged them into something I could read.  The more I learnt from them, the more it looked to be possible to use them to do the majority of the work in disassembling an AMOS Extension Library.  This package is the result.

I'll be pursuing the AMCAF version of amos.library and the extension library itself as that's what I need right now.  The other extensions I'll pursue at some time in the future (after AMOS Pro V2.10 is completed).

What I would like to see is some buy-in from any other interested people.  There's a lot here to digest but, with some enthusiastic support, we should be able to get bug-free Extension Libraries available for AMOS - the most useful ones anyway.

How far anyone takes these disassemblies depends on what you need the resulting sources for.  In my case, I need a full understanding of what AMCAF's up to.  I'll leave the rest until a future date.  If all that's required is a simple bug fix or nag message removal (HungryHorace note - try offset $7EE in AMOSPro_PowerBobs.Lib, a "bra" should fix it  ) further work may not be required.  It would be great if some other enthusiasts could have a go at some of them.  Please. please post what you're working on and any results here so we don't go reinventing the wheel 

Be sure to read the docs I've written.  There's also a quick database report in PDF format of the essential Resource documentation that I've created from its Help files.  If anyone's interested, I've also got disassemblies of Resource V6.06's executable and library files.  It's a program that would benefit from some bug fixes and fixes to its Help File system.  Let me know if anyone's interested and I'll post them.

Good luck and I hope this is of interest/benefit to someone...   

[Lonewolf10]

I've downloaded the files and will take a look when I can.

There's quite alot of info to digest 

[copse]

If anyone's interested, I've also got disassemblies of Resource V6.06's executable and library files.  It's a program that would benefit from some bug fixes and fixes to its Help File system.  Let me know if anyone's interested and I'll post them.

What state are they in?  Can they be assembled into a fully working version of Resource v6.06?  Are they disassembled comprehensively with decent labels, or are they pretty raw?

[Hungry Horace]

 I will certainly have a look to see ifs possible to remove the nag screen on PowerBobs!

[bruceuncle]

The AMCAF Extension is proving to be a bit of a nightmare!  Not only has it a much modified amos.library but it has also extended the AMOS data area (positive offsets from A5).  Of greater concern is that I can't yet see where it's allocated that extra memory!

The AMCAF amos.library specifies an extra $910 bytes but AMOSPro_AMCAF.Lib is cheerfully using locations into at least $1050 extra bytes.  Okay, so amos.library is a ready-modified part of the AMCAF install.  But the memory is allocated in the AMOSPro executable (or the Compiler) when that library is loaded, NOT by the library itself.  The third longword in amos.library does indeed contain the length of the data area, but its not used in amos.library. 

The AMCAF Installer is a compressed and obfuscated piece of work.  However, I've managed to extract its hunks and put them back to together so I can see what's happening.  That's currently in the tedious process of disassembly to find out what it's doing.  Looks like some config file changes being made there too.  But so far, no references to the exectuables that need changing to make that extra memory available.

It might be easier for me to create a plain-vanilla machine with AMOS Pro installed.  Then install AMCAF and check to see if it's made the change in AMOSPro.  But I need to fully understand what AMCAF is doing with its modifications for me to incorporate its amos.library changes into V2.10 anyway...

So, not happy and back to the grindstone. 

[Hungry Horace]

But what if you never used the AMCAF installer just manually added it to the interpreter?

I'm sure that's all I've ever done....

[bruceuncle]

But what if you never used the AMCAF installer just manually added it to the interpreter?

I'm sure that's all I've ever done....

Aye, there's the rub!  If you do that, the extra memory it uses never gets allocated!  It may be that it doesn't get allocated anyway (I'll find out soon).  For a system with heaps of memory, you'd probably get away with it, for a while...  It would be an unallocated 4k or so that Exec don't know anything about. 

Anyone had any inexplicable crashes with AMCAF? 

Don't fret too much.  I've got to incorporate the mods for AMCAF's amiga.library into V2.10 anyway.  As, otherwise, anyone installing the AMCAF libraries (or just copying them  ) would find the V2.10 fixes disappear.  And vice versa, installing V2.10 would wipe AMCAF.  When I know what it's being used for and checked it all out, I'll be doing the mods to the "b.s", "+equ.s" and "+w.s" sources to make it fit.  With a blunt instrument if necessary!   

My post was more a bit of a rant to let off steam as it's a fair bit of extra work...    Aaah, I feel better now 

BTW, AMOSPro_AMCAF.Lib and AMCAF's amos.library don't match together too well anyway.  They look like they may be from different release versions.  Either that or someone's just been a bit slack synchronising each library's view of how much extra memory is involved.  I should know more some time next week...

[SamuraiCrow]

I suppose it would be best to make a new extension in the same slot as AMCAF used to take and just implement enough commands to do all but the p2c and c2p related stuff including shade bobs, starfields and splinters.  The graphics commands can be integrated into another extension since they aren't as useful in day-to-day use.

[bruceuncle]

I suppose it would be best to make a new extension in the same slot as AMCAF used to take and just implement enough commands to do all but the p2c and c2p related stuff including shade bobs, starfields and splinters.  The graphics commands can be integrated into another extension since they aren't as useful in day-to-day use.

It's only amos.library that I'm working on for this phase, just to ensure no existing extensions break.  And only AMCAF looks to be a problem child.
The extensions themselves will come in the next phase.  I agree that it may be best for some to retain their existing slots but be reissued in a slightly different form.  They'd have to retain their existing token numbers though, otherwise any AMOS code using them would break.
And thanks for flushing the spam.   

[Lonewolf10]

Anyone had any inexplicable crashes with AMCAF? 

Hmmm... I don't think so, but AMCAF has alot of instructions and I have probably only every used a handful of them.

[bruceuncle]

Anyone had any inexplicable crashes with AMCAF? 

Hmmm... I don't think so, but AMCAF has a lot of instructions and I have probably only every used a handful of them.

I suspect that extra memory is only used by some of the less useful AMCAF instructions as SamuraiCrow pointed out.  I'll know more when I've completed tracing through what the installer's doing.  Wish me luck! 

[Tormentor]

I habe long time ago removed the Bower Bobs NAG Screen it was realy simple with the Reassembler & Assembler in MAXON ASM.

But now i am to silly todo it again