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

[kamelito]

@Olsen
IFAIK 6.58 was the last 68k sas/c is there a 6.59? What are the difference between the two?
https://www.warped.com/amiga/
Kamelito

[guest11527]

@Olsen
IFAIK 6.58 was the last 68k sas/c is there a 6.59? What are the difference between the two?

Really nothing substantial. The 6.59 had some very preliminary support for PPC binaries, or rather the binary format around it. The code generator is exactly the same, and the bugs are also exactly the same. In essence, it also only supports 68K, and it doesn't generate any better code. Thus, for the very purpose of this update, the 6.58 and 6.59 are exactly the same.

[kamelito]

Really nothing substantial. The 6.59 had some very preliminary support for PPC binaries, or rather the binary format around it. The code generator is exactly the same, and the bugs are also exactly the same. In essence, it also only supports 68K, and it doesn't generate any better code. Thus, for the very purpose of this update, the 6.58 and 6.59 are exactly the same.

It would have been great to have the SAS/C toolchain source code and all bought by some Amiga company. Parts that are licenced could have been rewritten.
Kamelito

[matt3k]

Matt: i have installed 3.1 on amiga 3000s no problem... also 2.04. default install disks work fine no need for another computer.

Hey Magnetic,

I have installed large ssd via adapter and large scsi drive that can't be recognized or use large partitions on the old scsi.device over the years.  I would think that the new scsi device would aid in large disk partitioning at least.  Have you been able to set large partitions booting on a stock install?

[guest11527]

It would have been great to have the SAS/C toolchain source code and all bought by some Amiga company. Parts that are licenced could have been rewritten.
Kamelito

Well, wishful thinking. The first question is whether Steve Krueger (right?) is still reachable. The second question is whether anyone at SAS institute (or Steve) actually still *have* the source. Last but not least, whether they are willing to give the sources out.

Given how big companies like SAS operate, this requires a lot of decision makers to make decisions on products they do not know. If you ask me, these are a lot of "if's", and chances are pretty slim.

[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.

[wawrzon]

@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.

[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.

[nicholas]

Can someone please clear this up once and for all?

Who the hell owns the 68k OS?

Commodore?
Amiga Inc?
Cloanto?
Hyperion?

[Iggy]

Can someone please clear this up once and for all?

Who the hell owns the 68k OS?

Commodore?
Amiga Inc?
Cloanto?
Hyperion?

 
 Commodore - Doesn't exist except as a trademark.
 
 Amiga Inc - Probably never owned anything except a trademark, but as a settlement in lawsuits brought by Hyperion has granted a license to Hyperion for the exclusive right to continue to develop operating systems from OS3.1.
 
 Cloanto - Former licensee of the software, continued distribute its software after dissolution of original licensor, which as of late has made multiple arrangements with various parties to strengthen its claim to ownership.
 
 Hyperion - See Amiga Inc.
 
 So what's confusing?
 
 That the Amiga curse taints everything like a wish granted by a cursed money's fist?

[Matt_H]

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.

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.

[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.

[Matt_H]

@ olsen

Wow, thanks for that answer. I had no idea it was that complicated. I suppose v43 would still be too large even with some of the compiler trickery you used on other components of this release?

[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]

Looks like we need to start moving to 1MB ROMs across the board (although I know that means additional hardware/mods will be required...)

[Heiroglyph]

Since assembly based modules are not really going to get smaller, what about shrinking more of the C based modules by using the new compiler?

The new layers.library for example was a backport from OS4 changes if I'm not mistaken, so would probably be C.

I would assume that there would be a few like that.