@Bruce - have you got the code for GetChunk? lol
I never bothered with GetChunk (it's compiled AMOS, so disassembly would be a nightmare!). I use Resource's binary save function:
- When Resource opens, select the load file from which you want to extract the binary. If you're already in Resource, select 'P/Open load file' from the menu.
- Set the data type as word (use <Left Amiga>+<W> - gets rid of the clutter).
- You'll already be at the start of the file, so select 'SV/Partial save/Set start' from the menu.
- Go to the end of the file (use <Alt>+<DownArrow>). If it's a long file, Resource may whir away for a few seconds as it examines the rest of the file.
- Check exactly where the end is. This is necessary as load files are always multiples of 4 bytes long. So there may be a few null bytes of padding at the end. (That's the reason I usually assemble the load file with a longword defining the length at the start so's I can check what the exact length is supposed to be. If you do that, skip the four bytes at the start with <Shift>+<RightArrow) four times before setting the start as above.)
- If there are padding bytes at the end, use 'SV/Partial save/Set End'. This should be done at the byte following the end. Bear in mind that most binary inclusions in AMOS need to be word aligned. So you might need a single pad byte to achieve that. Some others (the Editor Config ones for example) ensure word alignments in the source where the 'incbin' directive occurs.
- If you needed to set start and end to get rid of a length longword at the start, or pad bytes at the end, select 'SV/Save binary image/Partial' from the menu. If the binary is an exact fit, you can ignore all the above and just use 'SV/Save binary image/All' instead.
Or you can knock up a quick AMOS Pro program to do the same thing:
- Open the load file to get its length, then close it.
- Reserve a bank of that length and use Bload to get the file into it.
- Leek() the longword 28 bytes from the start of the bank. This is the length of the binary in longwords. So multiply it by 4 to get length in bytes.
- Use Bsave to save the binary. Starting address is the start of the bank + 32 bytes. End address is that starting address plus the length you just worked out.
- This method will include any pad byes at the end. If you assemble the load file with a longword at the start to show exact length, Leek that value at position 32 and add four bytes to your start address for the Bsave.
@Bruce I must congratulation on rebuilding that data, I didn't know you'd done those bits as well, that's really great, and you know I know how difficult/impossible that was! 
That comes from having used Messysoft Access and VBA in many versions in my commercial career (+ Sybase, Oracle, etc.). Plus my all-time favourite Messysoft Windows text editor - CodeWright - which to quote a project manager from way back 'Is as accommodating as an old tart.' (apologies to anyone offended.) Plus my early hacking career on a forgotten machine called an Hitachi Peach with a Motorola 6809 cpu (everyone was into fruit back then) and of course an Amiga 2000 when it was released.
The original sources were parsed and stored in a database. This enabled the 'tidied up' sources to be output (with one bug, I forgot the 'OPT' directive, so its parameter is output as an EOL comment - never bothered to fix it as it's an obvious error when it's assembled). I also use Access (2010) for the Help Files rebuild. But more content work on that is shelved for a while until I get the rest of V2.10 out. It can output the files in the new format, but needs a lot more work on content. Thank goodness for VB6's Treeview OCX to sort the menu hierarchies out. At least I can see the Help Menus as intended rather than struggling with the flat view when the database was just supplying output for a manual.
And what on earth is a Git or a Github?
I got dragged into a Wintel environment far too soon for my own good (it did earn the money though
).
Attached is something you guys might find useful for the Editor analysis. It's a spreadsheet of the relationship between the Editor's jump table, the Editor's Config file Keys table, its Autoload table and the flags accompanying the Editor's jump table. I included the comments from the sources as indicators as to what was intended. If you pour over it in conjunction with +Edit.s, +Editor_Config.s and +Editor_Menus_Bin.s it shows how that lot work together. Some of the source comments need tidying up a bit, but you should get an idea of how it all works together. Essential if you're going to make any changes to menus or track down spare jump table entries to use.
NOTE - I've already grabbed slots 170 & 171 for scrolling the Editor using a Wheel Mouse, and slot 184 for the Syntax Highlighting menu item.
Author
Topic: Where has the AMOS source gone? (Read 20126 times)