Click Here
home features news forums classifieds faqs links search
6005 members 
Amiga Q&A /  Free for All /  Emulation /  Gaming / (Latest Posts)



Lost Password?

Don't have an account yet?
Register now!

Your support is needed and is appreciated as is primarily dependent upon the support of its users.

Main sections
» Home
» Features
» News
» Forums
» Classifieds
» Links
» Downloads
» OS4 Zone
» IRC Network
» AmigaWorld Radio
» Newsfeed
» Top Members
» Amiga Dealers
» About Us
» FAQs
» Advertise
» Polls
» Terms of Service
» Search

IRC Channel
Ports: 1024,5555, 6665-6669
SSL port: 6697
Channel: #Amigaworld
Channel Policy and Guidelines

Who's Online
54 crawler(s) on-line.
 15 guest(s) on-line.
 0 member(s) on-line.

You are an anonymous user.
Register Now!
 simplex:  17 mins ago
 Steady:  23 mins ago
 DiscreetFX:  1 hr 17 mins ago
 freak:  1 hr 21 mins ago
 agami:  1 hr 37 mins ago
 matthey:  2 hrs 24 mins ago
 Hypex:  2 hrs 32 mins ago
 RobertB:  3 hrs 3 mins ago
 JKD:  3 hrs 24 mins ago
 ne_one:  3 hrs 29 mins ago

/  Forum Index
   /  Amiga OS4.x \ Workbench 4.x
      /  New mini update from Hyperion
Register To Post

Goto page ( Previous Page 1 | 2 | 3 | 4 | 5 | 6 )
Re: New mini update from Hyperion
Posted on 19-May-2021 11:04:11
#101 ]
Super Member
Joined: 21-Aug-2003
Posts: 1671
From: Trondheim, Norway



@kolla: He was aware of the release (as every betatester and developer on the AOS4-mailinglist) but it was a positive surprise for him, that the release was ready for December after all.

Update 1 was December 2016 - Update 2 was December 2020 - four years later.

There was no updates of Roadshow components in Update 1, and according to Olsen back then, it was due to Hyperion's way of organizing OS updates - he cannot just release updates when he is ready, it has to be "organized" by Hyperion. Well, 4 years later, and clearly there are no updates to Roadshow components in Update 2 either. I presume this time also due to Hyperion's way of "organizing" updates. Olsen says he couldn't find time in the start of December to get things done. Start of December? Was that when it was decided (by whom?) and "communicated" to developers that there would hopefully be a release at the end of December?

In the meantime, through these years... how many updates have there been to Roadshow for 68k?

My suggestion to whoever is in charge is organize this in a more predictable way - release updates frequently and regularly, so that both developers and user know when updates are due.


 Status: Offline
Profile     Report this post  
Re: New mini update from Hyperion
Posted on 19-May-2021 12:08:54
#102 ]
Cult Member
Joined: 31-Jul-2003
Posts: 574
From: Vienna/Austria



My suggestion to whoever is in charge is organize this in a more predictable way - release updates frequently and regularly, so that both developers and user know when updates are due.

I agree. Let´s hope that the last two mini-updates are a good sign for the future.

I see no reason why bugfixes/minor updates to Roadshow couldn't released in the same way.

AmigaOne X5000/40, 4 GB RAM, Radeon HD 7870 XT

 Status: Offline
Profile     Report this post  
Re: New mini update from Hyperion
Posted on 20-May-2021 6:42:22
#103 ]
Elite Member
Joined: 29-Oct-2012
Posts: 2252
From: Germany

@Trixie Quote:

Trixie wrote:
@cdimauro Quote:
Not only bug-fixes or a few minor new things added, like with the last OS4

You are absolutely right that OS4.1 FE Update 2 only contained bug fixes and minor new things. This is why it's called an update, right?

And I'm absolutely fine with that.

@kas1e Quote:

kas1e wrote:

And while it called "update2" it contain new things.

Please quote me and tell me where I've said that it has no news things.
Check the changelog if you for real interested (but sure you don't as you love to have your agenda and change the opinion based on truth is probabaly not in what you interested, right ?:) .

Now you are trying to cover your *ss.

Don't confuse me with your Talibans: I stick to facts, as I've always proven here.
This update It's that massive, that can't be calle "update", it even can be called a new version of OS if one care. Amount of changes, fixes, improvements are very big for real. So saying "nothing is blablalb", its really wrong and not true.

That's your questionable opinion.
How much i dislike what Ben may do or doing back in past, i still didn't feel it good enough to hide the truth : and truth is that there were a lot of work done on os4 in last years by all os4 developers. And that didn't mean Ben is ok an Hyperion do all allright. Its different matter.

Then you should understand that people can have a certain opinion about Ben and Hyperion, but can still stick to facts when talking about OS4.

The thing which I usually see is that people involved to or which loves Ben/Hyperion defends questionable decisions for OS4, or says that critics to OS4 are an attack to Ben/Hyperion. Another thing is that people which works to or loves OS4 tends to defends it, and by extension defends Ben/Hyperion.

This is ok (by definition) for fanboys/Talibans, but not for professionals, which should stick to facts (especially the technical ones).

While it calle update, it still contain new stuff too:

Then let's take a look at this "new stuff".
1. new dos.library,

These are the changes to dos.library:
@{b}dos v54.107 @{ub}

@{i}NEW @{ui}
o ObtainDirContext() now explicitly checks for NULL taglist
argument, just in case.
o Rewrote FindSegmentStacksize() to now use a dynamic cache
instead of a static model
o MakeLink(LINK_HARD) now checks to be sure the target object
is on the same volume as the hard link
o LoadSeg() now checks for V54 of ramlib if the new elf.library
is installed, shows a requester if ramlib LESSV54.
o Filehandle timestamp field added for open age detection.
o Added the missing complementary 64 bit DoPkt64() to the public
o SameDevice() now works even if the exec device names in the
fssm_Device is UTF-8 encoded.
o Added a validating parameter to file packets, this eliminates
a lot of time wasted doing memory testing calls when the
dospacket hasn't been fully initialized by the sender.

@{i}UPDATED @{ui}
o Removed the old appdir handler code from dos.library.
o Simplified 68K loadseg function, removed unused casts for
initializing hunk.library callback hooks
o We now have an IdString in the dos.library structure.
o Finally renamed the obsolete functions ExAll(), ExAllEnd(),
Examine(), ExamineFH(), ExNext(), Execute(), Seek(), SetOwner(),
SetVBuf(), CreateProc(), DeviceProc(), SetFileSize().
Added these entries to dos/obsolete.h for old source code
o Doslibrary initialization code now opens the hunk and
elf.libraries before the bootcli starts.
o The expansion library is now opened once, instead of once in
doslibinit() and once in initialcli().
o Re-enabled UTF-8 and Non-binding multi-assignment support.
o Reworked the notification handler completely

@{i}FIXED @{ui}
o Fixed a memory leak in UnloadSeg()
o NonBlockingModifyDosEntry(NBM_REMFREEDOSENTRY) would not free
the memory for the doslist node, if the node wasn't actually
present within the doslist.
o Fixed an obscure bug when trying to resolve a softlinked file
when it's in the root of a vector-port filesystem.

... and a lot more bugfixes and stability improvements.

And you call this a "new" dos.library? Seriously?

new handlers (ram handlers,

Ram handle isn't new. And here are the updates:

@{b}ram-handler v54.24 @{ub}

@{i}NEW @{ui}
o Now shows serial debug in memory allocator functions when exec
debuglevel GREATER0
o Softlinks now trim the target block memory, before, it used a
whole block regardless of size used.
o Added support for FSFileSystemAttr() tag FSA_MaxFileSizeR.
o Added FSExamineObj() function.

@{i}UPDATED @{ui}
o Adjusted maximum block size limit to 4MB.
o Block usage in FSDeviceInfoData() is now calculated using a
much faster 64 bit algorithm.
o Blocksizes are now rounded up to exec page sizes (-4), for
a better page fit.
o Relax the block shrinking criteria to allow a final block that is
within 32 bytes of the specified block size to be exempt from
reallocating it.
o FSSetDate() now always sets the date and does a change-update
regardless of the object datestamp.
o FSSetProtection() now always sets the mask and does a change-update
regardless of the object mask.
o FSSetOwner() now always sets the value and does a change-update
regardless of the object owner value.
o FSSetGroup() now always sets the value and does a change-update
regardless of the object group value.
o FSExamineObj() now only increments the hardlinked counter for
hardlink target objects.
o All examination function now use a common examinedata filling

@{i}FIXED @{ui}
o Inhibit() now works every time for anyone who actually expected it
to be inhibitable.
o Opening a new file and closing it without writing, would create a
zero byte file that would try and have the one and only block
shrunk to zero bytes, this would fail with just debug shown,
as it wasn't critical, but would just leave the full sized block
in place, now, if an empty file is closed, it still needs a block,
but the minimum allocation size is limited to 16 bytes.
o Creating hardlinked directories now fail if they were to cause a
directory loop.
o Creating hardlinks to targets on another volume now return the
correct failure code.
o Now fails to create any object with a colon or slash in the name.
o FSRelabel() and FSRename(), they now fail to allow a name with a
colon or slash.

appdir handler,

@{b}appdir-handler v54.17 @{ub}
The appdir-handler creates the "APPDIR" filesystem DOS device.
The filesystem presents the global variable cache in ENVARC:Appdir/ as
a virtual disk of softlinks that causes DOS to automatically resolve
all references to the target objects, as it would do with any softlink.

@{i}NEW @{ui}
o Initial release

Finally a new thing. Now the question: how does this changes the user experience?
env handler etc),

This isn't new as well. Here is the change log:

@{b}env-handler v54.18@{ub}

@{i}NEW @{ui}
o Attempting to delete the root dir now returns
o Env-handler dostype now identifies as 'ENV\1'
o FSFileSystemAttr() now supports FSA_MaxFileSizeR tag.

@{i}UPDATED @{ui}
o Simplified memory allocator and changed block size to 1K for

@{i}FIXED @{ui}
o Memory now gets cleared only when required.
o FSRelabel() now returns the correct error code.
o FSChangeFileSize() now respects the write protection attribute.
o Now fails to create any object with a colon or slash in the name.
2. pasemi_dma.resource

Yes, this is a new thing. Now let's take a look at the changelog:

@{b}pasemi_dma.resource v53.3 @{ub}
pasemi_dma.resource is a new kickstart component, used only on
the AmigaOne X1000. This needs to be added in the Kicklayout
file, before the MODULE Kickstart/graphics.library.kmod

@{i}NEW @{ui}
o Initial release

Are you serious? Do you know when the AmigaOne X1000 was released? And now it's time for it to have the DMA...
3. Append cmd

Yes, new stuff, for sure. Here's the change log:

@{b}Append_cmd v54.2 @{ub}
Append adds a given string, file or the output of a command, to the
end of another file, extending the original file as required. The new
content may be binary or ASCII.

@{i}NEW @{ui}
o Initial release

Now for exercise you can implement in Python this killer feature...
4. DiskDoctor v2

New stuff, sure. Change log here:

@{b}DiskDoctor v2.155 @{ub}
DISKDOCTOR version 2 attempts to find defects on a volume which may
or may not be corrupted, subsequently allowing you to have its
contents copied onto a different volume. The copy operation attempts
to reproduce the original file structure, including all the
properties of the files, directories, hard and soft links found.

You can use DISKDOCTOR on any volume which has been formatted using
the original Amiga file system, aka. OFS, (1986), the Amiga fast file
system, aka. FFS, (1987) and the modern Amiga file system versions
which are derived from them (1989-2006) which include the
international mode (1991), dircache mode, aka. DCFS/fastdir (1992)
and long name mode, aka. LNFS, (2006).

@{i}NEW @{ui}
o Initial release

I agree that this is an important addition for the end user, especially with the fragile filesystems which are used in the Amiga land.

However and correct me if I'm wrong, this was an external tool which is now just added to OS4.
5. SataControl

New tool. Let's see the change log:

@{b}SATAControl v54.1 @{ub}
SATAControl is a tool for interacting with the following SATA drivers
at runtime:

SATAControl will do nothing if used on an incompatible device.

@{i}NEW @{ui}
o Initial release

Similar question here: how does this changes the user experience?
6. ssh2-handler

New thing. Let's see the change log:

@{b}ssh2-handler v53.12 @{ub}
ssh2-handler is filesystem for accessing files remotely using the SFTP
protocol. It is based on libssh2 1.8.0 and uses AmiSSLv4 for SSL

@{i}NEW @{ui}
o Initial release

Nice. I don't know the last time which I've used sFTP, but for people which needs it I think that it can be useful (no joke).
That just brief check on above.

Then please it's better to check it again and bring some real cake, because I don't see much value on it.

BTW, many things which are reported as UPDATEs are FIXEs in reality.
But i am sure cdimauro doesn't much care about while have his opinion without knowing the details :)

I took a look at the details: you should be satisfied now, at list from this PoV.

However I don't think that you'd like my answers. But this is a different story. Maybe you'll understand them when you become a professional and treat the things (especially the technical ones) as they are.

I've spent my free time budget for today, so time to go work now.

 Status: Offline
Profile     Report this post  
Re: New mini update from Hyperion
Posted on 20-May-2021 22:58:53
#104 ]
Super Member
Joined: 8-Apr-2003
Posts: 1009
From: Copenhagen, Denmark




Are you serious? Do you know when the AmigaOne X1000 was released? And now it's time for it to have the DMA...
It had it also before. The change is that the implementation has been moved out of the main kernel into a separate module, which means it only needs to occupy space in memory on the machine type (X1000) where it is used.

Best regards,


Last edited by nbache on 20-May-2021 at 10:59 PM.

 Status: Offline
Profile     Report this post  
Re: New mini update from Hyperion
Posted on 21-May-2021 6:45:42
#105 ]
Elite Member
Joined: 29-Oct-2012
Posts: 2252
From: Germany

@nbache Quote:

nbache wrote:



Are you serious? Do you know when the AmigaOne X1000 was released? And now it's time for it to have the DMA...

It had it also before. The change is that the implementation has been moved out of the main kernel into a separate module, which means it only needs to occupy space in memory on the machine type (X1000) where it is used.

Best regards,


Thanks for the clarification. Then it's not even a new feature: the component is new, but not the feature, so it doesn't change anything to the user.

Whoever has written the changelog should have made it more clear, instead of causing confusion to the reader.

Anyway, it's an amateur project, as it's also evident from the other mistakes about what should be a fix, an update, or a new feature. Cannot pretend a work of professionals.


@matthey Quote:

matthey wrote:
cdimauro Quote:

Hum. I think that here Mr. Jenison was mixing two things.
The VideoToaster was possible because the Amiga had a system clock which was synched with TV standards (also PAL in Europe, and SECAM in France), so implementing a genlock was a perfect fit.

However this doesn't tell anything concrete about the Amiga o.s. capabilities as real-time o.s.. I mean: I don't see how the Amiga hardware allows the Amiga o.s. to be entitled as "real-time".

Those are just declarations to me, but not proofs: no facts supporting the statements.

It is the Amiga hardware and software working together which allowed the Toaster to be real time for that application. The best real time systems in the world aren't fast enough or responsive enough to measure or respond to something like particles traveling near the speed of light measured by copper wires yet they are called real time. They are real time for their applications and they use a RTOS which is designed for real time use. A RTOS installed on some hardware will not be responsiveness to be real time for some applications. A non-real time OS will be responsive enough for some real time applications. There are no latencies or timings which universally define real time but there are for particular applications. The AmigaOS was designed to be minimal and responsive and it allowed the Amiga to be used for more real time applications than most other desktop computers. The AmigaOS design resembles a RTOS yet was targeted at the desktop instead of embedded markets.

I've no problem accepting that the Amiga, has a complete platform (hardware + software), was capable of real-time work.

My problem, as a computer scientist, is to understand how the two separate things, the hardware and the software, can be classified as "real-time". So, it's also a technical question / definition.
FIDO is a clear example of real-time hardware.
For the Amiga o.s. this cannot apply, IMO, because there's no statement that says that it can guarantee to a system call can return within a certain number of milliseconds.
I wonder how many of those preemptive multitasking microkernel RTOSs copied the AmigaOS design which predates them.

It would interesting to know.
The 68k architecture was the most popular for 32 bit embedded use, then SuperH and then ARM Thumb2 which were each influenced by the predecessor. The embedded software and hardware ended up looking like the Amiga.

I don't know about the Amiga, but certainly for its processor.

You can take a look at Infineon's TriCore architecture, which IMO is the one which has copied/inspired most from the 68K, and specifically for the embedded (automotive) market.
cdimauro Quote:
I think that we're mixing different things here as well.

As I've already said, I've no problem stating that the Amiga o.s. was/is a very good candidate for being used for embedded markets.

However in such market hardware and/or software compatibility isn't very important.

Specifically, the Amiga hardware can be an handicap, because this forces the Amiga o.s. to be bounded to this hardware, whereas on an embedded system you may not need this hardware (I/O is much more important; and CIAs aren't strictly bounded to the Amiga hardware). What I want to say is that you don't need to have any display logic, the Copper, the Blitter, the audio channels, etc. etc. Embedded needs are... custom, but from another perspective.

Hardware and software compatibility is nice for embedded too! Some embedded applications have requirements where this is not possible, especially minimal embedded systems for energy savings or cost reduction but there are many embedded applications where a standard system is invaluable. The extra hardware features are usually not a problem for embedded use as can be seen on the Raspberry Pi and can be appealing for many embedded uses. It was the default monolithic Linux OS which was swapped out as it was not responsive enough or small enough memory footprint for some embedded uses. Would this be a problem for the AmigaOS on standard and cheap hardware?

Clearly no, but the Amiga has other problems: the custom chips are gone with Commodore.

As an Amiga developer I certainly see value on an embedded system which is based on the Amiga platform (hardware + software), because I can reuse the acquired knowledge (well, after so many years I've serious problems start coding again for it).

The problem is, that this platform is not available on the embedded market, but only on some nano-niches.
cdimauro Quote:
Those look kluges to me, applied to solve a very bad design problem.

The problem was that the Motorola 68000 CPU design and the Amiga custom chip design were not fully compatible so no CAS or TAS instructions were allowed.

The primary problem was that the Amiga engineers made an enormous mistake by not giving the Amiga a real fast ram, even only a reduced quantity (as a game coder I greatly prefer to have as many chip ram as possible). Instead they added the so called "slow-ram", which is neither chip nor fast ram: it has the disadvantage of both! It's incredible how naives were the Amiga engineers not realizing this stupid mistake.

Because with the fast ram then you had the chance to use CAS or TAS instructions!
Supporting SMP may have been a problem anyway as it was not clear back then that it would be so important in the future.

Hum. Not clear for the Amiga / Commodore maybe, but not for the industry, because there were already multi-processors systems.
The AmigaOS actually holds up better than most of the old single tasking or cooperative multitasking systems. The hardware limitations didn't keep CBM from experimenting with multi-core solutions using hardware.

That's true, but the original mistake cannot be fixed, even nowadays: it was/is too late.
cdimauro Quote:

I hope that he wasn't involved on the Aquarius project:

I expect Aquarius was the project Carl Sassenrath was working on. He left when he realized it was too ambitious and before it was cancelled.

It was clearly too ambitious: it's enough to quickly read the specs overview to realize it.

It recalls me Intel's iAPX432 "Object-oriented processor"...

 Status: Offline
Profile     Report this post  
Goto page ( Previous Page 1 | 2 | 3 | 4 | 5 | 6 )

[ home ][ about us ][ privacy ] [ forums ][ classifieds ] [ links ][ news archive ] [ link to us ][ user account ]
Copyright (C) 2000 - 2019 was originally founded by David Doyle