Hyperion announces OS 3.1 update

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

[guest11527]

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

Hopefully. Sorry if I sound stupid,but what is the A6 related bug?

[olsen]

@Thomas Richter
@olsen

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

Questions answered by software engineers can have interesting consequences (as in: reduced number of sales, lawsuits, etc.). I'm keeping my fingers crossed that we won't say anything we'll have to regret later, or regret more than we can already expect to regret given the state of the code and the manpower required to update and test it...

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

I believe that CacheCDFS was licensed for inclusion in AmigaOS 3.9. We currently try to do with what we have (CDFS, originally created for the CDTV by Carl Sassenrath), and for which Hyperion already has a license.

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.

BRU was originally intended to be used for data exchange between Amiga Unix and AmigaOS. This actually worked, if you used the A3070 tape drive. It also worked with floppy disks, using the same logic that must have been used for multi-reel tape backups back in the days of Unix version 7  This shows both the flexibility of the software, as well as its adaptability.

The Amiga version of BRU was a strange beast, as it worked almost exactly like the Unix version, with platform-specific adaptations (e.g. hard and soft link support). The HDBackup front-end was added so that you would not need to use BRU in the shell.

BRU goes back a long time and was either created or co-created by Fred Fish (I don't remember the details, but there's your Amiga-connection). The company which created the Amiga port and HDBackup (Software Enhancement Technologies) used to be around until recently. BRU is still a commercially supported product, just not on the Amiga. Chances are that your BRU backups from way back in 1991 are still readable with the modern BRU.

Anyway, the BRU and HDBackup code are not really useful anymore (unless you need to dump those old BRU backup tapes before they decay) and upgrading either to "modern" standards is not planned. Back in 1990/1991 they may have been state of the art, and BRU was possibly even "grossly over-engineered" for use on the Amiga. Today we have alternatives which are better adapted to the Amiga platform.

[NorthWay]

Hopefully. Sorry if I sound stupid,but what is the A6 related bug?

Not stupid at all. There was an ancient long-lived bug where (IIRC) A6 was treated as if it was pointing to the device base while it was actually some struct on the stack.

I have the original bug report at home somewhere. Oh yes, reported by the guy who made this http://aminet.net/package/comm/misc/ArtSer37_6

[Tenacious]

18 years ago, the Y2K bug created a lot of buzz about the way various platforms track the date and time.  It came to light, that there is a date in the Amiga's future (is it 2032?) when the original system for tracking seconds fills to the last digit.  It is an interesting problem.

Can this be fixed?

If not, can another system or workaround run along-side the original code to keep our Amigas tracking the date indefinitely?

Some might snap back that the hardware will be dead by 2032.  Maybe.  Who in 1985 imagined that there would be a fanatical Amiga following in distant 2017?

[Tenacious]

Gulliver

It is great to see you taking an interest in this.

[guest11527]

18 years ago, the Y2K bug created a lot of buzz about the way various platforms track the date and time.  It came to light, that there is a date in the Amiga's future (is it 2032?) when the original system for tracking seconds fills to the last digit.  It is an interesting problem.

Can this be fixed?

Probably not. By this time, I will be retired anyhow. (-: The problem is that the system time is in a 32-bit integer, in seconds since 1979 or so, which runs out in 2036 if I computed correctly.

So yes, we would need a 64-bit timer device and a 64-bit system time by then.

[guest11527]

Not stupid at all. There was an ancient long-lived bug where (IIRC) A6 was treated as if it was pointing to the device base while it was actually some struct on the stack.

If you can dig it out, I can look into it, but ad hoc, I don't see anything suspicious in the code. Actually, I *did* review this for a while and made two minor improvements that might help througput a little bit. However, serial is quite generic - with less options, it could be faster.

[NorthWay]

I found the original that should be in the bug db:

# Subject: Bugs in serial.device 37.4
# Type: bug
# Subsystem: serial.device
# Severity: b
# Release: KS=40.9,WB=40.6,Program=37.4
# Date: Fredag 23-Apr-93 02:53:23
# Refer: Nilsen,Petter (Ultima Thule Software ,phone +47-84-14250)
# Path: petter@pnilsen.adsp.sub.org
# ReferID: ETN007
# Config: a4000,68040,A=AA,D=AA,RAM=2megC/8megF,TD=1,HD=IDE,

### BRIEF BUG DESCRIPTION:

This is a posting on behalf of Arthur Hagen (*Art), author of the
artser.device which is a replacement device for serial.device.
He has discovered some bugs in serial.device which I have taken on
me to let you know of.

### BUG GENERATION PROCEDURE OR EXAMPLE:

Arthur Hagen writes:

There is a bug in serial.device 37.4 that seldom manifests, although
it should be fixed.  In the device's Close-routine, the macros
DISABLE/ENABLE are used without ExecBase in a6.  Normally, this won't
pose a problem, except that a byte in the positive part of the serial
structure will be temporarily trashed (luckily this is the MSB of the
mn_Pred of one of the internal IO-requests, and it won't be accessed
while multitasking is disabled).  But if this byte contains a positive
value (on a machine with 68012 or higher this could happen), inter-
rupts won't be reenabled at the correct time, but far later (if ever).

### IF THIS WORKS DIFFERENTLY ON OTHER VERSIONS OR HARDWARE, EXPLAIN:

Don't know.

### RELATED PROBLEMS:

Don't know.

[QuikSanz]

Probably not. By this time, I will be retired anyhow. (-: The problem is that the system time is in a 32-bit integer, in seconds since 1979 or so, which runs out in 2036 if I computed correctly.

So yes, we would need a 64-bit timer device and a 64-bit system time by then.

How about rewrite that piece of code and set the start date at Jan 1 2015?

[Oldsmobile_Mike]

How about rewrite that piece of code and set the start date at Jan 1 2015?

Heck, set it for 1/1/2000. Probably would still outlast all of us at that point.

[Tenacious]

I need to dig out an A500 without critical files on it and set the date to beyond its limit and see what happens to system time, file stamps, the RTC, etc.  What happens when rebooted?

[LoadWB]

I need to dig out an A500 without critical files on it and set the date to beyond its limit and see what happens to system time, file stamps, the RTC, etc.  What happens when rebooted?

See you in hell.

[fx]

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?

Backticks exists in unix-shells aswell but the gain is that you can nest things with the $(command) syntax. Now you sometimes need to break things up on multiple lines to obtain the same result. I don't think the exact same bash-like syntax would be necessary but I would really like the ability to nest commands if possible!

Something like:
Echo "$(dir $(cd))"
Which is a very bad and useless example but I just tried to come up with something quickly

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. (-:

Well, the default 3.1 shell mostly and the 3.9 one on one computer :O I have never updated my shell but I certainly need to do that now Happy to hear that is already in there!

[chris]

How about rewrite that piece of code and set the start date at Jan 1 2015?

That'll screw up all dates that are stored as a 32-bit integer.  I suspect this includes FFS.

I need to dig out an A500 without critical files on it and set the date to beyond its limit and see what happens to system time, file stamps, the RTC, etc.  What happens when rebooted?

I think the RTC will be OK until 1 Jan 2078, but SetClock won't understand the date and will probably fail with invalid data, or will overflow and set some obvious incorrect time.

There's no easy solution to this, all the instances where a 32-bit timestamp is stored will need to be changed, and all software which uses timer.device directly will need to be adapted to use a 64-bit value.  Everything using the old 32-bit API will break with dates after 2036.  I don't think there is any way to workaround this problem other than assuming the overflow has happened, and then you're breaking dates before 2036 which isn't necessarily an improvement.

I suppose you could say "high bit set means before 2036, high bit not set means after 2036", but you're still breaking dates before 2007, and only delaying the problem for another 29 years.

[guest11527]

That'll screw up all dates that are stored as a 32-bit integer.  I suspect this includes FFS.

No, FFS is fine. AmigaOs was always two operating systems under one hood, the "exec" part, and the "dos/Tripos" part. Surprisingly, as far as time is concerned, "dos" is fine. Its datestamp structure can keep time for a long, long while. Just the timer.device branch is broken, so the conversion between the dos and timer is broken.