Hyperion announces OS 3.1 update

[ferrellsl]

Haage & Partner licensed or aquired code from third parties which is part of the AmigaOS 3.5/3.9 update. They also created code in house which is part of AmigaOS 3.5/3.9, and they also paid developers to create code for it. The company still owns this software and, to the best of my knowledge, has not licensed or sold it yet.

None of this specific code owned by Haage & Partner is tangled up with the Amiga International-licensed AmigaOS 3.1 code. Even if Haage & Partner wanted to, they could not "bake" a fully legally sanctioned AmigaOS 3.9 out of their properties and AmigaOS 3.1.

Yes, it sounds weird, because it is. This is the Amiga business, after all

Ah, that makes perfect sense.  So until there's a clear owner of OS3.1 and the IP associated with it, Haage & Partner can't release and distribute a full-blown update of OS3.9.  I'm not sure that this issue will ever get lined out.  There are just too many vultures fighting over the dead carcass of OS3.1 and they fail to realize that there isn't a significant amount of money to be made even if they gained said rights.  Even with the Vampire's popularity I would guess that there would be fewer than 100 buyers of a Vampire specific release of OS3.1.  Most Vampire owners already own a copy of OS3.1 or 3.9 and they're quite happy to just patch their existing copies as needed.

Dreaming of an Amiga revival where Vampires are being sold in the tens of thousands bundled with copies of OS3.1 licensed from Hyperion borders on the absurd, but delusional business plans run rampant in this hobby that encompasses dead hardware and dead operating systems....

[guest11527]

An RDB library sounds like a very good idea.

Yes, and we had one for 3.9, but there is currently not enough manpower to write something from scratch.

Will you please replace graphicdump with a more usable snapshot tool?

Graphicdump is not really a snapshot tool - and given that we don't have new printer drivers - indeed quite unuseful. If you just want to save a snapshot to disk, there are plenty tools available for that already.

What about picture.datatype? Do you still have the v45 sources?

Some, yes. I have not yet really checked in which state they are, and in how far they are usable, but there is something we may use.

Regarding audio.device: do you have some plans to somehow incorporate AHI into it, so that old applications can finally become more friendly with soundcards?

No, not at this time. There will be a bugfix update of audio, but that is as far as we can go. The audio.device in its current state is not very useful, and too trivial for many things. Whether we will or can go in the direction of AHI I have not really thought about at all.

Remember, this is not a "new and complete" Os release. We - the two guys - do simply not have the manpower for such miracles. It is the "take down the trash" release where we try to fix the most anoyances. 64bit access to harddisks is one of these constant anoyances. There will be tiny improvements here and there, whenever I find something I can do quickly without breaking too much, but there is not enough time for rewriting a lot.

Given the amount of manpower, it is remarkable that we already have a new pipe-handler, a new aux-handler, a new queue-handler, an almost new cross-dos, and a new execute (the latter - of course - you already have).

[Jeff]

When will the update be available to purchase, and will it be in the form of an update or a complete new install?

[kolla]

we already have a new pipe-handler

Speaking of pipes... an official C:Pipe?
Or the shell dealing with $_pchar and $_mchar on its own?

Hope the new "ugly" HDToolBox has meaningful ways of dealing with small partitions on huge drives, like being able to specify partition size in MBs (or MiBs in newspeak).

So many questions

[olsen]

@olsen
@Thomas Richter

Thank you both for explaining the difficult situation regarding both the CDTV and the CD32.

I believe prod_prep is often forgotten, underlooked and unapreciated, and it is a very powerful tool that all amiga users should know about. Dealing with it, is certainly not easy, and could be made a little bit less difficult by including an amigaguide manual with plenty usage examples.

"prod_prep" certainly lacks documentation (as in: there is none even in the Commodore archives, unless you count the actual source code as the only documentation). Looks like now we'll just might have to write some after all.

While "prod_prep" is useful, its inner workings are not as robust as they should be. The command processing would need to be rewritten, for example, and we haven't even touched the tricky parts which deal with media size detection that are unchanged since about 1991 (the code assumes a sector size of 512 bytes, which is how the maximum disk size limit of 2.2 Terabytes comes about). The current state just about works, but it's not on the same level as HDToolBox is right now. Question is whether "prod_prep" really needs that extra bit of work & polish to make it look, well, like somebody actually cared about making it work properly and reliably.

From how it looks, "prod_prep" was branched off HDToolBox at some point in the late 1980'ies. While HDToolBox was still being updated until about 1993, none of the changes seem to have found their way back to "prod_prep". This was really an in-house tool, and not meant for anything else. It replaced even older tools (1986/1987) which the engineers put together who made the first Commodore hard disk controller work.

I personally use prod_prep for deploying my own customized system/workbench to my amigas from within a simple script. It is very small and it is a formidable tool for emergency install floppies, where space is severely restricted. This way you save space for other important components and dont need to put both format and hdtoolbox which are quite large compared to prod_prep. Furthermore, it is a bonus that you are not required to use it in an interactive way and that you can fully automate it.

Yes, "prod_prep" is a unique solution to a whole bag of problems. The scriptable partitioning tool is useful, if not essential. If only the implementation weren't so rickety from top to bottom

What about picture.datatype? Do you still have the v45 sources? And even a v45 rebuild without the infamous StormC compiler would be apreciated. I dont enjoy the fat binary aspect of its last incarnation in 3.9. I dont want to deal with code that I wont use. But I still want the 24 bit support.
And of course, I wont even need to mention all the datatypes that need updates. It seems a lot of work is here waiting to drive you crazy.

Yes, the code is still around, minus the PPC bits which came from Haage & Partner.

I'm not so sure we'll have to open the whole datatypes classes collection of 100% natural organic canned worms right now. In my opinion the basic classes (sound, picture, text, AmigaGuide) should work sufficiently well for a little while longer. If I remember correctly, I put the 24 bit ILBM support into picture.datatype (with quantization and dithering) and the ilbm.datatype, so that should still work.

Regarding audio.device: do you have some plans to somehow incorporate AHI into it, so that old applications can finally become more friendly with soundcards? Afterall, unlike the RTG scenario, AHI is open source and it has become the unique and default standard for modern audio applications with no other counterpart attempting to replicate that on the Amiga.

I believe that audio.device is not supposed to be replaced in ROM. It has a peculiar API (ha!) and offers functionality which is not available in AHI because audio.device is not intended to be more than the thinnest possible layer on top of the sound hardware (it's also possibly the oldest operating system component in ROM, virtually unchanged since Sam Dicker wrote it in the dawn of the Amiga). So thin that in the "good old days" software was making assumptions of how audio.device used the hardware.

Whether AHI can be layered on top of audio.device in the future is a different question. Again: 100% natural organic canned worms waiting for somebody to get careless with a can opener

Speaking about usefull commands, yes, my idea was to have both reboot and findresident installed. BTW, will you also include "warnifpressed". I believe you have the sources for all of these.

Yes, "warnifpressed" is available, too, but it's not one of the installer dependencies. It needs lowlevel.library to be installed, which is in ROM on the CD32, but not on the AmigaOS 3.1 installation disk.

[guest11527]

Speaking of pipes... an official C:Pipe?
Or the shell dealing with $_pchar and $_mchar on its own?

C:Pipe was always an ugly hack, and so was _pchar and _mchar. V46 supports | and || natively as pipe characters, and gets a new internal command ( which takes ) as last argument. This avoids 2nd-time guessing and parsing of the command line through just another external command.

Thus,

Code: [Select]

( list || dir ) | more
concatenates the output of list and dir together, and pipes the result into more. Note the blanks. For commands that cannot read from stdin or write to stdout, this can be replaced by the filespec "PIPE:", i.e.

Code: [Select]

( list || dir ) | type PIPE: hex | more
will give you the directory in hex. For whatever this is good for.

Hope the new "ugly" HDToolBox has meaningful ways of dealing with small partitions on huge drives, like being able to specify partition size in MBs (or MiBs in newspeak).

No, just in cylinders as it used to be. The GUI of HDToolbox is ugly, and the source code of this GUI is even uglier. It is some sort of automatically generated code which then has been drilled up infinitely by hand, which makes any attempt to extend it a real pain.

[olsen]

Hope the new "ugly" HDToolBox has meaningful ways of dealing with small partitions on huge drives, like being able to specify partition size in MBs (or MiBs in newspeak).

The HDToolBox GUI is incredibly resistant to change, and we did not succeed where scores of other developers tired themselves out before us (actually, make that three developers in total until development ceased in 1993).

The original HDToolBox GUI for the A590 and A2091 was created using PowerWindows. At the time (1988/1989) it was arguably the best-designed GUI in an Commodore-created Amiga program (seriously: internal Commodore communication mentions this). The limitations of PowerWindows (as in: little attention was paid to how Gadgets work, how fonts and window border sizes affect the placement of user interface elements) made it necessary to rewrite the GUI code for AmigaOS 2.0, which actually took 2-3 years to conclude. The result is unmaintainable, I'm afraid and I really feel for the developer who painstakingly reproduced the entire PowerWindows GUI with gadtools.library: that must have been the proverbial job from hell. This is why the specific changes that are needed are currently not within our reach

I mentioned that the scriptable runt brother to HDToolBox ("prod_prep") looks like nobody cared enough about it to make it work well. In HDToolBox the situation is similar, but more disheartening. The lack of care affects both the basic RDB management and the media queries (sector size, number of sectors, etc.) and GUI. Normally, one would throw everything away and start over from scratch, and guess what, this is what was done for AmigaOS 3.5 and AmigaOS 4, but we are unable to use that code. Right now we don't have the manpower to crack this problem.

HDToolBox is in its current form a provisional solution which will have to do until there's more time to make a better one. That could begin by writing a robust library for RDB and media queries, and to build on top of that. What went wrong with HDToolBox and "prod_prep" also affects the mass storage device drivers ("scsi.device") which used to have problems dealing with media that would not use 512 bytes per sector. Although the RDB specs do support these, your typical controller software only attempts to read and parse RDB blocks of 512 bytes.

Mind you, in the 1990'ies it was assumed that sector sizes would be 512 bytes, and strange things happened if this was not the case. The old HDToolBox contains special code to detect CD-ROMs and tried not to crash or hang the SCSI bus because these devices use 2048 bytes per sector, and some of the early CD-ROM drives would actually hang if you tried to read fewer bytes per sector. Fun fact: the Amiga Unix SCSI driver didn't know that its read buffer was too short to read a full CD-ROM sector, but tried anyway and ran smack into a kernel panic. So this was pretty much par for the course back then

[Nickman]

Was going to sak about this:
"Any chance of getting a "move windows" outside of screen feature like PowerWindowsNG?"

Then i googled and found this thread:
http://www.amiga.org/forums/showthread.php?t=67649

But still curious if maybe you would consider it in the future. Low res screens would find it very convenient to be able to move windows partially of screen.

[guest11527]

Was going to sak about this:
"Any chance of getting a "move windows" outside of screen feature like PowerWindowsNG?"

I believe we discussed this already elsewhere. Yes, we do have an intuition V45 which supports this, but it is unfortunately not compatible with Cybergraphics, so it looks like we will not ship it and stick with V40. The problem is here that all RTG systems hack pretty badly into the system and depend on internal implementation details of intuition. For P96, it is possible to get it supported with a kludge, but that's basically because the authors of the V45 had the P96 sources available and could load registers with the values P96 expects. For CGfx, none of us has the sources, so it remains completely unclear of why that fails.

Yes, we did send a letter to Frank Mariak, at this time I do not yet have a reply. One way or another, this requires a clearer interface than the current kludge for P96 right now, and we will certainly not ship a ROM that breaks 50% of the RTG installations in the field.

[Georg]

For CGfx, none of us has the sources, so it remains completely unclear of why that fails.

You don't need sources to figure out such simple things. As said elsewhere, just make sure to trash registers before screen bitmap allocbitmap call to force enforcer hit/crash to see which registers (apart from allcobitmap params) CGFX expects to contain some additional info.

You could probably also just write a little test AllocBitMap patch (no need to modify ROM for tests) which you run on a working CGX setup (after CGX init) which does something like:

New_AllocBitMap:
  save_all_regs
  trash_all_regs_except_params
  ret = call (*Old_AllocBitMap)
  restore_all_regs
  return ret;

[guest11527]

You don't need sources to figure out such simple things.

But I'm not talking about "simple things". It depends on more than just AllocBItMap, and the register dependency is more than "oh, please use register a4 to get the MonitorInfo". I'm talking about the stack frame, and the structure layout, and there are many more structures in intuition than what is in the official includes.

The code doesn't crash or hit in case the register layout isn't right. AllocBitMap() is a user-callable function, and the code probably goes in hoops to find out whether it is called from intuition, and whether the registers are consistent, and if not, it will do anything to *prevent* a hit and just operate normally.

You don't get this from a black-box approach.

[Georg]

But I'm not talking about "simple things". It depends on more than just AllocBItMap, and the register dependency is more than "oh, please use register a4 to get the MonitorInfo". I'm talking about the stack frame, and the structure layout, and there are many more structures in intuition than what is in the official includes.

You talked about Intuition now being compiled with different compiler and that was enough to break CGX. But structure layout and internal structure for the relevant things (to openscreen/modeinfo/etc.) is still the same, isn't it?

The code doesn't crash or hit in case the register layout isn't right.

Yeah, registers/pointer being "not right" in AOS is often not enough to cause immediate crash/hit. That's why you need to trash registers hard to increase likelyhood of crash/hit.

Unless you try with a patch like suggested or other things, you can't say beforehand if it's something simple which prevents CGX from working with new Intuition or not. So why not just try? Btw, with UAE's debugger it's probably easy to debug inside ROM, too (and UAE as said can run CGX as it emulates some gfx cards supported by it).

You also said:

For P96, it is possible to get it supported with a kludge, but that's basically because the authors of the V45 had the P96 sources available and could load registers with the values P96 expects.

so, if it was something simple in case of P96, why do you exclude from beginning that it may be something similiar simple (load register with values P96 expects) for CGFX?

[AmigaHope]

Um, well, this is still a work in progress and based upon a rewrite from scratch (there is no sense in rewriting or porting the original DiskDoctor). The goal is to make a command line tool which does three things: a) detect and report file system damage, b) recover data from a file system and c) repair any damage found.

This is good to hear. The original DiskDoctor is easily the most hated utility in classic AmigaOS and was the butt of countless jokes over how harmful it was. =)

https://www.techfak.uni-bielefeld.de/~joern/stories/AmigaTrek4.1

DiskSalv was the cure and honestly the DiskDoctor name was so tarnished it will probably take some very vehement mentions in future documentation that DiskDoctor will now be a useable tool.

[Georg]

The code doesn't crash or hit in case the register layout isn't right. AllocBitMap() is a user-callable function, and the code probably goes in hoops to find out whether it is called from intuition, and whether the registers are consistent, and if not, it will do anything to *prevent* a hit and just operate normally.

It cant do that ("operate normally") in case of OpenScreen AllocBitmap and some info it needs isn't there. That's what you need to try to trigger on a working CGX system -> make it fail to open a RTG screen. No need to try to trigger crash/hit. With some luck it's something simple like trash a certain register: then you know it expects some info in that register.

When writing a test patch (or realtime patch in ROM with UAE debugger) one should of course first test, if a do-nothing-patch still works (it could theoretically break the CGFX-is-this-the-allocbitmap-call-from-openscreen check).

[kolla]

V46 supports | and || natively as pipe characters, and gets a new internal command ( which takes ) as last argument.

Great, way to go

I have also somewhere mentioned that I want to ask you if you have thought of some equivalent to back-ticking, since back-ticks can be so tricky to ... communicate, something akin to $(command) instead of `command` on *ix shells. So, eh.. have you?

[psxphill]

But I'm not talking about "simple things". It depends on more than just AllocBItMap, and the register dependency is more than "oh, please use register a4 to get the MonitorInfo". I'm talking about the stack frame, and the structure layout, and there are many more structures in intuition than what is in the official includes.

Having the source would certainly be easier. Reverse engineering what needs to be done from the binary is definitely doable, if you had time. Which you don't appear to.

An emulator with a decent debugger would probably make things easier.