FS: Amiga Guru Book by Ralph Babel

[psxphill]

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.

[Pat the Cat]

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

[Pat the Cat]

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

[bloodline]

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.

[guest11527]

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.

[bloodline]

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.

[guest11527]

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.

[bloodline]

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!