@AP

Quote:

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

_________________
B5D6A1D019D5D45BCC56F4782AC220D8B3E2A6CC

@kolla

Quote:

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, 2.2 Ghz, 4 GB RAM, Radeon R9 280X, M-Audio Revolution 5.1, 240 GB SSD

@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: @cdimauro http://kas1e.mikendezign.com/aos4/ChangeLog_os4fe_update2.guide 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.
Quote:

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

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

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).
Quote:

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

Then let's take a look at this "new stuff".
Quote:

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
interface.
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
compatibility.
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?

Quote:

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

@{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.

Quote:

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?
Quote:

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
ERROR_OBJECT_IN_USE instead of ERROR_OBJECT_NOT_FOUND.
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
infodata.

@{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.
Quote:

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

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

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

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:
p50x0sata.device
p1022sata.device

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?
Quote:

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
encryption/decryption.

@{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).
Quote:

That just brief check on changelog.guide 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.
Quote:

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.

@cdimauro

TL;DR

But:

Quote:

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,

Niels

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

@nbache Quote:

nbache wrote: @cdimauro TL;DR But: Quote: 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, Niels

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.

Bests,
Cesare


@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.
Quote:

I wonder how many of those preemptive multitasking microkernel RTOSs copied the AmigaOS design which predates them.

It would interesting to know.
Quote:

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

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

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!
Quote:

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

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

cdimauro Quote: I hope that he wasn't involved on the Aquarius project: http://tenfourfox.blogspot.com/2019/12/and-now-for-something-completely_29.html https://archive.org/details/scorpius_architecture/mode/2up 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"...

@matthey

Quote:

Perhaps "allows" would have been a better word to use than "adopted" for AmigaOS 4 introducing an optional but inferior .so library standard but "adopted" does not infer one standard or even a preferred standard. If lowering quality standards and introducing inferior technology is thought to be the best way to proliferate the Amiga then something is wrong. AmigaOS 4 isn't proliferating because the desktop hardware it runs on doesn't have a good price/performance ratio and the desktop features aren't competitive.

Depends how you look at it. The .so standard is an external standard. But I don't recall .library being a standard used elsewhere in the world. It's also somewhat esoteric as it has jump pointers moving backwards. I don't recall any features of C that let you specify or naturally access negative positions in a structure. The point of course is to make porting software easier. This is what holds any AmigaOS back. Anything not Windows is considered Unix and that goes beyond complications of configuring a makefile.

I suppose the DLL standard could have been adopted instead. Given it's closer to the Amiga library standard it could make sense to do so. So that Windows DLL can be more easily compiled. Is it any less foreign than a .so? After all, AmigaOS is not Unix, so that places it with Windows.

If the MorphOS guys decided on Amiga library for SDL it would surely need some extra work. Since it wouldn't be written that way and they would need customise the open and close mechanism as well as in client code. But while we are at it what does OSX use? OSX apps are constructed like Amiga apps. They can use local libraries included in app or system wide ones. Unfortunately this system can break. The one time I have seen it fail on OSX was when I tested a PPC port of FS-UAE because all the depends were not included. It was clear it was compiled by an Amiga person because it didn't work out of the box. Amiga developers have a bad reputation for releasing complete builds of software that simply don't work. The user is expected to have a system that is an exact duplicate of the developer with libraries, volumes and all extra stuff installed and rarely it seems does a developer do a proper test on a bare bones install. I've even seen apps fail to open a library when the library was was there in a LIBS subdir and that takes talent.

Hypex Quote:

Depends how you look at it. The .so standard is an external standard. But I don't recall .library being a standard used elsewhere in the world. It's also somewhat esoteric as it has jump pointers moving backwards. I don't recall any features of C that let you specify or naturally access negative positions in a structure. The point of course is to make porting software easier. This is what holds any AmigaOS back. Anything not Windows is considered Unix and that goes beyond complications of configuring a makefile.

Almost all CPU architectures use signed displacements for pointer offsets. The 88k architecture tried to make some displacements unsigned and it caused major problems so they changed back to signed. As I recall, it was the Unix like kernels which were using negative offsets and compiler maintainers complained first during 88k development (source likely Mitch Alsup). A simple example would be a dynamic memory allocation pointer where the allocation size is kept at a negative offset. This is used on the Amiga too as well as the small data first data location starting at the most negative offset (negative offsets are hidden to even assembler programmers). Negative offsets from pointers work fine in C and they can be used. In some cases, a new pointer is created and positive offsets are used while the original pointer at a negative offset is off limits or hidden and should not be accessed. I don't believe negative library offsets were a problem although some architectures like PPC require multiple instructions to jump to a subroutine (JSR on 68k). It would have been more optimal if the offsets were 4 byte aligned instead of 2 (multiples of 4 bytes instead of 6 bytes) but most RISC processors are going to be restricted to jumping/branching no more than 64kiB (16 bit displacement) with the one instruction that fits in 6 bytes. Since RISC with 32 bit fixed length instructions took over after the 68k Amiga, the Amiga library system likely didn't appear worthy to copy. Indeed, it it less optimal on PPC Amigas as we could see when examining the PPC code. There was also no 64 bit Amiga library support, which as far as I'm aware, there is not today despite some PPC Amigas using 64 bit processors.

Hypex Quote:

I suppose the DLL standard could have been adopted instead. Given it's closer to the Amiga library standard it could make sense to do so. So that Windows DLL can be more easily compiled. Is it any less foreign than a .so? After all, AmigaOS is not Unix, so that places it with Windows.

Microsoft would have been better off copying the Amiga library standard but then they didn't have a flat memory space but rather segment hell because of x86. Then they created an inferior library system and DLL hell.

https://en.wikipedia.org/wiki/DLL_Hell

The answer to most of the incompatibility and security problems of DLLs is to not share these libraries. Address space conflicts can also result in multiple copies of the same library loaded in memory. The Amiga doesn't have the incompatibility problems as long as there is one upgrade path. The most common Amiga library problems are an old library that needs to be upgraded or a buggy library that needs to be rolled back to a previous version. The Amiga is superior at code sharing because of Amiga libraries. The 68k has superior PC relative code than x86 when DLLs were developed which helps with code sharing. The Amiga 68k libraries are simpler with less overhead while DLLs are more flexible. It would be nice if Amiga libraries supported shared and private data sections which may make compatibility with other library standards easier. Even the 68k should have a way to specify memory protection attributes for sections. The Amiga library standard was good although perhaps too architecture dependent and too rarely upgraded with improvements.

Hypex Quote:

If the MorphOS guys decided on Amiga library for SDL it would surely need some extra work. Since it wouldn't be written that way and they would need customise the open and close mechanism as well as in client code. But while we are at it what does OSX use? OSX apps are constructed like Amiga apps. They can use local libraries included in app or system wide ones. Unfortunately this system can break. The one time I have seen it fail on OSX was when I tested a PPC port of FS-UAE because all the depends were not included. It was clear it was compiled by an Amiga person because it didn't work out of the box. Amiga developers have a bad reputation for releasing complete builds of software that simply don't work. The user is expected to have a system that is an exact duplicate of the developer with libraries, volumes and all extra stuff installed and rarely it seems does a developer do a proper test on a bare bones install. I've even seen apps fail to open a library when the library was was there in a LIBS subdir and that takes talent.

Apple uses Mach-O format .dylib which is comparable to ELF format .so and PE format .DLL for dynamic libraries.

https://en.wikipedia.org/wiki/Comparison_of_executable_file_formats

Amiga libraries are very easy to use but more difficult to create because of restrictions. Those restrictions do allow for some of the best code sharing in memory and ROM (NAND flash today). The library version system has worked well to avoid incompatibility problems. These advantages can be sacrificed for faster porting. Without competitive hardware which brings a larger user base and more developers, the Amiga is lucky to get even quick and dirty ports. The decline of software quality is likely to lead to the user base shrinking further.

Last edited by matthey on 19-Sep-2021 at 09:34 PM.

@matthey

Quote:

The answer to most of the incompatibility and security problems of DLLs is to not share these libraries. Address space conflicts can also result in multiple copies of the same library loaded in memory. The Amiga doesn't have the incompatibility problems as long as there is one upgrade path. The most common Amiga library problems are an old library that needs to be upgraded or a buggy library that needs to be rolled back to a previous version. The Amiga is superior at code sharing because of Amiga libraries. The 68k has superior PC relative code than x86 when DLLs were developed which helps with code sharing. The Amiga 68k libraries are simpler with less overhead while DLLs are more flexible. It would be nice if Amiga libraries supported shared and private data sections which may make compatibility with other library standards easier. Even the 68k should have a way to specify memory protection attributes for sections. The Amiga library standard was good although perhaps too architecture dependent and too rarely upgraded with improvements.

WHDLoad can load separate Kickstart ROM image with corresponding Workbench installation from WHDLoad's data directory. Quitting the WHDLoad session restores the previous OS state. WHDLoad is effectively a single task weak hypervisor.

_________________
Ryzen 9 7900X, DDR5-6000 64 GB RAM, GeForce RTX 4080 16 GB
Amiga 1200 (Rev 1D1, KS 3.2, PiStorm32lite/RPi 4B 4GB/Emu68)
Amiga 500 (Rev 6A, KS 3.2, PiStorm/RPi 3a/Emu68)

@cdimauro

Amiga 500's Slow RAM with ECS Agnus can be considered to be Chip RAM since it can be accessed at different memory address locations. $C address is for backward compatibility.

_________________
Ryzen 9 7900X, DDR5-6000 64 GB RAM, GeForce RTX 4080 16 GB
Amiga 1200 (Rev 1D1, KS 3.2, PiStorm32lite/RPi 4B 4GB/Emu68)
Amiga 500 (Rev 6A, KS 3.2, PiStorm/RPi 3a/Emu68)

@cdimauro

Just becouse Ben is ass, does make other peaple a ass too, and just becouse Ben is ass, does not make it ok to do shity things, to prohibit development of AmigaOS.

Last edited by NutsAboutAmiga on 20-Sep-2021 at 06:16 PM.

_________________
http://lifeofliveforit.blogspot.no/
Facebook::LiveForIt Software for AmigaOS

@NutsAboutAmiga

Quote:

Just becouse Ben is ass, does make other peaple a ass too

Ben:

(_!_) 

      _\       
       /`b  
  /####J   
   |\ ||

_________________
B5D6A1D019D5D45BCC56F4782AC220D8B3E2A6CC

@kolla



Excattly. Anyway we need to get back to writing code, not wast time in the legal system.

Last edited by NutsAboutAmiga on 20-Sep-2021 at 07:27 PM.
Last edited by NutsAboutAmiga on 20-Sep-2021 at 07:26 PM.

_________________
http://lifeofliveforit.blogspot.no/
Facebook::LiveForIt Software for AmigaOS

Hammer Quote:

WHDLoad can load separate Kickstart ROM image with corresponding Workbench installation from WHDLoad's data directory. Quitting the WHDLoad session restores the previous OS state. WHDLoad is effectively a single task weak hypervisor.

Yes, that is true of WHDLoad which I have considered before. It is possible to provide process isolation by having different isolated hardware contexts and each context using its own copy of resources like libraries. The CPU32 Fido can do this. Multiple Amiga processes in contexts at the same time would be trickier as that requires some form of resource sharing, especially for screen display. Not sharing resources increases the memory footprint eliminating one of the Amiga's advantages although it would be useful to isolate certain untrusted processes.

@matthey

Quote:

matthey wrote: Hammer Quote: WHDLoad can load separate Kickstart ROM image with corresponding Workbench installation from WHDLoad's data directory. Quitting the WHDLoad session restores the previous OS state. WHDLoad is effectively a single task weak hypervisor. Yes, that is true of WHDLoad which I have considered before. It is possible to provide process isolation by having different isolated hardware contexts and each context using its own copy of resources like libraries. The CPU32 Fido can do this. Multiple Amiga processes in contexts at the same time would be trickier as that requires some form of resource sharing, especially for screen display. Not sharing resources increases the memory footprint eliminating one of the Amiga's advantages although it would be useful to isolate certain untrusted processes.

With 128 MB Fast RAM on Amiga 1200, it's freedom on the Amiga when compared to my early 1992 era Amiga 3000/030 with 2MB Chip RAM and 4 MB Fast RAM.

Shapeshifter can have 32 MB RAM with MacOS 8.0.

My Amiga 1200 has 32 GB and 16 GB flash storage devices, hence I'm okay with multiple WHDLoad's virtual machine Workbench installations and Shapeshifter's MacOS hard disk images.

In terms of retro computing, my Amiga 1200 with TF1260 handles both AmigaOS and MacOS 68K.
I need to figure out running Atari TOS on the Amiga.

_________________
Ryzen 9 7900X, DDR5-6000 64 GB RAM, GeForce RTX 4080 16 GB
Amiga 1200 (Rev 1D1, KS 3.2, PiStorm32lite/RPi 4B 4GB/Emu68)
Amiga 500 (Rev 6A, KS 3.2, PiStorm/RPi 3a/Emu68)

@matthey

You are now entering the realms of memory protection and not so flat memory space.

_________________
B5D6A1D019D5D45BCC56F4782AC220D8B3E2A6CC

@Hammer

EmuTOS is the keyword, an "atari kickstart" for Amiga.
I don’t know if anyone made a WHDLoad of EmuTOS…

_________________
B5D6A1D019D5D45BCC56F4782AC220D8B3E2A6CC

@matthey Quote:

matthey wrote: I don't believe negative library offsets were a problem although some architectures like PPC require multiple instructions to jump to a subroutine (JSR on 68k). It would have been more optimal if the offsets were 4 byte aligned instead of 2 (multiples of 4 bytes instead of 6 bytes) but most RISC processors are going to be restricted to jumping/branching no more than 64kiB (16 bit displacement) with the one instruction that fits in 6 bytes.

This is one of the other big mistakes of the Amiga o.s. developers: they should have aligned the library call entries to 64-bit size / 8-bytes to favor faster access to 32-bit processors and the ones with data caches.

The whole Amiga platform, both hardware and software sides, seems to be affected by the "16 bits ought to be enough for anybody" mantra...
Quote:

Since RISC with 32 bit fixed length instructions took over after the 68k Amiga, the Amiga library system likely didn't appear worthy to copy. Indeed, it it less optimal on PPC Amigas as we could see when examining the PPC code. There was also no 64 bit Amiga library support, which as far as I'm aware, there is not today despite some PPC Amigas using 64 bit processors.

Because there's no 64-bit Amiga o.s..

AROS has a 64-bit flavor and also MorphOS seems to being ported to x64, but I have no idea about how they implemented library calls. Keeping the 6 bytes convention they might:
- load an offset to a register;
- do a short jump to some (common) library's code which is near the library header;
- finally, the common code takes the offset, calculates the real address to jump to, and then makes the final jump.
But it's just an idea.
Quote:

Microsoft would have been better off copying the Amiga library standard but then they didn't have a flat memory space but rather segment hell because of x86. Then they created an inferior library system and DLL hell. https://en.wikipedia.org/wiki/DLL_Hell The answer to most of the incompatibility and security problems of DLLs is to not share these libraries. Address space conflicts can also result in multiple copies of the same library loaded in memory. The Amiga doesn't have the incompatibility problems as long as there is one upgrade path. The most common Amiga library problems are an old library that needs to be upgraded or a buggy library that needs to be rolled back to a previous version. The Amiga is superior at code sharing because of Amiga libraries. The 68k has superior PC relative code than x86 when DLLs were developed which helps with code sharing. The Amiga 68k libraries are simpler with less overhead while DLLs are more flexible.

True: Amiga libraries are very nice, simple, and efficient solutions to share code.

Nowadays I would have preferred a slightly but more efficient mechanism: replacing a library call with a JSR/CALL to an absolute address (for 32-bits code; to a RIP relative offset for 64-bit systems), to avoid the double jumps (or some stub code).
Quote:

It would be nice if Amiga libraries supported shared and private data sections which may make compatibility with other library standards easier. Even the 68k should have a way to specify memory protection attributes for sections.

That's a big problem, because it requires either a PMMU (which you don't like) or duplicating the library header + jump table each time that a library is opened by a task/thread/process.
Quote:

The Amiga library standard was good although perhaps too architecture dependent and too rarely upgraded with improvements.

As usual, in the Amiga land: very short vision. They've just gone for quick (and often dirty) solutions to the problems which suddenly popped-up during the development...

@Hammer Quote:

Hammer wrote: @cdimauro Amiga 500's Slow RAM with ECS Agnus can be considered to be Chip RAM since it can be accessed at different memory address locations. $C address is for backward compatibility.

True. That's an inheritance of the OCS chipset paired with the need to keep-up with the very bad code which was written by stupid game developers which didn't even opened the Commodore Guidalines...

@NutsAboutAmigaQuote:

NutsAboutAmiga wrote: @cdimauro Just becouse Ben is ass, does make other peaple a ass too, and just becouse Ben is ass, does not make it ok to do shity things, to prohibit development of AmigaOS.

Just because you like Ben's ass and you constantly make it clean doesn't mean that you have to continuously bash and defame what YOU recognized like his "enemies".

You're a so blind Taliban about Ben (and OS4) that you might defend him even if he rapes a child. AND, of course, you'd accuse Michele Battilana of having done it!

I never saw a fundamentalist like you 'til now: it's incredible at which very low-level of humanity you can go down to defend your idol.

Clarified that (which should be obvious to the users of this forum, which knows very well you), again no: there's no one which is prohibiting any development of the AmigaOS, if you intend OS4 (because there was no AmigaOS in the Commodore age: it was just the Amiga o.s.. Or... Kickstart... Or Workbench... Or AmigaDOS).

If OS4 is gone (not officially, but the lack of development is quite evident. Bug fixes and small improvements are coming only because of the charitable activity of unpaid external developers which still don't recognize the situation and continue to live in the gold-plated dream that they have built), it's certainly only because of your beloved Ben which only thinks about milking a skeletal cow and has no plans and not even ideas about developing this retro-o.s..

If you talk about Amiga OS 3.1.4, 3.2, ecc., well, you know that there exists a law which protects I.P.s? Do you understand that there are people / companies which have rights about the Amiga o.s. & Commodore I.P.s? Do you understand that if such rights seem to be stepped-on, then the legit owners have the rights to defend them?

If you don't understand such very simple and basic rules which are world-wide common, then please tell me your full address so that I'll reach you, and then I'll do whatever I want with your house, properties, etc., and you'll not move a single finger against me, right?

@NutsAboutAmiga Quote:

NutsAboutAmiga wrote: @kolla Excattly. Anyway we need to get back to writing code, not wast time in the legal system.

Nobody stops you: go and support your beloved OS4!

On my side I've no time to develop something, and the limited time that I've I'll use for writing articles for the Italian's tech site which I was working on before joining Intel.

@cdimauro

wow, your spiking like true radical, talking about burning building, and killing people,
I bet your on the side of people crashed plains into world trades senter. You certainly not on the side of freedom of speech. Because I have done noting but expressing my option publicly.

As for who owns what well Hyperion entertainment has invested all the R&D into AmigaOS, so all stuff they have added ether owner by Hyperion entertainment or there contractors, originally they got AmigaOS from buyback agreement with Amiga Inc, that was superseded by settlement agreement, if the legal cases around settlement agreement is no longer valid, then original legal actions around buyback agreement might be. giving Hyperion the right to develop AmigaOS for newer versions.

NO ONE IS WINING!!!!!, THIS CAN GO ON FOREVER…. UNLESS PEAPLE COME TO THEIR SENSES.

so yes let’s return to be productive, and write code.

I not sure way want be on the side that, wont Cloanto to charge high fee for Roms that are not being updated. Or on the side, that believe endless legal actions is best thing for Amiga and AmigaOS. Sure, it can be good for competes of OS, that this does not get resolved are you on side of this? or the side of sueing random companys like Amico?

No Amico you can't make game console for Television, because we are going to make Amiga console, some time in future....

It’s like jeff bezos argument why, SpaceX can’t land at sea.

Last edited by NutsAboutAmiga on 26-Sep-2021 at 12:46 PM.
Last edited by NutsAboutAmiga on 26-Sep-2021 at 12:34 PM.
Last edited by NutsAboutAmiga on 26-Sep-2021 at 12:33 PM.
Last edited by NutsAboutAmiga on 26-Sep-2021 at 12:27 PM.
Last edited by NutsAboutAmiga on 26-Sep-2021 at 12:17 PM.
Last edited by NutsAboutAmiga on 26-Sep-2021 at 12:14 PM.
Last edited by NutsAboutAmiga on 26-Sep-2021 at 12:00 PM.
Last edited by NutsAboutAmiga on 26-Sep-2021 at 11:58 AM.
Last edited by NutsAboutAmiga on 26-Sep-2021 at 11:56 AM.

_________________
http://lifeofliveforit.blogspot.no/
Facebook::LiveForIt Software for AmigaOS

@NutsAboutAmiga Quote:

NutsAboutAmiga wrote: @cdimauro wow, your spiking like true radical, talking about burning building, and killing people,

I don't know where you've read it. Do you also have problems reading other people's writings?
Quote:

I bet your on the side of people crashed plains into world trades senter.

In Italy we say that "lo specchio riflesso era in uso alle elementary" when someone is reusing the same example of another guy, against him. Literally, we say that this joke was used on the ground school...
Quote:

You certainly not on the side of freedom of speech. Because I have done noting but expressing my option publicly.

So, the freedom of speech that you want consists on bashing your enemies and DEFAMING them?
Quote:

As for who owns what well Hyperion entertainment has invested all the R&D into AmigaOS,

No, wait, I missed something important here. Hyperion has INVESTED something on OS4? Really? So, were all people which worked on it... rumble... PAID?!? :D
Quote:

so all stuff they have added ether owner by Hyperion entertainment or there contractors, originally they got AmigaOS from buyback agreement with Amiga Inc, that was superseded by settlement agreement,

Which gave Hyperion MUCH MORE that it was expected to have, since the question was about paying the Amiga o.s. port to PowerPC. Do you remember it?
Quote:

if the legal cases around settlement agreement is no longer valid, then original legal actions around buyback agreement might be. giving Hyperion the right to develop AmigaOS for newer versions.

In your mind...
Quote:

NO ONE IS WINING!!!!!, THIS CAN GO ON FOREVER…. UNLESS PEAPLE COME TO THEIR SENSES.

SENSES? Which are? Please, be clear: what do you expect, that Michele Battilana decides to do NOT defend HIS rights?
Quote:

so yes let’s return to be productive, and write code.

I want to see Ben Hermans writing code. Really. :D

At least Michele is perfectly cable of doing it.
Quote:

I not sure way want be on the side that, wont Cloanto to charge high fee for Roms that are not being updated.

Again, it's ITS asset. It has the RIGHTS do it?

I like YOUR house: can I do whatever I want with it?
Quote:

Or on the side, that believe endless legal actions is best thing for Amiga and AmigaOS. Sure, it can be good for competes of OS, that this does not get resolved are you on side of this?

I'm on the side of the right owner, whoever the court decides for.
Quote:

or the side of sueing random companys like Amico?

Random. Again, it's ITS RIGHTS? Do you understand?!?
Quote:

No Amico you can't make game console for Television, because we are going to make Amiga console, some time in future....

Ditto: IT IS ITS RIGHTS!
Quote:

It’s like jeff bezos argument why, SpaceX can’t land at sea.

You don't know what you're talking about. AGAIN...

You're hopeless..

@cdimauro

Quote:

AROS has a 64-bit flavor and also MorphOS seems to being ported to x64, but I have no idea about how they implemented library calls. Keeping the 6 bytes convention they might: - load an offset to a register; - do a short jump to some (common) library's code which is near the library header; - finally, the common code takes the offset, calculates the real address to jump to, and then makes the final jump. But it's just an idea.

In case of AROS the LVO table does not consist of the jumps to the library base. Instead AROS uses LVO table containing the addresses of jump targets, only. Therefore, on 32bit AROS targets the LVO consists of 4-byte entries, on 64bit AROS targets LVO consists of 8-byte entries. Fetching target address is just as effective (or even more effective) than jumping into LVO. That saves us one unnecessary jump :)

PS. The only exception from this rule are m68k targets, where the binary compatibility is important. There, the LVO is just as it is on AmigaOS - series of JMPs into library