Print

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

[bruceuncle]

Check line 4541 of +Lib.s.  It's illegal !        :

* Charge le fichier
   Rbsr   L_SaveRegs
   illegal
   move.l   Handle(a5),d5
   move.l   a0,d6
   move.w   #32767,d7
   Rbsr   L_IffFormLoad
* Ferme le ficher


I still couldn't get a byte-for-byte match on AMOSPro.Lib so I checked the differences.  After a bit of disassembly and matching with the +Lib.s source, I found the culprit in that line.  It's not in the executable (and I can't see why it would be unless someone was using the illegal trap vector for some sort of debugging?)

After removal I get an exact match.

So be wary if you can't get an exact byte-for-byte match to the AMOS Pro executables that were distributed as AMOS Pro V2.0.  You'll obviously get mismatches if you've been using some patched libraries.  But the originals are our yardstick.

I'm checking all the others myself and will publish the results and any corrected sources when completed.  Any corrected sources will be commented and have some marker - I'm yet to decide on what searchable string to use for this .

There's another which is more obvious.  I came across it while figuring out which are the essential files and which are there only for debugging or comparison with sources from previous versions.  Again, will publish the list when completed.

In +interpreter_config.s lines 127 & 128:

; Liste des 26 extensions
; ~~~~~~~~~~~~~~~~~~~~~~~
      EdT   16,<AMOSPro_Music.Lib>
      EdT   17,<AMOSPro_Compact.Lib>
      EdT   18,<AMOSPro_Request.Lib>
      EdT   19,<>
      EdT   20,<>
      EdT   21,<AMOSPro_IOPorts.Lib>
      EdT   22,<>
      EdT   23,<>
      EdT   24,<>
      EdT   25,<>
      EdT   26,<>


The <AMOSPro_3D.Lib> and <AMOSPro_Compiler.Lib> entries are missing.

I'm taking this as a priority task as otherwise we all run the risk of distributing bug-fixed executables with built-in bugs  .  So expect the results in the next coupl'a days or so (household chores permitting!).

[james666]

Quote from the "Extension_Readme.asc" file on the original AmosPro Tutorial disk:

Note, you can easily debug you code by placing an "Illegal" in your code. This will stop AMOSPro and you can then press [Amiga]+[A] to flip back to the workbench display. This works because Amiga-A is handled by interrupts.

[bruceuncle]

Quote from the "Extension_Readme.asc" file on the original AmosPro Tutorial disk:

Note, you can easily debug you code by placing an "Illegal" in your code. This will stop AMOSPro and you can then press [Amiga]+[A] to flip back to the workbench display. This works because Amiga-A is handled by interrupts.

Thanks james666.  That also explains why the DBL instruction - ILlegal - just jumps to an illegal.  I wondered how they went about debugging DBL code! 

The message I'm trying to send to everyone is just to take care that the source they're using is 'clean'.  The state of the sources strongly suggests that they've been used for debugging and may not always match the released version exactly.

What I'm doing in this task is a "CSI Amos" on the sources.     What makes up each AMOS Pro executable?  What's the dependency structure? What is manually edited?  What is generated by tools?  Any duplicated Symbols that might cause problems? What's the minimum to make the components for a complete AMOS installation.  What's missing?  Anything else I can think of that we may need to use to both bug-fix and enhance with confidence. 

[james666]

What I'm doing in this task is a "CSI Amos" on the sources.     What makes up each AMOS Pro executable?  What's the dependency structure? What is manually edited?  What is generated by tools?  Any duplicated Symbols that might cause problems? What's the minimum to make the components for a complete AMOS installation.  What's missing?  Anything else I can think of that we may need to use to both bug-fix and enhance with confidence.

Makes good sense.  For my hacking experiments I've found it helpful to create a simple makefile (executed with the SAS C smake utility) that tracks changes in the includes, reassembles as necessary and copies the resulting binaries to the right places.  My current version (not yet complete) looks like this:

#
# SAS smakefile
#

#Output binaries and destination paths:
AP=   sys:amos_pro/
APS=   $(AP)apsystem/
OBJS=   $(AP)amospro $(APS)amospro.lib $(APS)amospro_editor libs:amos.library\
   $(APS)amospro.lib $(APS)amospro_compact.lib

#Core include files:
INCS=   amos_includes.s equ.s debug.s cequ.s lequ.s wequ.s version.s

all:       $(OBJS)

$(AP)amospro:   $(INCS) b.s verif.s internal_jumps.s
      genam FROM b.s TO $(AP)amospro

libs:amos.library: $(INCS) w.s ReqPic.bin wfont.bin
        genam FROM w.s TO libs:amos.library

$(APS)amospro.lib:   $(INCS) lib.s lib_size.s Toktab_Verif.Bin ilib.s Dialog_Funcs.Bin
      genam FROM lib.s TO $(APS)amospro.lib
      
$(APS)amospro_editor:   $(INCS) edit.s
      genam FROM edit.s TO $(APS)amospro_editor

$(APS)amospro_compact.lib:   $(INCS) compact.s compact_size.s compact_labels.s
      genam FROM compact.s TO $(APS)amospro_compact.lib      

clean:
      @delete $(OBJS)

This is much more convenient than executing all those axxx scripts in the right order.