Print

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

[bruceuncle]

GenAm2 is a newer version of GenAm. I suspect GenAm came with a version of DevPac 1. GenAm2 is an executable and is an ASM editor and assembler in one. GenIm2 is also an executable and is some sort of command line tool - possibly used to link files together? I have never used GenIm2 before... I didn't use MonAm2 (or MonAm) either - debugging software part of DevPac 2 (or DevPac 1).

Thanks for that.    It makes sense that the AMOS team used something like GenAm2 as it's got a much smaller footprint than GenAm (around 65k).  Which would have been a help assembling big stuff on small systems.  Because I'm using WINUAE and can 'make' a powerhouse A4000 to order, I tend to forget what it was like programming on a 'real' A500 and A2000 .  But I've also set up an A2000 system, initially for nostalgia (that's what 'my' Amiga was) but now also useful for checking performance for any new stuff I'm writing.

I'd seen GenIm mentioned in the Equates section of AMOS Pro.  I'ts mentioned in a comment in AMOS_Pro\Productivity1\Equates\Make_Equates.AMOS:
"' Name of the .LST file, produced by GenIm "
and in ...\Equates.Doc:
"* You should use Genam2 (or 3), in fact the assembler, Genim2."
if that's a clue.

I know very little about Devpac as I'd only bought it just before my Amiga 2000 was retired years ago.  The only stuff I did with it was one simple procedure to embed in an AMOS 1.3 program (which is what prompted the purchase).  I was scared stiff (at the time) of working in assembler on the Amiga.     I'm using a dowloaded disc set and dowloaded docs at the moment.  Which isn't all that informative!  But I'm getting the hang of it now. 

Have you noticed the programs drip and flush in some of the scripts?  I lurve the names but would also like to know what they did if anyone's come across them?  They sound a bit too much like a couple of in-house programs from the names so we may never know...

The more I peek (terrible pun!) into the sources, the more confident I am that we can pull all this together without too much trouble.  But it's gonna take a loooong time.  Helluva a lot to do.

[Lonewolf10]

I'd seen GenIm mentioned in the Equates section of AMOS Pro.  I'ts mentioned in a comment in AMOS_Pro\Productivity1\Equates\Make_Equates.AMOS:
"' Name of the .LST file, produced by GenIm "
and in ...\Equates.Doc:
"* You should use Genam2 (or 3), in fact the assembler, Genim2."
if that's a clue.

Ok, thanks. I'll see if I can do some more digging...

I know very little about Devpac as I'd only bought it just before my Amiga 2000 was retired years ago.  The only stuff I did with it was one simple procedure to embed in an AMOS 1.3 program (which is what prompted the purchase).  I was scared stiff (at the time) of working in assembler on the Amiga.     I'm using a dowloaded disc set and dowloaded docs at the moment.  Which isn't all that informative!  But I'm getting the hang of it now. 

It's not that hard coding asm. I find it harder trying to use the OS via ASM, which is why my assembly written software will always close down the OS. Not to mention it's great fun having full control of the machine

Have you noticed the programs drip and flush in some of the scripts?  I lurve the names but would also like to know what they did if anyone's come across them?  They sound a bit too much like a couple of in-house programs from the names so we may never know...

Yes, there is one script which goes something like:

Code: [Select]

flush
drip
amos pro
flush
drip

Flush probably just ensures the system is cleared of anything that may have been running previously. Thus ensuring that no false bugs are found when testing AMOS Pro - some programs can crash when run because a previous program contained dodgy code.
Drip on the other hand is a mystery

[bruceuncle]

I know very little about Devpac as I'd only bought it just before my Amiga 2000 was retired years ago.  The only stuff I did with it was one simple procedure to embed in an AMOS 1.3 program (which is what prompted the purchase).  I was scared stiff (at the time) of working in assembler on the Amiga.     I'm using a dowloaded disc set and dowloaded docs at the moment.  Which isn't all that informative!  But I'm getting the hang of it now. 

It's not that hard coding asm. I find it harder trying to use the OS via ASM, which is why my assembly written software will always close down the OS. Not to mention it's great fun having full control of the machine

Drip on the other hand is a mystery

Yes, it was the OS that put me off back then.  A kind work colleague gifted me his full RKM set for an A1000 that he'd owned when he heard I'd just bought an A2000.  That's what did the damage!    It's the only bit of Amiga antiquity I've still got (if you can call around 10Kg of manuals a 'bit'!).  For some reason I hung onto them when my A2000 passed away in a flood at a friends place.  They're way out of date in the details compared to the WB3.x set.  But the basics haven't changed all that much and I've found them very useful now I understand what they're telling me.  And I prefer reading real books to reading online ones as my back problems make reading stuff on the PC a very real pain.  I tracked down a set of WB3 autodocs so I've got the up-to-date info too.  (Up-to-date seems a stange phrase for an Amiga in 2013  )

The only ASM I'd dabbled with previously were 6800 on a home-built 'Dream 6800' that no-one's heard of these days.  That was hand assembly with lots of graph paper!  I've still got the hardware in a cupboard.  It had a massive 64 x 32 pixel b&w display 

Then it was a 6809 in an 'Hitachi Peach', which is probably also something no-one's heard of these days.  I did lots in ASM with that as it had a fairly simple Basic-and-OS-in-ROM and a 'hackers guide' (= its RKM equivalent) was published and available whilst it was still a 'current' machine.

But that was all 'back then'.  I ain't afraid of nuffin' now!    And I'm loving the 68000 - a simple set of instructions but a magnificent set of addressing modes.  So easy and so logical compared to the Intel offerings of today.

Flush probably just ensures the system is cleared of anything that may have been running previously. Thus ensuring that no false bugs are found when testing AMOS Pro - some programs can crash when run because a previous program contained dodgy code.
Drip on the other hand is a mystery

That makes a lot of sense.  One can lose a lot of RAM to leaks crashing AMOS programs!  When I started programming AMOS again, I quickly learnt that it's essential to put a call to a 'clean up' procedure at the start of a program that uses a lot of memory banks as well as at the end.  An error or break can leave a lot of unreleased memory lying around.

Thanks for all the info.   

[james666]

BUT, before we get that far, we've got to arrive at a set of sources that will actually assemble into AMOS Pro V2.0. 

I have successfully recreated AmosPro.lib and the AmosPro executable by assembling +lib.s and +b.s respectively in Devpac 3.  (w.s appears to be an old, pre-2.0 version of the lib and can be ignored.)  The only changes I had to make were to fix the illegal bit instructions by subtracting 8 from the operand. For example, btst #x,DmaConR(a6) would be changed to btst #x-8,DmaConR(a6).  It seems that the illegal instructions aren't flagged in some versions of Devpac (or is there an error override option somewhere?), which would explain how this rather sloppy code managed to slip through the net.  As when creating an extension, the amospro.lib code needs to be assembled as an executable without any debug symbols.

My output files are not byte-exact copies of the originals but they seem to work fine as 1:1 replacements in my WinUAE AmosPro 2.0 installation.  AmosPro.lib is 101500 bytes vs 98184 bytes original.  AmosPro is 71652 bytes vs 22624 bytes original.

It's intriguing to read some of the documentation.  Seems that they were serious about doing the AGA version in early 93.  There's even a demo AMOS program to show an "AGA detected" message.  There's also talk of a "PCOS" windows port.  I wonder why Europress pulled the plug.

[james666]

A correction to my earlier post...  The +w.s file is of course the source for the amos.library, a rather critical part of the system.  The good news is that after a couple of minor adjustments, this one also assembles into a working binary.  The changes are as follows:

1. The include lines at the start need to be modified to point to the "include" directory.  exec/types.i needs to be added so that the STRUCTURE type is defined.  Non-standard names were used for gfx.i and layers.i.  These are also fixed: 

IncDir   "dh0:devpac/work/amospro sources/includes/"
Include "exec/types.i"
Include "graphics/rastport.i"
Include   "graphics/clip.i"
Include "graphics/layers.i"
Include "graphics/text.i"
Include "devices/input.i"
Include "devices/inputevent.i"
Include "exec/interrupts.i"
Include "exec/io.i"
Include "hardware/intbits.i"
Include "graphics/layers.i"
Include "graphics/gfx.i"

2. The source doesn't contain the LVO offsets for certain graphics and layers library calls.  I just looked them up in "Mapping the Amiga" and appended these lines to +libsoffsets.s:

_LVOInitBitmap      EQU   -$186
_LVONewLayerInfo   EQU   -$90
_LVOCreateUpfrontLayer   EQU   -$24
_LVOSetAPen      EQU   -$156
_LVOSetBPen      EQU   -$15C
_LVOSetDrMd      EQU   -$162
_LVOSetFont      EQU   -$42
_LVOInstallClipRegion   EQU   -$AE
_LVODisposeRegion   EQU   -$216
_LVODeleteLayer      EQU   -$5A
_LVODisposeLayerInfo   EQU   -$96
_LVONewRegion      EQU   -$204
_LVOOrRectRegion   EQU   -$1FE
_LVOOpenFont      EQU   -$48
_LVOCloseFont      EQU   -$4E
_LVOOwnBlitter      EQU   -$1C8
_LVODisownBlitter   EQU   -$1CE
_LVOWaitBlit      EQU   -$E4
_LVOText      EQU   -$3C
_LVOWaitTOF      EQU   -$10E

3.  You need to comment out the following debug code at c. line 9342.  I found that my WinUAE "Amiga" froze when Amos was started otherwise:

;IFNE Debug=2                            Si debug
;bclr   #WFlag_LoadView,T_WFlags(a5)   AMIGA-A normal...
;ENDC

(Interestingly, the immediately preceding code runs a check for the AA chipset.)

4. I changed all the "illegal" bit instructions as described in my first post.  This may not be needed for some assemblers.

5. Devpac needs to be set to non-case sensitive mode.

+w.s then assembles into a binary that can be used as a direct replacement for libs:amos.library.  It's 47320 bytes - slightly larger than the original. 

To summarise, we have working source code for the guts of AmosPro 2.0:

+lib.s  assembles into a working amospro.lib
+b.s assembles into a working amospro loader
+w.s assembles into a working amos.library

[Hungry Horace]

Whilst I don't think I will be doing any modifications to the Amos Pro myself, this is still great news!

Well done on getting the initial compile working... Bit strange that the Amos pro exe should be 3 times bigger though? I assume its been checked that the original doesn't have some kind of compression on it?

[james666]

Bit strange that the Amos pro exe should be 3 times bigger though? I assume its been checked that the original doesn't have some kind of compression on it?

Yes, it is a bit odd.  The code repository contains an bject file called "(b.o)" about 100k in size.  Maybe this was combined with a cruncher to generate the official amospro executable.

[bruceuncle]

The only changes I had to make were to fix the illegal bit instructions by subtracting 8 from the operand. For example, btst #x,DmaConR(a6) would be changed to btst #x-8,DmaConR(a6).  It seems that the illegal instructions aren't flagged in some versions of Devpac (or is there an error override option somewhere?), which would explain how this rather sloppy code managed to slip through the net.

The earlier versions of Genam will let this slip through without complaint.  If you use the version included in the source distribution, it will assemble without complaint.  You can just substitute that Genam executable into your Devpac3 installation (back up the original of course!) and you've virtually got the environment they used.

This btst, bclr, bset problem is mostly self-correcting.  See this post earlier in this thread for the gory details:  http://www.ultimateamiga.co.uk/index.php/topic,9600.msg45034.html#msg45034

However, I did notice one case in +w.s where it does matter.  I haven't got the details handy as I'm up to my ears in something else at the moment.  It's where the hardware registers are tested to see if a blit is completed.  The wrong bit is tested due to the Genam bug, so partial blits are the result.  I can see the effect in the AMOS Read Text instruction where the title bar for the window is missing chunks from some bit planes.  It also crops up occasionally when using Unpack to paste Resource Bank Images onto a screen - missing chunks.  Not easy to repeat as timing will vary and most of the time the missed 'wait for blit to complete has no effect.

My output files are not byte-exact copies of the originals but they seem to work fine as 1:1 replacements in my WinUAE AmosPro 2.0 installation.  AmosPro.lib is 101500 bytes vs 98184 bytes original.  AmosPro is 71652 bytes vs 22624 bytes original.

I got the same results.  It's mostly caused by the assembler not optimising bcc branches so it's defaulting to the word or long offset format.  Byte-by-byte comparisons of the original executable and the assembled one for amos.library shows all the differences to be bcc branches in the long offset format.

That explains your AMOSPro,Lib difference, but the AMOSPro difference is a bit too big for that explanation!  (as HungryHorace just pointed out  )

Work in progress

DBL Editor

Still have the DBL Editor and assorted AMOS tools to release on an unsuspecting public.  I've had some serious delays in this due to ill-health and an unexpected bereavement in my wife's family.  The app itself is finished and the AmigaGuide docs that go with it are just about complete.  All the other bits in the package listed below are complete excepting the AMOS Program Detokeniser which I'm releasing as 'work in progress'.

Why all this concentration on DBL?  Well, the entire Editor, Monitor and most of the Accessories use it.  So I thought we'd better get an understanding of it  .  And I needed to get my hands nice and dirty in AMOS and Assembler.

This is a package of bits and pieces:

DBL Editor	large AMOS program
DBL Editor.guide	extensive guide to the above
DBL Editor Menu Maker	AMOS program for an SDK for DBL Editor
DBL Editor Data Maker	AMOS program for an SDK for DBL Editor
DBL Editor Tutorials and files	these go with the AmigaGuide docs
DBL Editor asm source	used as an embedded proc in DBL Editor
*Comment Stripper Accessory	AMOS Accessory to strip comments
**AMOS Program Detokeniser	lists the AMOS tokens and parameters alongside the original source for an AMOS program
Resource Bank Message Lister	AMOS program
AMOS Editor Message Lister	AMOS program
Assorted commented DBL sources	includes the Default Resource Bank progs

*    This just reduces the size of an AMOS program.  If a program won't compile, it can save a lot of space (around 64k for the DBL Editor) for systems tight on memory.

**  This is very much a work in progress for an AMOS Variable, Label and Proc Xref Accessory.  In its current format, it just lists the tokens, parameters and texts along with the original source text.  But all the definitions are in there ready for the XRef Accessory to follow.  May be useful for anyone investigating tokenisation and the AMOS program file format.

I'm not giving a release date for the above as it was supposed to have happened last Xmas!  But too many things in my private life have buggered that all up.  Let's just say 'real soon now' and leave it at that.   

Source Investigations

I've printed out the sources and been browsing them for a while now.  It's time I corrected one of the pre-source-availability assumptions that I'd made about the way AMOS Pro works:

The way that relocatable calls within and between libraries uses the AFLINE 680xx instructions followed by one or two words of data.  I'd assumed that this was implemented as an interrupt vector.   Wrong, wrong, wrong!  If you browse +b.s (the loader) and its included file, +verif.s, you'll see that it does a full relocation of these instructions as it loads the libraries.  So the AFLINE instruction and its following one or two words of data are completely replaced by relocated jumps.  There's also a note in the source that proudly proclaims that these are replaced by bcc instructions in the compiler.  But I haven't looked at the compiler yet so I can't confirm that.

Currently I'm working on a full understanding of the tokenisation used by AMOS Pro.  The file +verif.s gives most of the detail.

I suggest we start to collate what we're each discovering.  Anyone got any ideas as to how we're going to accomplish that?  I can start a personal repository for info but one in the forum would be much better.

The following tables are very much work-in-progress so take it as unverified until I've completed them.  A bit long-winded, but the sort of stuff we need to do to understand how the jigsaw pieces fit together.

Source to Executable Xref:

Directory	File	Source
AMOS Pro	AMOSPro	+b.s, +verif.s, +Internal_Jumps.s
AMOS Pro	Compiler_Shell	Compiler_Shell.AMOS (compiled)
AMOS Pro\APSystem	AMOSPro.Lib	+lib.s, +Toktab_Verif.Bin, +Dialog_Funcs.Bin
AMOS Pro\APSystem	AMOSPro_Compact.Lib	+compact.s
AMOS Pro\APSystem	AMOSPro_Compiler.Lib	+compext.s
AMOS Pro\APSystem	AMOSPro_Editor	+edit.s
AMOS Pro\APSystem	AMOSPro_IOPorts.Lib	+io_ports.s
AMOS Pro\APSystem	AMOSPro_Monitor	+monitor.s
AMOS Pro\APSystem	AMOSPro_Music.Lib	+music.s
AMOS Pro\APSystem	AMOSPro_Request.Lib	+request.s
AMOS Pro\APSystem	APCmp	+apcomp.s ? (not verified)
AMOS Pro\APSystem	Compiler.Lib	+clib.s
AMOS Pro\APSystem	Header_Backstart.Lib	+header_backstart.s
AMOS Pro\APSystem	Header_CLI.Lib	+header.s
Libs:	amos.library	+w.s, +WFont.Bin, ReqPic.Bin, +AMOSPro_Mouse.Abk

Source cross-reference (*.s files only, i.e. no incbin files listed yet):

This is a bit too large to comfortably fit in the post.  So it's attached as a *.csv file.

[Sidewinder]

This is excellent news james.  I admit is had me excited to get it working myself and I'd very much like to see your changes if you can share them.  To that end I've set up a .git repository with the AMOSPro sources over at bitbucket.org.  This is where I plan to store my personal modifications to the source code, but if any of the other developers would like commit access, just let me know and I'll grant it to you (although the limit for the free account is 5 active developers).  But since the repository is public, everyone should have read access.  I've also set up a wiki and bug tracking services if those could prove useful.

https://bitbucket.org/mness1978/amospro

I have successfully recreated AmosPro.lib and the AmosPro executable by assembling +lib.s and +b.s respectively in Devpac 3.  (w.s appears to be an old, pre-2.0 version of the lib and can be ignored.)  The only changes I had to make were to fix the illegal bit instructions by subtracting 8 from the operand. For example, btst #x,DmaConR(a6) would be changed to btst #x-8,DmaConR(a6).  It seems that the illegal instructions aren't flagged in some versions of Devpac (or is there an error override option somewhere?), which would explain how this rather sloppy code managed to slip through the net.  As when creating an extension, the amospro.lib code needs to be assembled as an executable without any debug symbols.

My output files are not byte-exact copies of the originals but they seem to work fine as 1:1 replacements in my WinUAE AmosPro 2.0 installation.  AmosPro.lib is 101500 bytes vs 98184 bytes original.  AmosPro is 71652 bytes vs 22624 bytes original.

It's intriguing to read some of the documentation.  Seems that they were serious about doing the AGA version in early 93.  There's even a demo AMOS program to show an "AGA detected" message.  There's also talk of a "PCOS" windows port.  I wonder why Europress pulled the plug.

[bruceuncle]

To that end I've set up a .git repository with the AMOSPro sources over at bitbucket.org.  This is where I plan to store my personal modifications to the source code, but if any of the other developers would like commit access, just let me know and I'll grant it to you (although the limit for the free account is 5 active developers).  But since the repository is public, everyone should have read access.  I've also set up a wiki and bug tracking services if those could prove useful.

https://bitbucket.org/mness1978/amospro

This is going to be an ongoing problem as more people start making bug-fixes and enhancements.  We'll end up with umpteen versions of AMOS Pro!

My original concept was to collate changes as they are made with the objective of engineering a composite release incorporating them all.

The more I see of the sources, the more worrying this becomes as there's some tight-coupling between the loader/interpreter (+b.s and +verif.s), amos.library (+w.s) and AMOSPro.Lib (+lib.s).  This means that a change in one can radically affect the others if it's related to the token tables.

Simple fixes for incorrect logic within an instruction should be ok though.

Anyway, we need somewhere to stick this stuff so we can sort through it.  It's great to see changes being highlighted in the source as that will make that task easier.  Thanks james666.

1. The include lines at the start need to be modified to point to the "include" directory.  exec/types.i needs to be added so that the STRUCTURE type is defined.  Non-standard names were used for gfx.i and layers.i.  These are also fixed: 

2. The source doesn't contain the LVO offsets for certain graphics and layers library calls.  I just looked them up in "Mapping the Amiga" and appended these lines to +libsoffsets.s:

They're not non-standard names.  Just copy layers_lib.i and graphics_lib.i from the Devpac includes into the AMOS includes in the sources distribution.  That solves both problems.  Why they haven't got them in the includes layers and graphics directories is a mystery.

It's also worth setting up an alternative Devpac environment using the Genam executable from the sources distro.  Just slot it in as a replacement.  It will glide over the illegal bit manipulation instructions without reporting an error.  I know that sounds blasphemous, but bear in mind that we need to be able to reproduce amos.library exactly as the original to be sure we haven't got a modified version.  We know that bug exists so can address it later when we've proved we've actually got unmodified sources.

And it does cause a problem at least in one point in the code when it's used against the hardware registers - see +w.s at line 277.  Exactly which bit in DMACONR did they intend to issue a read to?  BZERO or SPREN?

For similar bit operations on label offsets from a5, it's self-correcting.  Which is probably why they didn't notice it.  But the hardware registers are different as I understand that they should always be referenced using word-sized data.  Can anyone confirm that as I'm still a novice as far as Amiga hardware's concerned?

[james666]

I just noticed that the +b.s loader file contains some conditional debugging includes.  If you open the debug.s file and change the DEBUG flag to 0, +b.s will assemble to a slimmed down 22624 byte executable - exactly the same size as the original.  Furthermore, if DEBUG=0 there is no need to edit out line 9342 of +w.s.

So let's recap.  To create working amospro, amos.library and amospro.lib binaries while making minimal changes to the original code archive we need to do the following:

1. As Bruceuncle suggests, use the provided version of genam2 to circumvent the illegal bit instruction errors.

2. Change the DEBUG flag to 0 in debug.s, as must have been the case when the final production version of AmosPro was assembled.

3. +b.s will assemble without changes to create a replacement Amospro executable.

4. +lib.s will assemble without changes to create a replacement AmosPro.lib

5. Copy & paste my above list of _LVO equates to +libsoffsets.s.  As Bruceuncle suggests, copy the standard Devpac layers_lib.i and graphics_lib.i to the includes directory.  +w.s will then assemble without changes to create a replacement amos.library so long as you enable Devpac's case-insensitive symbols option.

[james666]

And it does cause a problem at least in one point in the code when it's used against the hardware registers - see +w.s at line 277.  Exactly which bit in DMACONR did they intend to issue a read to?  BZERO or SPREN?

For similar bit operations on label offsets from a5, it's self-correcting.  Which is probably why they didn't notice it.  But the hardware registers are different as I understand that they should always be referenced using word-sized data.  Can anyone confirm that as I'm still a novice as far as Amiga hardware's concerned?

The BTST, BSET, BCLR and BCHG instructions always operate on a byte when the destination is a memory address, which a custom chip register is as far as the CPU is concerned.  If you want to manipulate bits 0-31 of a word or long word you have to load it into one of d0-d7 first. 

btst   #13,DmaConR(a6) does exactly what one would expect.  It tests bit 13 of a word address, which is the same thing as testing bit 5 of the high byte.  I can see why a programmer would prefer to write it that way than btst #5, DmaConR(a6), which does exactly the same thing but is less intuitive.  The problem arises when you really want to test bit 5 of the lower byte and naively type a btst instruction that tests the high byte instead.     

[james666]

Reading the Devpac manual, it turns out that you can enable case-insensitive mode and disable the illegal bit instruction errors by inserting "OPT    NOCASE" and "OPT    NOCHKBIT" respectively at the start of the source code. 

[bruceuncle]

I just noticed that the +b.s loader file contains some conditional debugging includes.  If you open the debug.s file and change the DEBUG flag to 0, +b.s will assemble to a slimmed down 22624 byte executable - exactly the same size as the original.  Furthermore, if DEBUG=0 there is no need to edit out line 9342 of +w.s.

Eureka!   

I completely missed that debug.s reference.  Now amos.library assembles exactly byte-for-byte.

I'd even resorted to using the original script file they used.  All the files in the sources distribution starting with a (from a3d through aw) are scripts for assembling/compiling/whatever the sources in their original environment.  They use Genim2 in some cases (with the only option being case-independent labels) Genam in others.  Plus a few that look like custom-built tools eg. Library_Digest which is compiled from a source in the Dot_AMOS directory (though the two compiled instances don't match!).  They make interesting reading (I haven't been through them all myself yet).

So let's recap.  To create working amospro, amos.library and amospro.lib binaries while making minimal changes to the original code archive we need to do the following:
~~~~~~~
5. Copy & paste my above list of _LVO equates to +libsoffsets.s
~~~~~~~

I found I didn't need these as they're already defined in layers_lib.i and graphics_lib.i - with those includes they shouldn't be needed.

Source Version Control

To that end I've set up a .git repository with the AMOSPro sources over at bitbucket.org.  This is where I plan to store my personal modifications to the source code, but if any of the other developers would like commit access, just let me know and I'll grant it to you (although the limit for the free account is 5 active developers).  But since the repository is public, everyone should have read access.  I've also set up a wiki and bug tracking services if those could prove useful.

https://bitbucket.org/mness1978/amospro

This is going to be an ongoing problem as more people start making bug-fixes and enhancements.  We'll end up with umpteen versions of AMOS Pro!

I've attached an XML export from the database I'm using to control the sources.  I used XML to try keeping it as generic as possible.  But I know stuff-all about XML, I just relied on the export to do it right!  Each file contains both the schema and data.  This zips up reasonably small to 2.8Mb but expands to over 80Mb, (I always said XML was a waste of space  No brickbats!  It's a joke.  It's a very weak joke!)  If that format's no use to anyone, let me know and I'll see what I can do for other formats (SQL Server data-definition SQL and bcp for the data?)

The database has the sources broken into label/instruction/operands/(comment) fields by source file, by source line.  I've keyed the lines so as to leave up to 1,000 lines of insertion between any two lines (should be more than enough!).  And there're fields for added-flag/date/version and removed-flag/date/version with an overall flag for inclusion in a source extract.  To explain: you'd be able to pull any source at any version just by setting this flag based on a version number and/or date.

Each source file has similar flags.  To kick off the data for these, they're all marked as added on 06/01/2001 (the date on the sources) and version 2.000.000.  Yeah, yeah, I know that's overkill for the version number but I always like to leave plenty of elbow room for projects like this.   

Cross-Referencing

I'm about to use the database to create a labels XRef.  Gotta parse them out of the operands field first.  It also required me to do a recursive check on the includes and incbin files so I know what to include (literally) when generating the cross-references.

That threw up some interesting info on what's missing (see attached PDF).  The only ones I'm concerned about are the pp/powerpacker_lib.i and pp/ppbase.i files.  We've solved the other Devpac standard library includes and the ones for +comp.s are (I think?) irrelevant as that file only seems to be there for comparison with the +apcomp.s replacement for V2.0 (both assembled to apcmp).

[james666]

We are also missing the source for Editor_DBL.bin, which is inserted (via Insert_DBL.AMOS) into AMOSPro_Editor_Resource.Abk.  I couldn't get your DBL editor to read it from a memory bank but the plain text is visible in the binary so I think we can reconstruct it.