Hyperion Confirms Leak Of AmigaOS 3.1 Source Code

[adrenochrome]

the only real amigaos3.1 successor was Morphos which came from the only existing powerpc boards creators(Phase5) for amiga. Hyperion was a company porting (unstably) windows game to the phase5 powerpc boards and came later by buying some amiga ip and improvising in os development.
Same goes for the hardware : Phase5 hardware part evolved in a firm called BPlan and created morphos dedicated powerpc hardware, Hyperion on his side was using rebranded teron motherboards (designed for linux).
Anyone interested in the powerpc amiga implementation should take a look at Morphos. this system is still impressive today because of his reactivity mostly coming by his "weakness" of using only real memory : everything is optimized to fit in ram only (a little bit like in game consoles)

[eltomito]

Due to this linked list design, the OS had to store some metadata into each allocated disk block, and it did it by putting them at the beginning of each block. This meant that when a block was read from the disk into the destination buffer, it had to be shifted by a certain number of bytes to skip the metadata. This may sound trivial today but on a 7 Mhz CPU with a 16 bit bus, it slowed things down quite considerably.

I know it's kinda late to optimize FFS loaders now but instead of shifting the block in memory, couldn't you just load every new block with overlap and temporarily store the few bytes at the end of the previous block which get trashed by the new block coming in?

Like this: let's say the block header is X bytes and its data payload is D bytes and I want to load the file at address A in memory.
1) I load the first block at A, get the block number of the next block from the header and - okay, no way around it for the first block - I move its payload which start at A+X to A.
2) Then I copy the last X bytes of the first block somewhere and load the second block at byte offset A + D - X.
3) I get the block number of the second block from the header and then I copy stored last X bytes of the first block (which I trashed with the header of the second block) back from where I stored it, etc.

So, for every block except the first one, it only involves copying X bytes back and forth, where X is probably something like 12. That doesn't sound like such a horror even on a 7Mhz CPU.

[jacob]

I know it's kinda late to optimize FFS loaders now but instead of shifting the block in memory, couldn't you just load every new block with overlap and temporarily store the few bytes at the end of the previous block which get trashed by the new block coming in?

Like this: let's say the block header is X bytes and its data payload is D bytes and I want to load the file at address A in memory.
1) I load the first block at A, get the block number of the next block from the header and - okay, no way around it for the first block - I move its payload which start at A+X to A.
2) Then I copy the last X bytes of the first block somewhere and load the second block at byte offset A + D - X.
3) I get the block number of the second block from the header and then I copy stored last X bytes of the first block (which I trashed with the header of the second block) back from where I stored it, etc.

So, for every block except the first one, it only involves copying X bytes back and forth, where X is probably something like 12. That doesn't sound like such a horror even on a 7Mhz CPU.

Yeah well, kinda late unfortunately But this wouldn't really help that much because if you are lucky and your file occupies several contiguous blocks, you still wouldn't be able to read them in a single I/O op. I don't know if you wouldn't also run into some problems with address alignment requirements for DMA.

[pracedru]

Yeah well, kinda late unfortunately But this wouldn't really help that much because if you are lucky and your file occupies several contiguous blocks, you still wouldn't be able to read them in a single I/O op. I don't know if you wouldn't also run into some problems with address alignment requirements for DMA.

I Remember having to wait for the OS to traverse the whole disk, if one had Powered off the machine in the middle of a Write OP.
That shit took forever. On my A2000 with 40 mb HD it wasn't that bad. But later I got an A1200 with a 250 MB HD. You learned to wait for the disk activity to stop before powering off.... haha.

I used my Amiga to do 3D graphics in a program called Imagine 3D. I would be running 4 to 5 programs at the same time on only 2 MB memory. I had an office suite comprised of several different programs. It could almost do all the stuff I need a computer for today. No PC owner i knew at the time could do that. It was MSDOS programs with no ability to say pipe graphics into a word processor. Sure the Workbench OS had its issues, but it worked very well. It would be in 1995 with Windows 95 that a PC was just barely functionally on par with an Amiga and Workbench. By then off course, Commodore had gone bankrupt.

[jacob]

I Remember having to wait for the OS to traverse the whole disk, if one had Powered off the machine in the middle of a Write OP.
That shit took forever. On my A2000 with 40 mb HD it wasn't that bad. But later I got an A1200 with a 250 MB HD. You learned to wait for the disk activity to stop before powering off.... haha.

To be fair, you can't blame AmigaOS for that. Only a journaled or CoW fs can save you from that and no personal computer OS had one in the 1980s. It was the same thing on DOS (scandisk) and even on linux before ext3/xfs (e2fsck). But the write op itself was slower on AmigaOS than it could and should have been.

I used my Amiga to do 3D graphics in a program called Imagine 3D. I would be running 4 to 5 programs at the same time on only 2 MB memory. I had an office suite comprised of several different programs. It could almost do all the stuff I need a computer for today. No PC owner i knew at the time could do that. It was MSDOS programs with no ability to say pipe graphics into a word processor. Sure the Workbench OS had its issues, but it worked very well. It would be in 1995 with Windows 95 that a PC was just barely functionally on par with an Amiga and Workbench. By then off course, Commodore had gone bankrupt.

Spot on! I remember that when Windows 95 came out, I wondered what all the fuss was about, it basically didn't do anything that the AmigaOS couldn't do years before that. It had memory protection in theory but of course that only worked for 32bit, protected mode processes and since most of the games and productivity apps we used back then were still 16bit, it was as crash-prone as ever.

Only the Mac was perhaps better for grahics and office work (it came nowhere close for games, of course). It only had cooperative multitasking but the UI was almost always better designed and by the time the Amiga was in full swing, Mac typically had more powerful hardware.

[TiberiusDuval]

At the time, Amiga outperformed and was more stable than Windows. Of course, that was a long time ago. Personally, I think that Hyperion has a great future with porting jobs.

Outperformed? Maybe with high end Amiga 4000 with turbo card against 486 PC running Windows 3.11. Stability? I do not know how stabile 3.x series AmigaOS was, But version 1.3 I have in my Amiga 500 is not very stabile, while Windows 3.11 quite rarely crashed on my 486 I had at 90's, Amiga crashed quite often mostly because od older software, dev's were just learning Amiga after c-64 and did things not very multitasking friendly way. No memory protection and software made to use memory directly without OS'es help quite often wrote something over memory used by OS, and then things will crash.

[TiberiusDuval]

Well, maybe that was because most people programmed in assembly which didn't need a dynamic linker. I never even tried to find out if a C compiler existed for the Amiga. I assume if there was one, it would probably have its own dynamic linker, right?

Amiga had quite many C-compilers as far as I can remember from old Amiga magazines I had in my collection. Here are some: http://www.amigacoding.com/index.php/C:Compilers