Official update to OS 3.1 from Hyperion

[Locutus]

I'm not sure you'd even want to do native development on something like AmigaOS.

The native development tools are all extremely primitive compared by what is the norm today.

[Olaf Barthel]

Originally Posted by wawa

i think being able to compile on itself should be a feature or at least aim of a regular operating system. but im not sure amiga operating system components have all fulfilled this demand ever, especially as we hear that the build process is so complicated.

I has been possible since 1998 for the Amiga V40 operating system (Kickstart and Workbench) to compile itself on an Amiga.

After the build has finished, you can literally copy the disk images to floppy disks and install a blank hard drive using them (well, just creating a blank partition suits the same purpose). Don't forget to copy the AmigaOS source code to that blank partition, while you're at it.

You can then load the Kickstart ROM image appropriate for your machine, reboot it and boot from the recently installed natively-compiled Workbench. You can now restart the AmigaOS build again from scratch.

Some small portions are, however, not built natively. These concern printer drivers, aux-handler, mathieeedoubtrans.library and mathieeesingtrans.library. These require a cross-compiler (aux-handler is written in BCPL and needs the BCPL compiler, the math libraries need the math runtime library of the Green Hills 'C' compiler) or are so old that porting them to a modern compiler makes little sense (Alphacom, Diablo 630, Howtek Pixelmaster, Seiko 5300, Sharp JX-730, Tektronix 4693d, Toshiba P351SX, Xerox 4020, etc.). Replacements for aux-handler and the math libraries exist, and in this case work better than the originals

Even with these small omissions, it has been possible for some 18 years for the Amiga operating system to fully build itself on an Amiga. Well, that was mostly my Amiga 3000UX with a 50 MHz 68060 CPU, but you get the general idea

[Olaf Barthel]

Originally Posted by Locutus

I'm not sure you'd even want to do native development on something like AmigaOS.

You should do native development if the platform allows for it.

When native development became possible for AmigaOS, it completely changed the operating system development culture at Commodore. Workbench/Kickstart 2.0 did benefit enormously from native development. It was not just "eating your own dogfood", the native development tools were considerably more powerful than the tools which had been used before.

The native development tools are all extremely primitive compared by what is the norm today.

That certainly is true, but they are the tools best suited for Amiga development, upsides and downsides included

[Olaf Barthel]

Originally Posted by modrobert

I remember reading something about an old Sun box being used for cross compile of the 3.1 sources by Commodore back in the day, and it will not compile entirely on a classic Amiga, but perhaps that's easily fixed.

The Amiga operating system, 1985 onward, appears to have been built using a specific set of compilers (one for the BCPL language in which parts of dos.library and the shell commands are written, one for everything written in 'C'), on Sun workstations.

I keep wondering which setup was used before that, after having read that the early work on the Amiga hardware and the operating system was using SAGE computers, but I digress.

Up until Kickstart/Workbench 1.3 the cross-compilers were still being used, and development work only moved slowly to "native development" with Lattice 'C' 4, SAS/C 5 and 6, Manx Aztec 'C' 3.6, etc.

Some components were rewritten so that native compilation could be used, but some were never adapted, e.g. audio.device, intuition.library, printer.device and most of the printer drivers were still being built using the cross compiler at the time when Commodore shut down in 1994.

[FOL]

Originally Posted by Ffin

I think this new release may be intended primarily for the Tabor A1222, see the UBoot image below:

That indeed is the tabor & Cyrus ESM.........errrrm.......ESC, .

[wXR]

Wait what, so the so-called Classic AmigaOS is going to work on the Tabor?

[Ffin]

Originally Posted by wXR

Wait what, so the so-called Classic AmigaOS is going to work on the Tabor?

So it would appear, using E-UAE and Linux I would guess.

Sent from my SM-G900F using Tapatalk

[modrobert]

Was holding my breath there for a while looking at the Tabor A1222 motherboard, thinking the Lattice FPGA on the board had enough speed rating and gates (logic elements) to hold the Apollo core, but doesn't seem like it, it's a LCMXO2-1200HC.

So I guess it's classic emulation in software then, not hardware.

[wawa]

Originally Posted by idrougge

If compiling the OS in one go was technically useful and technically feasible, it would have been made possible by now.

what makes you think it isnt? except, it hasnt been done yet.

[wawa]

Originally Posted by Olaf Barthel

I has been possible since 1998 for the Amiga V40 operating system (Kickstart and Workbench) to compile itself on an Amiga.

After the build has finished, you can literally copy the disk images to floppy disks and install a blank hard drive using them (well, just creating a blank partition suits the same purpose). Don't forget to copy the AmigaOS source code to that blank partition, while you're at it.

You can then load the Kickstart ROM image appropriate for your machine, reboot it and boot from the recently installed natively-compiled Workbench. You can now restart the AmigaOS build again from scratch.

Some small portions are, however, not built natively. These concern printer drivers, aux-handler, mathieeedoubtrans.library and mathieeesingtrans.library. These require a cross-compiler (aux-handler is written in BCPL and needs the BCPL compiler, the math libraries need the math runtime library of the Green Hills 'C' compiler) or are so old that porting them to a modern compiler makes little sense (Alphacom, Diablo 630, Howtek Pixelmaster, Seiko 5300, Sharp JX-730, Tektronix 4693d, Toshiba P351SX, Xerox 4020, etc.). Replacements for aux-handler and the math libraries exist, and in this case work better than the originals

Even with these small omissions, it has been possible for some 18 years for the Amiga operating system to fully build itself on an Amiga. Well, that was mostly my Amiga 3000UX with a 50 MHz 68060 CPU, but you get the general idea

okay.it sounds fine but still rather complicated. im all for building system natively, still i have doubts of advantage of it if it takes hundred times longer than cross compiling. i wouldnt insist on it no matter what.

actually to illustrate my workflow with aros 68k in comparison, i build or rebuild the whole os or desired module, like particular library or executable under linux crosscompiler after modification. using vmaretools feature i can simply copy the files in an instant over into a directory declared a winuae masstorage media and boot from there. when staisfied testing there i can attach an sd card or another masstorage media via usb to winuae and copy the data on that media, that i can use then to boot an actual amiga. to test the kickstart even there, you have to softkick it of course. none in their right mind would burn an eprom every time there is something to new test. i must admit i have not booted from a floppy since a while, but this is an option as well, since floppy images are being built alongside if you choose so.

this as example, i think it might be beneficial to organize build process of amiga-os in a similar manner, if a bigger team was expected to be involved. if you simply build it only yourself, or with one ot two collegues who are building only specific parts and know since years how to do it, then there is no problem of course. but admittedly licensing is what is a major issue, here, not the logistics.

[Locutus]

Originally Posted by Olaf Barthel

You should do native development if the platform allows for it.

When native development became possible for AmigaOS, it completely changed the operating system development culture at Commodore. Workbench/Kickstart 2.0 did benefit enormously from native development. It was not just "eating your own dogfood", the native development tools were considerably more powerful than the tools which had been used before.


That certainly is true, but they are the tools best suited for Amiga development, upsides and downsides included

I think that's sticking to a vision of 1989 a bit, i don't mean it offensively but hold on a for a minute :-)

That is looking at the perspective of working on AmigaOS as a true general purpose OS which should be fit for all use and on which you expect to also run and improve your (or the third party) development tools while you are at it.

Those conditions don't hold true any more. Nowadays AmigaOS has only very specific application areas and you don't expect it to have the best native development any more.

As such I would see working on it far more like how you would work on a VxWorks or Embedded Linux based system.

Of course this doesn't mean your system shouldn't have proper unit tests etc :-)

From what I have seen from the terrible AmigaOS 'build system' and read from you're comments I would take a bit more 'brutalist' approach to getting this to work.

Create harnesses for virtualised instances of all the exotic build environments and just build/populate/run/extract on the fly from you're build system.

Setup would be laborious but once created it would greatly improve productivity (think of the free CI :-D) You could build all of this on a stack of {Svn,Git}/Jenkins/UAE/QEMU/etc

/Fun!/

[idrougge]

Originally Posted by wawa

what makes you think it isnt? except, it hasnt been done yet.

The main reason I think it wouldn't be technically useful is reliance on actual features of different compiler. That's also the main reason I think it wouldn't be technically feasible. It's nice to have, and taken for granted if you're doing GNU bloatware, but not always an option if your target is a 512 kB ROM and you can't just buy more address lines.

[wXR]

I have to say, if that's the case, the Tabor sounds more and more like something I would be interested in buying. I'm adding A/EON to the list of people to contact about this open source research and campaign.

On that note I want to echo what was said above regarding that podcast with Cloanto. Really worthwhile, and gave me an increased sense that this might not be as hard as it sounds.

[Heiroglyph]

It's a little early to be working on build process improvements to source we don't have access to, don't you think?

That's the least of our problems at the moment and easily fixed if building a whole 4MB of binaries for a complete rebuild is an issue.

wXR: Assuming Tabor can run some version of UAE or even a custom chipless 3.1, why bother with a $600 1.2GHz PPC? My 2 year old cell phone has far better specs and I can make phone calls.

Focus on opening the source and I'll give you a dual 2GHz PPC Mac to port it to if that's what you're after.

[Locutus]

Originally Posted by Heiroglyph

It's a little early to be working on build process improvements to source we don't have access to, don't you think?

i suppose i got carried away :-)

[wawa]

Originally Posted by Heiroglyph

It's a little early to be working on build process improvements to source we don't have access to, don't you think?

i think the discussion is about that the source in question must not be kept unmaintainable and how workflow on it could be improved. but of course, possibility that something happens is in a range of promiles.

[Olaf Barthel]

Originally Posted by Locutus

I think that's sticking to a vision of 1989 a bit, i don't mean it offensively but hold on a for a minute :-)

That is looking at the perspective of working on AmigaOS as a true general purpose OS which should be fit for all use and on which you expect to also run and improve your (or the third party) development tools while you are at it.

Those conditions don't hold true any more. Nowadays AmigaOS has only very specific application areas and you don't expect it to have the best native development any more.

As such I would see working on it far more like how you would work on a VxWorks or Embedded Linux based system.

I cannot quite picture this. For now AmigaOS 3.1 appears to be useful only in the context of virtualization, emulation and legacy hardware (modified or unmodified). As such the best possible outcome for it which I could imagine today would be a platform for tinkerers, hobbyists and "makers".

Of course this doesn't mean your system shouldn't have proper unit tests etc :-)

That would be an interesting subject all by itself!

Does anybody reading this thread have experience in how to deal with legacy code on a platform which was developed using assembly language and 'C'?

The most straightforward definition of "legacy" code I read in recent years was that it referred to program code which lacked testing mechanisms.

The literature which I found on the subject was not particularly helpful, because it covered testing only in the context of object oriented programming languages.

Rewriting the existing code in a language which makes this kind of testing easier seems to be a non-starter. I already received some criticism for even suggesting that assembly language has its limitations.

How do you retrofit tests to this type of code? Is this even a good idea?

From what I have seen from the terrible AmigaOS 'build system' and read from you're comments I would take a bit more 'brutalist' approach to getting this to work.

You make it sound worse than it actually is. The current solution did not even exist in 1993. When Commodore gradually switched to native development, the original build system ("makemeta", which was built around the SunOS "make" utility) was phased out.

Each Commodore engineer was basically his own build engineer, and no two operating system components were likely to have anything in common when it came to building them.

The current build system uses GNU make and, with the exception of the process which cranks out ROM images and disks, is self-configuring with regard to what needs to be built. It's documented, the complete source code to all the tools is available. It's only 18 years old, and judging from today's offerings in terms of build systems, I find it hard to discard "make".

Those who do not know "make" are bound to reinvent it over and over again, poorly

But then again, those who know "make" often wish they had something better instead...

[eXeler0]

@Olaf Barthel
Short question, where is the OS3.9 source (which was extensively modernized over 3.1) kept? Who manages it as we speak?


Skickat från min LG-H850 via Tapatalk

[Olaf Barthel]

Originally Posted by eXeler0

@Olaf Barthel
Short question, where is the OS3.9 source (which was extensively modernized over 3.1) kept? Who manages it as we speak?

Short question, long answer coming up. I'll give some context first before finally answering your questions.

The source code of what was sold as AmigaOS 3.5 and 3.9 is not stored in a single repository. This is because for each of these projects a number of developers came together, each of whom contributed to the resulting product.

These projects were managed by Haage & Partner who themselves contributed software to the respective products. From Haage & Partner's perspective the AmigaOS 3.5 and 3.9 updates would consist mainly out of material licensed by third parties, these being Amiga International and the individual developers, respectively.

When Hyperion picked up development work, it licensed the material created by the AmigaOS 3.5 and 3.9 developers, where possible (some did not license their material), as well as the Amiga operating system source code from Amiga, Inc. Haage & Partner chose not to license the code they had produced (they quit the Amiga market shortly after the AmigaOS 3.9 release was complete).

This means that most of the material that was used in AmigaOS 3.5 and 3.9 wound up as the foundations on which AmigaOS4 was built. The gaps left by the material which Haage & Partner and other developers had not licensed for use in AmigaOS4 have been filled by now.

And it's time to answer your questions

The AmigaOS 3.5/3.9 source code which Hyperion has licensed is stored in a subversion repository, along with the AmigaOS4 source code. What exactly happened to the code outside this scope is (at least to me) unclear. Could be that it's sitting on a set of floppy disks, CD-ROMs, Zip or DAT cartridges somewhere in storage. Could be that it's been lost.

To the best of my knowledge, the source code, as stored in the subversion repository for AmigaOS4, is the only copy which is being managed at all. For the time being, I am responsible for keeping it safe and sound.

[Locutus]

Originally Posted by Olaf Barthel

I cannot quite picture this. For now AmigaOS 3.1 appears to be useful only in the context of virtualization, emulation and legacy hardware (modified or unmodified). As such the best possible outcome for it which I could imagine today would be a platform for tinkerers, hobbyists and "makers".

Ho, ho, i think you misunderstood :-)

I was not saying you should compare AmigaOS in its application area to VxWorks or so. We can all agree that this whole 'AmigaOS for embedded!1' thing people whine about is stupid.

What i meant is development methods.

Does anybody reading this thread have experience in how to deal with legacy code on a platform which was developed using assembly language and 'C'?

Yes, i've been paid to port software off of or 'blackbox' even more arcane operating systems then AmigaOS :-D

How do you retrofit tests to this type of code? Is this even a good idea?

I fear you will be working with a lot of external harness constructs to facilitate you're tests. Might not be as clean but you have to do with what you have to do.

You make it sound worse than it actually is.

Well, from a modern perspective the codebase is really bad, not just the various build systems but also a lot of code quality is questionable. The A4091 device driver code scared me.

Each Commodore engineer was basically his own build engineer, and no two operating system components were likely to have anything in common when it came to building them.

Which is of course one of the core problems, in essence when you look through the RCS data it becomes very obvious how the OS development was a set of very specific personal kingdoms, inter module cooperation is very low. (https://scholar.google.com/citations...J:WF5omc3nYNoC a fun paper on this subject).

The current build system uses GNU make and, with the exception of the process which cranks out ROM images and disks, is self-configuring with regard to what needs to be built. It's documented, the complete source code to all the tools is available. It's only 18 years old, and judging from today's offerings in terms of build systems, I find it hard to discard "make".

Those who do not know "make" are bound to reinvent it over and over again, poorly

That i haven't seen, and agreed :-D