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

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

[olsen]

thats exactly a part im sceptical about. you want to eat a cake and keep it. but i bet you wont get people involved if you dont open up. and you dont seem to plan to.

I understand this as being an unsatisfying solution for you. The situation as it is means that all of us, who are trying to get AmigaOS 3.1 into a maintainable state and beyond, are limited by the legal framework currently in place.

That framework (leaving aside for a moment why it is subject of criticism) at least allows for the work to be done such that it can be published without being challenged, that money can be earned by selling it and the publisher is legally required to honor the contracts being made with the participants of the project.

One downside to that framework is that the rightsholder (of the Amiga operating system as it is) requires that the material being worked on be treated as confidential. That's how it is for now. This would be a dealbreaker for many people who would otherwise feel more motivated to join in.

The Amiga community today is what is is: a community. It follows (at least from my point of view) that the same dedication should be extended to Amiga operating system development in the form of a community-driven project. I can agree to that. As things are, it's not going to  happen like that, with the existing legal framework governing the Amiga operating system in place.

This could change. I doubt that it will change in the short term.

While we are waiting for the change to come, there's something we can do that makes a difference.

One: figure out how the Amiga operating system might be made suitable in the context of a community-driven project (this will take time, knowledge of the legal framework,  talking to the right people and convincing them), making the change happen.

Two: work on Amiga operating system development as it is possible right now - at the very least you could get insights into how it works, how to develop it, and that is information you could in time pass on to others when the operating system development becomes more open (even NDAs elapse). You cannot be expected to gain all that working knowledge solely from studying source code

[olsen]

I agree that hacking and patching are not tidy or desirable solutions for long term development, they are just a quick fix, nothing more.

Hopefully kickstart development can catch up with what 3.9 offered and grow from there. Because right now it is a little poor in that area, so we are still better of with the hacks&patches from 3.9 and third parties, which is not the ideal solution.

For the moment, the 3.1 operating system is in "consolidation & cleanup" mode. The baseline which future work should build upon is arguably in not that much better shape than it was in 1994. Some bugs have been fixed, but in order to reduce the risk of breaking anything at all, the changes made so far have been very modest.

Changes that were made for the AmigaOS 3.5 and 3.9 updates should be possible, but even these would need reviewing again: they are barely 5-6 years "younger" than the original 3.1 release.

I also wonder why didnt Olsen integrate his Roadshow TCP stack with this release, as it could have made the update much more interesting, and I guess many people could have happily agreed to even pay a bit more for the workbench disks if it was included/added to them. After all, Roadshow is also the TCP stack of OS4, so I guess negotiations with Hyperion would have been pretty easy to acomplish since they have been already done for the OS4 version.

Considering that I had a really hard time making the updates to Roadshow 1.11 which I had planned (most of the interesting stuff didn't happen), then lost a lot of time testing the results because my only 68000 machine had failed, I expect that integrating Roadshow into Workbench would have delayed everything into 2017.

That's one reason why there is no Roadshow in this Workbench update.

The biggest reason is that this Workbench update sticks very close to the original 3.1 release in order to make sure that it actually worked well enough without having to spend the same amount of QA work as Commodore and Village Tronic did in their time. The fewer changes, the lower the risk to ship an update that breaks in subtle and/or baffling ways.

That said, this update did suffer from subtle problems: the installation script has a problem with copying the contents of the "Fonts" disk, and the Workbench disk should have been bootable. Both issues are fixable, and a fix should be available shortly.

Furthermore, there is a lot of 68k material from Hyperion that could have been included to enrich this release, at no cost of development at all. It was just a matter of collecting it from OS4 releases and prereleases.

You are onto something... Still, the deliberately limited scope of this update took priority.

[olsen]

I find this... astonishing :confused:

Between a handful of emulators, FPGA, Minimig and rather cheap systems from ebay...how hard is it to get access to a 68000 system?

Until very, very recently WinUAE support for SANA-II hardware was very limited. Roadshow needs to be able to send and receive Ethernet packets for a test to be in any way representatitive of what problems it might encounter on real hardware (e.g. A600 with cnet.device + NE2000-compatible PCMCIA hardware). In fact, it wasn't until yesterday that I was able to use the A2065 support in WinUAE public beta #13 and have Roadshow run through a complete DHCP exchange, assigning it an IPv4 address from my local network.

So far I tried to get by with "real" vintage hardware and did not see the need to with a Minimig.

The (so far) last 68000 machine I bought on eBay was the A600HD which failed in 2015. I did not repeat the exercise, because this year 2016 has been the most stressful and busy in a very long time. My priorities had shifted elsewhere, and something had to give... It happens to all of us, I suppose.

Don't you at least have people who can run tests for you?

In the mean time I managed to ask for help, the end result being the Roadshow 1.12 update, whose README file credits the testers.

I consider it likely that future 68000 testing can be conducted primarily in emulation, now that the A2065 support in WinUAE finally seems to put all the necessary pieces together.

[olsen]

@Olsen

I believe if you need resources such as a working A600 (either replaced or repaired) or some cash to get some testing machines a simple PayPal account or some way to show support would likely yield some good results.

There are a lot of motivated users wanting to see OS3.x move forward. You just need to ask.

Have a great day!

The A600HD issue (which seems to have gained a life on its own by now, it seems) was not a question of money, but of a different type of resource: spare time. Had that been available in 2015/2016 to a larger degree, Roadshow 1.12 might have shipped earlier I just lacked the necessary time to see it through.

But I'll have to look into how one might get that A600HD repaired here in Germany. With the exception of my first Amiga (a 1987 A500, the type with a red keyboard LED) and of course the A600HD, all other 68000 machines which I own are still in good working order. However, none of these other 68000 machines can be conveniently fitted with networking hardware.

I do appreciate the offer to help

[olsen]

Wonder if it's a similar problem to what Cloanto had with their "3.X" ROM's?

If there are similarities, I expect they resulted from changing what used to work back in 1994 and finding that subtle problems slipped through the testing process.

In the case of this Workbench/Kickstart 3.1 update, the changes made were deliberately kept small so as to reduce the risk of breaking anything. That was the plan, but what caused the troubles was for one part the build process itself, and the subtleties of writing installation scripts.

The build process cranks out ready-made Kickstart ROM images and a set of drawers whose contents correspond exactly to the Extras/Fonts/Install/Locale/Storage/Workbench disks. In order to create those disks, the respective contents are copied to RAD: and the result then goes into an .adf image, one disk at a time. The Install/Workbench disks are special in that they both need to be bootable (they have been since the original 1994 release), and that the respective disk boot blocks need to be installed manually (ever tried "install rad:"?). Lack of automation of this process kept the Workbench disk from being bootable (the A4000T has its own issues with the Workbench disk; see below).

The contents of the Workbench disk set in this update are peculiar in that their contents were slightly rearranged so as to make one single set which can be used both on the A4000T and all other Amiga models. Because the A4000T does not have workbench.library in ROM, Commodore shipped a special variant of the Workbench 3.1 installation disk set, and that wasn't going to fly.

Making an installation disk set which works with all Amiga models resulted in disk space constraints, i.e. you can boot off the Install disk, but due to Workbench disk lacking the workbench.library, booting from it is not an easy option on the A4000T. Something had to give

What broke the installation script, which ended up copying the contents of the Install disk to the newly installed Workbench "fonts" drawer, was a change made so that you could more easily install everything from a single disk: just copy all the disk contents into drawers on the installation medium, set up assignments to those drawers and launch the installation script: no more prompting to insert a disk.

Because the Installer tool allows/needs very strict control over whether installation is permitted from an assignment rather than a volume, this caused trouble with the "Fonts" disk. If the Fonts disk was not present, then the installation script would copy the contents of the drawer which "FONTS:" was bound to. Because there is no "fonts" drawer on the Install disk, the "FONTS:" assignment was bound to the root directory of that disk (this is what the boot process does by default), and hilarity ensued... How do you fix that? You can actually test if "Fonts:" is an assignment, and you can test if that assignment refers to the boot disk's root directory. If so, then you can tell the Installer to prompt for the Fonts disk to be inserted and the assignment to be ignored. Even back in the day there was little love for Installer scripts. Now you know why.

Bottom line is: you will likely miss something important if you change anything at all, no matter how little the change was

[olsen]

The fonts disk was always a strange one. The other disks all have a 3.1 suffix - Workbench3.1, Storage3.1, etc. but Fonts doesn't. Was that so floppy-only users could simply insert the disk and not have to worry about an assign? (Come to think of it, I think the Locale disk behaves the same way). Kinda strange that they didn't do an "assign fonts: fonts3.1: add defer" line in the floppy startup-sequence instead...

The Workbench 3.1 disk set has more than one purpose. My pet theory is that this produces certain requirements and limitations.

The first purpose is to provide a bootable Workbench, and you better have a second floppy disk drive handy, because you are going to need it. You will end swapping the Fonts/Locale disks in and out time and again.

The second purpose is to install the contents of the disk set to hard disk. One floppy disk drive is sufficient for that.

The Fonts/Locale disks can be conveniently used both by the Workbench and the Install disks without having to tinker with the Locale and Fonts assignments. It simplifies things a bit. Furthermore, the installation script is using the default Installer command for prompting a disk to be inserted, which is hard-wired not to accept an assignment as a substitute for a volume (you can override this default behaviour, of course). This is really the least complex solution that works.

The updated Workbench disk set, which allows you to use assignments in place of volumes, is comparatively more complex because it overrides the default behaviour of the Installer "prompt for disk" command, which in turn caused further complications.

[olsen]

The 4000 and 1200 KS ROMs are a single 512KB file.  What can I use to break these KS ROMs into two parts for the even and odd ROMs?  Or, can these motherboards accept a single 512K ROM?

Which layout exactly is needed? Could you describe it?

[olsen]

FF???

More like WTF, actually...

The "FF" command ("FastFonts, Copyright 1986 by Microsmiths, Inc, Non-exclusive license granted to Commodore Business Machines") accelerates rendering of the "topaz" font family (8, 9 and 11 point sizes) by adding a simpler rendering path on top of graphics.library/Text.

The original graphics.library/Text function deals with all kinds of fonts, fixed-width, variable width, etc. and features only a single all-purpose bitmap glyph extraction/rendering routine.

If you know in advance what you are dealing with, then you can write special case code for the glyph extraction/rendering and on a 7 MHz 68000 machine that change could really matter.

Commodore shipped the "FF" command with Workbench 1.3, as a standard feature. However, it turned out that on machines with an 68030 CPU or better the accelerated glyph extraction showed a curious bug.

How curious? Imagine you wanted to play a prank on a friend by installing a shell command which would perform real-time ROT13 encryption for all text that would be printed on the screen with a "topaz" family font.

While this can be somewhat entertaining for a while, it looked too much like a bug, which is why the "FF" command invocation in the S:Startup-Sequence has been commented out. it's the only way to be sure.

[olsen]

Oh... this is Workbench 1.3.3, my eyes must have crossed, thought it was 3.1.

Two out of three ain't bad

Oops, I just found the source code. It seems that what triggers the bug is that the fast rendering operation involves self-modifying code. Which might have worked sufficiently well on the humble 68000, but less so on the 68030 and beyond.

[olsen]

What's wrong with 3.10? And then 3.11 for Workgroups - aka built in Envoy?

For a start, in 1993 Commodore disbanded the networking group which at the time had been responsible both for the AS225R2 TCP/IP stack (derived from 4.3 BSD Reno, if I remember correctly) and Envoy.

Development of both projects stalled and was never completed in-house. Years later INet-225 and Envoy 2.0 would surface as polished commercial products.