Hyperion announces OS 3.1 update

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

[guest11527]

It cant do that ("operate normally") in case of OpenScreen AllocBitmap and some info it needs isn't there.

I *personally* do not believe the job is done by understanding how AllocBitmap is expected to be called. There is most likely more CGfx wants to grab out of the internal structures of intuition, so the job surely doesn't stop there.

I do not need sources, I need an interface description.

[Georg]

I *personally* do not believe the job is done by understanding how AllocBitmap is expected to be called.

With "and some info it needs isn't there" I meant some info it expects in a place (register/stack) that isn't allocbitmap param registers.

So for example if CGX in it's AllocBitMap patch would rely (after detecting the call is
the screen bitmap allocation call inside openscreen) on A4 to point to some info which helps it to figure out the screenmode, then a way to figure that out without knowing about that would be:

- on a working CGX RTG system patch the allocbitmap call such that all registers which are not params for allocbitmap call are trashed.

- this would cause CGX to no longer be able to open RTG screen, because it does not find the necessary info in register A4

- you do not know that the register is A4, so you would change patch so long to narrow it down to register A4

- then you look into original 3.1 openscreen code to see what A4 happens to point to before call to AllocBitMap()

In reality it may be something different, but if you are lucky it may be one part of the puzzle solved. Without having source/interface. And without disassembling CGX AllocBitMap and/or breaking/trapping/single stepping AllocBitMap() call when it happens in OpenScreen, which may be easiest of all, but maybe you prefer to avoid such in your opinion maybe (?) illegal (?) sneaking into foreign code.

[utri007]

Sorry my ignorance, but Power Windows NG has a working hack to do that both PIcasso96 & CGX. Would it be usefull to see how it does that? http://aminet.net/package/util/misc/PowerWinNG_Src

[NorthWay]

Since we're fishing around 3.x - was there a changelog for serial.device 43.1(?)?

[guest11527]

Sorry my ignorance, but Power Windows NG has a working hack to do that both PIcasso96 & CGX. Would it be usefull to see how it does that? http://aminet.net/package/util/misc/PowerWinNG_Src

No, it would not. Because that is a hack on top of the V40 sources where the registers are in place where both CGFx and P96 expects them, and where the structure layout is exactly as both expect them. For V45, we had to use another compiler, so register allocation changed and parameter passing changed.

[ExiE_]

The HDToolBox...  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.

Can you please explain this a bit - "but we are unable to use that code" - are you talking about technical problem or is it copyright again. I am wondering if you are able to use bits of OS4 where possible, or is it out of your reach even though it is both Hyperion business?
First few years OS4 was at least partially running on 68K, so there should be lots of C code replacing old asm ones...

[olsen]

Can you please explain this a bit - "but we are unable to use that code" - are you talking about technical problem or is it copyright again. I am wondering if you are able to use bits of OS4 where possible, or is it out of your reach even though it is both Hyperion business?
First few years OS4 was at least partially running on 68K, so there should be lots of C code replacing old asm ones...

The solution that was used in AmigaOS 3.5/3.9 was developed specifically for these products. As far as I know the contract under which it was developed is still in effect and Haage & Partner controls the use of the software. This is why we cannot use it.

The solution that is used in AmigaOS 4 was licensed for inclusion in the product. Hyperion does not own it. We cannot license it for use in AmigaOS 3.1.4, and even if we could, the size of the application and its reliance on a GUI framework make it somewhat too unwieldy for inclusion. Warts and everything, HDToolBox is pretty small for what it does, and it fits on the installation disk without a problem.

[guest11527]

Since we're fishing around 3.x - was there a changelog for serial.device 43.1(?)?

It looks I don't have one on my record, which does not mean that none exists. However, I can also tell you otherwise what happened. Heinz made the serial.device NSD-compliant, in particular, it does not yet grab its resources on OpenDevice(), which is necessary given the (ill) NSD design. There was also one minimal change in how it blocks and locks interrupts, something I reworked a little bit since it might probably be the reason for some of the problems that were reported. Other than that, nothing serious changed. There will be again a changelog from V45 on.

[fx]

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?

This would be very nice if it was possible to implement without too much hassle. And if not, perhaps something like allowing multiple backtick-commands on a single line could be supported, like WShell allows you to.

[guest11527]

This would be very nice if it was possible to implement without too much hassle.

I wonder why adding another incompatible syntax layer on top of the already inconsistent syntax would really help here. Backticks exist since ages. What do you gain by more syntactic sugar?

And if not, perhaps something like allowing multiple backtick-commands on a single line could be supported, like WShell allows you to.

Ehem. Which shell have you been using the last decade? Go, upgrade your shell to V45, it's in the Aminet. Yes,of course it supports multiple backticks on a line. (-:

[Gulliver]

@Thomas Richter
@olsen

Thank you for being so open and honest to discuss about the update development. Your answers are truly interesting.

Which version number will this update feature? V46? Or just whatever version number comes out from incrementing older components?

Will it feature a less broken cdfilesystem (like cachecdfs in 3.9) and will it have UDF support this time?

Do you plan on including atapiismajik (idefix97 kind of clone), from OS4 Classic, to deal with 4 channel IDE interfaces?

And please, dont waste your time updating for large drive support for the also ancient HDBackup + BRU twin brothers. I have never seen anyone use that pair, and probably for good reason. You could even replace it with former 3rd party commercial tools such as ABackup, which has been recently open sourced, entirely written in SAS/C and residing in Aminet (http://aminet.net/disk/bakup/abackup_src.lha).

[guest11527]

Which version number will this update feature? V46? Or just whatever version number comes out from incrementing older components?

That's undecided. Currently, most components are at V45, some at V46, and many we do not upgrade remain at V40. Make this "probably V46" but I do not know. It is really a formality.

Will it feature a less broken cdfilesystem (like cachecdfs in 3.9) and will it have UDF support this time?

No. It will likely have no CD file system because what was delivered before was just not usable, there is no manpower to fix (or rather rewrite) it, and there are plenty alternatives in Aminet, so you don't miss anything. We don't help anyone by offering a sub-standard system component if better alternatives are existing.

Do you plan on including atapiismajik (idefix97 kind of clone), from OS4 Classic, to deal with 4 channel IDE interfaces?

I need to check what the scsi.device I currently have actually supports. I'm not sure, but it *may* support such things. Anyhow, scsi (aka ide) will get fixes, but not a feature update. Again, this is a bugfix release, not a "please add my favourite feature" release. We don't have the manpower nor the time for it. Leave alone the beta testers to test it properly.

And please, dont waste your time updating for large drive support for the also ancient HDBackup + BRU twin brothers.

No chance, no time. HDToolbox, yes. Backup and BRU go right where they belong: SYS:Trashcan. There are really plenty alternatives with less ancient formats that are more up to date. Really, if you want a backup these days, get a USB adapter and an external harddrive or a thumbstick, and use SortCopy off aminet to make a 1:1 incremental copy of your data. BRU sources are rotten (yes, I really mean it), the program stinks. You don't get tape drives at consumer friendly prices, and you don't get new floppies, so the whole concept of BRU is just broken.

[kamelito]

@Olsen @Thor,
Is there plan to support the Vampire? SAGA, 16bits audio, AMMX1/2 ?

Kamelito

[guest11527]

@Olsen @Thor,
Is there plan to support the Vampire? SAGA, 16bits audio, AMMX1/2 ?

There will be no vampire specific Kickstart. There will be neither a Cyberstorm specific Kickstart, nor a GVP specific Kickstart. If vampire wants to support customized device drivers, there are plenty methods how to add such devices to the system. Autoconfig is one option. Adding the devices to the F-space ROM is another.

[NorthWay]

Other than that, nothing serious changed.

Thanks. I guess I will have to ReSource it to find out if the ancient A6 related bug has been fixed.