Hyperion: "Halloween special double-treat for the Classic AmigaOS"

[olsen]

That they had to shrink workbench.library only to give space for new copyright text says a lot about their priorities.

You make this sound less weird than it actually is

The copyright text had to be updated, but due to how the Kickstart ROM layout works out, this required changes in the fixed-size area of the ROM which precedes the exec coldstart code. The copyright text sits within what's called the "manufacturing pattern" area, which is quite clever because it's right at the beginning of the ROM. There is just enough room for the copyright text, too.

Now there's a problem: the new copyright text was a bit longer than the old one, and it would no longer fit into the "manufacturing pattern" area. My solution to this problem was to place it in the coldstart code, with a branch instruction skipping over the text.

Well, that was some kludgy hack work, if I say so myself, but my troubles were only beginning...

This change made the exec module a bit larger because the copyright text now used up space which was not needed before. The consequence of this being that the A1200 ROM no longer had enough space left for everything to fit into it.

This is why there is a "workbench.library" in the ROM which was rebuilt using SAS/C 6.59 rather than Lattice 'C' 5.04, which was used in the original 1993/1994 build. The SAS/C version is quite a bit smaller than the Lattice 'C' version, and everything would fit.

Anyways, my kickstart says 3.10, the next will be 3.11 for Workgroups, haha

I'm still very much in favour of the TeX and Metafont version number schemes. Kickstart 3.1 is closer to Pi than to e, so maybe we're going to get Kickstart/Workbench 3.14, followed by 3.141, then 3.1415, etc.

[olsen]

From what gunnar said in public he negotiated with Hyperion and the answer was very honest that they are not interested in 68k. So either they changed mind since that or they just want to make some easy money without investing to much efforts in it. Before I do not see anything different I would bet on the second.

I do not often comment on issues such as these, because there's enough trouble either way if you say something. Not saying anything proved to be less troublesome.

So anyway... I would like to add that business negotiations do break down for any number of reasons, and the parties involved are usually very reluctant to explain in public as to what went wrong. This in itself is a tactical decision.

Sometimes negotiation tactics fail because the negotiating parties are unable to make their respective points and find common ground.

The short term tactics may have no direct relation to long term strategy.

This is "normal" in this business, in any business.

Things change, and the change is not a indication of poor performance or lack of confidence on the side of any party involved.

[olsen]

I am not sure what you are wanting to say without saying it (almost politician like)

Ouch - I was trying for "diplomat".

In the past 25 years we all saw great plans and eagerly awaited announcements which came to nothing. At times I resented the grandstanding, later I learned that this is how business is conducted in a high risk market. The Amiga certainly qualified for that term.

We tend to view the ambitions and the failure to deliver on them as dishonest, as display of incompetence, if not outright malicious intent. It's the easiest explanation, I suppose. The more uncomfortable explanation is that the ambition and dedication is real, it's just that in the Amiga market it takes very little to make a big impact, and also very little to derail even modest efforts. This is the nature of this business: it's very volatile.

Big changes happened in the 68k hardware field very recently which could help to boost operating system development work, beause there is now a genuine foundation to build upon: somebody might actually pay for that work to be done, and the requirements of the hardware could drive operating system development.

I believe we may have crossed an important threshold.

[olsen]

+2

Without really digging into it, I don't really see how this would be of any use to someone already running a fully patched 3.9. But  I suspect I'm not their target market.  Thoughts?

This was intended to be a robust Kickstart/Workbench 3.1 version which would correct as many defects as possible while at the same time minimizing the possible negative impact of the changes on existing software and hardware solutions.

These are quite strict constraints, which unfortunately result in this somewhat lackluster list of changes. This is the kind of small scope upgrade Commodore could have made back in 1994, if it had been possible.

If you are running a fully upgraded AmigaOS 3.9 system, then the changes made in this updated Kickstart/Workbench combination are not needed because the scsi.device and SetPatch you already have installed take care of the problems which the Kickstart/Workbench update address.

[olsen]

It would have been great to have the SAS/C toolchain source code and all bought by some Amiga company.

Amen to that.

However, SAS Institute is a really, really big shop. One would have to be very lucky to find the right person to ask about this legacy product, and maybe the same amount of luck to convince the company to part with the material. It does not seem to be relevant to the company's core business.

SAS Institute bought Lattice, Inc. in the late 1980'ies because their compiler technology allowed for the SAS stochastic analysis platform to be ported more easily to more computer/hardware platforms.

The Amiga compiler did benefit from this greatly, but it sold very poorly (especially compared to the other SAS Institute products).

Well, you never know... Let's make a wish

[olsen]

The big advantage for a 3000 user will be the scsi device update (assuming it is on the rom).  

Getting a new drive working in a 3000 with the stock controller is a challenge.

I can see this saving time and energy, you can start a new install of 3.9 without using another system to configure the drive ahead of time.

That would be my thought.

The scsi.device in this updated Kickstart 3.1 ROM is still version 40, not version 43, which sports large disk support and a multitude of enhancements and bug fixes.

The problem with scsi.device V43 and, for that matter, FastFileSystem V43 is that they are both significantly larger than the V40 versions. Hence, if you put the V43 versions into ROM, you would have to take something out of the ROM.

While this is technically feasible (see the A4000T ROM, which has special support code in it that will find and use the "workbench.library" located on any currently mounted volume, if the library cannot be found in "LIBS:"), it was important for this updated Kickstart 3.1 ROM set to contain all components which the 1994 ROM versions would.

[olsen]

@olsen

for what i know there are simple solutions for 1mb kickstart on amiga. i dont remember technical details though. ít could be googled i guess.

but how it stands, the kickstarts here being simply images not actual roms, the 512k limit doesnt apply anyway, since winuae and fs-uae can take advantage of split images, and so far i know even some aca accelerators can be fed with 1mb kickstart replacements.

The updated Kickstart ROM image was intended to be a replacement for actual hardware ROMs, which limits further what could be done about its contents without rocking the boat.

Once it's in a physical ROM (or rather something in the same package as the ROM; they don't make the kind of ROMs any more which were used in the 1980'ies and 1990'ies) any bugs (or "unintended side-effects") will be doubly embarrassing.

That said, flash ROM-based solutions which allow great flexibility have been available for a long time. This is what might be a possible target for a follow-up to this Kickstart 3.1 release.

[olsen]

Instead of putting in v43 scsi.device/FFS, could 64bit support be added to a new revision of v40? i.e., what I'm wondering with this line of inquiry is whether present day coding/compiling methods could achieve 64bit functionality in a smaller package than the ~1999 v43. Doesn't v43 also have all that NSD stuff (that I never really understood)? I would imagine that uses up some space and wouldn't be necessary for 3.1.

It should be possible to add 64 bit support to the V40 version of scsi.device and the FFS, but then again, it has been done already as well as it could be done. In my book, if Heinz Wrobel rose the challenge, the job is done and need not be tackled again. Possibly for the next few decades.

Both scsi.device and the FFS are written entirely in hand-crafted assembly language (with the exception of the Fast SCSI variant of scsi.device, which contains 'C' code and firmware bytecode for the SCSI microcontroller). This is, in my opinion, some of the most complex code in the entire Amiga operating system. And it was originally written by Randell Jesup, to whom I ever so humbly doff my cap. I forgot: the FFS and scsi.device are built on top of code written by Steve Beats.

While retrofitting 64 bit support is clearly possible, it's a really challenging task. Arguably, FFS may be easier to upgrade, but the real challenge is in making scsi.device work. Not only do you have to safely support the 64 bit I/O command set (NSD), you also have to support the gaggle of different hardware platforms which scsi.device works with.

The scsi.device still contains code to support ST and XT devices (as commonly used in 1987/1988 such as in the A590; I think this code is "dormant", though), the WD SCSI hardware (A590, A3000, etc.), the IDE hardware in the A1200, A4000 and A4000T, as well as the LSI Fast SCSI hardware used by the A4000T. The V43 scsi.device upgraded the ATA support as well as the Fast SCSI support, which along with the 64 bit I/O support accounts for the increased size of the driver binary.

If you ask me (well, you did ask me, didn't you?), this is the kind of code I'd rather find an excellent excuse not to modify. That level of complexity takes a very special kind of person to approach it. I had my brush with glory at this level of complexity with the FFS reimplementation which is part of AmigaOS4 and MorphOS. While the driving force behind this project was my own curiousity, I would not want to repeat the exercise. In particular not if the exercise involves writing faultless 68000 assembly language. This screams to me "run away!", in Graham Chapman's voice

Bottom line is, I believe that the V43 scsi.device and FFS are the best possible solutions for the problem at hand, although they create problems with ROM space.

[olsen]

@ olsen

Wow, thanks for that answer. I had no idea it was that complicated.

Others may have a different point of view on the subject of rewriting scsi.device and the FFS. My personal opinion of assembly language at this scale and at this level of complexity is that I would rather write this in 'C', if possible. Alas, this is not an option here.

I suppose v43 would still be too large even with some of the compiler trickery you used on other components of this release?

I honestly have not checked this yet, but there there is room for experimentation: the boot menu (which appears when you hold down both mouse buttons during the system startup), the con-handler (which implements the CON: device), gadtools.library, icon.library, layers.library, ram-handler (which, as the name says, implements the RAM: device) and the ROM shell are written almost entirely in 'C' and would most certainly shrink when rebuilt using SAS/C.

There is something of a catch, though. Commodore chose not to use SAS/C 6 back in 1993/1994 because it was felt that the code generation was not yet sufficiently mature for ROM code. While SAS/C kept maturing after Commodore had collapsed, it was never used on a larger scale for a production ROM build. The 'C' language portion of the A4000T (and A4091) scsi.device was built using SAS/C 6, but it was the exception.

I am not that knowledgeable about the quality of the code generated, and the bugs that might still be present in it. This means that additional testing would be required before more ROM components could be rebuilt with SAS/C 6.59, falling back onto the original SAS/C 5.04 compiler where needed.

[edit] Actually, now that I think about it, and if I'm remembering correctly, didn't the different version numbers of the original 3.1 (40.63/68/70) have to do with bugs/problems with scsi.device depending on platform? Now I see why! [/edit]

The A3000 build of scsi.device did cause problems in Kickstart 40.70 for some SCSI devices, if I remember correctly. This is why (and which is where I learned about it) Village Tronic went back to the Kickstart 40.68 ROM for the A3000 and A3000T.

What exactly did not work properly was very difficult to tell, because the code change history of scsi.device between versions 40.63 and 40.70 is incomplete. These were among the last changes made to the operation system before Commodore eventually shut down in April 1994. Heinz Wrobel told me that these issues had been successfully resolved in scsi.device V43, which he had prepared.

[olsen]

@Olsen
Thank you for describing so elaborate how the closed source model doesn't work

Could be... but it's hard to tell which contributes more to the somewhat disfunctional state of the art: the lack of development process, the lack of contributors, the use of a very old toolchain, the use 68000 language in complex subsystems, the need to remain backwards compatible with any changes made, the lack of documentation for ancient hardware, the age of the target platform itself.

Fix any two of these issues and you might just find that the others remain as stubbornly intractable as before

[olsen]

You should get Iggy to buy you SCO UNIX, the old one, before they started relying on FreeBSD, maybe Xenix! Then it would be so much better! :laughing:

Thomas mentioned Linux as a build platform with regard to a different application.

The Amiga V40 operating system can be built completely natively, using tools which only run on the Amiga operating system itself. That's nice, but not so nice if you wanted to perform automated build verification / smoke testing / integration testing. This is best performed automatically, regularly on a dedicated build server.

How do you do that? Thomas found a solution for that problem, and it involves Linux (but could also run on FreeBSD/NetBSD/OpenBSD/MacOS X/CygWin/AmigaOS).

And, no, SCO Unix will not do, due to its age.

[olsen]

The problem with the Os sources is that they delicately depend on the tools in the toolchain, so you cannot just take "a generic C compiler" and a generic 68K assembler. Instead, there are two compilers (lattice C and SAS 6.59), one assembler, a specific version of "gnuMake" and some other binaries that are compiled from scratch using the tools. Which is already an improvement given that intuition originally required a third compiler.

I would like to add that the build tools which are used to orchestrate the entire build process, as well as those specialist tools which knit together the Kickstart and Workbench contents, are available with full source code. The AmigaOS 3.1 build is almost entirely self-contained.

The only exceptions are the two compilers and the 68k assembler being used. I am not the expert, but it appears likely to me that the specific 68k assembler could be replaced. Which leaves the Amiga-platform-specific compilers as the biggest stumbling block. Please note that the compilers are not just used for building executable code, their respective debugging tools are important, too. The debuggers are really hard to replace.

[olsen]

Two things i'd like to see in a future update is Peter Ks excellent rewritten icon.library included as default if possible (and allowed by him)

The workbench.library/icon.library combo has, in my opinion, hit the wall so hard by now that it's coming out on the other side. The way in which workbench.library and icon.library interact with directory scanning is something I hesitate to call a self-inflicted injury. It certainly is not helpful. It is not helpful either to use large icon files. The interaction between the three parties (workbench, icon, dos) sort of works, but it works no better than it did in 1986: only the storage devices have become larger, and the CPUs have become faster.

Finally, I doubt the wisdom in including such a large (it's one single file), complex assembly language implementation in the operating system. It's bad enough that we have to deal with the FFS and the scsi.device driver family, and even dos.library. There is a place for assembly language code in the operating system, but in my opinion the solution should match the problem at hand in terms of complexity and maintainability.

[olsen]

One of the many examples of something that would be better to reimplement from scratch - though that would most likely also mean incompatibility with lots of existing "bedroom" software. Likewise, con-handler vs. console.device vs. shell, would be great to have that mess cleaned up.

The workbench.library/icon.library combo has resisted change for almost 30 years.

By now I am inclined to accept that it cannot be changed, only replaced by a solution that is API-compatible with it.

As long as workbench.library/icon.library continue to exist and are maintained, they will suck up developer effort best spent somewhere (make that "anywhere") else, just like space vacuum acts as a heat sink.

If you get too close to it, you will be sucked into creating enhancements which only burden the already over-overloaded architecture. My (so far) final contribution to this series of unwisely chosen enhancements was the Workbench ARexx interface.

By comparison the console.device/con-handler/shell combo seems charmingly 'whacky' and ultimatively redeemable

We shall see...

[olsen]

i applaud your effort, guys. the thing is, that as long as solutions proposed by you cost more and deliver less than third party replacements, they still are supposed to be met with criticism. especially, as its been mentioned already, that the target audience has been left outside, standing in the rain for years and had to look for alternatives, and also that the updates are being published under a label with known track of record of ignorance against the genuine amiga hardware and scene, and also been known for not delivering on announcements.

Call me uncharacteristically optimistic. I believe that changes made to the AmigaOS V40 code will be beneficial, although they are likely to be considered too little, too late.

The work that went into making the AmigaOS 3.5 update was intended to open up the platform by introducing new APIs, so that developers could build upon them, and by integrating functionality into the operating system which up until then had to be added through patches, which were fighting among each other for control.

In my opinion, this is the direction in which future development work should continue.

It won't be terribly exciting (excitement is something you would be well-advised not to seek in software development), but it seems reasonably likely to succeed to me at advancing the state of the Amiga operating system and getting more Amiga developers involved. It must be considerably less fun to "play" with what was last updated and polished in 1999.