Amiga.org
Amiga computer related discussion => Amiga Marketplace => Topic started by: nicholas on January 22, 2017, 10:01:29 PM
-
Pristine condition, and rarely on the market.
70GBP, PayPal gift + postage costs.
Will ship anywhere.
-
Bargain price given its rarity. Hope it goes to a good home!
-
Bargain price given its rarity. Hope it goes to a good home!
Did I say 70? I meant 700. ;)
-
English version? What's the condition like?
-
This book is only good for developers right ?
-
English version? What's the condition like?
English version and absolutely pristine.
-
This book is only good for developers right ?
You'd be a developer after reading it ;)
-
You'd be a developer after reading it ;)
If you understand what Ralph is telling you :rofl:
-
Isn't there a digital version included on the ADCD 1.2?
-
Isn't there a digital version included on the ADCD 1.2?
No. This includes electronic versions of the RKRMs, IIRC. However, the RKRMs have no section on the dos.library, which is covered in the ADos Manual from Bantam books. Well, sort-of - it's a lousy source with little information whatsoever.
-
You'd be a developer after reading it ;)
I wished I had instant ASM powers as well. :P
-
I wished I had instant ASM powers as well. :P
:)
No one interested? I'm saddened, probably a sign that there's only consumers left in the scene mostly now. :'(
-
Might help if you cleared out your PM drawer?
I would buy it, but there is a problem if it is what I want. The full version.
Ralph Babel saved my ass back in the day. I am not about to disrespect him now by buying a copy of his work, not without him getting a cut.
I doubt he remembers talking, but a couple times when I had an issue reviewing GVP kit, he was at the end of a phone ready to talk me through it. He did that for a lot of journalists and end users at the time, I remember.
I think I will buy the German version and struggle with that instead.
Nothing personal here, but that's the way I feel.
-
Might help if you cleared out your PM drawer?
I would buy it, but there is a problem if it is what I want. The full version.
Ralph Babel saved my ass back in the day. I am not about to disrespect him now by buying a copy of his work, not without him getting a cut.
I think I will buy the German version and struggle with that instead.
Nothing personal here, but that's the way I feel.
You've lost me.... Eh?
-
AFAIK R Babels book, the 700 odd page one, was withdrawn from publication in English, but was published in German. Am I wrong about that?
-
AFAIK R Babels book, the 700 odd page one, was withdrawn from publication in English, but was published in German. Am I wrong about that?
FWIW he mentions it briefly at the bottom of this page:
http://babel.de/amiga.html
-
Assuming the book wasn't stolen, Ralph already made his money. You've never bought anything used before?
-
Im actually really curious with whats in the book ? just want to see what the fuss is all about.
-
AFAIK R Babels book, the 700 odd page one, was withdrawn from publication in English, but was published in German. Am I wrong about that?
Yes. There are two editions of the book, the first edition was in German, and the second - extended and reworked edition - in English. If possible, get the English version, it covers more material and is a bit more up to date.
-
Im actually really curious with whats in the book ? just want to see what the fuss is all about.
It is a very good manual on the interfaces and data structures of - in particular - the dos.library. It covers many of the dark areas the Bantam Books "Amiga Dos Manual" should have covered, but did not. It is rather hard to write a robust file handler or dos handler without this book because the "Dos Manual" (aka "Tripos Manual") fails to cover so many important aspects.
In addition, it also includes some details about the processors, command line options of the Aztec and the (back then up to date) Lattice 5, and exec internals like the kick mem and resident tags.
If you want to do some serious programming on the Amiga, especially in the dos area, it's highly recommended.
It would require some updating here and there (the 68060 is not discussed because the book predated the processor, there is nothing on the MMU, there is nothing on the SAS/C 6 for the same reason, and there are - here and there - a couple of very minor mistakes that slipped through).
There was never a newer edition because some freak had nothing better to do than to pirate the book and provide a copy in PDF in the net, which resulted in Ralph quitting the project. Thanks, folks!
-
There was never a newer edition because some freak had nothing better to do than to pirate the book and provide a copy in PDF in the net, which resulted in Ralph quitting the project. Thanks, folks!
That bit I'm confused at. His website states that he stopped publication a few days before the due date and withdrew the English edition from sale to suppliers. The German edition went ahead...
... So it's not that the 2nd edition wasn't ever printed in English, just that the books didn't hit the open market. The German ones did, but are all sold out now anyway.
As for "The AmigaDOS manual", I think the Bantam books one was done by Mark Smiddy? I don't think the intention was for it to be a developer resource, but rather a public resource. There was a clear distinction at the time, so I doubt he could access material on the DOS Library, or a lot of other developer issues. He certainly was not happy at gaps in the content, but I doubt he ever really thought it would be used as a resource for development. Maybe he did and I just didn't notice.
I never pointed developers at Mark Smiddy's book, it was for end users trying to find a definitive reference for just using the Amiga. I pointed them at the RKM and CATS and said "They know. I don't, and they can't tell me." For software, anyway. For hardware I pointed people at the HRM.
I didn't know anyplace else to point them, and the web didn't exist. The internet did, but I didn't have any kind of access to it, and was dimly aware of things like Compuserve and email addresses as things other people could use, but I didn't have much access to, for obvious reasons. I had no connections TO anybody by email, having zero university background. I could chat on BBS, that was about it.
-
That bit I'm confused at. His website states that he stopped publication a few days before the due date and withdrew the English edition from sale to suppliers. The German edition went ahead...
I do not remember that anything was withdrawn. You could get the English edition (2nd edition) for quite a while at "Schatztruhe", just that it is sold out by now. I have this at home, so there is nothing particularly secret about it. As said, the German edition is the first edition, and somewhat different in content, though I never owned it so I cannot tell you the differences.
As for "The AmigaDOS manual", I think the Bantam books one was done by Mark Smiddy?
I do not recall who the editor is, or was. Amazon lists CBM as author, though this is certainly not adequate.
https://www.amazon.com/AMIGA-MANUAL-Bantam-Amiga-library/dp/0553354035
I don't think the intention was for it to be a developer resource, but rather a public resource. There was a clear distinction at the time, so I doubt he could access material on the DOS Library, or a lot of other developer issues.
Actually, it is a developer resource as well. It does list all the entries in the dos.library, the packet types, the CLI and Dos structures, overlays and the FFS structures. Just not in the detail necessary you would need for high quality development.
That's mostly because the AmigaDos manual is more or less a copy-paste job of the "Tripos Manual". The books are really almost identical (in the earlier editions at least) except a sed -e "s/Tripos/AmigaDos/", and some details. Structures in Tripos were mostly identical (CLI, for example, is exactly the same thing, the filing system is exactly the same thing, packets were identical, most commands were identical).
Archive.org seems to have a copy:
https://archive.org/details/1986-metacomco-intro-to-tripos
so you can judge yourself.
-
Actually, it is a developer resource as well. It does list all the entries in the dos.library, the packet types, the CLI and Dos structures, overlays and the FFS structures. Just not in the detail necessary you would need for high quality development.
That's mostly because the AmigaDos manual is more or less a copy-paste job of the "Tripos Manual". The books are really almost identical (in the earlier editions at least) except a sed -e "s/Tripos/AmigaDos/", and some details. Structures in Tripos were mostly identical (CLI, for example, is exactly the same thing, the filing system is exactly the same thing, packets were identical, most commands were identical).
Archive.org seems to have a copy:
https://archive.org/details/1986-metacomco-intro-to-tripos
so you can judge yourself.
It is scary how much of the "Amiga" we know is actually Tripos!
-
AFAIK R Babels book, the 700 odd page one, was withdrawn from publication in English, but was published in German. Am I wrong about that?
The 1st edition was Das Guru Book, then the 2nd and slightly updated edition was in English as The Guru Book.
There was supposed to be a heavily updated 3rd edition around 10-ish(if memory serves me) years ago but a PDF of it was leaked to the internet so Ralph never published it sadly.
Mine is the second edition.
-
OK, that clears most things up. If nobody has paid cash to you in 1 week, I'll buy it. No postage, I'll be checking it with a loupe. You can have either cash or Paypal.
That gives me a chance to check into a few things - like I said, the guy treated me very well. Not just me, a helluva lot of people.
Oh yeah, the Mark Smiddy thing. He wrote something else, more of a users guide, handy for seeing when commands appeared and disappeared. "Mastering AmigaDOS", Bruce Smith books. My mistake.
https://openlibrary.org/books/OL12081193M/Mastering_AmigaDOS_3
-
There was supposed to be a heavily updated 3rd edition around 10-ish(if memory serves me) years ago but a PDF of it was leaked to the internet so Ralph never published it sadly.
The PDF on the internet wasn't leaked, someone scanned the 2nd edition book and uploaded it.
-
The 1st edition was Das Guru Book, then the 2nd and slightly updated edition was in English as The Guru Book.
There was supposed to be a heavily updated 3rd edition around 10-ish(if memory serves me) years ago but a PDF of it was leaked to the internet so Ralph never published it sadly.
I remember that; it was in 2008 and i did sign a petition to have it published anyway - to no avail as you can see now.
-
Yeah, I can see why that would upset him. Designers spend years getting pages looking right, good thick use of true colour, arrange things perfectly so there's depth in the visual presentation. Page layout is an art. So is technical writing, although maybe it doesn't look that way.
So, he spends years getting it looking just perfect, then some rotten so and so uploads a 256 colour scan that looks OK on a screen, and terrible when printed out in the real world. I'm fine with people doing similar with stuff I wrote, but I don't own copyright on that, and it wasn't that accurate to begin with. Ralph is way off the other end of the scale on Amiga technology. No wonder he was upset. Still is, by the sound of it.
I do use scanned works, but I scan them from originals I am interested in. I do not distribute them. I don't even leave them around on machines with internet access so they cannot be hacked. This is legal, they really ARE for personal study. And they are never as easy to use as a printed work.
I can guarantee you, it won't be in pristine condition by the time I'm done with it. That might sound like sacrilege of a holy relic, but books are tools, as well as beautiful objects.
-
Humorously, it was Ralph that popularized the PDF. It wasn't common knowledge until he ranted about it. As I recall, it's a quality scan and fully searchable. The content is black and white, so it's not like it needed to be anything other than greyscale anyway. Still, I'm sad
Ralph never published the third edition. The only winner was Ralph's ego.
-
Humorously, it was Ralph that popularized the PDF. It wasn't common knowledge until he ranted about it. As I recall, it's a quality scan and fully searchable. The content is black and white, so it's not like it needed to be anything other than greyscale anyway. Still, I'm sad
Ralph never published the third edition. The only winner was Ralph's ego.
Actually, from that stand-point it was more Ralph's ego which was a casualty. Everyone lost, including whomever did all the work to scan and distribute something which is not up-to-date (I don't want to say out-dated because obviously it's still useful.)
In any case, I have an English Guru Book and it's great reading. Even though I'm not a developer I have found it incredibly informative and helpful in understanding the how and why of Amiga.
-
You're right. I just never liked the "this will hurt me more than it hurts you" response. Personally, I stopped tinkering with Amiga software years ago. I'll get around to selling my kit eventually. I know the Blizzard 1260, SCSI kit, and Zorro IV+Mediator want a new home.
-
I've decided against selling it guys.
It still sits on the shelf alongside the other religious books. :)
-
Thank you for your honourable behaviour sir.
-
Just out of curiosity, imagining the 3rd edition became legally available (for sale or whatever), would that be of any use for AOS4 or MorphOS development ? I still got a few projects that I never finished that I'd like to one day...
-
It's a shame that the plug was pulled on the book, and I don't blame him. On the other hand though if I was able to download a pirated digital copy of the book (either the old English one or a new one) I would still buy a real copy because a book is a book in my opinion and not an image on a screen. Also, of course, to financially support an Amiga book is a reward in itself.
I wonder if a Kickstarter for a new edition would be successful? I'd like to think there's still enough interest out there to make it financially rewarding for Ralph, but it does seem as though he's washed his hands of it from what I've read.
:(
-
Just out of curiosity, imagining the 3rd edition became legally available (for sale or whatever), would that be of any use for AOS4 or MorphOS development ?
For that, the third edition still needs to be written. Or at least completed. From what I know (private communications) an update also covering 3.1 was planned, with a couple of extensions here or there. I somehow doubt that Ralph ever looked into AOS4 or Morphos, even though I cannot really tell.
-
Just out of curiosity, imagining the 3rd edition became legally available (for sale or whatever), would that be of any use for AOS4 or MorphOS development ? I still got a few projects that I never finished that I'd like to one day...
Not really, only in a loose general sense.
It's all about Amigas not those clones. ;)
-
Not really, only in a loose general sense.
It's all about Amigas not those clones. ;)
Who you callin' an clown Nik? ;-)
-
The PDF on the internet wasn't leaked, someone scanned the 2nd edition book and uploaded it.
Is there any chance of getting this chap or chapess named and shamed?
-
I've decided against selling it guys.
It still sits on the shelf alongside the other religious books. :)
One day, my eyes will look upon thy holly scripture.
-
I've decided against selling it guys.
It still sits on the shelf alongside the other religious books. :)
I might have to get your help understanding the Amiga Hunk format then ;)
-
I might have to get your help understanding the Amiga Hunk format then ;)
You are most welcome to borrow the book if you want mate?
-
You are most welcome to borrow the book if you want mate?
Very kind offer, but I am using:
http://amiga-dev.wikidot.com/file-format:hunk
which should do for now... I will see... ;)
-
http://amiga-dev.wikidot.com/file-format:hunk
This seems to somehow confuse load files with object files and libraries. Oh well. For this particular topic, the Bantam book is good enough.
-
This seems to somehow confuse load files with object files and libraries. Oh well. For this particular topic, the Bantam book is good enough.
This website does seem to be very confusing to me... But I put that down to my lack of understanding.
-
This seems to somehow confuse load files with object files and libraries. Oh well. For this particular topic, the Bantam book is good enough.
Which I also have if you want to borrow it Matt.
-
Which I also have if you want to borrow it Matt.
I think I will have to take you up on the offer!
Please see which book has the best description of the Hunk format and how Loadseg works, then PM your PayPal address and I'll send over the cost of shipping (plus any other overheads) cheers :)
-
I think I will have to take you up on the offer!
Please see which book has the best description of the Hunk format and how Loadseg works, then PM your PayPal address and I'll send over the cost of shipping (plus any other overheads) cheers :)
You should have bought the GURU book before he changed his mind. :)
-
Please see which book has the best description of the Hunk format and how Loadseg works
How much detail do you need? If we can disregard overlay files (rarely used), then LoadSeg() is really rather trivial. A binary load file consists of a HUNK_HEADER, which contains the number of hunks, and for each hunk, the number of long words to allocate per hunk, and the memory type to use in its upper two bits.
Following that is a sequence of HUNK_CODE, HUNK_DATA or HUNK_BSS, each of which may be followed by one or multiple relocation information (HUNK_RELOC32 or HUNK_RELOC32SHORT). HUNK_CODE and HUNK_DATA contains both the number of longwords contained in the hunk (which may be less than the number of LWs allocated in the header), followed by the data itself. HUNK_BSS is just blank space, hence no data included.
HUNK_RELOC32 defines which offsets in the hunk loaded before have to be relocated, and the base address of which hunk has to be used for relocation. HUNK_RELOC32 consists of one or multiple lists, each list starts with the number of entries to relocate, followed by the hunk to be used as base address, followed by the offsets in the just loaded hunk that have to be relocated, one longword per entry. All LoadSeg() does is to add the base address of the hunk indicated in the second long word of the list to the long word at the base address of the current hunk plus the offset in the list.
If the number of entries is zero, then HUNK_RELOC32 ends.
HUNK_RELOC32SHORT is similar, except that the offsets are 16 bit wide, not 32bit wide.
HUNK_END ends a hunk.
Hence, if you want to define a syntax:
binary load file := HUNK_HEADER HUNKS
HUNKS := one or multiple HUNK
HUNK := HUNK_BODY, HUNK_RELOCs, HUNK_END
HUNK_BODY := HUNK_CODE or HUNK_DATA or HUNK_BSS
HUNK_RELOCs := one or multiple HUNK_RELOC32 or HUNK_RELOC32SHORT
HUNK_RELOC32 := 0x3ec RELOC32TABLES
RELOC32TABLES := END_TABLE or FULL_LONG_TABLE
END_TABLE := 0
FULL_LONG_TABLE := count, base_hunk, count times 32bitoffsets
HUNK_RELOC32SHORT := 0x3fc RELOC32SHORTTABLES
RELOC32SHORTTABLES := END_TABLE or FULL_SHORT_TABLE
FULL_SHORT_TABLE := count, base_hunk, count times 16bitoffsets, cludgefill
where "cludgefill" is an empty 16 bit word if the number of entries is odd, i.e. does not end on a LW boundary. All other entries are longwords (BCPL cells).
Relocation works as such:
longword at (address of(current hunkt)+ 32/16bitoffset) += address of(base hunk)
Things get a bit more hairy for overlay files, but it does not require any other types except HUNK_BREAK or HUNK_OVERLAY. All the other hunk types in the above web resource are reserved for libraries or object files, and you do not need them.
To work on binary load files, I suggest:
http://aminet.net/package/dev/misc/Hunk
-
How much detail do you need? If we can disregard overlay files (rarely used), then LoadSeg() is really rather trivial. A binary load file consists of a HUNK_HEADER, which contains the number of hunks, and for each hunk, the number of long words to allocate per hunk, and the memory type to use in its upper two bits.
I want to be able to parse the Hunk executable file, and load it into an arbitrary memory location, setting up sufficient heap and stack to point my 68k emulator at it and execute what it finds.
In my current implementation, I have allocated 16megabytes for use by the emulator. I wish to load the file at address 0x200000 (I have 8megabytes reserved at this location for code), relocating the code and allocating memory as required.
I have a pointer at address 0x000004 pointing to a faked exec structure (currently located at 0xafe7fe, which seems to be away from any important address space), with the jump table set up (as defined by Christian Vogelgsang for his VAMOS project):
my fake lib entry:
real amiga lib entry:
So I can trap exec library calls.
The executable I am using as my test is the AmigaDOS 1.3 command "Type", perhaps not the best example, but it is small and should only call the exec.library and dos.library.
(I will be ignoring overlay hunks).
Following that is a sequence of HUNK_CODE, HUNK_DATA or HUNK_BSS, each of which may be followed by one or multiple relocation information (HUNK_RELOC32 or HUNK_RELOC32SHORT). HUNK_CODE and HUNK_DATA contains both the number of longwords contained in the hunk (which may be less than the number of LWs allocated in the header), followed by the data itself. HUNK_BSS is just blank space, hence no data included.
HUNK_RELOC32 defines which offsets in the hunk loaded before have to be relocated, and the base address of which hunk has to be used for relocation. HUNK_RELOC32 consists of one or multiple lists, each list starts with the number of entries to relocate, followed by the hunk to be used as base address, followed by the offsets in the just loaded hunk that have to be relocated, one longword per entry. All LoadSeg() does is to add the base address of the hunk indicated in the second long word of the list to the long word at the base address of the current hunk plus the offset in the list.
If the number of entries is zero, then HUNK_RELOC32 ends.
HUNK_RELOC32SHORT is similar, except that the offsets are 16 bit wide, not 32bit wide.
HUNK_END ends a hunk.
Hence, if you want to define a syntax:
binary load file := HUNK_HEADER HUNKS
HUNKS := one or multiple HUNK
HUNK := HUNK_BODY, HUNK_RELOCs, HUNK_END
HUNK_BODY := HUNK_CODE or HUNK_DATA or HUNK_BSS
HUNK_RELOCs := one or multiple HUNK_RELOC32 or HUNK_RELOC32SHORT
HUNK_RELOC32 := 0x3ec RELOC32TABLES
RELOC32TABLES := END_TABLE or FULL_LONG_TABLE
END_TABLE := 0
FULL_LONG_TABLE := count, base_hunk, count times 32bitoffsets
HUNK_RELOC32SHORT := 0x3fc RELOC32SHORTTABLES
RELOC32SHORTTABLES := END_TABLE or FULL_SHORT_TABLE
FULL_SHORT_TABLE := count, base_hunk, count times 16bitoffsets, cludgefill
where "cludgefill" is an empty 16 bit word if the number of entries is odd, i.e. does not end on a LW boundary. All other entries are longwords (BCPL cells).
Relocation works as such:
longword at (address of(current hunkt)+ 32/16bitoffset) += address of(base hunk)
Things get a bit more hairy for overlay files, but it does not require any other types except HUNK_BREAK or HUNK_OVERLAY. All the other hunk types in the above web resource are reserved for libraries or object files, and you do not need them.
To work on binary load files, I suggest:
http://aminet.net/package/dev/misc/Hunk
I think you have provided enough information for me to progress, I would appreciate a worked example if you have one... I appreciate this might not be the best place for that :)
-
...So I can trap exec library calls.
The executable I am using as my test is the AmigaDOS 1.3 command "Type", perhaps not the best example, but it is small and should only call the exec.library and dos.library.
(I will be ignoring overlay hunks).
...
I think you might be on to something there. I did try hacking into some 1.3 commands once with a cartridge dissassembler, single stepping etc, and was completely baffled by the amount of system activity going on for just very simple commands.
Your approach seems much more level headed... it was like a spaghetti waterfall, trying to track what on earth the processor was doing or which bit of ROM it was looping around. :confused:
And I certainly didn't have a clue how headers worked, that was an education. :rtfm: I guess largely designed 32 bit from very early in AmigaOS. Made adding fully 32bit CPUs a lot easier.
-
I have a pointer at address 0x000004 pointing to a faked exec structure (currently located at 0xafe7fe, which seems to be away from any important address space), with the jump table set up (as defined by Christian Vogelgsang for his VAMOS project):
But you are aware that vamos already has a segment loader? You find it in amitools/binfmt/load_image(). In particular, amitools/binfmt/hunk/HunkLoadSegFile.py also includes the parser of the Hunk format.
It is certainly a bit convoluted and probably over-engineered, but it works. It shouldn't be too much of a problem to hack it up a little bit to include loading a binary to a specific address in VAMOS' address space.
The executable I am using as my test is the AmigaDOS 1.3 command "Type", perhaps not the best example, but it is small and should only call the exec.library and dos.library.
VAMOS is certainly capable of executing "type", this will work out of the box.
I think you have provided enough information for me to progress, I would appreciate a worked example if you have one... I appreciate this might not be the best place for that :)
Well, see above for a working example in python. I also have working examples in C, but since you're more into vamos anyhow, I would simply take what it already offers.
-
I think you might be on to something there. I did try hacking into some 1.3 commands once with a cartridge dissassembler, single stepping etc, and was completely baffled by the amount of system activity going on for just very simple commands.
Please note that 1.3 is a horse of a different color. The commands in C: of workbench 1.3 were written in BCPL, and hence used a lot of the BCPL magic. In particular, they depend on an *additional* structure within the code hunks that defines which "GlobVec" entries to populate. This structure has been phased out, and is not part of LoadSeg() or the hunk structure.
You find more about this obsolete junk (not hunk) here:
http://aminet.net/package/dev/misc/BCPL
Commands from 2.0 onwards were plain C, did not depend on any arcane BPCL magic, used C linkage and the plain HUNK format without the higher level structure that was defined by the Tripos loader.
-
But you are aware that vamos already has a segment loader? You find it in amitools/binfmt/load_image(). In particular, amitools/binfmt/hunk/HunkLoadSegFile.py also includes the parser of the Hunk format.
I must confess, I've never seen python before, and I have trouble reading it. stumbling over Chris's code in a strange language isn't much fun.
It is certainly a bit convoluted and probably over-engineered, but it works. It shouldn't be too much of a problem to hack it up a little bit to include loading a binary to a specific address in VAMOS' address space.
VAMOS is certainly capable of executing "type", this will work out of the box.
That gives me hope :)
Well, see above for a working example in python. I also have working examples in C, but since you're more into vamos anyhow, I would simply take what it already offers.
I would prefer C as that is the only language I have used in the past 17 years :)
-
What I need really is to know what data expected to see at each offset.
at byte 0 I expect to see 0x3F3
at byte 4 I always see 0x0 (the spec says this should be "Strings")
at byte 8 I should see "table size" (what is the table? the total number of hunks +1?)
at byte 12 I should see the first hunk (I guess for a load file this should always be 0)
at byte 16 I should see the last hunk (so this tells me how many hunks I am expecting?)
at byte 20 I should get a list of hunk sizes? (I don't understand what this is)
at byte 24 not sure what I'm looking at...
at byte 28 I see my first code hunk... (0x3E9)
at byte 32 Guess is the size of the code hunk in 4byte blocks?
-
What I need really is to know what data expected to see at each offset.
at byte 0 I expect to see 0x3F3
at byte 4 I always see 0x0 (the spec says this should be "Strings")
This must be zero. It is used by some arcane BCPL linkage of libraries that is no longer supported (and which actually only worked with the dos.library anyhow.).
at byte 8 I should see "table size" (what is the table? the total number of hunks +1?)
This is just the number of hunks to load.
at byte 12 I should see the first hunk (I guess for a load file this should always be 0)
Yes.
at byte 16 I should see the last hunk (so this tells me how many hunks I am expecting?)
Yes. This is the number of hunks - 1. So for three hunks, this is 2. The exception are overlays.
at byte 20 I should get a list of hunk sizes? (I don't understand what this is)
What follows is for each hunk the number of long words to allocate for it. That is, if the binary consists of three hunks, three longwords are in this part of HUNK_HEADER. Each longword lists the number of long words to *allocate* for the hunk. I.e., you get the number of bytes to allocate by multiply the number in this section by four - or rightshift by 2.
Bits 30 and 31 are then shifted out. They contain the memory type. If both are zero, the type is MEMF_PUBLIC. If the bits are 01, it is MEMF_CHIP | MEMF_PUBLIC. If the bits are 10, it is MEMF_FAST | MEMF_PUBLIC. If it is 11, the next longword contains the memory type.
Actually, the combination 01 (MEMF_CHIP|MEMF_PUBLIC) is pretty much the only combination in use.
at byte 28 I see my first code hunk... (0x3E9)
at byte 32 Guess is the size of the code hunk in 4byte blocks?
That is the number of longwords *to load*. Note that this can be smaller than the number of bytes to *allocate*. The remaining bytes remain undefined then. This allows, for example, to place the BSS data within another hunk, except that they are not cleared.
-
Thomas!
Fantastic, very helpful! Many thanks. I will have more questions later :)
Also, I will proabably ignore the Memory flag high bits for this experiment... since I only have a single address space (for now ;) )
-
Please note that 1.3 is a horse of a different color... Commands from 2.0 onwards were plain C, did not depend on any arcane BPCL magic, used C linkage and the plain HUNK format without the higher level structure that was defined by the Tripos loader.
Yes, AmigaOS started as a port. PL1 was a bit like that arcane magic stuff. Idea was you ran a programme in a sliced mainframe environment. Not stuff I ever really used, except to understand strictly defined data structures, pointers, other stuff.
Arrays have their uses, but for the finer definition of metrices and dimensional spaces, you definitely get advantage from more flexible means of defining data structures. I only realy experienced 1.2-3.1 Commodore era releases, much more the earlier. It all started as BCPL and gradually got recoded into C, partly in the UK at first I think. Amiga INC did a lot of C coding, but just enough to make it the Amiga boot, and a lot of other people have recoded it since. Of course.
1.3 commands seem both more bulky and clunky than their later descendants. A couple paradoxically seem quicker, or perhaps that is just my imagination... I haven't witnessed enough of the later releases to comment really.
-
Yes, AmigaOS started as a port.
Well, to some degree. Tripos was already 68K based, so it was more like putting Tripos on top of the (very small) micro-kernel exec had to offer. Actually, the number of changes are rather minimalistic, so the dos.library is really Tripos in action. Not much a port, but the real thing. Amiga genuine parts were really graphics (the big ugly) and intuition (a much better design than the rest), on which the workbench was put on top.
1.3 commands seem both more bulky and clunky than their later descendants. A couple paradoxically seem quicker, or perhaps that is just my imagination... I haven't witnessed enough of the later releases to comment really.
Well... compared to their Unix counterparts, even the Tripos commands were pretty short. This is because Tripos has a much better low-level support than Unix has. For example, command line parsing aka "ReadArgs()" and formatted priting ("WriteF()" - BCPLs "printf") were always part of Tripos, just not accessible from C, so a BCPL command already got a lot of services from the Os.
The only reason why the C counterparts are even shorter is a) the BCPL compiler did not exactly generate "ideal" code due to all the shifting of the BCPL "pointers" (not really, BCPL is a typeless language), and b) a lot of additional services were added to dos with v37, most of which came from the "arp" project of the software distillery, as for example the pattern matcher, and c) there was still a minimum amount of BCPL startup magic necessary within each command (the first hunk of the BCPL commands) that sets up the "GlobVec" of the command given the undocumented and arcane inner structure of the code hunks.
Thus, for example, while the average Unix C program uses "printf" from libc outside the kernel, and implements argument parsing itself, all this comes "for free" from the operating system, namely the dos.library, if you know how to use it.
-
It all started as BCPL and gradually got recoded into C, partly in the UK at first I think. Amiga INC did a lot of C coding, but just enough to make it the Amiga boot, and a lot of other people have recoded it since. Of course.
Amiga Corporation wrote all their code in C or assembler, when commodore bought them it was still pretty much smoke and mirrors. IIRC you loaded software onto the Amiga using a Sun workstation (the original Macintosh used a Lisa for a similar purpose http://www.folklore.org/StoryView.py?story=Shut_Up.txt).
They had a design for an operating system (called CAOS) but didn't have the time to do the development in house and they were let down by the people they contracted it to http://www.thule.no/haynie/caos.html So they had to start looking for existing solutions and TripOS was very similar to what they wanted and it would be easy to make it run on top of exec. TripOS was re-branded, a small amount of development was done and they had dos, a file system and commands.
-
Amiga Corporation wrote all their code in C or assembler, when commodore bought them it was still pretty much smoke and mirrors...
They had a design for an operating system (called CAOS) but didn't have the time... looking for existing solutions and TripOS was very similar to what they wanted and it would be easy to make it run on top of exec. TripOS was re-branded, a small amount of development was done and they had dos, a file system and commands.
Well... I had a little brush contact at the time all that was going on, with "Metacomco" associates of Dr Tim King. I was in the neighbourhood, so I kind of twigged he was a heavyweight in designing and implementing dev and operating systems.
I didn't really understand how important all that would be to me later, it was enough of a shock seeing Dr King on TV talking about the Amiga and Boing demo. I just saw his name and "Metacomco" on a stack of dev source code for a 6502 dedicated system.
I didn't work with him, but one of his graduate students, Masters I think. Guy was like Steve Wozniak, could view a page of hex and translate it into a program listing, in his head. Interesting days for a 16 year old as I was at the time, about 1985. Somebody told me later I made him nervous for his job. I thought that was a silly idea, he could code in his sleep. I fumbled for hours getting things right. Ian Culls, I think he was called.
Yes, looks like exec and intuition, file system, basic commands were done in UK. Amiga Inc probably did most of the hardware drivers, libraries, handlers. In whatever they could, including the first Basic, which they got off Metacomco to write Boing demo. This was the guy who did the first drafts, I guess. 6 months or more.
https://www.youtube.com/watch?v=dXGFqKjc9AY
-
Yes, looks like exec and intuition, file system, basic commands were done in UK. Amiga Inc probably did most of the hardware drivers, libraries, handlers. In whatever they could, including the first Basic, which they got off Metacomco to write Boing demo. This was the guy who did the first drafts, I guess. 6 months or more.
https://www.youtube.com/watch?v=dXGFqKjc9AY
-
Well after quite a bit of work, I did eventually figure out the Amiga Hunk file format. With all the executable files I tried, there are only three hunks I need to look out for: the Hunk header, which tells me how much ram to allocate (which in turn gives me my segment addresses), and the code Hunk and the data Hunk... everything else can be ignored, I found that my build of Deluxe Paint IV has a debug hunk for some reason.
Once you have found either a code or a data hunk, you need to load it into the previously allocated memory... then check if it has a reloc32 block (I haven't found any other type of reloc block) after it, if yes... then you need to put the addresses of the previously allocated segments at the listed offsets. and you keep scanning until you reach the end of the file.
None of this was making much sense, until I realised that the format is optimised to be processed while being streamed from a disk! So every operation you perform is done in the order you find it! Cli commands like "Type" only have a code hunk, no data or reloc32!
So now I can happily load an Amiga executable file, point my 68k at it and it will run!
I have built an exec.library Jump table style interface which when called, jumps execution out of the 68k emulator and into an x86 Obj-C compatible interface.
Which means I can write my libraries in Obj-C and their methods will be called by the 68k program (so much byte swapping!). I now have the arduous task of implementing the functions on demand. Exec is quite easy (I initially implemented AllocMem, FreeMem, openLibray and CloseLibrary), but dos is more difficult, because I never really used it before... but since I'm mostly testing cli programs, this is what I need to focus on for now.
-
Well after quite a bit of work, I did eventually figure out the Amiga Hunk file format. With all the executable files I tried, there are only three hunks I need to look out for: the Hunk header, which tells me how much ram to allocate (which in turn gives me my segment addresses), and the code Hunk and the data Hunk... everything else can be ignored, I found that my build of Deluxe Paint IV has a debug hunk for some reason.
Hunk BSS doesn't really do much beyond inidicating a new hunk to follow, though it must be present to keep the hunk count in sync.
Once you have found either a code or a data hunk, you need to load it into the previously allocated memory... then check if it has a reloc32 block (I haven't found any other type of reloc block) after it, if yes... then you need to put the addresses of the previously allocated segments at the listed offsets. and you keep scanning until you reach the end of the file.
In principle, HUNK BSS could also take reloc information, though its use might be a bit dubious. There are also 16-bit relocation information hunks, though most linkers do not generate them.
None of this was making much sense, until I realised that the format is optimised to be processed while being streamed from a disk! So every operation you perform is done in the order you find it! Cli commands like "Type" only have a code hunk, no data or reloc32!
It depends, and you cannot count on this. It is rather the matter of the compiler switches that were used to compile the command.
I have built an exec.library Jump table style interface which when called, jumps execution out of the 68k emulator and into an x86 Obj-C compatible interface.
I wonder a bit why you want to reinvent the wheel. Vamos exists already.
Which means I can write my libraries in Obj-C and their methods will be called by the 68k program (so much byte swapping!). I now have the arduous task of implementing the functions on demand. Exec is quite easy (I initially implemented AllocMem, FreeMem, openLibray and CloseLibrary), but dos is more difficult, because I never really used it before...
You will soon notice that it doesn't stop there. To support all programs, you will need to provide task switching, which is not quite that easy and requires a good abstraction in the emulator part. "Vamos" doesn't do that, and more or less "sneaks around it" by implementing one of the dos.library functions that actually depend on it (namely, SystemTagList()) in a different (non-conforming) way, and others (namely CreateProc()) not at all.
It was good enough for my use case, even though I had to "help" a couple of binares here and there, for example by providing an alternative command line front end for the Lattice compiler, which uses CreateProc() to start the compiler, optimizer and code generator.
-
Hunk BSS doesn't really do much beyond inidicating a new hunk to follow, though it must be present to keep the hunk count in sync.
In principle, HUNK BSS could also take reloc information, though its use might be a bit dubious. There are also 16-bit relocation information hunks, though most linkers do not generate them.
My seg loader, flags up if it finds a hunk I don't currently support... so it is easy enough just to add support for other hunk types as I find them.
It depends, and you cannot count on this. It is rather the matter of the compiler switches that were used to compile the command.
:(
I wonder a bit why you want to reinvent the wheel. Vamos exists already.
Several reasons;
Firstly, I am doing this for fun! it's quite a complex project and very satisfying.
Secondly, I have no time or motivation to learn Python, figure out how Chris has structured Vamos and then figure out how to make his ideas fit with mine... like integrating Vamos with my ADFBench would be particularly uninteresting for me.
Thirdly, Vamos is essentially abandoned.
This has been a lot of fun, I'm particularly pleased with my exec.library -> Obj-C method calling interface :)
You will soon notice that it doesn't stop there. To support all programs, you will need to provide task switching, which is not quite that easy and requires a good abstraction in the emulator part. "Vamos" doesn't do that, and more or less "sneaks around it" by implementing one of the dos.library functions that actually depend on it (namely, SystemTagList()) in a different (non-conforming) way, and others (namely CreateProc()) not at all.
You are quite right, Vamos doesn't really work how I want it to. Though Full credit to his jumptable idea, it's the perfect solution for me (my original idea was to trap the CPU when it tried to read from an address in the jumptable area, which is a terrible idea).
It was good enough for my use case, even though I had to "help" a couple of binares here and there, for example by providing an alternative command line front end for the Lattice compiler, which uses CreateProc() to start the compiler, optimizer and code generator.
-
Secondly, I have no time or motivation to learn Python, figure out how Chris has structured Vamos and then figure out how to make his ideas fit with mine... like integrating Vamos with my ADFBench would be particularly uninteresting for me.
Actually, pyhton is a cute and even quite powerful language and certainly worth learning. It's not wasted time. At times, vamos is really overenginered, though.
Thirdly, Vamos is essentially abandoned.
Huh, is it? Not by me, at least. I wouldn't say that I'm continuing the project on my own, but at this time, quite a bit already depends on it, and I keep fixing the problems I identified.
You are quite right, Vamos doesn't really work how I want it to. Though Full credit to his jumptable idea, it's the perfect solution for me (my original idea was to trap the CPU when it tried to read from an address in the jumptable area, which is a terrible idea).
Vamos uses the line-A traps as entry points from the emulated 68K CPU to the "real world" python code. This is as such a good idea, but you get twists in your brain as soon as you need to do the reverse: Call 68K code from python code. Unfortunately, it is necessary in a couple of places, namely for implementing functions like RawDoFmt().
The current mechanism for that is quite a stunt and implies patching the 68K return stack to redirect the 68K where you want it for executing code.
-
Actually, pyhton is a cute and even quite powerful language and certainly worth learning. It's not wasted time. At times, vamos is really overenginered, though.
I know a lot of people who love Python, but I find it a great deal of effort to read... which after a day at work (I'm a business analyst) is not as much fun to read as C/C++/Obj-C. :)
Huh, is it? Not by me, at least. I wouldn't say that I'm continuing the project on my own, but at this time, quite a bit already depends on it, and I keep fixing the problems I identified.
apologies, I didn't realise you were contributing to the project! I was going just by the Lallafa blog. I, obviously, think it is an awesome project, but I feel the end goals are quite different.
Vamos uses the line-A traps as entry points from the emulated 68K CPU to the "real world" python code. This is as such a good idea, but you get twists in your brain as soon as you need to do the reverse: Call 68K code from python code. Unfortunately, it is necessary in a couple of places, namely for implementing functions like RawDoFmt().
The current mechanism for that is quite a stunt and implies patching the 68K return stack to redirect the 68K where you want it for executing code.
I haven't really thought about the reverse, that will be fun to figure out :)
The hardest part for me is the AmigaDos stuff with I never really did anything with when I used to write on the Amiga!