Print

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

[MadAngus]

Alrighty folks :

Now that the source has been released it is now time to get it into a source repository and versioning system. This will help alleviate the potential confusion that multiple development streams can have without some root repository.

The two main repositories are Google and SourceForge, there are however others, also which versioning system to use SVN, GIT, HG, CVS. A decision on this should made ASAP.

For the release/build versioning I would recommend a system already defined rather than expending the time and effort creating a new one. One example is the Eclipse.org system defined in Eclipse.org Version Numbering document.

Whatever repository the code is placed in a project name is required. This name should cover the ClassicAMOS development and the eventual AMOS 3.x branch. Think of one!

Only the core developers will have write access to the repository with everyone else given anonymous read only access.

Q:
Who will create the repository and be the repository manager/maintainer. (Not me)

@ghizzo
A written licence would be preferred for use in the repository and to be distributed with the source. It could be based on the BSD licence modifyed to specify that the code and compiled binaries can only be used for non-commercial purposes and include a copyright statement specifying the copyright holder. This licence could be called the
AMOS Public Licence (AMOSPL).

What do you think?

NotE: For the core developers and the repository manager/maintainer
All source modules from the original release should have a header added stating the licence and copyright holder. This will ensure there in no confusion between the original code modules and any additional code modules.

[bruceuncle]

Good thinking.

My biggest worry is the mayhem that may ensue from multiple developers working on AMOS.  It's not exactly well partitioned.  The library format and 'relocatable building bricks' do give some natural partitioning, but there is close coupling between a lot of the 'bits'.

Stage 1:  AMOS Pro V2.0 as released and fully documented
Stage 2:  AMOS Pro V2.1 with bugs fixed and updated docs
Stage 3:  AMOS Pro V2.2 with approved extensions and updated docs
Stage 4:  AMOS Pro V3.0 for AGA and fully documented

For V2.0.x versions, would suggest an approach of:

• First exploration of the sources to be with a view to mapping the dependencies.  Initially, only be concerned with code-module to code-module dependencies (i.e. file to file).
• Derive loose initial partitioning model based on existing architecture.
• At that point, decide whether bug fixing for V2.1.x versions (no enhancements - bug fixing only) is to be done within that existing architecture or whether it would benefit from any architecture changes.  Keep clearly in mind that the only reason that any re-architecting prior to V2.1 could be justified is if it assists bug fixing.  A clear set of bugs-to-be-fixed is essential before that judgement can be made.
• Either way, that model's probably about the best break up of what to version and where.
• In some ways, the restrictions imposed by what's already there will assist in deciding what can be changed:
  
  • None of the original equates can be touched as that would destroy compatibility with existing extensions.  Any new storage space or references for bug fixing will have to be an extension of that.  We can't change its existing structure.  This applies throughout all V2.x versions.
  • amos.library, similarly, cannot have its interface changed.  Any requirements will again have to be met by extending it.

I'm probably stating the bl**ding obvious above but it's essential that we all appreciate what the environment will be.

Any suggestions welcome as usual.

I'm unsure whether any work could proceed on the above before the docs phase V2.0.x is complete.  Maybe they could run in parallel if anyone's keen to get their hand dirty.   

[Lonewolf10]

My biggest worry is the mayhem that may ensue from multiple developers working on AMOS.  It's not exactly well partitioned.  The library format and 'relocatable building bricks' do give some natural partitioning, but there is close coupling between a lot of the 'bits'.

It is going to be difficult to fix/add everything that has been mentioned in "the plan" without multiple people working on it. I think everyone should have their own source files, comment out (with ; or a *) uneeded code and stick all new code within "asterisk fields", e.g.:

Code: [Select]

   dc.b "Original code here..."
*****\
   dc.b "New code here..."
*****/
;   dc.b "Commented out code"

I used string fields just to make it all clear
I only recently started using what I have dubbed as "asterisk fields" whilst debugging my current AMOS project (Tile Master). It makes seeing original code and new code easier to spot.

Once something has been fixed/added, it can then be added to the master code (a separate set of files only available to one person?). That would avoid possible confusion with multiple people working with the same files.

[bruceuncle]

It is going to be difficult to fix/add everything that has been mentioned in "the plan" without multiple people working on it. I think everyone should have their own source files, comment out (with ; or a *) uneeded code and stick all new code within "asterisk fields", e.g.:

Code: [Select]

   dc.b "Original code here..."
*****\
   dc.b "New code here..."
*****/
;   dc.b "Commented out code"

I used string fields just to make it all clear
I only recently started using what I have dubbed as "asterisk fields" whilst debugging my current AMOS project (Tile Master). It makes seeing original code and new code easier to spot.

Once something has been fixed/added, it can then be added to the master code (a separate set of files only available to one person?). That would avoid possible confusion with multiple people working with the same files.

It's going to be a tricky probelm to control.  I like the idea of using a consistent 'marker' to highlight changes with 'original code' commented out.  I use that technique a lot in VBA and VB.NET (wash my mouth out!).

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 mentioned here:
http://www.ultimateamiga.co.uk/index.php/topic,9520.msg44972.html#msg44972
that at least +w.s is corrupt.  Looks like a fix is half-way programmed in it (?).

So I've self-delegated the task of reconstructing it from the amiga.library load file in conjunction with the +w.s source.  And translating the Frech comments as I go.  It's a lot easier than it sounds using Resource and the symbol files I posted here:
http://www.ultimateamiga.co.uk/index.php/topic,9604.msg44953.html#msg44953
Resource tells me I'm 10% of the way through it.

Has anyone else looked at the other sources yet for completeness?

Other bits of interest:

• I've databased the sources in Access 2010.  That process at least proved to me that all the sources are syntactically correct.  (The +w.s problem results from missing labels, not syntax errors.)  The database table just holds these fields:
  
  

  fld_source	Arbitrary primary key
  fld_file_name	Source File Name
  fld_line number	Line Number
  fld_line_text	The original source text with tabs expanded to spaces
  fld_is_full_line_comment	Is this line a full-line comment?
  fld_is_eol_comment	Does this line have an end-of-line comment?
  fld_label	ASM Label field
  fld_instruction	ASM Instruction field
  fld_operands	ASM Operands field
  fld_comment	ASM Comment (eol or full-line)
  fld_comment translated	Empty - any translators out there?

• Dug up two new DBL instructions (ILlegal and BLock).  And noticed that I'd missed ArrayRead from the AMOS Pro V2.0 Interface Summary.  So I'll publish the next revision when I get around to it.  The new instructions are only really useful to an AMOS Pro developer (Hey!  That's us!) for debugging.
• The AMOS Pro V2.0 AMAL Summary is still where it was a while back.  There were a few questions I needed answering involving the effects of the relationships between Channel Numbers, Hardware Sprites and Computed Sprites.  Should be easy to resolve now I've got some source to wade through.  Also have to finish the AMOS Basic AMAL instructions.
• The AMOS Pro V2.0 Reference Manual is still ongoing and all the stuff I'm finding out is going in there bit by bit.  There's still a lot to be re-written (the original AMOS Help text was invaluable but not suitable for publication).

So that's all the other stuff that's going on in conjunction with these sources.

I need a few days to re-group.  Then I'll post what I think would be a suitable plan of attack.  The first step will most likely be a matching of source files to the AMOS Pro file set...

[Lonewolf10]

Has anyone else looked at the other sources yet for completeness?

No
I glanced at some of the files after downloading the source, but have been tied up with other stuff ever since. I'm unlikely to have free time for a while, but will try to have a look at the "+w.s" file.

[Lonewolf10]

I mentioned here:
http://www.ultimateamiga.co.uk/index.php/topic,9520.msg44972.html#msg44972
that at least +w.s is corrupt.  Looks like a fix is half-way programmed in it (?).

It doesn't look corrupt to me. I tried assembling it and found these files

Code: [Select]

Include "layers_lib.i"
Include "graphics_lib.i"

weren't with the other files, but I did find them in the includes files that came with DevPac 3.18

However, some of the variables used to define some other variables in the WB OS includes files are missing, and those are what appears to be generating the errors when assembling.
The problem with the way the code is written is that sometimes code references/jumps to code found in other files and can make it very hard to follow.

Can I suggest that you add the Includes files into your references (e.g File "A" requires files "B","C" etc.) and perhaps build a tree so it's easy to see which files are required to attempt to reassemble the sourcecode?

[bruceuncle]

I mentioned here:
http://www.ultimateamiga.co.uk/index.php/topic,9520.msg44972.html#msg44972
that at least +w.s is corrupt.  Looks like a fix is half-way programmed in it (?).

It doesn't look corrupt to me. I tried assembling it and found these files

Code: [Select]

Include "layers_lib.i"
Include "graphics_lib.i"

weren't with the other files, but I did find them in the includes files that came with DevPac 3.18

However, some of the variables used to define some other variables in the WB OS includes files are missing, and those are what appears to be generating the errors when assembling.
The problem with the way the code is written is that sometimes code references/jumps to code found in other files and can make it very hard to follow.

Can I suggest that you add the Includes files into your references (e.g File "A" requires files "B","C" etc.) and perhaps build a tree so it's easy to see which files are required to attempt to reassemble the sourcecode?

Thanks for the excellent feedback Lonewolf10.  So far, I've only actually assembled the equates files to derive symbols for Resource to use.  This stuff is coming from chasing a few AMOS Basic instructions up for the Reference Manual.  I found this particular problem checking whether AMOS Memory Banks are cleared when they're created (they are).  So, accepted that there are symbols and labels all over the place.  That's not what I'm referring to.

Examples from the +w.s file:

Line 9,983 onwards is part of the jump table for system functions in amiga.library:

   bra   ChipMM         ;55-SyChip:    Reserve CHIP
   bra   FastMM         ;56-SyFast:    Reserve FAST

You won't find those symbols as destination labels anywhere in the sources nor the Amiga Includes directory and sub-directories.

A little further on, you'll find their 'replacements' at line 10,020:

   bra   WMemFast      ;92-MemFast      
   bra   WMemChip      ;93-MemChip      

There are a few other labels in that jump table that seem to be both 'legacy' and 'current'.

Exploring a bit further, the only mention of these 'legacy' labels elsewhere is in the Monitor (+monitor.s) where they're used as parameters to a macro.  So you see a somewhat different subroutine call table that look like this at line 905:

   bsr   TT_SPatch   ChipMM      ;55- Reserve CHIP
   bsr   TT_SPatch   FastMM      ;56- Reserve FAST

That macro is at line 953:

;   Patch systeme normal...
; ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
TT_SPatch
   move.l   a0,-(sp)
   move.l   4(sp),a0
   sub.l   T_SyVect(a5),a0
   subq.l   #4,a0
   add.l   Old_SyVect(pc),a0
   move.l   a0,4(sp)
   move.l   (sp)+,a0
   rts

I haven't gone any further than that yet as I'm overloaded to blazes with other stuff right at the moment (violin screeches in background  ).  But it looks suspiciously like a remapping of jump tables.  At first I thought Pre-Pro and post-Pro perhaps?  But more likley would be Monitor and Interpreter maybe.  (And, as a relative newcomer returning to 68000 assembler after 20 years, I like the cute way of getting at the macro parameter...  .)

Anyhow.  Surely +w.s won't assemble unless those symbols are resolved?  And a few others in that jump table - mainly to do with memory management.  So what I'm doing with a few percent of my head's multi-processor time is reconstructing the +w.s source from the amiga.library load file (V2.0 - straight out the box) to see what they resolve to when I get that  far.

I've also already plonked all the sources into that database I mentioned earlier in this thread:

Other bits of interest:
•I've databased the sources in Access 2010.  That process at least proved to me that all the sources are syntactically correct.  (The +w.s problem results from missing labels, not syntax errors.)

That will let me build that 'tree' you mentioned.  Time is the biggest problem at the moment though.  I've got to get some other stuff completed and published before I chase all these other bits up.

If you want to have a go at the task yourself, drop me a PM and I can get a copy of that database to you.  What we need are:

• "Which source goes with which AMOS component?"  E.g.  +w.s = amiga.library; +lib.s = AMOSPro.Lib;  etc.  A spreadsheet would do.
• Then, knowing what's what, move into "Which of these will assemble ok 'as is'".  Most should if they've got the correct includes in them.  Also, bear in mind that Francois used his own equates for Amiga library functions(??!)  So you won't get a direct correlation to an Amiga Includes symbol.  Though most use the same symbol name just to confuse things! But they will always be in +equ.s.  That's the file I used to generate the user-defined Resource symbols files from and they're working spot-on so far in +w.s.  Again, a spreadsheet would do for the results.  If you have to change any of the original sources to get them to work, keep them separate and just note what's needed.  What we're after is info at this stage.  Then we can plan the changes under source-code version control.
• The objective is to reproduce AMOSPro V2.0 byte-for-byte, as it came 'out-of-the-box', from these sources plus whatever else is necessary to make that happen.
  
• Document the above.  As suggested, spreadsheets would do.  I can database those and relate them to the sources already there.  Then start to build the 'big picture' out of that database.

If you do manage to get some load files out of them and want to compare them with the original load files, I've also got a powerful differencing tool that does the job if you don't have anything yourself.  Just send 'em back to me.  Unfortunately, it's Windows platform and it's part of a commercial package I've used for years and, although it's been abandonware for a while now, it's still copyright.  So unless I can get permissions from the copyright owners, I can't exactly give it away.

As you've probably gathered by now, I'm insisting that this all gets databased.  It provides an organised storage for what we're doing.  It's the initial code repository until we come up with something better.  And I've many, many years of working magic with MS Access (wash my mouth out, etc, etc) from Version 1.0 through to 2010.  So I can pull out just about any query results we may need for this project that way rather having to deal with text source files.  As a side benefit, if anyone wants to volunteer a bit of French-to-English translation talent, all the comments have already been isolated in that database...

The Resource user-defined symbol files I mentioned above, and a bit more info are here http://www.ultimateamiga.co.uk/index.php/topic,9604.msg44953.html#msg44953

I'm off to try assembling +w.s to see if I'm fooling myself or not.  But I thought I'd better put you in the picture first  .

[bruceuncle]

I should have mentioned in that previous post that there's a personal agenda in this Resource reconstruction of amiga.library.

I've always found the best way to get to 'know' a piece of software is to pour over the sources.  Using Resource forces me to do this in an intense way that means I'm getting a good grounding in how it all works and hangs together.  With amiga.library being the interface to both the Amiga libraries and direct hardware access (tut, tut, but faaast) it's the logical one to start with.  It's also forcing me to translate all the French comments as I go.  And, although my French is pretty pathetic schoolboy standard, the context in the code usually makes it a lot easier.

[bruceuncle]

I'm off to try assembling +w.s to see if I'm fooling myself or not.  But I thought I'd better put you in the picture first

I just tried that after kicking the includes into shape.  The layers_lib.i and graphics_lib.i are a bit of a mystery as I can't find them anywhere.  However, leaving them out completely allows some checking by GenAm.

More of a mystery to a novice like me is all the errors then thrown up for bit manipulation instructions on address destinations.  The 68000 only allows bits 0 - 7 unless the destination is a register.  But this source has quite a few that break that.  E.g. at line 275:

ColRW:   bsr   BlitWait
   btst   #13,DmaConR(a6)
   rts

That's one that's hard-coded in the source which makes the example obvious.  Most of the others are bit-number symbols in +equ.s (BitBobs, etc).  I also had to turn on case insensitive as some symbols don't follow case sensitivity rules, which is a bit of a worry.

As I said, I'm to be considered a novice in 68000 assembler and using DevPac.  So, am I missing something?  Help!!

[bruceuncle]

I'm off to try assembling +w.s to see if I'm fooling myself or not.  But I thought I'd better put you in the picture first

I just tried that after kicking the includes into shape.  The layers_lib.i and graphics_lib.i are a bit of a mystery as I can't find them anywhere.  However, leaving them out completely allows some checking by GenAm.

More of a mystery to a novice like me is all the errors then thrown up for bit manipulation instructions on address destinations.  The 68000 only allows bits 0 - 7 unless the destination is a register.  But this source has quite a few that break that.  E.g. at line 275:

ColRW:   bsr   BlitWait
   btst   #13,DmaConR(a6)
   rts

That's one that's hard-coded in the source which makes the example obvious.  Most of the others are bit-number symbols in +equ.s (BitBobs, etc).  I also had to turn on case insensitive as some symbols don't follow case sensitivity rules, which is a bit of a worry.

As I said, I'm to be considered a novice in 68000 assembler and using DevPac.  So, am I missing something?  Help!!

"All projects fail because of assumptions!"

I should nail that to my forehead perhaps .  The wild goose chase I've been on about missing symbols is because I assumed that the AMOS team were using case-sensitive symbols and labels.  Not so.  Which is a bit of a worry.

More concerning is that 'illegal' bit number referencing for memory location destinations.  The 680xx bibles quite clearly state that only values of 0 thru 7 are allowed unless the destination is a register.  So I examined the structure of the instruction in that example I quoted in the amiga.library load file:

ColRW:   bsr   BlitWait
   btst   #13,DmaConR(a6)
   rts

The result in hex is:  $082E 000D 0002

Translating that back to assembler opcodes and adressing modes is as follows:

$082E = %0000 1000 0010 1110

Rearranged as an opcode:

Bit Number:   15 14 13 12 11 10  9  8  7  6  5  4  3  2  1  0
Value:         0  0  0  0  1  0  0  0  0  0  1  0  1  1  1  0
Meaning:      <----------btst-------------> <-Effective Addr>
                                            <-Mode-> <-Reg--> 

Mode:     %101 = "Address register indirect with displacement".
Register: %110 = A6.


The two words following the opcode are  $000D 0002
These give the bit-number on which to operate ($000D) and the displacement offset for the addressing mode ($0002)

So the bit number is 13 (illegal!) and the displacement is 2.

Despite the bit-number being out of the 'legal' range of 0 thru 7, the 68000 seems to accept this as OK! 

So how did they manage to assemble that source?

I looked at the GenAm file supplied with the sources and it's V3.2.  Mine's V3.18.  Time to make a new instance of DevPac to test out my suspicions.  Sure enough, after the usual messing about getting the includes recognised in a new location, it compiled fine.  Incidentally, those graphics_lib.i and layers_lib.i files were missing from my V3.18 includes.  So I substituted a genuine WB 2.0 set and there they were.

The resulting load file doesn't match the AMOS Pro amiga.library 'out-of-the-box' file.  But a quick differencing showed these all seem to be relative address offset differences.  I haven't checked yet (here I go again) so I'm assuming that's just because I haven't set an optimal offsets option somewhere in DevPac.  So branches without a specific offset size (e.g. just bra instead of bra.s, etc) aren't being optimised to the same values as in the load file.  Checking that would take some time so I'm shelving that investigation until later.

Conclusion (and this is critical guys!)

You need the version of GenAm that comes with the sources to assemble any of this stuff as that version has been hacked to assemble those bit instructions with 'illegal' bit-numbers.

And does anyone have any idea what the files GenAm2 and GenIm2 do?

[bruceuncle]

I looked at the GenAm file supplied with the sources and it's V3.2.  Mine's V3.18. 

Scrub that.  That's the file version reported by DOpus.  It's actually version 3.02 - the original version, unhacked and untouched.  So that must have been a bug in V3.02 of GenAm.

Next questions.  Looking back at the source from V1.23, these operations were originally done using registers for the bit operations (along with absolute addresses, etc).  So the bit numbers were 'legal' as bits 0 thru 31 can be specified for a register destination.  In converting that to fully relocatable code, did the AMOS team just use the original bit numbers and not realise that their assembler would swallow them without protest?  Although the processor doesn't protest, is it a legal operation (does the correct bit respond)?  Is this a source of some AMOS bugs?  What am I doing chasing all this up when I should be doing other stuff?     Watch this space...

[bruceuncle]

Just can't keep away from this thread .

When the processor encounters one of these 'illegal' bit-number values, it wraps it into the range 0 thru 7 of whatever's specified in the bit-number word.  Note it wraps it (modulo 8 ) .  It does not mask it.  It then uses the result on the byte pointed to by the destination effective address.

So, in the example I've been using so far, that bit-number of 13 ($D) modulo 8 results in 5.  The bit-numbers are counted from zero so specifying bit-number 13 for a btst operation would actually refer to bit number 5 and give the result $20 (%0010 0000).  As it follows a blitter operation, the bit to be tested probably was bit-number 13 (DMAB_BLTNZERO in hardware/dmabits.i) and not bit-number 5 (DMAB_SPRITE in hardware/dmabits.i) which is what it actually does.

Getting back to the AMOS sources in general, as far as I can tell so far, other bit-numbers affected range from 8 thru 15 (in +equ.s):

*************** Test control bits
BitControl:   equ    8
BitMenu:      equ    9
BitJump:      equ    10
BitEvery:     equ    11
BitEcrans:    equ    12
BitBobs:      equ    13
BitSprites:   equ    14
BitVBL:       equ    15

Which will yield 'legal' values of 0 thru 7.  The memory address referred to is a word at address T_Actualise(a5) .  So any bit operations on that address will be performed on the high byte.  Which may not be what was wanted. 

Interesting.   

Now I really will get on with some other stuff.

[Lonewolf10]

"All projects fail because of assumptions!"

I should nail that to my forehead perhaps .  The wild goose chase I've been on about missing symbols is because I assumed that the AMOS team were using case-sensitive symbols and labels.  Not so.  Which is a bit of a worry.

I should have spotted that. When I assembled my amiga demo (in 2011 and 2012) I always turned case-sensitivety off, as it's too easy to mistype a label in terms of upper/lower case.

I looked at the GenAm file supplied with the sources and it's V3.2.  Mine's V3.18.  Time to make a new instance of DevPac to test out my suspicions.  Sure enough, after the usual messing about getting the includes recognised in a new location, it compiled fine.  Incidentally, those graphics_lib.i and layers_lib.i files were missing from my V3.18 includes.  So I substituted a genuine WB 2.0 set and there they were.

The resulting load file doesn't match the AMOS Pro amiga.library 'out-of-the-box' file.  But a quick differencing showed these all seem to be relative address offset differences.  I haven't checked yet (here I go again) so I'm assuming that's just because I haven't set an optimal offsets option somewhere in DevPac.

Don't assume anything!

Does Pietro (Ghizzo) remember whether the sources are before or after the fixes he did?

Conclusion (and this is critical guys!)

You need the version of GenAm that comes with the sources to assemble any of this stuff as that version has been hacked to assemble those bit instructions with 'illegal' bit-numbers.

And does anyone have any idea what the files GenAm2 and GenIm2 do?

I'm not sure that GenAm has been hacked. I have seen plenty of codes before that also test for illegal bits.
GenAm2 and GenIm2 are part of the files from DevPac 2. I will try to look up what they do as my memory is hazzy right now (down to the fact I'm damn sleepy!) and I haven't used DevPac2 for a few years now.

[bruceuncle]

I'm not sure that GenAm has been hacked.

No it hasn't.  My apologies if that post mislead anyone.  It's just GenAm V3.02, not the 3.20 that DOpus reported (see a couple of posts back in this thread where I'd just realised what I was doing wrong).  And that version will let these bit-numbers through without an error.

So, in the example I've been using so far, that bit-number of 13 ($D) modulo 8 results in 5.  The bit-numbers are counted from zero so specifying bit-number 13 for a btst operation would actually refer to bit number 5 and give the result $20 (%0010 0000).  As it follows a blitter operation, the bit to be tested probably was bit-number 13 (DMAB_BLTNZERO in hardware/dmabits.i) and not bit-number 5 (DMAB_SPRITE in hardware/dmabits.i) which is what it actually does.

Those 'illegal' bit-numbers are a bit more of a problem.  Not so much the values used, as the processor will always do the modulo/mask to get them in the correct range.  The problem is that the destination address is sometimes a word, not a byte.  So the processor will hit the high byte of the word when the low byte may be what was intended.

In most cases that won't matter too much because the result will be consistent if the equates are used each time.  And bit 13 is bit 5 for the high byte of a word address, so no damage done in theory if it's just data storage memory.  However, in practice, the usage is scrappy and that hardware address example I gave points out the problem.

It's worth scanning through the 1.23 and 1.3 sources to see what they were doing there.  They used data registers for the hardware address bit-number operations back then.  So they hit the correct bits.  Obviously, hitting the wrong bits for hardware addresses could be a disaster at worst or an intermittent bug at best.

I've attatched a quick grep across the sources for a symbol called T_Actualise to illustrate the sort of things to look out for.  T_Actualise is a negative offset from A5 used to store a few flags.  It's defined as a word size.  You'll see that someone programming the editor realised the mistake and subtracts 8 from the flag values  .  But there's also a lot of simple testing of the byte at that address.  Again, that's ok as it will be the high byte of the word so no damage done.  There's some word-sized movement back and forth to data registers which looks like it's just preserving the value.  Again, no serious damage.  But you can see the potential if the data register then has low byte bits set and tested while it's sitting in a data register...

It's just something to bear in mind as we review these sources with an eye on bugs.  And it's why I'll continue the Resourcing of amiga.library.  So I can see if there is any real difference (other than branch offset sizes) between the source and the load file.  But don't expect that to be completed any time soon as there's too much else to be completed before I seriously get into these sources (hysterical laughter as the men in white coats chase me again while I ponder the word 'understatement' ).  I'd always thought semi-retirement would give me more time but it just seems to keep filling up  .

Postscript:  I'll try to stop assuming.     Please regard these posts as "thinking out loud".      And they're in the wrong thread anyway. 

@MadAngus, can you be persuaded to move them to the Source Code Reviews and Comments thread here:
http://www.ultimateamiga.co.uk/index.php/topic,9604.0.html
when you've got some time?  (You can borrow my men in white coats if yours are getting a bit worn out.  They come with a lifetime supply of dried frog pills and a complimentary set of steak knives...  )

[Lonewolf10]

And does anyone have any idea what the files GenAm2 and GenIm2 do?

GenAm2 and GenIm2 are part of the files from DevPac 2. I will try to look up what they do as my memory is hazzy right now (down to the fact I'm damn sleepy!) and I haven't used DevPac2 for a few years now.

Ok, just looked them up. In the version of DevPac 2 I have they have the following sizes:

GenAm2 - 23,684 bytes (23.1K)
GenIm2 - 29,104 bytes (28.4K)


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).