Amiga.org
Amiga computer related discussion => Amiga Software Issues and Discussion => Topic started by: kirk_m on November 13, 2017, 04:41:01 PM
-
https://www.generationamiga.com/2017/11/08/hyperion-announces-workbench-3-1-4/
-
Beyond the new version number, that post is pretty short on info. :(
-
Beyond the new version number, that post is pretty short on info. :(
There is more information, including a picture on the announcement at the Amiga32 in Neuss here:
http://www.a1k.org/forum/showthread.php?t=62888
-
a1k threads aren't publicly accessible. But there is also a real news entry: http://www.amiga-news.de/en/news/AN-2017-10-00059-EN.html
-
Great, but I just installed OS3.9 with all possible updates ;). How much more someone can update 060.library?
I think people would be happy to have new chip rom with "official" updates so we don't need to restart Amiga's multiple times.
We need new OS3.95 :D.
What about OS3.9 update...
-
Great, but I just installed OS3.9 with all possible updates ;).
There is a bit more than that in the making. Like fixed softlinks, long file names in the FFS and DirectSCSI support.
How much more someone can update 060.library?
Not quite sure what you mean. The 68060.library you better take from your Turbo board vendor. Or, failing that, directly from me. (-;
CBM never released a 68060 board, so there is no 68060.library from CBM either.
What about OS3.9 update...
The situation is complicated... Some of the 3.9 sources have been lost because H&P never checked them back into the repository. Some of the 3.9 rights were lost because authors can no longer be reached.
What I'm trying is to find the latest possible version of all tools I can get hold of, provided that we can use it. Which is sometimes less than 3.9 (so the HDToolBox is based on the 3.1 version, just in a working condition), and sometimes more than 3.9 (like asl, diskfont, layers and the shell).
However, before this complete package will be released, there will be a "Museum version" which will be a very very minor update. Probably just the FFS and the HDToolBox.
-
Not quite sure what you mean. The 68060.library you better take from your Turbo board vendor. Or, failing that, directly from me. (-;
I think I'm using yours (for sure not the original). I have to start remembering names of people involved in Amiga in more direct way... :). Due to Internet (any "me" learning English), I actually can talk to people who made software I used 20+ years ago :).
The situation is complicated... Some of the 3.9 sources have been lost because H&P never checked them back into the repository. Some of the 3.9 rights were lost because authors can no longer be reached.
I was on "sabbatical" for some time as far as Amiga, so I missed like 10 years (or more) of various type of issues..., so I'm still learning. I know for sure that there was plenty of issues.
What I'm trying is to find the latest possible version of all tools I can get hold of, provided that we can use it. Which is sometimes less than 3.9 (so the HDToolBox is based on the 3.1 version, just in a working condition), and sometimes more than 3.9 (like asl, diskfont, layers and the shell).
However, before this complete package will be released, there will be a "Museum version" which will be a very very minor update. Probably just the FFS and the HDToolBox.
It would be nice to have updated OS3.1 as much as possible and officially.
-
So does this mean we will now have a "fork" of AmigaOS 68k at 3.1, so we'll have 3.9 which has to fall the way-side for official updates while 3.1 gets official updates?
-
a) 3.1.4 will just confuse the matter. Call it 3.14
b) Make DST work
-
a) 3.1.4 will just confuse the matter. Call it 3.14
b) Make DST work
Amiga OS Pi
-
@Thomas Richter,
Do you think we will see an updated "Reaction"?
-
Hehe, will C:Wait and C:Sort be updated? :D
-
b) Make DST work
Oh yes, optional UTC system clock and let the "timezone" in Prefs/Locale actually make a difference :)
-
So does this mean we will now have a "fork" of AmigaOS 68k at 3.1, so we'll have 3.9 which has to fall the way-side for official updates while 3.1 gets official updates?
Yeah, to me, it feels like 3.5/3.9 was a dead-end fork, and development has resumed based on 3.1. AmigaOS 4.1 is based on the 3.1 codebase as well, and AROS/MorphOS are made to be API-compatible with 3.1.
In terms of features and eye-candy out of the box, 3.9 is probably still the best, but what matters in the end is that all the tools, commands, libraries, patches etc.
-
Yeah, to me, it feels like 3.5/3.9 was a dead-end fork, and development has resumed based on 3.1. AmigaOS 4.1 is based on the 3.1 codebase as well, and AROS/MorphOS are made to be API-compatible with 3.1.
In terms of features and eye-candy out of the box, 3.9 is probably still the best, but what matters in the end is that all the tools, commands, libraries, patches etc.
Agree completely. In addition, when I am handing money over for software I expect some basic level of support when problems/issues crop up. Why would I pay money for a dead product with no support?. If there are bugs or problems that was just money well wasted.
Plus with the 3.1 updates there are tangible developers benefiting from their work... developers that should be carrying the torch going forward. :)
-
As I recall I had issues getting the OS3.9 Boing Bag 2 installed (I had to find a missing library first or something), and so I was cautious about installing Boing Bags 3 & 4. As long as my software works I really not bothered that OS3.9 is no longer developed. I definitely not going back to Workbench 3.1, that would be insane! My only guess is that this Workbench 3.1 development is so that Hyperion can negotiate a bundling deal with the Apollo Team for the upcoming Vampire V4 standalone machine otherwise what's the point?
-
So does this mean we will now have a "fork" of AmigaOS 68k at 3.1, so we'll have 3.9 which has to fall the way-side for official updates while 3.1 gets official updates?
If you put it like that, it is a fork of sorts, because it has to be.
To the best of my knowledge the prerequisites for continuing development on the AmigaOS 3.9 project "evaporated" when Haage & Partner and Amiga International either changed their business model or shut down, respectively. More than 15 years have passed since then, and many of the bits and pieces which made up AmigaOS 3.9 have long ceased to be available for further development work. For example, all the updated preferences editors are gone.
By (hypothetically) "rewinding" AmigaOS 4 you will not produce a product which connects straight up to the AmigaOS 3.9 development path, allowing the end-result to be officially supported with further updates and bug fixes.
What we ended up with in the form of the "AmigaOS 3.1.4" project (note: don't get hung up on the "code name", as it might actually change in the future) is a compromise which attempts to bring all the components together which are part of the AmigaOS 3.9 update that are suitable and supportable. It is something in between AmigaOS 3.1 and AmigaOS 3.9, yet also has features which were never available in either of these.
-
But why? Is it to allow the exotic features of the Vampire boards to be fully supported by Workbench 3.1.x developers? I fail to see how the ability to develop for 3.1 going forwards is going to be better for the casual end user than just dusting off 3.9. If you want something up to date then you'd look at OS4.x not this crusty old grey and blue relic surely?
-
But why?
Because 3.1 is full of bugs and annoyances?
3.9 is out of reach - a lot of the code is not available for maintenance.
-
Will this also include all the updates that were part of "3.X"?
-
But why? Is it to allow the exotic features of the Vampire boards to be fully supported by Workbench 3.1.x developers? I fail to see how the ability to develop for 3.1 going forwards is going to be better for the casual end user than just dusting off 3.9. If you want something up to date then you'd look at OS4.x not this crusty old grey and blue relic surely?
There is a need for AmigaOS on the 68k platform to be cared for. As helpful as the changes in the AmigaOS 3.5 and 3.9 updates were, once development ceased it became more difficult to find solutions for bugs and limitations. Patches and reworked operating system components helped to close the gaps, but it should have been easier to achieve these remedies. Source code access, and the ability to build complete and working Kickstart ROM and Workbench disk sets from that source code should deliver that.
Assuming responsibility for solving such problems is what the AmigaOS 3.1.4 update (and the work leading up to it) is all about. While you cannot assume that equivalent functionality to AmigaOS 3.9 could be delivered in the same time frame the AmigaOS 3.5/3.9 updates required, at least we can make a start and listen to user and developer feedback.
Let's see where this is going to take us. It ought to be an improvement over the stagnation of the past 15+ years in the AmigaOS 68k area, as the minimum requirement.
-
Because 3.1 is full of bugs and annoyances?
3.9 is out of reach - a lot of the code is not available for maintenance.
Yeah, why not is a more appropriate question. Lots of people still use 3.x in classic Amigas, emulation etc. Probably way more than use AmigaOS 4.
Don't focus too much on the version number. AmigaOS is very modular. If most components are a higher version in 3.1.4 than 3.9, then which is the most up to date? It's just that 3.9 was already taken, and calling it something like 3.95 would have made it seem like a minor update to 3.9. Think of it as AmigaOS 3.14 (as in fourteen).
-
Will this also include all the updates that were part of "3.X"?
Everything that's in the box directly comes from either the original Commodore code base or from material licensed for inclusion in the AmigaOS 3.5/3.9 updates for which Hyperion has a license to use it. All the changes subsequently made to this code are completely home-grown.
There is bound to be functional overlap with the "3.X" code, but as far as I know no code is shared between it and the 3.1.4 update.
-
I look forward to Hyperion striking a deal with the Apollo Team to get this bundled with the stand alone Vampire V4. If not then I cease to be interested. My current OS 3.9 setup works fine. Why mess with it?
-
I'm just asking in a benign manner, since this seems to be a Vamp/AROS/base system 3.1.X update, and that OS3.5 must be installed over OS3.1, will the installation of OS3.5 break anything in the new OS3.1.X update? Now I know what you might reply with.... NO ONE uses OS3.5 and that, possibly, this new OS3.1.X will not be supported in this manner when installing OS3.5?
Other question is, when this is released, might there be updated components that could manually be copied over to a fresh OS3.5/3.9 installation?
^ Hmmm, just asking.... ^
I love OS3.5 on some machines.
-
@gizmo350
That's a great idea! Hyperion should include an install option to update current OS3.5 or OS3.9 systems in addition to fresh installs. That way it could double as a Vampire V4 install disc or a Classic machine library update disk :cool:
-
@gizmo350
That's a great idea! Hyperion should include an install option to update current OS3.5 or OS3.9 systems in addition to fresh installs. That way it could double as a Vampire V4 install disc or a Classic machine library update disk :cool:
Exactly!!! :)
-
I'm just asking in a benign manner, since this seems to be a Vamp/AROS/base system 3.1.X update, and that OS3.5 must be installed over OS3.1, will the installation of OS3.5 break anything in the new OS3.1.X update?
First, one clarification: This project is not related to Vampire. It is for 68K systems, and by that will most likely also work on the vampire, but there are no tools or resources in it that are specific to it. The Os, as it stands, is capable enough to handle hardware extensions of all kinds, provided its makers want to use them.
Second, this will be a self-contained distribution. It is not meant to be "installed on top" of something. This said, all the components that are currently in existance of course work in AmigaOs 3.9, and this is exactly how I use it and test it. It would be sheer folly to break compatibility with existing distributions. However, we don't have sources or licenses for all Os 3.9 components, so in some cases we *need* to go back to older versions that have been updated for additional functionality.
The HDToolBox is such an example: There are currently no resources to re-implement a reaction-based HDToolBox as found in 3.9. There will be, however, a HDToolBox that looks as bad as the 3.1 version (sigh), but it handles big partitions fine, is able to enable the DirectSCSI flag of the FFS, switch on the long-filename support....
So, things work right, but the GUI is not as fancy as it could.
Now I know what you might reply with.... NO ONE uses OS3.5 and that, possibly, this new OS3.1.X will not be supported in this manner when installing OS3.5?
It will probably replace many components that came with 3.5 with more modern and updated components. I really don't see why anything in 3.5 should break either.
Other question is, when this is released, might there be updated components that could manually be copied over to a fresh OS3.5/3.9 installation?
You should understand that Hyperion will most likely not be able to support such installations, but quite frankly: This is exactly what I am doing here. However, keep care! Not everything 3.9 did will likely be supported by 3.1.4 simply because we do not have sources, or licenses. 3.1.4 will probably come with the 3.1. preferences tools. The Prefs format is documented, so nothing breaks, but some of the extended functionalities of 3.9 will not work due to lack of information, licenses or sources.
To give you an example: 3.9 had a "1:1 GUI" button that rescaled the resize button of windows. This was implemented as part of IPrefs and it *probably* patched up intuition. Now, besides my unwillingness to patch up system componens just for eye candy, the sources of all this stuff is lost, so the feature is lost. A new intuition that implements this natively is out of reach due to incompatibilities we are currently facing with CyberGraphics, and some badly written programs that do not dynamically allocate border space in their windows. (E.g. Workbench & ViNCEd work with rescaled buttons, Kingkong does not... hint, hint...)
So, you get in some cases less functionality (mostly in the eye-candy section) and sometimes more functionality (mostly in the systems layer), such as getting rid of the need to have a 4GB boot partition and getting softlinks.
-
If you want to get rid of KingCON you should simply make it redundant :)
-
I would say that adding basic functionality of OS3.1 recognizing larger HDD "out of the box" is a OK choice, but spending more time/resources on it is like asking MS to make updates for Win 3.0 so I can use my USB printer. Considering that MS has BILLIONS and hundred of thousands of people working for them and they made STRATEGIC decision to "move on", why in Amiga environment we have so much resources do continue prolonging dead or... already dead system. There is community of people who is making patches to it and that is great. The same is happening eg. in case of Win 98 with "Service Pack 3" type of ideas.
I would rather see new working network driver/FPU for Tabor (IF people really have to have PPC under the hood for some reason?!), that it is taking like 2 YEARS to develop.
There is plenty of third party updates for OS3.1/3.9 and lately people can buy original ROMs and floppies with OS3.1, to install it on their Amiga. Small update to make life easier (but at the same time 4gb CF card is amazing size for anything Amiga related. I could not use 100Mb of HDD space...
Overall, from my perspective I don't see DIRECTION in development of "Amiga" overall. Scattered projects as far as HW as software goes. Diluting resources, man power will not lead to anything with exception of more frustrations and division of already quite divided environment.
-
I would say that adding basic functionality of OS3.1 recognizing larger HDD "out of the box" is a OK choice, but spending more time/resources on it is like asking MS to make updates for Win 3.0 so I can use my USB printer.
True, but isn't that the point in Amiga? I mean, as in "retro computing"?
Overall, from my perspective I don't see DIRECTION in development of "Amiga" overall.
Well, different people want different things. The system is certainly outdated by many means, so which direction do you expect? To "move forward" to catch up with PCs? This ship sailed away a long time ago, and CBM failed for a reason.
There is a need to clean up the system a little bit, there is some demand from the user side,so why not address this need?
-
The HDToolBox is such an example: There are currently no resources to re-implement a reaction-based HDToolBox as found in 3.9. There will be, however, a HDToolBox that looks as bad as the 3.1 version (sigh), but it handles big partitions fine, is able to enable the DirectSCSI flag of the FFS, switch on the long-filename support....
So, things work right, but the GUI is not as fancy as it could.
I'll be very interested to see if the HDToolBox (and other utilities) from 3.9 work with 3.1.4 (or 3.14). I guess time will tell. ;)
-
He seems to be assuming we'll happily do a clean install of Workbench 3.1.4 and then copy over some OS3.9 files however the way I see it the new bits of Workbench 3.1.4 could be added to OS3.9. Why would the average user 'downgrade' to an uglier system just to allow the devs to keep pushing out the equivalent of Atari 2600 games?
-
Initially I was quite happy with idea of some updates for OS3.1, the more I think about it I really don't see much reason for it.
I did not even bother to install OS3.1, went straight to OS3.9+BB 1, 2, 3 and 4. I really think there is plenty of updates floating around for OS3.1 and OS3.9 (updates? Take AmiKit!? - this is AMAZING what can be done)
It is not like new updates add new functionality to my system... such as Office 98 ;).
Every-time I use my Amiga's there is this time I "hit the wall" meaning, miraculously everything works and... nothing more can be done. Sure, I can check email, listen to mp3... etc. watch Warp3D cow animation for about 3h a day or in near future move Warp3D logo on the second screen...
I'm going to sell all this Amiga stuff and play Angry Birds on my phone with 4GB ram.
My point is (?) that we (I'm just a customer!) don't have much of productivity software that is up to date. Sure, updates for system are good, but we have plenty stable OS3.1/OS3.9 and what next?
I think I'm not alone in this, but "pimping my Workbench" become main use of AmigaOS, new clock, calendar, new icon set, new background, another picture viewer, DVD recorder etc. etc. and that IS OK, and it still can be in future, but...
In some way I would like to have AmigaOS that... my wife could use for her business. How many people HATES MS, APPLE, GOOGLE etc. etc. digesting all your personalities and treating your personal lives as product?
Personally I see AmigaOS as system that is "SECURE, light, fast, virus free, don't track every single click on your keyboard and reads all your emails, and downloads ALL user info. etc.". This type of system would become some sort of alternative to main stream today. There is plenty angry users of NOKIA phones ;).
Main "base" is there, AmigaOS rights are protected and this system IS distinct from everything else is there. It is actually good that is not developed for 20 years, it can avoid all this "20gb size after installation + 4GB ram + ... " thing. KEEP it small, simple, one CD installation (MAX). People don't need all this features they never use.
-
True, but isn't that the point in Amiga? I mean, as in "retro computing"?
Well, different people want different things. The system is certainly outdated by many means, so which direction do you expect? To "move forward" to catch up with PCs? This ship sailed away a long time ago, and CBM failed for a reason.
There is a need to clean up the system a little bit, there is some demand from the user side,so why not address this need?
I concur.. as a very user group person. The biggest request we get is how to use big hard drives. It drives (grin) everyone crazy. Amigians come in with new hard drives always over 4 gigs and ...you know, etc
These small updates make life and Amiga better!
-
Well, different people want different things. The system is certainly outdated by many means, so which direction do you expect? To "move forward" to catch up with PCs? This ship sailed away a long time ago, and CBM failed for a reason.
Apart from subjective wish lists, there are a number of fundamental areas that need to be addressed across the board. No one is expecting a quantum leap to current relevance.
How any of this relates to Commodore is a mystery to me. Their decline certainly doesn't relate to OS development that ended 25 years ago. I'm not sure that we can extend that same courtesy to those that have been in charge of the platform and let it language for the past 15 years.
-
@kreciu
Secure? Surely you jest? AmigaOS is anything but secure.
It's design almost screams "invade me, look around, do whatever you like, not only will I put up no fight I'll actually help you" :-)
-
@kreciu
Secure? Surely you jest? AmigaOS is anything but secure.
It's design almost screams "invade me, look around, do whatever you like, not only will I put up no fight I'll actually help you" :-)
I did not say it IS secure, I'm saying that should be one if possible direction of development.
Right now even I know it is everything BUT secure :-)
-
Thomas and Olaf, I'm very excited about what you are doing. I very much look forward to trying it out. Thank you!
I'm guessing that your improved 3.14 will be compatible with all Amigas, even the most basic configurations? Asked differently, your improvements and bug-fixes will not crash an otherwise stock A500 that is equipped with an updated rom?
Years ago, I was happy to upgrade to 3.5 and then 3.9 as they came out. At the time I was also pushing my A3000D with a 68060, PicassoIV and Delfina, believing then there would always be an evolving path to keep the Amiga near cutting edge or at least relevant. After a few years, my system could not keep up with the then new YouTube, changing net code, and security protocols. There were also little annoying compatibility issues among the HW and SW. About 8 years ago, a HD failure blew it all away. In retrospect, 3.5 and 3.9 were paths for advancing hardware with some great system improvements but especially lots of eye candy for advanced Amigas.
Today, I happily run more modest A2000s. The most advanced has a 68030, Indivision, and MASplayer and is closer to a 'pure' Amiga experience than the ubber A3000 was. Also, the net is far too hostile and evolving for me to ever venture there with an Amiga again. OTOH, I have always enjoyed the Amiga's OS and HW for their own sake. I still do. OS3.1 suites these systems very well. Hopefully, 3.14 will too.
Simply my humble 2 cents...
-
Initially I was quite happy with idea of some updates for OS3.1, the more I think about it I really don't see much reason for it.
My A600 for example doesn't have an O20 or greater in it. This means 3.5/3.9+ are off limits. This is true for a lot of systems that 3.1ish works on. I hope the 3.1.4 or 3.14 update works with 68000 3.1 ROM'ed Amigas as well.
Granted most of my Amigas are accelerated, but some aren't.
-
I'll be very interested to see if the HDToolBox (and other utilities) from 3.9 work with 3.1.4 (or 3.14). I guess time will tell. ;)
It will work, but you will not get access to the new features. As DirectSCSI and long file names. These are new functionalities, and the 3.9 HDToolbox has no idea about them.
-
Initially I was quite happy with idea of some updates for OS3.1, the more I think about it I really don't see much reason for it.
Look, if you don't want it, don't buy it. But I've seen here people for years complaining that there is no update, that they need to hack up their system, that the owners/licensors are so bad that they do not support the system anymore.... Now we get an update, and it's also wrong.
I did not even bother to install OS3.1, went straight to OS3.9+BB 1, 2, 3 and 4. I really think there is plenty of updates floating around for OS3.1 and OS3.9 (updates? Take AmiKit!? - this is AMAZING what can be done)
And how do you know that this all works together? We have tons of some third-party upgrades of excellent to mediocre quality, but not integrated into the Os. Just tons of patches floating around.
It is not like new updates add new functionality to my system... such as Office 98 ;).
No, you don't, and you won't, and nobody is going to make an Office for Amiga. It's a retro system. If you need a system for productivity, get a PC.
I'm going to sell all this Amiga stuff and play Angry Birds on my phone with 4GB ram.
Please do. There are certainly collectors out there that are keen to get another system. Complaining that Amiga is way back behind does not help. It will remain way back behind, as it was left behind 30 years ago, and it will not catch up anymore. The whole point here is that it is a museum piece.
My point is (?) that we (I'm just a customer!) don't have much of productivity software that is up to date.
Right, and it won't come. This ship sailed away a long time ago. The system is too small, too slow, too outdated, misconstructed to be useful for anything even remotely modern.
I think I'm not alone in this, but "pimping my Workbench" become main use of AmigaOS, new clock, calendar, new icon set, new background, another picture viewer, DVD recorder etc. etc. and that IS OK, and it still can be in future, but...
And I personally do not even care about "pimping the workbench". Mine looks rather basic. I don't mind. This is not what I use the system for.
In some way I would like to have AmigaOS that... my wife could use for her business.
Won't work, won't happen. M$ will not port Office to Amiga, not now, not in any distant future. Get her a Mac or a PC. We don't even have any decent printer drivers and we won't make new ones.
Personally I see AmigaOS as system that is "SECURE, light, fast, virus free, don't track every single click on your keyboard and reads all your emails, and downloads
Amiga is nothing of that. It is not secure, it has no idea about security at all. It is neither virus free. It lacks any serious means to defeat any type of virus, neither any isolation or mechanism to disrupt user tracking. The only reason why such malware does not exist is because the system is not worth considering for the authors of such software. Other than that, writing malware on the Amiga is considerably easier than on any other system, given its total lack of protection. The whole Os concept is so completely outdated, it is totally out of scope to even think about adding it. Forget it, won't happen.
If you want privacy, get a Linux system.
What we get here with 3.1.4 is a bugfix release. Only that. It is "clean up and take down the trash". Not less, not more. It will not give you a modern system. If you want a modern system, go to Wallmart and buy one. If you want a system that respects your privacy, also go to Wallmart, then download and install Linux.
-
BTW, I'm pretty sure I saw Joanne Dow post in a Slashdot thread about Amigas just a few weeks ago.
-
Thomas: if you had the 3.9 sources and rights, would this update exist?
I think not, but would like an honest answer, because it otherwise does seem a pointless back to the future update.
-
Thomas: if you had the 3.9 sources and rights, would this update exist?
If that was the case, we would have a maintained 3.9, or maybe even 3.10.
There is a lot of 3.1 in OS3.9 still, (and pre 3.0 too) and I suspect that many of the bits and pieces that are updated in this 3.1.4 are also relevant for 3.9.
-
Thomas: if you had the 3.9 sources and rights, would this update exist?
I'm not quite clear what you are asking. This update (3.1.4) exists. You mean an update for 3.9? Of course we would update 3.9 if we had all the rights and sources, but we don't. Some of the components are lost because H&P never checked them in (IPrefs from 3.9) so we had to reimplement parts of it. Other components where never checked in by other parties, so we had to replace them completely (The Os 3.9 Execute by Heinz is just lost), others we don't have the rights to (HDToolBox by Joanne Dow). The situation is complicated.
But, as said, I'm always trying to pick the latest and greatest component I can get hold of, and this also implies that *some* of the components are later than those in 3.9. This is either because I had newer sources (diskfont, asl) or because I made newer components (layers, shell) or because I reimplemented them for the purpose of just this project (queue-handler, clipboard.device, port-handler).
So this update is really "somewhere between" 3.1 and 3.9, and beyond 3.9.
I think not, but would like an honest answer, because it otherwise does seem a pointless back to the future update.
See, that's the best we can do with the components we have. That's all I can say. I'm not removing anything from 3.9 because I'm a mean guy.
-
Im looking forward to the update, and I intend to use it with Vampire. I also are following Olafs developments with AROS Vision, but unlike some, I dont feel that they are mutually exlusive. I like to think the variety compliments eachother.
I do feel a bit ...sorry (?) for you Thomas, having to deal with the legal minefield, but again, looking forward to the end result.
-
I will have a system ready to try this out when it's ready. I have both bare 68000 and 68020+ I can give a whirl. Of course, if I ever bothered with UAE or AmigaForever I'd have much more versatile configurations available :)
-
T
I'm guessing that your improved 3.14 will be compatible with all Amigas, even the most basic configurations?
Yes. This is all strictly 68K only. You will probably need more RAM as we will likely not be able to sweeze the new workbench into ROM. It just doesn't fit there. The workbench - as I see it - is shorter than the 3.9 edition because I could play a couple of compiler tricks there (and in icon as well) but it is not short enough to fit into ROM.
-
@gizmo350
That's a great idea! Hyperion should include an install option to update current OS3.5 or OS3.9 systems in addition to fresh installs. That way it could double as a Vampire V4 install disc or a Classic machine library update disk :cool:
Yes, this would be very worth having. Figuring out what to copy, and what to omit, whether there are potential conflicts between the different versions (e.g. SetPatch, IPrefs, etc.), will be a really tough nut to crack, though...
I can see this happening, eventually, but I expect that the initial release of the 3.1.4 update will focus on getting the update ready to ship.
-
Thomas and Olaf, I'm very excited about what you are doing. I very much look forward to trying it out. Thank you!
I'm guessing that your improved 3.14 will be compatible with all Amigas, even the most basic configurations? Asked differently, your improvements and bug-fixes will not crash an otherwise stock A500 that is equipped with an updated rom?
That is very much the plan. The baseline build of the operating system and its components is still all-68000 code, with only the ROMs for the Amiga 1200 and Amiga 4000(T) requiring an 68020 (the A3000 expects an FPU to be present, but that's a different story).
While building operating system components specifically for the 68020 and beyond would result in significant ROM space savings, as well as disk space savings, it would open a big can of worms.
-
I did not say it IS secure, I'm saying that should be one if possible direction of development.
The security aspects have been discussed before, but the Amiga operating system architecture is not designed with security in mind. If anything, the focus was on making the most of very little available RAM and squeeze as much performance out of the CPU as possible.
Security measures are built from layers of isolation which limit what a program or operating system function may accomplish. These are completely absent in the Amiga operating system. Compare this to the then (1985) contemporary Macintosh or Atari TOS designs which use "software interrupts" to call operating system functions. There is at least a context change implied, which could be leveraged to enforce permissions to perform an action. Nothing comparable exists on the Amiga, except perhaps the Envoy server which has a single point of entry (authentication) to either grant or deny access to a resource.
Retrofitting operating system designs not intended to offer security measures typically produce compromises which end in tears.
You could redesign the system, of course, but then you'll invariably have to "triage" the software that is expected to still work with it. A more secure Amiga operating system is guaranteed not to work with the vast majority of currently available software.
-
My A600 for example doesn't have an O20 or greater in it. This means 3.5/3.9+ are off limits. This is true for a lot of systems that 3.1ish works on. I hope the 3.1.4 or 3.14 update works with 68000 3.1 ROM'ed Amigas as well.
People need to let the 68000 go, lol. :lol:
-
A more secure Amiga operating system is guaranteed not to work with the vast majority of currently available software.
I thinks AmigaOS4.1 don't work with most available software and I don't think it is more secure then older version?
-
The A3000 expects an FPU to be present, but that's a different story.
That's just the matter of compile time options. It currently selects the FPU-only version of mathieeesingbas for the A3000, but that is a poor choice if people upgrade the system with an "Economy Class" CPU. Well, frankly, mathieeesingbas was always a poor choice to begin with, but now that workbench is on disk, there should be enough ROM space available to fit the full ieeesingbas in. Or, even, remove it from ROM completely as it is really not worth having...
Which is a shame given the amount of time I spend to compile mathieeesingtrans. Oh well...
-
Look, if you don't want it, don't buy it.
Yes, it is VERY true.
-
The security aspects have been discussed before, but the Amiga operating system architecture is not designed with security in mind. If anything, the focus was on making the most of very little available RAM and squeeze as much performance out of the CPU as possible.
Security measures are built from layers of isolation which limit what a program or operating system function may accomplish. These are completely absent in the Amiga operating system. Compare this to the then (1985) contemporary Macintosh or Atari TOS designs which use "software interrupts" to call operating system functions. There is at least a context change implied, which could be leveraged to enforce permissions to perform an action. Nothing comparable exists on the Amiga, except perhaps the Envoy server which has a single point of entry (authentication) to either grant or deny access to a resource.
Retrofitting operating system designs not intended to offer security measures typically produce compromises which end in tears.
You could redesign the system, of course, but then you'll invariably have to "triage" the software that is expected to still work with it. A more secure Amiga operating system is guaranteed not to work with the vast majority of currently available software.
So, you tell me that AmigaOS4.x will never be secure?
-
I would be happy to purchase update (3.1.4) for my A2000/030 (currently running classicWB advsp) and A500s (3.1).
That is, if it was a fully functioning OS as classicWB tries to be, with all the patches and bells and whistles. I would rather pay then have to install this stuff manually. Too much to hope for?
Running OS 3.9 on the 2000 used a lot of resources without anything running and was a good starting point, but required a lot of additions, patches, etc. to get it up to snuff.
3.1 is just a blank slate.
Well, I would probably still purchase it even if it was just a modest update. These were just a few thoughts.
-
People need to let the 68000 go, lol. :lol:
Nah, the Minimig is probably the most rock solid Amiga system I have :)
-
now that workbench is on disk
Which workbench.library will 3.1.4 come with?
-
On an unrelated thought, where's that troll who used to always say you should never upgrade your Amiga to 3.1? Haven't heard from him in a while. Wonder how he feels about all this? :laughing:
-
Which workbench.library will 3.1.4 come with?
V45, but a later release that goes beyond what was shipped with 3.9. I don't have the release here, probably something like 45.178 or so, but this is still going to increase as we find bugs.
In particular, it includes a couple of fixes for big partitions, and it copies softlinks and hardlinks correctly (unlike the 3.9 version which just left them out). Hardlinks will be copied within the same partition, and decay to softlinks across partitions (or this is the algorithm right now).
Oh yes, this is a ROM-able version again. I wrote about the whole story a while ago. It was costing me some nerves to get this working.
-
You must have read my mind. I was mulling about with the 1MB KS ROM question (I have a ROMY for my 4000, and I understand the 1200 supports 1MB KS natively,) so being able to build my own ROM *could* be useful, or maybe the option to obtain official 1MB KS.
-
ThoR & Olaf,
https://www.patreon.com/
Let the true Amigans support you directly.
-
Will the A4000T version have room for the SCSI + IDE device drivers?
-
It would be cool if someone could put together a sort of "Boing Bag 5" that pulled forward improvements from 3.1.4 into 3.9 as well as could be applied. Some stuff (like HDToolbox as mentioned) might have to be downgraded to the "ugly" version, but as much of 3.9 as possible could be salvaged. 3.9 was a much nicer environment than 3.1 so it would be a shame to waste what could be salvageable from it.
btw does "Long-filename" FFS introduce a new identifier/dostype to reflect the changes? If it implements long filenames using the old dostype it would cause holy hell with tools that don't understand the changes but doesn't expect them to be there by recognizing the old FFS dostype.
Or does it implement it with some semi-compatible overlay like how Joliet/VFAT implements long filenames in Windows? (ISO-9660/FAT 8.3 MS/DOS-compatible filenames with extra metadata to contain the long names).
-
V45, but a later release that goes beyond what was shipped with 3.9.
Great! And a new prefs program to go along with it?
This OS3.1.4 (or whatever it will be called) sounds like exactly what I want :)
-
On an unrelated thought, where's that troll who used to always say you should never upgrade your Amiga to 3.1? Haven't heard from him in a while. Wonder how he feels about all this? :laughing:
Don't tempt me, I'm thinking to become troll... Just for the sake of argument ;-).
...Few months ago I got fresh, new AmigaOS3.1 floppies and NOW I hear about update! Can we finally stop this updates I can't keep up. Now I will have outdated system.
-
Will the A4000T version have room for the SCSI + IDE device drivers?
Yes, of course. It will not have room for the workbench and icon, but that is old news.
-
btw does "Long-filename" FFS introduce a new identifier/dostype to reflect the changes?
Yes. Actually, we have currently three. DOS/6 has long file names, but OFS block layout. DOS/7 has long file names and FFS block layout. DOS/6 and DOS/7 are exactly as in AmgiaOs 4, but unfortunately not backwards comaptible to DOS/0 and DOS/1. Olaf is currently working on a new DiskDoctor to address this issue.
Then we have another stranger, and this is DOS/8 which will probably go. The fun part about it is that DOS/8 was "sort of present" already in the Os 3.9 version, but there not fully functional. It has 54 character long file names (so more than the usual 30), but is backwards compatible in the sense that the block layout is just like the one in DOS/1, except that unused fields are populated with the extra characters, so old tools will at worst damage the file name, but nothing else.
Probably we'll keep DOS/8 inofficial, as it used to be.
DirectSCSI works in a different way. This is not a DosType, but we recycled some flags elsewhere.
-
Great! And a new prefs program to go along with it?
I'm not yet at the prefs. Currently, the 3.9 Prefs work ok with it, and there aren't any new features beyond 3.9, except bug fixes. Did I say that this is a bugfix release?
-
(New filesystems)
Yes. Actually, we have currently three.
Have you pondered anything about how the Amiga filesystems perform with non-seektime storage like SSD/flash? Has some of the old tech choices become better or worse? Any minor tunings that can align better to this?
-
(New filesystems)
Have you pondered anything about how the Amiga filesystems perform with non-seektime storage like SSD/flash? Has some of the old tech choices become better or worse?
As far as I can tell the file system design choices made back in the late 1970'ies have not aged well. The file system does not have an effective strategy to organize the layout of directories, and the data structures associated with files so as to minimize access times. This is a major drawback which SSDs alleviate.
Even with these limitations out of the way, the design is still not sufficiently scalable and is still vulnerable to damage and corruption caused by the lack of journaling.
The file system design was adequate for the technology of the time it was created for, which would have been hard disk drives no larger than 20 Megabytes. It still strikes me as odd that this file system was used for floppy disks which were significantly slower than those hard disks and were a big source of trouble on account of the file system using a write cache.
Any minor tunings that can align better to this?
It definitely helps to use larger block sizes (2048 bytes or more), if the increased size does not negatively impact overall data throughput (changes are that throughput will be higher, though). The larger block sizes have beneficial effects on how file and directory data structures may be used. The tables which these data structure contain are larger, which reduces seek times, etc. Mind you, larger block sizes help with mechanical electromagnetic storage devices, too ;)
That aside, the file system design provides little to no leverage to improve its performance by minor tuning exercises. It is, as I mentioned, a design which has not aged well.
-
Have you pondered anything about how the Amiga filesystems perform with non-seektime storage like SSD/flash?
No, not at this time. The code is still the same assembler based FFS code it used to be before, with the same block allocation strategy as before, plus the three new layouts, plus TD64 support, plus directSCSI support, minus the bugs we (or others) found.
Thus, one may wonder in how far one can improve the old design. For mechanical disks, an improved block allocator would certainly help. For SSDs or CF, you can already use larger block sizes today. But before we introduce more bugs by changing algorithms, please let us remove the old bugs first. There is still plenty of work ahead, and experimenting too much with this old code has a certain danger.
-
Olaf is currently working on a new DiskDoctor to address this issue.
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.
The detection operation is a prerequisite to recovery and repair, and it will never modify the contents of the file system. You can save the information which the detection process gathered to a file and then use that file as the basis for recovery or repair later, or you can of course rerun the detection before recovery or repair are performed.
The recovery operation will likely work similar to how DiskSalv would do the job, with the difference that you would have a choice to copy only those files which are sound (like a "copy #? all clone" command), only those files which are not known to be sound (deleted, corrupted, etc.), or to perform a "deep salvage" operation which would copy everything that is even remotely recoverable, including data file fragments.
The repair operation would excise any damage found, returning the file system to operational state again. This is what the original DiskDoctor was intended to deliver, except that it rarely accomplished even that, and could be depended upon to leave the file system in a much more damaged state than it was before. You would use the repair operation only if you had previously recovered all the salvageable data.
The new DiskDoctor handles large volumes, on storage media larger than 4 Gigabytes. It supports all Amiga ROM file system flavours including dircache and long name mode, with block sizes up to 65536 bytes. Because large volumes need to be supported, covering hundred thousands of blocks, the new DiskDoctor is specially optimized to use as little memory as possible for its work. You may still need 10 Megabytes of RAM for very large drives, mind you.
This is a rather large project, I'm afraid and I cannot currently quote a release date.
-
I'm not yet at the prefs. Currently, the 3.9 Prefs work ok with it, and there aren't any new features beyond 3.9, except bug fixes.
Good. I ask for prefs since I have been using tweaked 3.9 on 68000 since forever, and the only really "big" problem are the prefs of OS3.9 that all depend on resource.library and Reaction, which are 68020+. And among them, only the Workbench prefs is lacking in 3.1.
I take it for granted that Reaction (and resource.library) are among the code that is ouch of reach? All prefs programs rewritten with gtlayout.library would have been superb, and so ... fitting :D
-
I have a ClassticWB_LITE OS 3.1 system installed on an A1200. PFS3 is installed as well. With this update, I saw that the native HDToolbox will be fixed to recognize large drives/partitions. I was wondering if the Workbench drive windows will be patched also to report the correct space used/remaining. This is currently not accurate.
Fortunately, I can use Dir Opus to get more accurate values but it would be nice to see the correct info in Workbench windows.
-
No, not at this time. The code is still the same assembler based FFS code it used to be before
Isn't Olaf the author of FFS2 written in C? Wouldn't be better base fixed ffs on these sources?
-
I was wondering if the Workbench drive windows will be patched also to report the correct space used/remaining. This is currently not accurate.
This has been fixed already.
-
Isn't Olaf the author of FFS2 written in C? Wouldn't be better base fixed ffs on these sources?
Maybe, in the long run. At this time, I still prefer the old sources. 68K is not exactly a fast microprocessor, and the FFS is a sort-of critical system component. It doesn't make much of a difference for PPC, and patching up the assembly code on 68K was not *that* much a problem.
-
Yes. Actually, we have currently three. DOS/6 has long file names, but OFS block layout. DOS/7 has long file names and FFS block layout. DOS/6 and DOS/7 are exactly as in AmgiaOs 4, but unfortunately not backwards comaptible to DOS/0 and DOS/1. Olaf is currently working on a new DiskDoctor to address this issue.
Then we have another stranger, and this is DOS/8 which will probably go. The fun part about it is that DOS/8 was "sort of present" already in the Os 3.9 version, but there not fully functional. It has 54 character long file names (so more than the usual 30), but is backwards compatible in the sense that the block layout is just like the one in DOS/1, except that unused fields are populated with the extra characters, so old tools will at worst damage the file name, but nothing else.
Probably we'll keep DOS/8 inofficial, as it used to be.
It will be interesting to compare these with PFS/SFS. Any predictions which will be "better"?
-
Sorry-- when you say "already", you mean it is included in the latest update or I should already have it with my current install?
Thanks.
This has been fixed already.
-
Isn't Olaf the author of FFS2 written in C? Wouldn't be better base fixed ffs on these sources?
Tough one. The FFS reimplementation which is used both by AmigaOS4 and MorphOS was designed and developed on AmigaOS 3.1. It has worked on 68k since, well, the day it actually started working properly ;)
The FFS reimplementation would be a better foundation for future file system development work than the assembly language version. One of the drawbacks, compared to the assembly language version, is that the FFS reimplementation needs much more ROM space. Because it tries to do better in avoiding data corruption, the FFS reimplementation deliberately flushes modified blocks to disk, slowing write operations.
In the mid/long term perspective, I see the FFS reimplementation supporting journaling using write-ahead logging, which would solve many performance and reliability issues. I have a cunning plan how to make this work which could be compatible even with AmigaOS 2.x (which would not support the journaling, though).
-
It will be interesting to compare these with PFS/SFS. Any predictions which will be "better"?
Always bet against FFS. Both SFS and PFS, in spite of limitations and bugs which may still be present, can't help but kick the FFS to the curb without even trying.
-
Always bet against FFS. Both SFS and PFS, in spite of limitations and bugs which may still be present, can't help but kick the FFS to the curb without even trying.
Oh well, it really depends on what you are doing. As far as raw data transfer is concerned, neither file system can do any magic. It just has to take the user blocks, and direct the device to write them out. So far, so simple.
It gets more complicated for any higher file system operations. FFS is actually quite good at *locating files*, i.e. if you give it a name, to find the name. It is quite bad at *listing* files, as in directories. It is also quite bad at managing the space on disk - the algorithm for that is quite naive: Take the nearest block you get can.
So, there are certainly some options for improving the FFS - as a better allocation strategy - and some limitations I have no idea how to address at all.
-
Sorry-- when you say "already", you mean it is included in the latest update or I should already have it with my current install?
No, I mean "I fixed this for the latest version I have". It is not fixed in your version. Beware! There is a third-party plugin "AsyncWB"(sp?) by Stephan Rupprecht which also has issues with large volumes. We don't have sources, so cannot fix it.
-
Yes. Actually, we have currently three. DOS/6 has long file names, but OFS block layout. DOS/7 has long file names and FFS block layout. DOS/6 and DOS/7 are exactly as in AmgiaOs 4, but unfortunately not backwards comaptible to DOS/0 and DOS/1. Olaf is currently working on a new DiskDoctor to address this issue.
Then we have another stranger, and this is DOS/8 which will probably go. The fun part about it is that DOS/8 was "sort of present" already in the Os 3.9 version, but there not fully functional. It has 54 character long file names (so more than the usual 30), but is backwards compatible in the sense that the block layout is just like the one in DOS/1, except that unused fields are populated with the extra characters, so old tools will at worst damage the file name, but nothing else.
If you're adventurous, you can test out Toni's patched FFS 45.13 which fixes some bugs and enables DOS\8 long filenames! See this post on EAB (http://eab.abime.net/showpost.php?p=1188826&postcount=32).
-
Thanks for clarifying.
No, I mean "I fixed this for the latest version I have". It is not fixed in your version. Beware! There is a third-party plugin "AsyncWB"(sp?) by Stephan Rupprecht which also has issues with large volumes. We don't have sources, so cannot fix it.
-
If you're adventurous, you can test out Toni's patched FFS 45.13 which fixes some bugs and enables DOS\8 long filenames! See this post on EAB (http://eab.abime.net/showpost.php?p=1188826&postcount=32).
When it comes to the FFS, one man's adventure is another man's daredevil stunt with tragically comic consequences.
Heed the warning: make backups of the data and check that you can restore them when needed, and only then maybe give this a spin.
-
When it comes to the FFS, one man's adventure is another man's daredevil stunt with tragically comic consequences.
Yup. Unless Toni invested quite a bit of work, this will not do. About the only thing that was present of DOS/8 in the 3.9 release is ExAll() and friends, and the computation of the maximum file size. Everything else on file names in DOS/8 was there borken... Open, Rename, Lock, .... you name it. I cleaned this up for V46, so it now works quite fine on my HD since probably a year or so.
One way or another: DOS/8 is most likely not going to become official. Not because it is too experimental - rather because we have another alternative that is more flexible.
-
Oh well, it really depends on what you are doing. As far as raw data transfer is concerned, neither file system can do any magic. It just has to take the user blocks, and direct the device to write them out. So far, so simple.
The things which the FFS does well it really does better than any other Amiga file system. For example, the FFS performs asynchronous read operations with very little overhead, and nearly zero CPU load if the underlying storage system supports DMA. There's even a demo created by Commodore which shows off streaming a pre-rendered animation (generated by "VistaPro"), the use of the double-buffering screen API in graphics.library, and rendering animations on top of that.
However, what the FFS does well is a small subset of the operations a file system generally has to get done properly, because they occur so frequently. This is where the FFS does not compare well against other Amiga file systems, except perhaps CrossDOS or CDFS (irony be damned).
What ought to work well is storage management, as in finding free space to store new data in quickly, while at the same time keeping fragmentation at bay and just maybe reduce seek latency at the same time (releasing storage space to the free pool is the flip side of this coin). This is doable, but it will cost you, e.g. XFS does this very well, but it has to throw a lot of memory and storage space at the effort.
Directory scanning, including retrieval of metadata, ought to be fast, too. The FFS has never scored well here, because it does not separate directory lists and file metadata. You should not have to wait for the directory contents to arrive in dribs and drabs. It makes the floppy/hard disk appear to be much slower than it actually is. The original 1.x Workbench tried to sidestep this problem by recording the contents of the directory in a ".info" file, but it only went so far: instead of having to walk through the entire directory list and reading the icon files it found, the ".info" file only helped to cut the scanning process short. Finding and reading the icon files remained dead slow because the file system didn't care about seek times or fragmentation.
I wish there were some convenient remedies in reach to address the shortcomings of the FFS design, but the only solutions I can imagine right now begin with introducing journaling with write-ahead logging. Once that can be made to work, we could enable dircache mode, which would instantly improve the directory access performance. Making storage management work better is particularly difficult because there exist no data structures in the FFS design to assist the process.
In any case, resolving these limitations will have the probably unwelcome side-effect of requiring more RAM and more storage space than the FFS needs today. Could be this will be a worthwhile trade-off, but none of these possible changes will come together without a lot of prior work and testing. We are still kinda short-handed in brushing up AmigaOS 3.1 for more exciting things to come, so all of the FFS changes might have to wait a little while longer.
-
Hi, I have a couple of questions regarding the 3.1 update:
Will there be a CD32 workbench version support? Or will CD32 users still have to resort to hacks and custom built workbench cdroms? (freeanim+joymouse+setcdreboot+cdaudio+OSK)
And then, what about also adding CTDV workbench support with the RMTM command?
HDToolbox unfriendly brother prod_prep will be updated to support large drives?
Will you also include the quite handy but never directly included "reboot" and "findresident" commands?
Thank you for your time.
-
Once that can be made to work, we could enable dircache mode, which would instantly improve the directory access performance. Making storage management work better is particularly difficult because there exist no data structures in the FFS design to assist the process.
Is that a different dircache mode to Commodore's one? IIRC that had some shortcomings and wasn't recommended to be used, although I forget why.
-
Hi, I have a couple of questions regarding the 3.1 update:
Will there be a CD32 workbench version support? Or will CD32 users still have to resort to hacks and custom built workbench cdroms? (freeanim+joymouse+setcdreboot+cdaudio+OSK)
Sorry, this has not been discussed yet. Building a CD32 ROM should be possible with a minimum of fuss, using the CD32-specific components last updated in 1994. But so far nobody has even investigated if it would be possible to build them from source.
So, you might want to wait until we've shipped something and just maybe we could have a look at the CD32 bits to see what can be made to build. This is rather exotic code to begin with, mind you...
And then, what about also adding CTDV workbench support with the RMTM command?
The CDTV code is closely linked to the Kickstart 1.3 ROM code. Nobody knows how to build any of this today, except perhaps the original CDTV project members, including Carl Sassenrath, and we haven't asked them yet. So, the short answer for now is "probably not, because we haven't got enough of a clue to make it happen".
I for one would like to see more light shed on the CDTV code, which is frankly pretty amazing stuff which was so far ahead of its time that it was almost tragically destined not to achieve lasting impact on the state of the art.
HDToolbox unfriendly brother prod_prep will be updated to support large drives?
Sir, I bow to you, because you just made my day merely by asking that very question :)
Yes, "prod_prep" has been updated by yours truly to support large drives, to the general puzzlement of everybody involved in this AmigaOS 3.1 update project (most Amiga users don't know what "prod_prep" does, some are probably afraid to ask, or embarrassed to admit having wrecked their hard disks by accidentally using it). However, no amount of rewriting can remove all the quirky & twisted limitations of that runt of a partitioning program. Right now "prod_prep" is generally safe not to make a big mess/crash/set your cat on fire if it encounters a drive larger than 2 Gigabytes. If my calculations are correct, the upper limit are 2.2 Terabytes, but you would be very "brave" indeed to allow "prod_prep" to set up a partition scheme for you on a disk that large.
We really ought to have a safe and sound baseline RDB library which would support all RDB data structure management operations, including reading and writing them. A robust "prod_prep" and "HDToolBox" could be built from that library, and hard disk controllers which deal with RDB data could rely upon a single tested library for that purpose. Right now we have none of that, with hilarious consequences.
Will you also include the quite handy but never directly included "reboot" and "findresident" commands?
These are part of the "Install3.1" disk "C" commands, if I remember correctly, so in a way these are still included, just not installed by the installation script. I believe you would like to see them installed among the regular shell commands, is that correct?
-
Is that a different dircache mode to Commodore's one? IIRC that had some shortcomings and wasn't recommended to be used, although I forget why.
It's the same thing, and just to confuddle and befuse everybody, it has several different names (DCFS, fastdir mode, dircache mode).
The shortcomings are finally documented in the Wikipedia article (https://en.wikipedia.org/wiki/Amiga_Fast_File_System), which links to the low level documentation on the DCFS and LNFS flavours which I wrote so that finally there was something that Wikipedia could quote ;)
-
It's the same thing, and just to confuddle and befuse everybody, it has several different names (DCFS, fastdir mode, dircache mode).
Oh no, not DCFS again... Yes, this thing "sort of" works, but I was more than happy that I did not need to touch *this* part of the code for the new DOS variants. Mind you, the FFS code is not in perfect shape. It's the sort of assembler code that lacks proper convention - in the sense that *this* function requires arguments in a3 and d0, and messes a2, but *that* function preserves registers and requires arguments in a0 and d0. Not that anyone felt that documenting calling conventions would be necessary...
One way or another: I will certainly, most definitely, not touch the DCFS code on *this* particular implementation.
-
Will there be a CD32 workbench version support? Or will CD32 users still have to resort to hacks and custom built workbench cdroms? (freeanim+joymouse+setcdreboot+cdaudio+OSK)
The build chain includes CD32 targets, yes. Question is whether there will be any chance to test it.
And then, what about also adding CTDV workbench support with the RMTM command?
...and there are no traces of CDTV support in the build chain whatsoever. So probably make this a "likely not".
HDToolbox unfriendly brother prod_prep will be updated to support large drives?
Hah, and I didn't even knew about what that is probably a day ago. (-: Yes, Olaf updated prod_prep. It will probably go through another polishing stage to make it use TD64 or DirectSCSI if applicable, but it's again the type of source you better don't touch, and you feel dirty all over after having done the job.
Will you also include the quite handy but never directly included "reboot" and "findresident" commands?
I cannot really tell, as I haven't checked whether we have sources. But it looks to me as they are either easy to do, or easily replacable by existing tools.
-
While we are throwing around ideas... how about some mechanism to have system time survive reboots, even without RTC available?
Would also be nice if C:reboot could "lock" mounted local disk devices before performing the reboot (I think for example LoadModule does this).
C:Date needs some love, it's confusing the way it does locale, and it could really need "LFORMAT" like option.
And speaking of LFORMAT, the default output from C:List does not work well with long filenames and more, would make sense to make it terminal/console width aware, or ar least user configurable (for example via a variable). Oh, and.. the lack of a %X (where X is any available letter) that is similar to %P only without trailing / has been driving me nuts!
-
Great, but I just installed OS3.9 with all possible updates ;). How much more someone can update 060.library?
I think people would be happy to have new chip rom with "official" updates so we don't need to restart Amiga's multiple times.
We need new OS3.95 :D.
What about OS3.9 update...
They dont have rights for "3.9" haage and parnter still retains them afaik
-
They dont have rights for "3.9" haage and parnter still retains them afaik
Rights extended to them by whom? A long dead company? Any agreements they had with a company or companies that are now out of business are null and void and I'm certain they were never extended a perpetual license, so stop spreading this crap.
OS3.x became abandoware years ago yet Cloanto kept distributing copies anyway....as have other dealers out there who thought they could make a quick buck by continuing to sell copies....and now Hyperion has jumped on the same bandwagon. They have no more rights to OS3.x than anyone else...they just have an attorney who threatens to sue anyone who wants to sell copies.
-
Rights extended to them by whom? A long dead company? Any agreements they had with a company or companies that are now out of business are null and void and I'm certain they were never extended a perpetual license, so stop spreading this crap.
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 :(
-
While we are throwing around ideas... how about some mechanism to have system time survive reboots, even without RTC available?
Yes, I noted the issue, but haven't thought about a cure yet. There are so many other items on my agenda, it is hard to keep an overview.
Would also be nice if C:reboot could "lock" mounted local disk devices before performing the reboot (I think for example LoadModule does this).
This is all fairly trivial stuff. DiskSafe + Reboot will do just that for you, which puts another item on my agenda. It would be much better if DiskSafe would be integrated into the FFS instead of operating as a patch on top of the dos.library. IOWs, I don't quite see why existing tools cannot do that for you right away.
C:Date needs some love, it's confusing the way it does locale, and it could really need "LFORMAT" like option.
Maybe yes. This issue wasn't pressing enough to be on my list.
And speaking of LFORMAT, the default output from C:List does not work well with long filenames and more, would make sense to make it terminal/console width aware, or ar least user configurable (for example via a variable).
List is a rather simple "linear list" output I don't want to modify for backwards compatibility reasons. There are surely programs that parse what list generates, so I'd better not touch it. Yes, it has problems with long file names, but more internally in the buffer management. They have been fixed. List also got an option to indicate links and link targets. Actually, the same as in AmigaOs 4.0 (don't create too many inconsistencies here).
If you want a "nicely formatted output", this is what "dir" is good for. Yes, "Dir" got some care, and yes, it is now aware of the console dimensions. It will even work nicely over AUX: provided the connected terminal speaks CSI sequences. It no longer uses only two columns, but computes the number of columns dynamically. Pretty much like "ls" on *ix does.
Dir also learned softlinks and hardlinks.
Oh, and.. the lack of a %X (where X is any available letter) that is similar to %P only without trailing / has been driving me nuts!
This sounds like a doable idea. I just need to check which letter is available, and whether there is something like this in Os 4.
-
Thanks for answers :)
-
@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.
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.
An RDB library sounds like a very good idea.
Will you please replace graphicdump with a more usable snapshot tool?
It is archaic and not flexible at all. A simple screen grabber that saves to disk would suit much better, and even more now, taking into account the sad state of the printing system.
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. :D
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.
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.
Thanks again.
-
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....
-
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).
-
When will the update be available to purchase, and will it be in the form of an update or a complete new install?
-
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
@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. :D
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.
-
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,
( 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.
( 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.
-
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 :(
-
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.
-
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.
-
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;
-
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.
-
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?
-
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.
-
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).
-
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?
-
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.
-
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.
-
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.
-
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
-
Since we're fishing around 3.x - was there a changelog for serial.device 43.1(?)?
-
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.
-
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...
-
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.
-
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.
-
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.
-
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. (-:
-
@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).
-
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.
-
@Olsen @Thor,
Is there plan to support the Vampire? SAGA, 16bits audio, AMMX1/2 ?
Kamelito
-
@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.
-
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.
-
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?
-
@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.
-
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
-
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?
-
Gulliver
It is great to see you taking an interest in this.
-
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.
-
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.
-
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.
-
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?
-
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. ;)
-
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 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. :D
-
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!
-
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.
-
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.
-
That'll screw up all dates that are stored as a 32-bit integer. I suspect this includes FFS.
The date stamp information used by the FFS, all file systems, dos.library, etc. is genuinely and thoroughly "pre-screwed" already (thank you very much, Tripos). It is good for at least another 5 million years, although I suspect that the time and date conversion inside dos.library will have rolled over several times before the signed 32 bit day counter reaches the ends of its tether ;)
Modern man has been around for only 1 about million years, so I guess we could pin our hopes on other intelligent species to arise and maybe find a fix for that pesky year 5,883,516 problem in what the ancients used to call the one true operating system.
-
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 :)
The basic problem we have with the shell is that it's not designed to be extensible. You cannot currently write a shell script which is able to probe for extended shell capabilities. Mind you, the shell is not an interpreter, and it does not have a consistent language as such. Sure, it's Turing-complete, but that doesn't mean it's useful (your basic Turing machine is Turing-complete, too, but it doesn't do anything beyond that).
If I remember correctly, the complete shell "language", such as the portion which covers variable expansion, escape characters, brackets and other arcana, is still underdocumented to the point that you could drop the letters "der" from that word and still make sense. Let's not put lipstick on that pig just yet ;)
-
Just port DCL already, hehehe :p
-
Mind you, the shell is not an interpreter, and it does not have a consistent language as such. Sure, it's Turing-complete, but that doesn't mean it's useful (your basic Turing machine is Turing-complete, too, but it doesn't do anything beyond that).
If I remember correctly, the complete shell "language", such as the portion which covers variable expansion, escape characters, brackets and other arcana, is still underdocumented to the point that you could drop the letters "der" from that word and still make sense. Let's not put lipstick on that pig just yet ;)
Years ago I tried to cover the syntax of the shell in the Shell.guide that should be part of 3.9, or at least of the shell updates I provide from time to time. Yet, the syntax documented there is rather the consequence of various Tripos legacy functions that are used here and there within the shell, and I try to keep this syntax consistent, even though it is ugly as hell. Unfortunately, nobody really thought of the consequences when implementing this stuff, aparently in a rather ad-hoc way of "ok,works for me".
So for example foo"bar parses as a single token by the dos.library ReadItem(), which is why the shell syntax parser has to follow it. Similarly, foo" is a single token whose last character is a double quote,and so is foo) or (foo, where the bracket is not a separate token, but part of the token. Then, the "*" is an escape character, but only within quotes, and mind you again, an inner quote is not a quote but a literal, so it does not make the star any special.
All this weirdness has several consequences, especially in the low-level "tools" of the such as Execute, which has to insert formal parameters into strings, and depending on whether they are quoted, has to use the escape mechanism of BCPL to get the substitution right. Execute was, therefore, seriously broken up to V45, and probably even there it might have some corner cases I simply failed to fetch. Escaping and quoting *should* work now, but its non-obvious.
Just recently, I found that RequestFile is also broken as it always puts double quotes aruond the selected files. Which is wrong - consider a file that contains a double quote as part of its name, or an asterisk. Select a file named foo"bar, and the result of RequestFile would be "foo"bar", which are two tokens, namely "foo" and bar", and not the desired one token. Oh well...
This is precisely why I prefer *NOT* to extend the shell syntax. It's really not getting any better by adding more rules to the already inconsistent syntax.
-
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.
UNIX worked the same way. So how are they handling this situation?
I would recommend a 64-bit integer accurate to three decimal places instead of just to the nearest second. How many decimal places does the new Apple APFS track seconds? Can't remember off the top of my head.
Deprecate the old 32-bit integer system. Old software using this system after the 2036 roll over will get the wrong date. But at least new software and the OS would be able to track proper dates and times.
-
@olsen
@Thomas Richter
Hi, back again. Here is a list of old bugs/abnormalities, have they been addressed?
Sorry for the long post. :D
utility.library (bug reported by Peter Keunecke)
===============
There is a potential risk of getting asystemcrash in some rare
cases caused by a dangerous procedure in the ROM-function
CloneTagItems(), which does not switch off the multitasking
during the copy routine. Whenever another task uses
RefreshTagItemClones() or other means to change the source
TagList while the copy is still running, it could happen, that
CloneTagItems runs out of memory and trashes the next memblock.
exec.library (bugs reported by Harry Sintonen)
============
exec/Alert() causes privilege violation trap with 68010+
CPUs if VBR is not at zero and the alert is of DEADEND type (very
annoying bug).
exec/FreePooled() not releasing memory. Empty puddles would not
get returned to the free memory list until the pool was DeletePool()ed
(minor but yet annoying bug).
exec/ReleaseSemaphore() trashing d0/d1/a0 when calling release
without obtain (minor bug, can only occur with misbehaving exec/Alert()
patch).
Missing BOOL return code workaround to exec/CheckIO() routine. The new
code should try to figure out if the caller is going to interpret the result
wrong, and if this is the case, will fix the return code (minor bug).
exec/OpenLibrary() not passing open-version in d0 for LIB_OPEN,
unlike the example sources suggest. (minor bug)
SAD/TURN_ON_SINGLE returning crap as old trace vector address
and SAD/TURN_OFF_SINGLE sending 4 bytes of crap after command DONE.
(minor bugs, as no-one really use SAD)
Return code workaround for old amiga.lib (upto version 40.15)
CreateTask() misinterpreting exec/AllocEntry return code. amiga.lib
V44.1 fixed this bug, but lots of current programs still have the bugged
CreateTask() routine in them. (nasty bug, causes crashes in low mem
situations)
Workaround for exec/GetMsg() and 68060 CPUs, braindead programs
calling GetMsg() in tight loop would lock up the system. (minor bug)
exec/ReleaseSemaphore() calculating wrong SS_NESTCOUNT when
both Procure() and ObtainSemaphore() were pending for the same task.
(nasty bug)
graphics.library
================
graphics/InitArea() bug, AreaEllipse() crashed if buffer wasn't
explicitly zeroed & maxvectors was limited to 8191.
The SetRGB32CM() AGA OS call doesn't set the lower 4 bits of the
blue component. You can prove this by calling SetRGB32CM() and
studying the blue component calling GetRGB32().
AmigaOS knows three functions in graphics.library that output
chunky pixels to a RastPort: WritePixelLine8, WritePixelArray8
and WriteChunkyPixels. The original versions of these routines
in the KickstartROM are rather slow and have a bug that trashes
the chunky source buffer. (Michael van Elst)
queue-handler (Heinz Wrobel)
=============
Nasty bugs with PIPE:, like loosing characters.
requestchoice (Joerg Riemer)
=============
The description of Requestchoice explains, that the secondary return
value will hold the selected gadget number. but RequestChoice never
returned a corresponding pr_result2 variable.
the reason for that is requestchoice uses the dos function (setioerr) to save
the selected gadget number as the result2 variable. but due the fact that
the result2 variable depends on the returncode a program leaves in register
D0, this one never alifes a succesful exit of requestchoice.
during the debugging of RequestChoice i found two other hidden bugs. there
was some allocated memory never freed on exit and secondly, the dos function
ReadArgs() was not associated with FreeArgs().
version (Frederic Steinfels)
=======
The original c:version command had a nasty bug: If the last
four bytes of a file contained a $ sign, the version command
went into an endless loop.
amigaguide.library (James Jacobs)
==================
A delay is required between the SetAmigaGuideContext() and
SendAmigaGuideContext() calls.
No AmigaGuideMsg is sent back to the launching application when the
user quits an AmigaGuide which was launched via the
OpenAmigaGuideAsync() function.
asl.library 45.4: (James Jacobs)
===========
If you type a nonexistent path into the "Drawer" gadget (eg. SYS:Foo
when there is no such drawer) and then press ENTER, then (after you have
declined any offer to create the drawer), the program which called the
ASL library will crash (suspend/reboot requester) with error $80000005.
dos.library (James Jacobs)
===========
LoadSeg() will always report success on files that are less than 4 bytes
in size, even though the smallest valid executable is 36 bytes. Files from
4-35 bytes in size are still correctly reported as non-executable.
Installer (James Jacobs)
=========
The documentation for the "askchoice" function is wrong. The result of
"askchoice" is returned as a zero-based ordinal integer, not a bit mask.
version.library (James Jacobs)
===============
It doesn't seem to like being closed if some other program still has it
open (very briefly flashes up some guru alert).
-
I found the original that should be in the bug db:
Yes, but *this bug* was fixed a long time ago. 1993 in my records. (-: So no worries.
-
No AmigaGuideMsg is sent back to the launching application when the
user quits an AmigaGuide which was launched via the
OpenAmigaGuideAsync() function.
That was only recently fixed for OS4. Hopefully it's an easy one to backport.
There are also bugs in GadTool's image menu functionality (which may be an Intuition bug), which have been fixed in OS4 but existed in OS3 when I was trying to test if I was doing something wrong - and I suspect never worked. I don't see that being fixed though, as it doesn't work at all nobody uses it!
-
utility.library (bug reported by Peter Keunecke)
===============
There is a potential risk of getting asystemcrash in some rare
cases caused by a dangerous procedure in the ROM-function
CloneTagItems(), which does not switch off the multitasking
during the copy routine. Whenever another task uses
RefreshTagItemClones() or other means to change the source
TagList while the copy is still running, it could happen, that
CloneTagItems runs out of memory and trashes the next memblock.
This is not a bug. Tags are not shared resources, and if they are, tasks need to use a locking protocol to avoid conflicts when accessing the same resource simultaneously. Taglists are not any different from this.
exec.library (bugs reported by Harry Sintonen)
============
exec/Alert() causes privilege violation trap with 68010+
CPUs if VBR is not at zero and the alert is of DEADEND type (very
annoying bug).
This is hairy and hard to address given that at DEADEND alert time, almost no guarantees can be given. I have this fixed, though I hope the fix works.
exec/FreePooled() not releasing memory. Empty puddles would not
get returned to the free memory list until the pool was DeletePool()ed
(minor but yet annoying bug).
This is not a bug. This is a design decision that puddles stay around and remain available, even if full, for the next allocation to be coming.
exec/ReleaseSemaphore() trashing d0/d1/a0 when calling release
without obtain (minor bug, can only occur with misbehaving exec/Alert()
patch).
This has already been fixed in Os 3.9.
Missing BOOL return code workaround to exec/CheckIO() routine. The new
code should try to figure out if the caller is going to interpret the result
wrong, and if this is the case, will fix the return code (minor bug).
I believe it was me who reported this bug to Heinz, and the v40 workbench was guilty of running into this. Yes, there is a workaround in exec, and a patch in SetPatch.
exec/OpenLibrary() not passing open-version in d0 for LIB_OPEN,
unlike the example sources suggest. (minor bug)
It cannot pass the version number in d0 - where is this nonsense documented?
SAD/TURN_ON_SINGLE returning crap as old trace vector address
and SAD/TURN_OFF_SINGLE sending 4 bytes of crap after command DONE.
(minor bugs, as no-one really use SAD)
SAD is a sad story. Hmm. I might even replace this by good ol' RomWack again. That was actually *a bit* useful.
Return code workaround for old amiga.lib (upto version 40.15)
CreateTask() misinterpreting exec/AllocEntry return code. amiga.lib
V44.1 fixed this bug, but lots of current programs still have the bugged
CreateTask() routine in them. (nasty bug, causes crashes in low mem
situations)
That's a bug in AmigaLib. There is no workaround in exec. Yes, it is a bug to easily trap into. At worst, I would probably add something to setpatch. At this time, there is no fix.
Workaround for exec/GetMsg() and 68060 CPUs, braindead programs
calling GetMsg() in tight loop would lock up the system. (minor bug)
The fix is in since 3.9.
exec/ReleaseSemaphore() calculating wrong SS_NESTCOUNT when
both Procure() and ObtainSemaphore() were pending for the same task.
(nasty bug)
The fix is in since 3.9.
graphics.library
================
graphics/InitArea() bug, AreaEllipse() crashed if buffer wasn't
explicitly zeroed & maxvectors was limited to 8191.
The SetRGB32CM() AGA OS call doesn't set the lower 4 bits of the
blue component. You can prove this by calling SetRGB32CM() and
studying the blue component calling GetRGB32().
At this time, I'm not touching graphics. Sorry. This code is too messy, and I don't want to make it any worse.
AmigaOS knows three functions in graphics.library that output
chunky pixels to a RastPort: WritePixelLine8, WritePixelArray8
and WriteChunkyPixels. The original versions of these routines
in the KickstartROM are rather slow and have a bug that trashes
the chunky source buffer. (Michael van Elst)
See above. Not now.
queue-handler (Heinz Wrobel)
=============
Nasty bugs with PIPE:, like loosing characters.
The pipe handler has been completely rewritten. The old code was crap. There were a couple of new requirements for the shell and its pipe, so I had to add functionalities anyhow, like proper handling of the broken pipe condition, or unnamed pipe targets.
requestchoice (Joerg Riemer)
=============
The description of Requestchoice explains, that the secondary return
value will hold the selected gadget number. but RequestChoice never
returned a corresponding pr_result2 variable.
This is not really a bug, it is a side effect of how the shell works, but I don't want to change this in the shell. RequestChoice returns now a return code 1 in case it wants to signal that something but the rightmost gadget has been pressed. Besides, you can now set an abritrary variable (not just $Result2) on return, which is far more useful.
version (Frederic Steinfels)
=======
The original c:version command had a nasty bug: If the last
four bytes of a file contained a $ sign, the version command
went into an endless loop.
This must have been fixed already, it works fine here.
amigaguide.library (James Jacobs)
==================
A delay is required between the SetAmigaGuideContext() and
SendAmigaGuideContext() calls.
No AmigaGuideMsg is sent back to the launching application when the
user quits an AmigaGuide which was launched via the
OpenAmigaGuideAsync() function.
Cannot reproduce at this time, sorry. But there is a new version...
asl.library 45.4: (James Jacobs)
===========
If you type a nonexistent path into the "Drawer" gadget (eg. SYS:Foo
when there is no such drawer) and then press ENTER, then (after you have
declined any offer to create the drawer), the program which called the
ASL library will crash (suspend/reboot requester) with error $80000005.
The new version does not seem to have this problem.
dos.library (James Jacobs)
===========
LoadSeg() will always report success on files that are less than 4 bytes
in size, even though the smallest valid executable is 36 bytes. Files from
4-35 bytes in size are still correctly reported as non-executable.
Dos is again one of the components I will not touch at this time. I could create a SetPatch for this, but this does not seem to be serious enough to justify a patch.
Installer (James Jacobs)
=========
The documentation for the "askchoice" function is wrong. The result of
"askchoice" is returned as a zero-based ordinal integer, not a bit mask.
This is a documentation bug. But anyhow, there was and still is enough wrong with the installer which I need to revisit. For example, pattern matching seems to use the wrong style of patterns, and I found a MuForce hit in its internal wirings.
version.library (James Jacobs)
===============
It doesn't seem to like being closed if some other program still has it
open (very briefly flashes up some guru alert).
[/QUOTE]
Yes, this is fixed.
-
@Thomas Richter
Thank you again for taking the time to answer.
I have a couple more of questions: :D
1.Will printer.device be 24 bit capable?
2.Is Reaction/ClassAct going to be included?
3.What about DefIcons?
4.AsyncWB?
5.RAWBInfo?
6.Will iconedit support glowicon editing? or will it be the same as 3.1?
7.Will ScreenMode prefs have the "Test" button function like in 3.9?
8.Will WBPattern have a layout option like in 3.9 where it lets you center, scale, tile or scale well the chosen pattern?
9.Mounter tool will be there?
10.A fixed Unarc?
-
Number 7 question above is a good question.
-
1.Will printer.device be 24 bit capable?
The more relevant question is probably "will there be a printer.device". Quite frankly, which printers do you want to connect to the Amiga, and how? Parallel printers are hard to get, except in a museum, and printers you can get are most likely not supported by any printer driver we have. So what exactly do you plan to do?
At this time, I'm not sure whether I have an updated printer.device, but we most certainly do not have updated printer drivers, so this device is kind of pointless.
2.Is Reaction/ClassAct going to be included?
I do not know. We probably do not have the copyright, I need to check. Did I say that this is a bugfix release, and it is named 3.*1*.4, not 3.*14*? The GUI will be the gadtools GUI.
3.What about DefIcons?
4.AsyncWB?
5.RAWBInfo?
6.Will iconedit support glowicon editing? or will it be the same as 3.1?
7.Will ScreenMode prefs have the "Test" button function like in 3.9?
8.Will WBPattern have a layout option like in 3.9 where it lets you center, scale, tile or scale well the chosen pattern?
9.Mounter tool will be there?
10.A fixed Unarc?
No, no, no no... Please, these are to a major degree third party contributions,and we neither have sources, nor the copyright. To my best of my knowledge, things will continue to work, probably with the same bugs as before, but we cannot ship what we do not have.
E.g. for AsyncWB we already know that it has a problem with showing the drive info correctly on large devices, and without having sources available, it will continue to be broken.
To get updated versions of these programs, please contact their corresponding authors.
Once again: This is a bugfix release of 3.1 which is why it is named 3.1.4. We try to get as many of the existing components on board, but we can surely not simply ship third-party contributions to 3.9 along with it without permission of the corresponding authors.
-
The more relevant question is probably "will there be a printer.device". Quite frankly, which printers do you want to connect to the Amiga, and how? Parallel printers are hard to get, except in a museum, and printers you can get are most likely not supported by any printer driver we have. So what exactly do you plan to do?
Probably just about any current printer can be used with a PostScript driver - if you don't mind printing through a PC or RaspberryPi. There are some network printing utilities on Aminet (like http://aminet.net/package/comm/tcp/NetPrinter or http://aminet.net/package/comm/tcp/lpr-dev) - it should be possible to print via properly configured Linux machine.
So I wouldn't remove the printer support.
-
The more relevant question is probably "will there be a printer.device". Quite frankly, which printers do you want to connect to the Amiga, and how? Parallel printers are hard to get, except in a museum, and printers you can get are most likely not supported by any printer driver we have. So what exactly do you plan to do?
Print to network printer or to file, like I always did.
I have a Commodore MIPS 1200P line printer :laughing:
What plans are there regarding prefs apps in general? Just leave them as is? Especially I am curious about workbench prefs, since I get the impression that workbench.library v45 will be used.
-
Just use TurboPrint with the best supported printer you can find on eBay and don't let it break down! IrseeSoft will issue more updates one day if we wait long enough and maybe new DENEB USB boards will be given away with breakfast cereal :laugh1:
-
OS3.1 Update? As you can see there is plenty of people that would like to have update "here and there" etc. Like I wrote before, leave it as is. That way it stays as a retro system with all it limitations etc. Most of those limitations can be overcome in some way and is actually part of "retro experience".
If someone have to much time in their hands why not to fix AmigaOS4.1 FE for Classics? This system can't be installed on "supported" HW without many issues, Update 1 is useless and Enhancer Package for classics is configured by default not for classics but for way more powerful Amiga. Why not to add support for some other HW?
-
@kreciu
That way it stays as a retro system with all it limitations etc. Most of those limitations can be overcome in some way and is actually part of "retro experience".
So struggling to get a 4Gb+ hard drive to work is "part of the retro experience" is it? Or are hard drives voodoo too because you think an unexpanded A500 was the only 'true' Amiga? There is nothing wrong with removing bugs but it is a shame we can't use the OS3.9 code base after all these years :-(
-
If someone have to much time in their hands why not to fix AmigaOS4.1 FE for Classics?
If you have enough time to write this post, then why can't you come and clean my car?
-
@Olsen @Thor
One update has already been done but what is the plan regarding pricing.
If I buy a new update of WB&KS are the update after them free?
If yes free until when? 3.2?
Kamelito
-
@Olsen @Thor
One update has already been done but what is the plan regarding pricing.
If I buy a new update of WB&KS are the update after them free?
If yes free until when? 3.2?
Kamelito
We are developers, not product managers. I cannot really say anything about pricing whatsoever.
-
We are developers, not product managers. I cannot really say anything about pricing whatsoever.
Good. So I suppose that there's a plan to publish all developers information to date for the OS. Something like wiki.amigaos.net but for AmigaOS 3.1.x and maintain it if the developer API evolve. To my knowledge only 2.0 is covered by the RKRM.
Kamelito
-
Good. So I suppose that there's a plan to publish all developers information to date for the OS. Something like wiki.amigaos.net but for AmigaOS 3.1.x and maintain it if the developer API evolve. To my knowledge only 2.0 is covered by the RKRM.
Kamelito
This is definitely in the cards. For AmigaOS4 the complete 3rd RKM text was imported into MediaWiki (from the original manuscripts), revised and subsequently updated to cover AmigaOS4. The same could be done for AmigaOS 3.
However, getting everything revised and updated for AmigaOS4, including the illustrations, was a huge effort that took its time. So, please be patient...
-
This is definitely in the cards. For AmigaOS4 the complete 3rd RKM text was imported into MediaWiki (from the original manuscripts), revised and subsequently updated to cover AmigaOS4. The same could be done for AmigaOS 3.
However, getting everything revised and updated for AmigaOS4, including the illustrations, was a huge effort that took its time. So, please be patient...
Sure but, when it was imported in the wiki all the docs where the 3rd RKRM with nothing specific to OS4, so it has already been done. Why not go back to the point of the first import? Except course if you do not share with them. Kamelito
-
Sure but, when it was imported in the wiki all the docs where the 3rd RKRM with nothing specific to OS4, so it has already been done. Why not go back to the point of the first import? Except course if you do not share with them. Kamelito
Yes, that's the point I was making. However, importing the text is but just the first step of making the contents available.
For example, the illustrations need to be imported as well, which is a tad difficult. These are PostScript files, and a good number of these are missing and cannot be regenerated from the original Professional Page files due to corruption. For AmigaOS4 that problem was solved by redrawing the missing illustrations. The illustrations were then rendered to PNG image files.
If I remember correctly, the import process generated artefacts in the wiki text which had to be found and repaired manually, and then there's the issue with hyperlinks.
All of that was done for the AmigaOS4 version, and it's a time-consuming process which, while doable, requires a lot of effort.
-
Yes, that's the point I was making. However, importing the text is but just the first step of making the contents available.
For example, the illustrations need to be imported as well, which is a tad difficult. These are PostScript files, and a good number of these are missing and cannot be regenerated from the original Professional Page files due to corruption. For AmigaOS4 that problem was solved by redrawing the missing illustrations. The illustrations were then rendered to PNG image files.
If I remember correctly, the import process generated artefacts in the wiki text which had to be found and repaired manually, and then there's the issue with hyperlinks.
All of that was done for the AmigaOS4 version, and it's a time-consuming process which, while doable, requires a lot of effort.
Fair enough, don't hesitate to ask for help for the wiki, I'm sure that many are willing to help. Kamelito
-
Probably just about any current printer can be used with a PostScript driver - if you don't mind printing through a PC or RaspberryPi. There are some network printing utilities on Aminet (like http://aminet.net/package/comm/tcp/NetPrinter or http://aminet.net/package/comm/tcp/lpr-dev) - it should be possible to print via properly configured Linux machine.
This is true for an old CUPS version (a couple of years ago). Since then, the CUPS support seems to be broken (http://www.amigans.net/modules/xforum/viewtopic.php?post_id=101224#forumpost101224) (SSL issues?).
-
This is true for an old CUPS version (a couple of years ago). Since then, the CUPS support seems to be broken (http://www.amigans.net/modules/xforum/viewtopic.php?post_id=101224#forumpost101224) (SSL issues?).
Maybe not... (http://www.amigans.net/modules/xforum/viewtopic.php?post_id=108769#forumpost108769)
-
Just port DCL already, hehehe :p
Holy crap, I should be careful with what I suggest! :roflmao:
http://aminet.net/package/misc/emu/AmiVms
-
Holy crap, I should be careful with what I suggest! :roflmao:
http://aminet.net/package/misc/emu/AmiVms
Wow - as an ex OpenVMS guy that is a seriously cool piece of work. Can't think why I would ever use it these days though, but damn some work went in to it!
Must have been used for porting apps to the amiga at one stage.
-
every time they upgrade 3.1 they make it slower. 3.9 , I wish I had never installed it, it turned my wondefull Amigas into something really ugly to look at and so slow I haven't turned them on in 8 years.
Just swung in here today just to see if it was still alive.
-
every time they upgrade 3.1 they make it slower.
That's called "adding features". But you know, if you don't want that, I hear 1.3 is really fast. :laughing:
-
Sure, 3.1 with a 4 or 16 color HiRes Workbench is fast. Noticeably faster than 256 color AGA, and 16-bit color via RTG. Still quite usable even with the 040 I used to have in this rig (now an 060.)
To be fair, my 030 500+ can still only do a 16 color Workbench, but even with that 3.9 is quite usable.
Sorry you had such problems. Maybe someone here can help before you put them back away -- either fix up your Amigas or take them off your hands.
-
I decided to write some preliminary documentation about Prod_Prep for those of you who would like to tinker with it, since it seems from previous posts of this thread, it is widely unknown.
This documentation is full of inacuracies, incomplete, and prone to explode :D
Prod_Prep v39.1
=========
WARNING: This is an advanced partitioning and format tool. Incorrect usage will definately damage your harddisk structure. You have been warned!
Prod_Prep is the ugly but otherwise powerful brother of HDToolBox. It comes hidden, and is never installed by default. Can be located in the 3.1 floppy disk "Install3.1", inside the C: drawer. It is a very comfortable tool for automatically deploying an entire Amiga system from within a script. It lets you partition and format harddrives in a non interactive manner by feeding the program the proper instructions from a shell/script.
It is still bound to the same limitations that the 3.1 HDToolbox has. All the same warnings about HDToolBox from 3.1 apply to Prod_Prep.
TEMPLATE:
? - list all template commands
Prod_Prep [|-] [device ] [unit ]
[layout] [badfile ] [formatonly] [noverify] [verifyonly] [slowdown]
quit - exit this program
addpart M|K|C|%|rest
[bootable ] [dostype 0x]
[buffers ] [mask 0x]
[maxtransfer 0x] [customboot ]
[nomount]
deletepart [noerror]- delete a partition
writerdb [force] - write out rigid disk block
format [force] - format drive
verify- check for bad sectors and map out
readfs [] [version ] [dostype 0x] -read FFS from file (default l:fastfilesystem)
synch [on|off] - turn synchronous mode on or off
reselect [on|off] - turn reselect mode on or off
readrdb - reads rigid disk block from drive
Examples:
Prod_Prep layout.script device scsi.device unit 0
; In here, layout.script is a file that should only contain the list of instructions that will alter the drive 0 structure that is connected to scsi.device
; layout.script file contents example:
addpart Workbench: 200M bootable 1 dostype 0x444f5303 buffers 300
addpart Work: rest dostype 0x444f5303 buffers 300
format force
readfs Install3.1:L/FastFileSystem dostype 0x444f5303
reselect on
writerdb force
quit
; End of sample layout.script file (do not add any comments to your script file!).
; This will create 1 bootable, already formatted partition named Workbench: using FFS intl/nodircache of 200MB in size.
; Will also create another non-bootable partition called Work: using FFS intl/nodircache using the rest of the drive remaining space.
; The filesystem used will come from Install3.1:L/FastFileSystem
It is important for the correct use of this tool to understand that each single filesystem buffer will take away 1KB of ram from your system, so if you analyze the example above, you will realize, it will cost you 600KB of ram. The more buffers the faster your system will be able to handle big files, always at the cost of precious ram. As a suggestion, never go too low, to avoid potential issues, and if your system can handle the loss of 2MB of ram, just go nuts, and go for up to 2000 buffers. An average between 90 and 300 is what I would consider a good compromise between speed and ram usage. But the choice is yours, and it may largely depend on how your system is setup/used.
ADDENDUM: AMIGA FILESYSTEM DOSTYPES
FILESYSTEM, DOSTYPE, COMMENTS, LIMITS
PFS3_aio, 0x50465303, Amiga PFS file system 3. Even runs on a 68000 with kickstart v1.3!, Filename 107 chars/filesize 2GB/partition 104GB.
PFS3_aio, 0x50445303, Amiga PFS file system 3 SCSIdirect. Even runs on a 68000 with kickstart v1.3!, Filename 107 chars/filesize 2GB/partition 104GB.
SFS0, 0x53465300, Amiga Smart File System V1, Filename 107 chars/filesize 2GB/partition 128GB.
SFS2, 0x53465302 Amiga Smart File System V2, Filename 107 chars/filesize 2GB/partition 1TB.
FFS Intl+noDirCache, 0x444f5303, This is the most commonly used and compatible one. Came with AmigaOS >= 2.0., Filename 30 chars/filesize 2GB/partition 2GB.
FFS2, 0x444f5307, This is the one that comes with OS4. Also supports DOS 8., Filename 107 chars/filesize 2GB/partition 128TB.
FFSAIO, 0x444f5308, DOS 8. Beta status. It comes as a patch for FFS v45.13 (FFS 45.20r1)., Filename 54 chars/filesize 2GB/partition 2GB.
The scsi.device (or whatever name the harddrive interface driver has on your expanded system), has limitations of its own, and those will be imposed first, before, the ones the filesystem of your choice has.
There are many other Amiga filesystems. This does not pretend to be a complete list. Most of the missing ones, are not worth mentioning since they are not common, too old, or buggy for the average user.
-
This documentation is full of inacuracies, incomplete, and prone to explode :D
So is prod-prep. Actually, in the meantime, I "cleaned it up a little bit", or I should better say "another layer of duct tape around the code". This piece of junk (sorry, really) is contains hard-coded code for some of the early "xt.device" adapters CBM delivered, inluding a hard-coded "17 sectors per track" computation for identifying what the first track should be, and how to "format" a harddisk (which, actually, only overwrites the first "track", sorry, 17 sectors - or some other crazy number I forgot). It neither has any provision to handle disks with anything but 512 bytes per sector, and its "defect management" rather assumes that the exec device loads the defect sector list manually into the device, from the RDB of course, and checks manually for defect sectors, and manually replaces them. In the code of the device.
Well, nowadays that doesn't work like this anymore - the harddisks do defect managment themselves - but the code still builds a defect list. Of course, it must be short enough to fit into 256 (yes, really) bytes, or the code explodes.
I *hope* I cleaned up at least the worst parts of this code, and I hope it continues "working", for whatever this means for this program.
-
How bad does it have to be, before you throw your hands in the air and decide to rewrite from scratch? :)
-
How bad does it have to be, before you throw your hands in the air and decide to rewrite from scratch? :)
I sort of dragged Thomas into this mess, having taken on the task of fixing the last two big issues with the 2016 AmigaOS 3.1 Workbench disk set release: the hard disk partitioning software. Thomas then thoroughly reworked my rewrite, and the prodprep command is part of the package. HDToolBox had its problems (still has some, owing to how the user interface was integrated with the nuts & bolts partitioning code), but prodprep's problems had their own problems, and then some. Both HDToolBox and prodprep are based upon common code which diverged over the years and each developed different issues of their own (e.g. prodprep leaked memory like you wouldn't want to know, HDToolBox got this much better under control).
Rewriting prodprep from scratch is something that is bound to be on the agenda some day. The state of the hard disk partitioning software that ships on Workbench is such that rewrites and fixes can only yield ever diminishing returns. The nuts & bolts partitioning code just about squeaks by in getting its job done. It fails to implement the full RDB spec, it does not validate existing data structures, etc. This bit has to be redone. Once it has been redone, a saner prodprep and HDToolBox pair could be built on top of it.
-
It seems that the entire HDD management code is hanging on some nasty code leftovers and bizarre workarounds, waiting to fall apart any day.
Not a comfortable way to code, I grant you that, and applaud you both for your bravery.
-
Validation: The mother of all evils
One of the major setbacks AmigaOS 3.1.x users will face, is that along with the benefits of large drives and newer FFS support, big volumes will definately become very common. This means that if you had to wait for quite some time before to get your volumes validated, on lets say a 500MB partition, just imagine how long will it take with a 20GB partition (and I am being really modest here).
So if in 2018 you buy, lets say for the purpose of this exercise, a new 2TB harddrive and install FFS (DOS7) on it, if a FS error occurs you will have to wait till your grandchildren finish college with your Amiga 1200 turned on all that time, to get the volume validated.
I know, clever users will still partition drives in a more reasonable manner, so that volumes dont get that large, but then is that a real solution?
And please dont tell me this is no problem, as this has been happening for decades, despite all AmigaOS developers not visualizing it as an issue. A simple fact, that illustrates the severity of the matter: many, if not all of the best third party filesystems for Amiga were originally developed to avoid the validation paradigm (PFS, SFS, etc), and they were quite succesfull, so much that many are still used and updated till this day, and are despite of some unresolved issues, still chosen over FFS which comes already installed by default.
Whilst keeping the status quo, and ignoring the issue, is the cheapest way, it will bring up lots of issues, especially with inexperienced users. Some flexibility could be certainly adopted regarding FFS. My proposed solution is a cli command to tweak FFS behaviour:
C:Validate
Changes how the filesystem manages write errors.
OPTIONS
oneatatime -Validates/fixes volumes one at a time.
novalidate -Ignores any FS errors and doesnt validate/fix them.
prevent -Attempts to trap the reset signal so that FS write corruption may be prevented.
warn -Detects FS errors and gives a warning but doesnt perform any repair/validation action at all.
fix -This is the default FS behaviour: If FS error occurs, all volumes are mounted read only and validate/repair starts on all of them.
waitfix -If FS error occurs all volume activity is halted until validate/repair is finished. Then volume activity resumes as usual.
ask -If error in the FS occurs, the user is asked to either validate/repair, ignore or mount readonly.
some options can be combined:
the "prevent" option can be combined with any other one.
"oneatatime" can be combined with "waitfix", "ask" and obviously as mentioned before, with "prevent".
-
Validation: The mother of all evils
Is it? Actually, my Linux box validates regularly, in timely intervals. From time to time, it finds some mischief and fixes it. So the validation itself is not the problem. Slow I/O of Amiga hardware is a problem.
So if in 2018 you buy, lets say for the purpose of this exercise, a new 2TB harddrive and install FFS (DOS7) on it, if a FS error occurs you will have to wait till your grandchildren finish college with your Amiga 1200 turned on all that time, to get the volume validated.
It is not *quite* that bad, but it takes time. I haven't tried with 2TB (I guess probably all of Aminet will then fit ;-), but I did try with a 64GB flash disk, and this took about five minutes. Not nice, but still workable.
What I suggest is to make blocks larger. 4K is a good round number. It also makes disk IO a bit speedier, by that the bitmap smaller, and by that keeps validation time at a minimum. A large minimum, admittedly, but still smaller than with 512 byte blocks.
Changes how the filesystem manages write errors.
Not really a good option. If the bitmap is inconsistent, then hell can break loose as an attempt to write data to the disk might overwrite other data - or even worse - administration information.
A particular solution would be a journaling option in the file system, i.e. a file system that logs transactions and can re-play them in case the system reboots unexpectedly. Olaf planned for this for quite a while, but frankly - with the given assembly code I'm messing around with right now - this is not a serious option. This is something you may want to play with with Olaf's C implementation of the FFS because that is then handlable. Of course, it will also be a tad slower, and then all the "cycle counters" in Amiga land will complain....
So I guess you cannot have everything. Or at least not immediately.
-
It seems that the entire HDD management code is hanging on some nasty code leftovers and bizarre workarounds, waiting to fall apart any day.
If you really want to start worrying, consider how the respective scsi.device RDB handling might slip up. In the small set of tests I made so far I found that disk drivers as a rule do not handle storage devices well which use sector sizes larger than 512 bytes.
The RDB specs call for sector sizes larger than 512 bytes to be supported, but the code I have seen may fail to find the RDB header block because it may not check for larger sector sizes.
-
Validation: The mother of all evils
Only for file systems designed in around 1978, upgraded in 1987, which suffer from "scalability" limitations ;)
One of the major setbacks AmigaOS 3.1.x users will face, is that along with the benefits of large drives and newer FFS support, big volumes will definately become very common. This means that if you had to wait for quite some time before to get your volumes validated, on lets say a 500MB partition, just imagine how long will it take with a 20GB partition (and I am being really modest here).
The FFS is not well equipped to handle volumes that large.
For example, the file system startup itself will take a very long time, because once a volume is mounted, the OFS/FFS/DCFS mode requires that all the currently allocated blocks on the disk are counted. The file system literally keeps counting bits.
File sizes beyond 2,147,483,647 bytes are not entirely safe to use although in theory they might just work if you only read such files sequentially. More trouble begins if you write more than 4,294,967,295 bytes to a file. This might actually work, but the byte counters in the file header block will roll over which breaks the relationship between the reported file size, the number of blocks used as reported, the number of blocks actually used by the file. Disk repair utilities might just truncate such files during the repair operations.
Finally, the file system cannot manage volumes larger than 4,294,967,295 blocks, and it might not even know that it can't handle more than that.
The validation process itself is "just" one problem here, and by comparison, it only gives you trouble rarely, whereas the limitations of the daily file system operations are giving you trouble on a much more permanent basis :(
I know, clever users will still partition drives in a more reasonable manner, so that volumes dont get that large, but then is that a real solution?
Given the constraints (creaky design which did not evolve and improve over time, practically impossible to fix), this is what users tend to do. They cope by limiting what they can do with the file system and the media the file system uses. This started way back when Amiga hard disk drives became much larger than the comparatively "safe" 4 Gigabytes. If memory servers, that was in 1996.
And please dont tell me this is no problem, as this has been happening for decades, despite all AmigaOS developers not visualizing it as an issue.
Of course it's a problem, it's just quite difficult to fix. Actually, I have a cunning plan how to add journaling with write-ahead logging to the FFS in a backwards-compatible manner which will resolve the validation issue (well, up to a point). This is a long-term project, though. At the moment I'm working on something else that deals with file system defect repairs and data recovery.
My proposed solution is a cli command to tweak FFS behaviour:
C:Validate
Changes how the filesystem manages write errors.
OPTIONS
oneatatime -Validates/fixes volumes one at a time.
novalidate -Ignores any FS errors and doesnt validate/fix them.
prevent -Attempts to trap the reset signal so that FS write corruption may be prevented.
warn -Detects FS errors and gives a warning but doesnt perform any repair/validation action at all.
fix -This is the default FS behaviour: If FS error occurs, all volumes are mounted read only and validate/repair starts on all of them.
waitfix -If FS error occurs all volume activity is halted until validate/repair is finished. Then volume activity resumes as usual.
ask -If error in the FS occurs, the user is asked to either validate/repair, ignore or mount readonly.
some options can be combined:
the "prevent" option can be combined with any other one.
"oneatatime" can be combined with "waitfix", "ask" and obviously as mentioned before, with "prevent".
I'd say that this would be doable from a technical point of view. Not so much from the point of view of available manpower to make it happen right now, as far as I can tell :(
-
Does your cunning plan involve radishes?
-
waitfix -If FS error occurs all volume activity is halted until validate/repair is finished. Then volume activity resumes as usual.
Largely this is what SETPATCH WAITFORVALIDATE does.
I'm not sure when that was added, it definitely exists in OS4. If a new SetPatch is planned for the 3.1 update then this option might end up in it.
-
Largely this is what SETPATCH WAITFORVALIDATE does.
I'm not sure when that was added, it definitely exists in OS4. If a new SetPatch is planned for the 3.1 update then this option might end up in it.
It was added in 3.9, mostly because I poked Heinz about it. However, there it is only considered before the system is rebootet. It does not make sense to run into a restart while the FFS is still working on the harddisk. It originally came from MuMove4K and some other tools of mine that reboot the system as part of their function.
No, there is no need for this option in 3.1.4 anymore. SetPatch does not load any modules there.
-
Does your cunning plan involve radishes?
Definitely not ;)
The difficult part is making the journal operations work within the framework of the Amiga file system and stay backwards compatible.
There is a precedent for this kind of thing in NetBSD, for example, in the form of the WAPBL feature (WAPBL stands for 'write-ahead physical block logging'). WAPBL can keep a log for a file system separate from the file system's blocks or it can keep it on the file system itself.
The type of journaling I have in mind would be limited to metadata blocks, and it would log complete blocks rather than "compress" the individual metadata changes (e.g. change a file name, change the file size, etc.) and store them. I read a paper by the principal developer of the ext3 file system (Theodore Ts'o) in which made the convincing point that logging complete blocks can be safer than logging "compressed" metadata changes. After all, if the block which individual metadata changes are applied to already has defects, the changes will probably make things worse. Logging complete metadata blocks has been shown to do better in this respect.
Anyway, this kind of journaling could be added to my 'C' language FFS reimplementation with very little changes required. However, making the journal operations fast is tricky, and I also still have to figure out how large the journal should be. This could be an interesting project for 2018 :)
(Incidentally, did anybody actually like series 1 of Blackadder, or is it just that it pales so much in comparison to the series which followed it?)
-
(Incidentally, did anybody actually like series 1 of Blackadder, or is it just that it pales so much in comparison to the series which followed it?)
The later series were just repetitive nonsense, sure very good repetitive nonsense but still just repetitive nonsense ;)
1st series had some sort of "sensible" storyline.
-
Considering the large number of Amiga FFS implementations, one would think it's a well understood filesystem.
-
Considering the large number of Amiga FFS implementations, one would think it's a well understood filesystem.
We have an awful lot of file systems for such a small market. ;)
-
We have an awful lot of file systems for such a small market. ;)
Yeah, it's ridiculous.
-
Anyway, this kind of journaling could be added to my 'C' language FFS reimplementation with very little changes required. However, making the journal operations fast is tricky, and I also still have to figure out how large the journal should be. This could be an interesting project for 2018 :)
(Incidentally, did anybody actually like series 1 of Blackadder, or is it just that it pales so much in comparison to the series which followed it?)
Sun implemented journaling in UFS in Solaris 7. I am curious how it did so but I have never spent the time to dig up the information.
I liked it, but I think I enjoyed the first season more for Brian Blessed.
-
Considering the large number of Amiga FFS implementations, one would think it's a well understood filesystem.
Yes and no. The structure of the file system is well understood and documented. This does not mean that the implementation is well understood - or at least, the assembly implementation is not. It's 20 year old legacy assembly code.
There are also a couple of implications of the file system and the interface towards the dos.library that raises quite a couple of "architectural questions", to put it this way. ACTION_EXNEXT is probably one of the hardest to implement requests of the filing system, and it interacts deeply with the rest of the file system if done correctly.
In particular the assembly version is completely multi-threaded, which means that an ACTION_EXNEXT can overlap with file removal, creation and renaming. If journaling has to be itnerleaved in all this game again, the equation does not become simpler.
The C version is not as highly multithreaded as the assembly version, and for this reason easier to maintain. It might also imply - but I haven't tested - that it does not perform quite as well in situations where you have multiple processes accessing the disk simultaneously.
-
Considering the large number of Amiga FFS implementations, one would think it's a well understood filesystem.
How the file system data structures look like and work together is reasonably well-understood. One might still wish for some of the unexplainable mysteries to be resolved (e.g. why are the data block references in a file header processed in reverse order, why does the root block indicate the size of the hash table when this property follows directly from the size of the block), but you generally get a pretty good idea of how the parts hang together.
Still, that isn't the whole story. The implementation language and its operating system set a few rules which you are supposed to know, except nobody really wanted to explain them to you in the early days of the Amiga. Things didn't get much better, documentation-wise, in the decade that followed, save for Ralph Babel's "Amiga-Guru book" which succeeded in explaining everything that could be explained. The file system design assumes that the basic building block for all data structures, the 32 bit word, is a signed quantity, but both design and implementation tend to ignore this. Put another way: the design is generally unaware of its limitations, and so is the implementation. This is why you should be worried if you are about to deal with files larger than 2,147,483,647 bytes. You cannot necessarily predict what's going to happen. Same thing with the volume size, for which strange things might just happen if more than 2,147,483,647 blocks are used.
It does not at all look sunny if this file system has to run on the Amiga operating system, because it has to interface with the dos.library and application software which uses the dos.library API and/or the packet interface. What is often overlooked is just how complex the file system implementation has to be, because it has schedule the packet I/O and treat each client fairly. Since dos.library doesn't do file systems any favours, what you end up with in the FFS, or rather the default ROM file system, is almost a self-contained multitasking operating system of its own.
The original BCPL version did lean on the BCPL runtime library so as to provide for coroutine threading (think Python generators: this is the closest thing I can think of in terms of how they work). The assembly language versions which followed had to implement their own version thereof, and as the file system functionality became more complex, it became harder and harder to guarantee that certain operations actually worked out correctly.
For example, writing to a file can trigger a series of operations which all have to complete in a specific order and need to be reversible in case of trouble: the file may have to be extended, for which new storage space will have to be allocated, the storage space needs to be linked up with the bookkeeping data structures which also may have to be reallocated, and then everything has to be recorded in the file header, and eventually the client will need to be notified that the write operation succeeded. Unless something goes wrong, of course, in which case the whole cascade will have to be rolled back. And don't forget that during the rollback errors might occur.
All of this uses strange data structures which don't always suffice for carrying around all the information that is needed. Weird workarounds exist, such as for stuffing everything that doesn't fit into a file handle or the "file info block" into the humble file lock, which then has interesting repercussions all over the place. It's not just that file locks become "relay batons" for multi-stage operations, the file system has to watch out for race conditions (oh, the irony), too.
This threading model is one reason why the file system is so brittle, and desaster might follow if the "relay" is aborted (crash, disk ejected, etc.). The file system design generally does not care in which order the operations that modify its data structure are completed, but the implementation should. The FFS version 40 tries its best to modify the disk data structures in an order which minimizes the irreversible damage should one modification go awry. But this only goes so far: the Amiga file system has a write cache which tends to aggravate any problem that may occur in this domain.
I've seen the belly of the beast from the inside when I reimplemented the FFS in 'C'. This was, in retrospect, the toughest software project I have ever undertaken. It certainly is the most complex piece of software I have written so far.
That's what you get from seemingly simple designs...
-
Sun implemented journaling in UFS in Solaris 7. I am curious how it did so but I have never spent the time to dig up the information.
If I remember correctly, the NetBSD WAPBL feature did not require the file system to cooperate much. You could implement it as an abstraction layer on top of the low level block access. It probably did call for a more optimized, higher performance journaling implementation.
I liked it, but I think I enjoyed the first season more for Brian Blessed.
Now that you mention it... It's hard to think of Brian Blessed not making the kind of contribution which elevates the end result far beyond what it might otherwise have deserved.
-
Right, and NetBSD also implements "ADOS" filesystem, Linux has affs, AROS and MorphOS also have their implementations. One would think some sort of cooperation would be beneficial.
-
So, my concern with an update to OS3.1 is compatibility. Would software and hardware still function properly like the old video toaster?
-
So, my concern with an update to OS3.1 is compatibility. Would software and hardware still function properly like the old video toaster?
That is, of course, the plan. There is nothing like "new fancy toys" in the making that would potentially break compatibility.
-
@Thomas Richter
@olsen
A journaling filesystem woulld certainly improve reliability.
But why not better kill more birds with one stone?
A versioning filesystem would be a much better overall solution, because not only it would allow the user to roll back to previous versions of files in case of system corruption, but it also means that if the filesystem does the work twice (comitting to disk), you at least do the job completely and not halfway like in a journaled filesystem, and also keep the benefit of having an older backup automatically.
The drawback, is of course, increased disk space usage, but is that really a problem in an Amiga system where files are really small in size and when storage media keeps getting bigger each day? And of course, you can also provide some algorithm for garbage collection when the amount of backup exceeds certain amount to free some space.
As a huge side benefit, a versioning filesystem will also be an excellent filesystem candidate for flash/ssd solutions. We dont have any filesystem or tools to deal with wear levelling on Amigaland. A versioning filesystem does not need to overwrite the same blocks of data (unlike a journaled one). And you can make each block/cluster keep a write counter to estimate the media life and take action when reaching a critical life cycle limit.
Another benefit, is that due to the nature of the versioning filesystem, it may be used, with little customization as a developer aid.
-
Now about adding snapshots? Running ufsdump against fssnap is a dream :)
-
That is, of course, the plan. There is nothing like "new fancy toys" in the making that would potentially break compatibility.
Russian proverb, "New is first enemy of old". :lol:
-
I would rather see work progress on AmigaOS4.2 and finished AmigaOS4.1 for looooooooooooooooooooooong awaited A1222.
How long it takes to make a network driver? 3 years?
-
I would rather see work progress on AmigaOS4.2 and finished AmigaOS4.1 for looooooooooooooooooooooong awaited A1222.
Hyperion are all about OS3 now, they don't care much about OS4 anymore :)
-
Hyperion are all about OS3 now, they don't care much about OS4 anymore :)
They obviously didn't care about OS4 either based on it's current state after 15 years of nothing but band-aid patches to allow it to run on ever increasingly rare and expensive PPC CPUs.
Hyperion's only concern is how to squeeze more cash out of Amiga users....classic and NG.
-
Hyperion are all about OS3 now, they don't care much about OS4 anymore :)
I kind of doubt this, actually. Frankly, I have no insight into the company policy or what the plans with 4.x are.
-
This is the best thread I've seen in ages. Please keep posting more about Amiga OS development.
-
Frankly, I have no insight into the company policy or what the plans with 4.x are.
Neither do anyone else, apparently.
And from that one can conclude that not much is really going on.
-
In my view, and this is both for OS3 and OS4, it would be better to decouple the various OS elements and let individual developers work on their components individually, without too much coordinated "upper management". Components should be individually replaceable anyways.
-
Hey guys, a question on IDE device. There is a discussion on the Apollo IRC/forums on the poor IDE performance with modern flash drives. Any thoughts on this? Maybe an updated IDE device?
I have patched in the basics of the discussion below. Thanks and have a great day!
---------------------------------------------------------------------------------------------------
The problem with AMIGA OS IDE is the following:
The old AMIGA OS SCSI /IDE device does "split" any access into 512 byte transfers.
So if the file system says PLEASE LOAD 64 KB then the SCSI DEVICE will devide this into 128 individual LOAD commands each doing 512 Byte. This works but it lower the possible performance more a problem is WRITING as instead doing 1 write of 64 KB the existing SCSI device will split this into 128 writes each being 512 byte.
Modern flash devices do not support 512 byte block internally. They have internally bigger block - e.g. 4 KB.
To support 512 byte writes the flash device will internally read the 4 KB block / erase it / alter the 512 Byte into it / and the write it back to the flash device.
This means this splitting into miriads of 512 byte writes - is really bad for todays CF/SDD/ SDcard flash drives. This is all known.
This problem is known and was also reported to Hyperion 2 years ago.
-
Hey guys, a question on IDE device. There is a discussion on the Apollo IRC/forums on the poor IDE performance with modern flash drives. Any thoughts on this? Maybe an updated IDE device?
What we currently have is a slightly reworked version of the scsi.device which supports natively LBA48 bit transfers, TD64, does not have the MaxTransfer bug and does not return nonsense-results if requesting a non-zero LUN, it also lacks a "division by zero" crash for some devices. Plus probably a couple of other fixes I forgot.
However, there is currently no man-power to rework the low-level part of the block transfer. The only difference between eight 512 byte transfers in row and a 4096 block transfer is in the low-level signalling of the IDE transfer, so the benefit of larger block transfers is not clear at all. The scsi device, if transfering 8 blocks in a row, already uses a block-transfer command for IDE - but this already holds for the V40 version out in the wild.
If you want to avoid the additional wear of flash devices, I would recommend to use the FFS with 8 BlocksPerSector, which is - up to some low-level IDE transfer details - identical to the 4096 byte transfer.
-
@Thomas Richter
@olsen
A journaling filesystem woulld certainly improve reliability.
But why not better kill more birds with one stone?
A versioning filesystem would be a much better overall solution, because not only it would allow the user to roll back to previous versions of files in case of system corruption, but it also means that if the filesystem does the work twice (comitting to disk), you at least do the job completely and not halfway like in a journaled filesystem, and also keep the benefit of having an older backup automatically.
The drawback, is of course, increased disk space usage, but is that really a problem in an Amiga system where files are really small in size and when storage media keeps getting bigger each day? And of course, you can also provide some algorithm for garbage collection when the amount of backup exceeds certain amount to free some space.
I don't quite see this yet. There is not a lot of wiggling room within the constraints the FFS on-disk data structures impose upon you. With a log of changes growing as write operations take place, you will have to deal more and more with managing disk space. This is where this file system design is really weak. There are no data structures to assist making optimal storage allocations under certain constraints (e.g. allocate closest to the tail end of the file, allocate closest to the file header block, pick the largest consecutive chunk of free space, etc.). As far as the FFS is concerned, the storage space is broken down into two big sets of almost identical size with no block preferable to the other.
If I remember correctly how log-structured file systems work, I can see how they are more attractive for use with SSDs. You rarely rewrite anything, if at all. The downside is that you have to deal with accessing the versions (through the existing file system API? we can't conveniently upgrade dos.library), representing the available storage space (minus the versioned data which could be reclaimed) and with scrubbing the log. You have to have all three, and each of these is quite challenging to implement.
By comparison, journaling with write-ahead logging would be much simpler to implement. It could be integrated into the metadata block access operations and the remainder of the file system, its APIs and data structures would remain unchanged.
I'd rather prefer to tinker with something that I understand up to a point, and which is extensible, than having to invent a big bag of new stuff, all of which would need a lot more testing just to make sure that it works as intended, including how it deals with defects.
-
I think it's funny that Gunnar complains about old scsi.device, shouldn't he be more concerned with getting the SD card device driver of the Vampire cards working properly? Anyways, nothing stops his team of brilliant engineers from doing their own version of scsi.device for the Vampire cards.
-
@olsen
It is true, a journaled filesystem is much more straightforward in its design and much easier to implement, besides, it doesnt require a change in the API. Whilst a log or versioning filesystem would be great, I understand the amount of challenge it would represent in an Amiga enviroment is well into the realm of uncharted territory.
Sometimes it is better to just do what you know best. :)
-
I think it's funny that Gunnar complains about old scsi.device, shouldn't he be more concerned with getting the SD card device driver of the Vampire cards working properly? Anyways, nothing stops his team of brilliant engineers from doing their own version of scsi.device for the Vampire cards.
I think it's funny you compulsively slam anything the Apollo team does on every Amiga forum you belong to.
And as far as I know the sagasd device driver is working properly.
-
@TrashyyMG
And the request was a generic one. This affects all users with solid-state drives.
-
@Thomas Richter
I understand about man-power.
Please consider this for future enhancements as it does affect all users with solid-state drives (excessive wear, low performance).
Thanks
-
And as far as I know the sagasd device driver is working properly.
Except that it's slow, unreliable and you cannot boot from it. Yes, I suppose that passes as "properly" :)
Glad you find entertainment value in my Apollo Core slamming.
-
And as far as I know the sagasd device driver is working properly.
Unfortunately it's not working properly and is in dire need of fixing. The issue is that it causes some Micro SD card brands to throw a lot of CRC errors and the only solution is to slow transfer speed. I bought a Kingston 32MB and Patriot 32MB Micro SD card, nothing wrong with them, and yet both of them throw a ton of CRC errors. Can't use them until it's fixed.
-
The only difference between eight 512 byte transfers in row and a 4096 block transfer is in the low-level signalling of the IDE transfer, so the benefit of larger block transfers is not clear at all. The scsi device, if transfering 8 blocks in a row, already uses a block-transfer command for IDE - but this already holds for the V40 version out in the wild.
In theory some drives can only do 4k transfers. In practice most of them offer 512 byte sector emulation & you might not find a PATA drive that only does 4k.
However even with 512 byte sector emulation you have a potential performance problem, especially if you are doing a lot of unaligned writes. Writing 512 bytes into a 4k sector requires a read modify write. However this might not be that bad when you consider how long it will take an amiga to transfer those extra bytes.
-
However even with 512 byte sector emulation you have a potential performance problem, especially if you are doing a lot of unaligned writes. Writing 512 bytes into a 4k sector requires a read modify write. However this might not be that bad when you consider how long it will take an amiga to transfer those extra bytes.
This problem is avoidable if you align partition boundaries correctly. Arguably, this is harder than necessary with the current HDToolBox.
-
This problem is avoidable if you align partition boundaries correctly.
Alignment helps, you also need to make sure you always write in multiples of 4k. Even when appending data to the end of a file.
-
Hey guys -
Any news on this OS3.1 update?
Thanks
-
Yes, it would nice to know how is it going.
-
Any news on this OS3.1 update?
What do you want to hear? It's down to the "tedious bug finding - bug fixing" part. Yes, that's the boring stuff.
The latest thing I have done is having spend around 12 hours of not finding a non-existing bug in icon/workbench that, in the end, turned out to be a bug in MungWall. The story itself is funny (well, not so much after having missed 7h of sleep, but...), so here we go.
One of our fellow betatesters reported MungWall hits from icon. I could not reproduce. He went that far of supplying a winUAE snapshot which allows to reproce them (yuck. I like the real stuff. Yuck, Windows! Eeek.). Anyhow, hits show up. It looked like icon was damaging the rear mungwall of memory allocations. After 4h of debugging, it looked like icon was writing into non-allocated memory. Strangely, the bug went away also after downgrading layers to v40. A bug in V45 layers? Really?
Debugging went on... I could see the allocations. Of course, every time you boot allocations are a bit different, so it is *really really hard* to reproduce the problem such that you could set a breakpoint at a specific place. After another 7h of debugging, it turned out that the memory was allocated ok, there was no corruption due to task switching or inter-task dependency, and all the hits were "bogus". After another hour of debugging I finally found the culprit, and the reason.
MungWall! Layers V37!
Now, here is the story. The CBM developers of layers had the "great" idea to allocate the cliprects of layers in one continuous memory chunk ("AllocMem(sizeof(struct ClipRect) * 5,...);)" and then split this chunk into pieces, and release them individually. Which is a bit against the protocol of exec/AllocMem, and which is a really stupid thing to do as it really throws another fragmentation bomb on the system. But anyhow... MungWall would scream about this b*llsh*t, and for that reason, MungWall includes a workaround by not munging memory if the allocation comes from layers, just to be tolerant. Which is all nice, except that V45 doesn't have this problem. Actually, even layers V40 doesn't have it. So the workaround is not even actually needed in first place.
But how could this impact icon? I'm not debugging layers here, right? Due to a matter of bad luck and just coincidence, MungWall now believed that the icon.library allocation code comes from layers, though classified the icon.library (actually exec) memory release call as regular. This is because icon as well as layers are "loadmodule'd" and for that reason, the resident list, which is checked by MungWall, is a bit "unusal", so the mungwall heuristics of detecting "this PC belongs to layers" failed.
Now, what happend now is that MungWall did not create a mungwall upon allocation (as, this was supposed to be layers) but checked the mungwall upon the memory release (as it looked harmless). Result? No Mungwall on memory release, as none was created in first place -> Big bad warning!
Morale of the story: Choose debugging tools wisely, and select tools that are still maintained. MuGA is aware of the layers problem, and includes a workaround, which is of course disabled for later releases of layers. Wipeout is also still maintained, and doesn't have the problem. The problem wouldn't have popped up if it would have been one of the two.
Old legacy debugging tools with bugs suck big time. 8h to be precise.
-
Thanks for sharing the process Thomas.
Its something people should have in mind when they nag about the pace of development, whatever it might be.
I dont think people appriciate this timethief when they make comments about dev-team set deadlines that comes and goes.
-
What do you want to hear? It's down to the "tedious bug finding - bug fixing" part. Yes, that's the boring stuff.
Thanks for the good explanation on the latest bug fix. We have all been there before. Makes you want to take up raising Llamas or something.
But seriously, each of those old nasty bugs that is found and exterminated is a great thing - one less source of instability and pain for all developers going forward.
If you have a beer fund or something I would happily kick in.
Cheers!
Greg
-
On a related note, I would like to add.....
Stefan "bebbo" Franke continues to work on his 68K gcc6 port. He appears to be getting close to a working compiler. At the moment he is working on debugging his code optimizer.
There are a couple of developers filing some good bug reports and helping to iron out the last few issues.
I think now is a good time for some donations to keep Stefan motivated. He has mentioned he would like to get a working debugger as well (gdb) which would be very good.
Come on folks, pull out some spare change. A good base gcc compiler is important for many reasons. Let's give him some more motivation to keep going. I have done my part for now.
His PayPal donation link is part way down this page: https://github.com/bebbo/amigaos-cross-toolchain
Let's keep the party going! :)
-
On a related note, I would like to add.....
Stefan "bebbo" Franke continues to work on his 68K gcc6 port. He appears to be getting close to a working compiler. At the moment he is working on debugging his code optimizer.
There are a couple of developers filing some good bug reports and helping to iron out the last few issues.
I think now is a good time for some donations to keep Stefan motivated. He has mentioned he would like to get a working debugger as well (gdb) which would be very good.
Come on folks, pull out some spare change. A good base gcc compiler is important for many reasons. Let's give him some more motivation to keep going. I have done my part for now.
His PayPal donation link is part way down this page: https://github.com/bebbo/amigaos-cross-toolchain
Let's keep the party going! :)
I for one would really, really like to see a decent source-level debugger become available. While we can make do with SAS/C and the CodeProbe debugger, if it's going to be GCC, there has to be a debugger to go along with it.
-
BTW, while we are at it. The big "thank you" note goes to Olaf for contributing an updated disk-doctor which has just been released to our beta testers. Yes, the one that speaks long file names that will come with 3.1.4.
I still need to see on which disk we can possibly fit it since it gained some weight - while it also gained a lot of knowledge. It is hard to believe, but the old "barely translated from BCPL" disk doctor didn't even know a lot about subdirectories...
But maybe I should leave it to Olaf to tell this story.
-
BTW, while we are at it. The big "thank you" note goes to Olaf for contributing an updated disk-doctor which has just been released to our beta testers. Yes, the one that speaks long file names that will come with 3.1.4.
I still need to see on which disk we can possibly fit it since it gained some weight - while it also gained a lot of knowledge. It is hard to believe, but the old "barely translated from BCPL" disk doctor didn't even know a lot about subdirectories...
But maybe I should leave it to Olaf to tell this story.
FANTASTIC! Indeed, thank you, Olaf. You know we all want to hear about it.
-
What do you want to hear? It's down to the "tedious bug finding - bug fixing" part. Yes, that's the boring stuff.
The latest thing I have done is having spend around 12 hours of not finding a non-existing bug in icon/workbench that, in the end, turned out to be a bug in MungWall. The story itself is funny (well, not so much after having missed 7h of sleep, but...), so here we go.
One of our fellow betatesters reported MungWall hits from icon. I could not reproduce. He went that far of supplying a winUAE snapshot which allows to reproce them (yuck. I like the real stuff. Yuck, Windows! Eeek.). Anyhow, hits show up. It looked like icon was damaging the rear mungwall of memory allocations. After 4h of debugging, it looked like icon was writing into non-allocated memory. Strangely, the bug went away also after downgrading layers to v40. A bug in V45 layers? Really?
Debugging went on... I could see the allocations. Of course, every time you boot allocations are a bit different, so it is *really really hard* to reproduce the problem such that you could set a breakpoint at a specific place. After another 7h of debugging, it turned out that the memory was allocated ok, there was no corruption due to task switching or inter-task dependency, and all the hits were "bogus". After another hour of debugging I finally found the culprit, and the reason.
MungWall! Layers V37!
Now, here is the story. The CBM developers of layers had the "great" idea to allocate the cliprects of layers in one continuous memory chunk ("AllocMem(sizeof(struct ClipRect) * 5,...);)" and then split this chunk into pieces, and release them individually. Which is a bit against the protocol of exec/AllocMem, and which is a really stupid thing to do as it really throws another fragmentation bomb on the system. But anyhow... MungWall would scream about this b*llsh*t, and for that reason, MungWall includes a workaround by not munging memory if the allocation comes from layers, just to be tolerant. Which is all nice, except that V45 doesn't have this problem. Actually, even layers V40 doesn't have it. So the workaround is not even actually needed in first place.
But how could this impact icon? I'm not debugging layers here, right? Due to a matter of bad luck and just coincidence, MungWall now believed that the icon.library allocation code comes from layers, though classified the icon.library (actually exec) memory release call as regular. This is because icon as well as layers are "loadmodule'd" and for that reason, the resident list, which is checked by MungWall, is a bit "unusal", so the mungwall heuristics of detecting "this PC belongs to layers" failed.
Now, what happend now is that MungWall did not create a mungwall upon allocation (as, this was supposed to be layers) but checked the mungwall upon the memory release (as it looked harmless). Result? No Mungwall on memory release, as none was created in first place -> Big bad warning!
Morale of the story: Choose debugging tools wisely, and select tools that are still maintained. MuGA is aware of the layers problem, and includes a workaround, which is of course disabled for later releases of layers. Wipeout is also still maintained, and doesn't have the problem. The problem wouldn't have popped up if it would have been one of the two.
Old legacy debugging tools with bugs suck big time. 8h to be precise.
Now this is the stuff I like to read about!
You protest but you know you loved every minute Thomas. ;)
-
FANTASTIC! Indeed, thank you, Olaf. You know we all want to hear about it.
Bit of a dry subject, I suppose... Well, somebody asked for it ;)
The new Disk Doctor is the result of some hairy research into how the original version worked and why it failed. Commodore stopped shipping it with Workbench 2.1, and since then no file system repair or data recovery tool has been included with subsequent Workbench versions for Amigas with 68000 family CPUs.
The new Disk Doctor should solve a couple of hairy problems. Volumes can be much larger than they used to be in the 1980'ies and 1990'ies. Not only do you have to deal with storage media much larger than 4 Gigabytes, the number of files, directories and the associated management data structures have to be analyzed and their contents need to be kept in memory. Memory constraints are the biggest problem here, actually. The original Disk Doctor needed about 1.5% the size of the volume as working memory (RAM). For example, in order to "repair" a 20 Megabyte hard disk partition, you would have to have at least 330 Kilobytes of free RAM available. This would not fly on the original Amiga 500/1000/2000. Now imagine how the math would work out for a 1 Gigabyte hard disk partition. For the new Disk Doctor I developed a special type of data structure which lowers the memory requirements to around 0.1% of the volume size. Which means that about 1 Megabyte may be sufficient to deal with a 1 Gigabyte partition, and 8 Megabytes for an 8 Gigabyte partition. At least, this is what testing revealed so far.
Unlike the original Disk Doctor, the new version does not currently modify the contents of the volume. It only does two things: 1) examine the contents of the volume, looking for defects and 2) copy the contents of the directory tree to a different volume. It does what Dave Haynie's DiskSalv program did 32 years ago, but of course it does a lot more than that ;)
The "examination" begins by looking into every single block of the volume, taking note of the contents, the type of data found, damage to the contents. This is followed by another pass to figure out what files, directories, hard links and soft links exist and can be reached through the root directory (if there is one). Finally, this information is tied together so that one can tell which files, directories, etc. are still "sound" and undamaged, which ones are deleted, damaged or "orphaned", i.e. have no valid parent directories.
This information can be stored in a "disk and block information" (DABI) database file (actually, it's just a gzip-compressed plain text file) which might just become useful later. Instead of rerunning the examination (which takes quite a while to complete on a large volume), you can reuse the information gathered later.
You can use the new Disk Doctor just to check if a volume is in good shape, and not bother with the DABI files or the copying operation. But there's a lot more you can do. For example, you could use the DABI file to have Disk Doctor show you what it would have copied and then narrow down the set of files to copy through very simple filter restrictions (e.g. copy only "sound" files, copy only damaged files, copy only deleted files, copy only files matching a wildcard pattern). The copy process itself works very much like a "copy all clone #? .." command would, preserving all the properties (comment, user/group ID, modification time) of the original directory entries. When damaged files are copied, the damaged sections are skipped. The copy will retain the entire directory tree structure, if possible.
The new Disk Doctor takes a very thorough look at the state of the volume and its data structures. This includes, for example, making sure that all directories are consistent. It's possible for directory entries to show up when you list the directory contents, yet remain inaccessible when you try to open or delete them. The linkage information underlying hard links to directories and files is validated, too. Cycles in the many list data structures which the file system uses are detected. The root directory and its associated data structures (e.g. the bookkeeping information on what blocks are still available for use) are examined, too, which covers the bitmap extension block information. The extension blocks were added in 1987 with the introduction of the FFS. Their "Achilles heel" is the lack of a checksum which would make detection of corruption easier. The directory cache lists which give the directory cache (DCFS) file system variant its name are validated, too, and any differences found between a directory and the cache contents are recorded.
All this information is in part intended for a repair operation which is currently not implemented. A repair strategy would be needed first, and I have yet to come up with one. The more I learned about what can go wrong the more alternatives to dealing with the defects revealed themselves. You may be able to correct the smaller problems, such as restoring the consistency of directories, but if the root directory is damaged, how do you rebuild its bookkeeping information without destroying other data that might still be recoverable? So, after four months of work, this is still a research project, I'm afraid.
Finally, in case you wondered, the new Disk Doctor supports all Amiga file system variants which stem from the 1986 ROM file system and the 1987 Fast file system. This includes the international mode (introduced with Workbench 2.1), the directory cache mode (introduced with Kickstart 3.0) and the long name mode (introduced with AmigaOS 4). Hard links and soft links are supported (currently only soft links are restored by the copy operation, restoring the hard links still needs work). Volume block sizes of 512..65535 bytes per block are supported, too.
I can't promise you that using the new Disk Doctor will be an enjoyable experience (ha!), but it should be a whole lot less exciting than it used to be with the old Disk Doctor. If you need a tool to check if your volumes are sound and in good shape, and which will help you to recover data from them when you really need it, the new Disk Doctor should get the job done.
-
I suppose everyone knows the "amiga connection" of gdb? :)
-
Due to a matter of bad luck and just coincidence, MungWall now believed that the icon.library allocation code comes from layers, though classified the icon.library (actually exec) memory release call as regular. This is because icon as well as layers are "loadmodule'd" and for that reason, the resident list, which is checked by MungWall, is a bit "unusal", so the mungwall heuristics of detecting "this PC belongs to layers" failed.
So can you fix the resident list to make mungwall happy?
All this information is in part intended for a repair operation which is currently not implemented. A repair strategy would be needed first, and I have yet to come up with one. The more I learned about what can go wrong the more alternatives to dealing with the defects revealed themselves. You may be able to correct the smaller problems, such as restoring the consistency of directories, but if the root directory is damaged, how do you rebuild its bookkeeping information without destroying other data that might still be recoverable? So, after four months of work, this is still a research project, I'm afraid.
When I've done similar data recovery, I've ended up using a "what if" algorithm that tries multiple things when there are ambiguity & picks the most consistent one.
It's a load of planning and a load of code. You shouldn't aim for perfect recovery in all cases though because it's impossible. Getting consistency back means you don't have to choose between reformatting and losing more data when the corruption upsets the file system.
-
So can you fix the resident list to make mungwall happy?
There is nothing wrong with the resident list. There is quite a bit wrong with MungWall. Apparently, its heuristics to identify layers is broken, and its missing a version check on it, too, so just don't use it. There are two replacements available for it.
-
When I've done similar data recovery, I've ended up using a "what if" algorithm that tries multiple things when there are ambiguity & picks the most consistent one.
It's a load of planning and a load of code. You shouldn't aim for perfect recovery in all cases though because it's impossible. Getting consistency back means you don't have to choose between reformatting and losing more data when the corruption upsets the file system.
Thank you, this is good advice. I do tend to spend a lot of time researching a problem and eventually overengineering a solution (why not? I don't like to return to the same project over and over again to fix issues I could have caught at the research & design stage). The simplest solution that works might just be the ticket here.
Hard to believe, but it appears that the original Disk Doctor's purpose was to only get the file system into a state which allows its contents to be copied to a different medium, using the tools available at the time (the "Copy" command, for example). It did just enough to make the basic file system structures work again, even rebuilding the consistency of directories. Broken files, etc. remained broken, sometimes becoming even more smashed if you reran Disk Doctor again. It was all too tempting to view this process as a repair operation, but it was never even that. If you only had one single disk drive, though, you had to hope for the volume to be "repaired", because you could not easily copy its contents to a separate volume (i.e. switch disks for each single file copied).
From that perspective the new Disk Doctor can already deliver what the original command tried to make possible: copy/salvage data from a compromised, if not defective medium.
If the new Disk Doctor is to repair a volume, it should be able to deliver a consistently readable and writable file system. The simplest working approach to make this happen would be to remove all the damaged contents and to rebuild both the root directory and its bookkeeping data structures. I reckon that this is doable without overengineering the solution too much ;)
Because the new Disc Doctor already supports a "preview" feature, one could show which files and directories would be cut. The user could then decide which data to copy before letting the new Disc Doctor make changes which would then result in loss of data.
-
..I can't promise you that using the new Disk Doctor will be an enjoyable experience (ha!), but it should be a whole lot less exciting than it used to be with the old Disk Doctor. If you need a tool to check if your volumes are sound and in good shape, and which will help you to recover data from them when you really need it, the new Disk Doctor should get the job done.
thanks & yes much needed as the old DD unfortunately was like playing the lottery (at least for me)...thank goodness for DiskSalv more recently that saved quite a few hairy situations & reminded me yet again to backup, backup, backup:p
-
two months after the last repsonse here, is there any news ?
-
I would say this is cancelled.
The coder now has a full-time job trash-talking Apollo/Vampire stuff, so there's no time left to actually produce something himself I'm afraid :(
-
I would say this is cancelled.
The coder now has a full-time job trash-talking Apollo/Vampire stuff, so there's no time left to actually produce something himself I'm afraid :(
Well, then I am glad, because now the Apollo guys will be forced to implement a proper MMU tu run Linux. Or they could stil resell AmigaOS 3.9 and Fusion mac emulation.
-
I would say this is cancelled.
Nope. Where is all this nonsense coming from.
-
Nope. Where is all this nonsense coming from.
IRC Freenode, #apollo-team - ever been there? It's a crazy place, they make up truths as they go, revision history and badmouth everyone else. It's like a late night dive bar, except they're not even drunk.
-
IRC Freenode, #apollo-team - ever been there? It's a crazy place, they make up truths as they go, revision history and badmouth everyone else. It's like a late night dive bar, except they're not even drunk.
and for what purpose are you there?
-
and for what purpose are you there?
I am not, I left long ago.
-
two months after the last repsonse here, is there any news ?
So, what's new? Been busy the last weeks with a replacement of the CD file system (CDFS). One may wonder why this is actually needed, there are really sufficient replacements out there. The main reason (besides "it was fun to do") was "consistency". 3.1.4 comes with three file systems, and a couple of handlers. For file systems, we have FFS, CrossDos and CDFS. For handlers, we have the port-handler, the queue-handler, the aux-handler, and the speak-handler.
What we also have is a new "Mount" command, and a couple of new mount options that are also supported by HDToolBox. As mount options we have "DirectSCSI" which enables SCSI transport rather than trackdisk-style transport. "NoNSD" which disables NSD-probing since probing for NSD may have bad sideeffects on devices that do not support NSD, and "SuperFloppy" which tells filing sytems "go hunt for the disk geometry yourself".
And we have now - thanks Tony - a fourth file system out there in the wild which already supports these options. That's PFS3.
So, what do we have: A FFS that can be told to "talk SCSI" by a mount option or a RDB flag, to be set by HDToolBox. Clearly, I also updated CrossDos to support that. While at it, CrossDos now also supports long file names, FAT32, FAT24 and FAT16.
Now, it was only logical that CDFS should support the same, so some work was required. The 3.1 CDFS was out of the question (rotten), so I back-ported the Os 4 CDFS to Os 3.1.4, and added the new options, and fixed a couple of things. So, the CDFS will also speak SCSI if you tell it so. It now honours "Mask", "Maxtransfer" and "BufMemType", which it failed to do so. The same goes for CrossDos and FFS , of course.
Last but not least, there is one new feature both in CrossDos and CDFS, and that is "multi-threading". If an application triggers a big read or write from/to the harddisk, FFS is not quite as stupid as one may think: It triggers the read asynchroniously, but then is still ready to take new commands, for example the workbench ACTION_DISK_INFO that comes in about every second. Now, in the past, if you had a read going on from a CD, the workbench was "frozen" after a second or so. This is simply because it does not get its command through when looking for drives. The CDFS was busy, waiting for the data on the CD to arrive for the user process that triggered the read, but could not answer the trivial "are the disks all still there" request from the workbench.
This all changed. Unlike Fat95, "CrossDos" is now multithreaded. And unlike all the other CD file systems I'm aware of, "CDFS" is now also multithreaded. It dispatches the read, then goes back processing other commands, not getting in your way.
CDFS is a backport from 4.0, but after code review, I wasn't happy with all the code I found, so it currently "only" delivers ISO, rockridge, joliet and CDDA support - digital audio tracks appear as files in the file system. I have currently mixed-mode CDs, UDF-support, HFS support and HFS-plus support disabled. Code is under review, and depending on how far we get, might or might not be included in the final distribution.
While at it, the port-handler also became pre-emptive. Thus, it can queue up multiple read/write requests at a time without putting everything on hold.
So, that's what I have been busy the last three weeks: Re-designing CDFS, introducing co-routines, re-viewing code, testing code.
As I'm not the only developer, there are also other news. Since Reaction is gone, the ASL and workbench prefs are gone. We now got replacements for them, based on gadtools. Ok, they don't look "as nice" as the reaction parts, but they fit well to the optics of the remaining 3.1.4 "gadtools" based preferences.
We also got a new "UTF to Compugraphic" font mapping. There are multiple compugraphic fonts out there that seem to miss characters. However, the characters are there, just in places where the bullet library does not look for. All that is hidden in a unicode to intellifont ("dumb-o-font") translation table "if.uc" which takes care of that - just didn't do that right...
We got "Ed" fixed up. This is really a pretty screwy program - probably because it came from BCPL and was "translated automatically to C". Or at least, the code looks like that. Good part: Ed can now run in the same shell window it was called from, and can be run over "AUX:", i.e. a serial connection.
So, all the usual: Bug fixes, and lots of work.
Yes, we're looking for more beta testers as well. More testing is certainly needed.
-
This CDFS has nothing to do with old L:CDFileSystem (aka cdfs.library 40.11), which be gone? Sounds good to me. There have been some queue-handler replacements around too, don't know if you know about them? One is versioned 50.something, so I wonder if maybe it comes from OS4.0 or OS4.1 for classic.
-
We got "Ed" fixed up. This is really a pretty screwy program - probably because it came from BCPL and was "translated automatically to C". Or at least, the code looks like that. Good part: Ed can now run in the same shell window it was called from, and can be run over "AUX:", i.e. a serial connection.
So, all the usual: Bug fixes, and lots of work.
Nice! Looking forward to seeing which of these programs I can "hack" to work under my existing 3.9 installs. Maybe someone should write a guide. ;)
Would be nice if PFS3 was made the default file system, but I can't really see such a "radical change" being adopted by the community as a whole. :lol:
-
This CDFS has nothing to do with old L:CDFileSystem (aka cdfs.library 40.11), which be gone?
It probably has, yes, though that was a long time ago. CDFS was updated originally by Jörg Strohmeier, then by Sebastian Bauer, all for Os 4.0 and later, so the Os 4 version is at 52.4 or so. The backport beta (or rather, alpha) we have right now is again 45.1, so version numbers are certainly a bit backwards. Adding the "auto-boot" capabilitiy of the cdfs.library is by that in principle possible, though this mounts hardcoded on the "scsi.device" and not every Amiga has it. Besides, the ROM is full anyhow.
There have been some queue-handler replacements around too, don't know if you know about them? One is versioned 50.something, so I wonder if maybe it comes from OS4.0 or OS4.1 for classic.
Queue-Handler is new from scratch, no relation to the old code (which was just broken) nor any other new code. The problem with all the replacements (and the old code) was that it didn't work right with the new shell pipe support.
In particular, the following is an interesting race condition one had to fix: If you have a long directory listing (say) going and pipe that to "more", such as
list all | more
and then abort "more" with ^C, then you somehow need to take care of to interrupt "list" as well. None of the pipe handlers I found did that right. Also, you somehow need to tell commands that cannot read from "stdin" to read from the pipe. The "hack-me-up" approach of the "C:Pipe" command you find in aminet is to do second-level parsing, which is a dangerous thing to do with the weird shell syntax, so that approach is long gone. Pipes are intrinsic in the shell. Now, instead, you can now (with the new pipe handler) use the unnamed Pipe to do just the same:
list all | type hex PIPE:
will give you the directory output in hex. For whatever this should be good for, but... we have it. Also "Sort" can be run on a pipe, and "Dir" reformats its output according to the shell window size.
So, all tiny tiny improvements here and there. There is no "big new thing" that will come with 3.1.4. It is just "cleaning out the dust and bring down the trash".
But no, we're still busy, and CDFS will keep me busy for more time. Besides, I will be away for conferences, meetings and vacations for the next weeks, which will slow things do. Nothing is dead here, not at all.
-
Woop woop!
Great to see gadtools replacement prefs for Workbench and ASL! :)
(btw - http://aminet.net/package/util/misc/AslToRT - patch all programs to use ASL instead of ReqTools etc)
Also very nice to see old Ed getting some love, it's pretty much the "vi of Amiga" (while c:edit is the "ed of Amiga" ironically, btw your very own SED could very well be included, super useful!). Really looking forward to more reliably be able to run Ed remotely over serial and TCP connections. I presume the old problem of Ed "clearing" protection bits when writing files is taken care of too? :)
Oh no, guess I will be repeating myself now, but here goes...
Links in filesystems, softlinks - Workbench now indicates them with underline, which is great, but from CLI they just looks like directories. C:List should be able to indicate that they are links and more important, display where they point to.
Ram-handler? I think I have mentioned before that "version RAM:" could/should output version of ram-handler that is used, if at all (there are other means of setting up RAM: after all) to be consistent with FFS (and PFS3 and others).
Formatted output from C:Info - Info DH0: LFORMAT "Size of %d: is: %s, its name is %n and it is %p%% full, using %u bytes, having %f bytes free!"
I better stop... :rolleyes:
-
Also very nice to see old Ed getting some love, it's pretty much the "vi of Amiga" (while c:edit is the "ed of Amiga" ironically, btw your very own SED could very well be included, super useful!). Really looking forward to more reliably be able to run Ed remotely over serial and TCP connections. I presume the old problem of Ed "clearing" protection bits when writing files is taken care of too? :)
Probably not, but thanks for pointing this out.
Links in filesystems, softlinks - Workbench now indicates them with underline, which is great, but from CLI they just looks like directories. C:List should be able to indicate that they are links and more important, display where they point to.
That has been taken care of already. Softlinks are shown correctly, can be deleted by delete, and - even better - work now. Both FFS and the Ram Disk had really a couple of issues here.
Ram-handler? I think I have mentioned before that "version RAM:" could/should output version of ram-handler that is used, if at all (there are other means of setting up RAM: after all) to be consistent with FFS (and PFS3 and others).
Hmm. I wouldn't know why that should not the version, but I'll see.
Formatted output from C:Info - Info DH0: LFORMAT "Size of %d: is: %s, its name is %n and it is %p%% full, using %u bytes, having %f bytes free!"
I better stop... :rolleyes:
Well, that would probably too much of a change right now, or more than I would be willing to handle. Also, we lost the "sort" option of List since the old sources of List from 3.9 seem to be lost in space and time. I already rewrote Execute. I don't really want to spend too much time on List.
-
Probably not, but thanks for pointing this out.
This was a good one:
#define BACKUPNAME ":T/ed-backup"
DeleteFile(BACKUPNAME);
Rename(file_name,BACKUPNAME);
do_writebuf(line_first,line_last,file_name,BACKUPNAME);
...spot the error. CBM quality code at its best.
-
...spot the error. CBM quality code at its best.
Yes, not the only program that loves to have a directory :T on whatever filesystem you are editing a file, I think C:edit does the same. Can you imagine race-condition cases when a user is editing multiple files on same filesystem using Ed? The lolz :)
-
Yes, not the only program that loves to have a directory :T on whatever filesystem you are editing a file, I think C:edit does the same. Can you imagine race-condition cases when a user is editing multiple files on same filesystem using Ed? The lolz :)
C:Edit was probably the last executable program in BCPL. The last handler in BCPL was the Aux-Handler, but that got rewritten already. My current handling of C:Edit is that I removed it from the distribution. It is about the only binary (along with C:MagTape) I haven't used *once* in 20 years. It shares now the same destiny with MagTape -> NIL:
-
C:Edit was probably the last executable program in BCPL. The last handler in BCPL was the Aux-Handler, but that got rewritten already. My current handling of C:Edit is that I removed it from the distribution. It is about the only binary (along with C:MagTape) I haven't used *once* in 20 years. It shares now the same destiny with MagTape -> NIL:
It is a pitty as c:edit is great for building scripts to edit the startup-sequence in a non interactive manner. I am all for a replacement, but not for a removal without something that replaces that functionality.
We had a little chat about edit a while ago about this with Olaf Barthel:
http://www.amiga.org/forums/showthread.php?t=57601&
On the other hand, I have nothing good to say in favour of Magtape. :)
-
Totally expect MEmacs updates, haha
-
So, all tiny tiny improvements here and there. There is no "big new thing" that will come with 3.1.4. It is just "cleaning out the dust and bring down the trash".
It might seem like that but, after having read through all the changes and improvements, it does altogether amount to a pretty "big new thing" and really wanted to thank you for undertaking such a task. I'm really excited about the changes and am looking forward to trying them out.
I bought WB 3.1 ADF's from Cloanto last year so there's one thing I'm not clear on: how will 3.1.4 be released? Is there a rough time frame?
-
Thomas, any chance to include GhostBuster (http://aminet.net/package/util/cdity/GhostBuster) (hiding invalid disks depending on user settings) functionality in the improved Workbench?
-
Well, that would probably too much of a change right now, or more than I would be willing to handle. Also, we lost the "sort" option of List since the old sources of List from 3.9 seem to be lost in space and time. I already rewrote Execute. I don't really want to spend too much time on List.
Wasn't the SORT option first introduced by Heinz Wrobel in Envoy, long before OS 3.9?
-
Wasn't the SORT option first introduced by Heinz Wrobel in Envoy, long before OS 3.9?
Yes, it was. But we don't have the sources of this particular version. What I do have are the sources of the 4.x "List" which includes the same as far as I know, but given my experience with CDFS, I currently plan to inverst the little work power we have into more serious issues.
-
Thomas, any chance to include GhostBuster (http://aminet.net/package/util/cdity/GhostBuster) (hiding invalid disks depending on user settings) functionality in the improved Workbench?
Please understand. We have very limited resources for development, and we cannot just include feature after feature. The central theme of this release is "we fix bugs" not "we add new features". We don't have resources beyond the bare essential means, and most of the resources go into important bug fixing, so please lower your expectations.
Just to give you an idea: Workbench and icon are already too large to fit into the ROMs. There will be only a loader version in the ROM, and the libraries will be on disk. Because they already have more features, they will take more RAM, so that there is less left on the low-end machines. It will probably not work with 512K alone. This already gave reasons for complains.
We cannot do everything right for everyone, and we cannot address every need, every feature, yet at the same time keep it fast, small and simple. It is a painful compromize to include the essential features, and only that, and focus on the most important issues we have.
My experience is that 3.1.4 as we have it right now is already much larger (in the amount of changes we did) than I expected it to become, and yet, as an update, it is much smaller than what 3.9 offered. We try to keep 3.9 components workable, but we cannot include many 3.9 components for multiple reasons. Leave alone, update 3.9 components.
There is a reason why this is 3.1.4 and not 3.14.
-
That's perfectly OK, I only asked - in fact, I have asked for this particular feature only because it seems very simple to implement (one more value for already existing configuration parameter + few more C statements to determine if disk icon should be displayed)... at least from the point of view of someone, who didn't see the Workbench 3.9 source code :)
-
C:Wait and C:Sort, both version 42.1, at least the sources are not a problem, hehe :)
The FILE option of Wait 42.1 has turned out to be quite useful for me, simple trick to solve situations with several background running scripts having dependencies on each other etc.
-
C:Wait and C:Sort, both version 42.1, at least the sources are not a problem, hehe :)
The FILE option of Wait 42.1 has turned out to be quite useful for me, simple trick to solve situations with several background running scripts having dependencies on each other etc.
The problem with those updates as far as I know is that they are post 3.1 CBM era and are not part of the rights Hyperion has, so they cant be included, but of course, their extra features can be reimplemented. :)
-
The problem with those updates as far as I know is that they are post 3.1 CBM era and are not part of the rights Hyperion has, so they cant be included, but of course, their extra features can be reimplemented. :)
That sums it up, and I believe we might even have 4.x versions with these features, but I really did not consider them important enough to bother at this time.
-
The problem with those updates as far as I know is that they are post 3.1 CBM era and are not part of the rights Hyperion has, so they cant be included, but of course, their extra features can be reimplemented. :)
dr-xr-xr-x 0 root root 0 Jul 19 1993 os-source/v42/src/workbench/c/wait/
-r-xr-xr-x 0 root root 5628 Jul 19 1993 os-source/v42/src/workbench/c/wait/wait.ld
-r-xr-xr-x 0 root root 2 Jul 12 1993 os-source/v42/src/workbench/c/wait/wait_rev.rev
-r-xr-xr-x 0 root root 217 Jul 12 1993 os-source/v42/src/workbench/c/wait/wait_rev.i
-r-xr-xr-x 0 root root 976 Jul 19 1993 os-source/v42/src/workbench/c/wait/wait.ld.strip
-r-xr-xr-x 0 root root 5604 Jul 19 1993 os-source/v42/src/workbench/c/wait/wait.o
-r-xr-xr-x 0 root root 1158 Jul 19 1993 os-source/v42/src/workbench/c/wait/wait.map
-r-xr-xr-x 0 root root 175 Jul 12 1993 os-source/v42/src/workbench/c/wait/wait_rev.h
-r-xr-xr-x 0 root root 6050 Jul 12 1993 os-source/v42/src/workbench/c/wait/wait.c
-r-xr-xr-x 0 root root 2201 Jul 19 1993 os-source/v42/src/workbench/c/wait/lmkfile
dr-xr-xr-x 0 root root 0 Aug 9 1993 os-source/v42/src/workbench/c/sort/
-r-xr-xr-x 0 root root 1884 Aug 9 1993 os-source/v42/src/workbench/c/sort/sort.map
-r-xr-xr-x 0 root root 5984 Aug 9 1993 os-source/v42/src/workbench/c/sort/sort.ld
-r-xr-xr-x 0 root root 214 Aug 9 1993 os-source/v42/src/workbench/c/sort/sort_rev.i
-r-xr-xr-x 0 root root 18533 Aug 9 1993 os-source/v42/src/workbench/c/sort/sort.c
-r-xr-xr-x 0 root root 2280 Aug 9 1993 os-source/v42/src/workbench/c/sort/sort.ld.strip
-r-xr-xr-x 0 root root 2201 Aug 9 1993 os-source/v42/src/workbench/c/sort/lmkfile
-r-xr-xr-x 0 root root 172 Aug 9 1993 os-source/v42/src/workbench/c/sort/sort_rev.h
-r-xr-xr-x 0 root root 2 Aug 9 1993 os-source/v42/src/workbench/c/sort/sort_rev.rev
From what I recall - CBM folded in 1994.
https://pastebin.com/L3uU1Cmq
-
dr-xr-xr-x 0 root root 0 Jul 19 1993 os-source/v42/src/workbench/c/wait/
-r-xr-xr-x 0 root root 5628 Jul 19 1993 os-source/v42/src/workbench/c/wait/wait.ld
-r-xr-xr-x 0 root root 2 Jul 12 1993 os-source/v42/src/workbench/c/wait/wait_rev.rev
-r-xr-xr-x 0 root root 217 Jul 12 1993 os-source/v42/src/workbench/c/wait/wait_rev.i
-r-xr-xr-x 0 root root 976 Jul 19 1993 os-source/v42/src/workbench/c/wait/wait.ld.strip
-r-xr-xr-x 0 root root 5604 Jul 19 1993 os-source/v42/src/workbench/c/wait/wait.o
-r-xr-xr-x 0 root root 1158 Jul 19 1993 os-source/v42/src/workbench/c/wait/wait.map
-r-xr-xr-x 0 root root 175 Jul 12 1993 os-source/v42/src/workbench/c/wait/wait_rev.h
-r-xr-xr-x 0 root root 6050 Jul 12 1993 os-source/v42/src/workbench/c/wait/wait.c
-r-xr-xr-x 0 root root 2201 Jul 19 1993 os-source/v42/src/workbench/c/wait/lmkfile
dr-xr-xr-x 0 root root 0 Aug 9 1993 os-source/v42/src/workbench/c/sort/
-r-xr-xr-x 0 root root 1884 Aug 9 1993 os-source/v42/src/workbench/c/sort/sort.map
-r-xr-xr-x 0 root root 5984 Aug 9 1993 os-source/v42/src/workbench/c/sort/sort.ld
-r-xr-xr-x 0 root root 214 Aug 9 1993 os-source/v42/src/workbench/c/sort/sort_rev.i
-r-xr-xr-x 0 root root 18533 Aug 9 1993 os-source/v42/src/workbench/c/sort/sort.c
-r-xr-xr-x 0 root root 2280 Aug 9 1993 os-source/v42/src/workbench/c/sort/sort.ld.strip
-r-xr-xr-x 0 root root 2201 Aug 9 1993 os-source/v42/src/workbench/c/sort/lmkfile
-r-xr-xr-x 0 root root 172 Aug 9 1993 os-source/v42/src/workbench/c/sort/sort_rev.h
-r-xr-xr-x 0 root root 2 Aug 9 1993 os-source/v42/src/workbench/c/sort/sort_rev.rev
From what I recall - CBM folded in 1994.
https://pastebin.com/L3uU1Cmq
The key element there is not that of the year, but of the version number.
Version 42.x was post 3.1, so it is a no go, despite still being built during CBM era.
-
My current handling of C:Edit is that I removed it from the distribution.
I wonder how wise that is, I believe I have seen installer scripts use C:Edit, for altering startup-sequence and other things.
-
The key element there is not that of the year, but of the version number.
Version 42.x was post 3.1, so it is a no go, despite still being built during CBM era.
That sounds whack, one would think that released 3.1 CBM code and unreleased WIP "3.2 beta" CBM code was pretty much the same, legally.
Who owns rights for the kickstart "3.2" kickstart of the Walker? :)
-
That sounds whack, one would think that released 3.1 CBM code and unreleased WIP "3.2 beta" CBM code was pretty much the same, legally.
Who owns rights for the kickstart "3.2" kickstart of the Walker? :)
Legally speaking 3.1, and post 3.1 code are two entirely different worlds apart.
As for who owns 3.2 beta kickstart, one thing for sure: it is not Hyperion.
-
I wonder how wise that is, I believe I have seen installer scripts use C:Edit, for altering startup-sequence and other things.
Because I made a mistake when I wrote the Roadshow installation script I thought I could put the "Edit" command to good use in order to fix the problem I had created. The "Installer" tool has only very limited string/file manipulation functions, so "Edit" seemed like an option to try. However, it turned out that the V36 "Edit" command could not be used because the editing commands I needed either did not work at all, or crashed the command.
The "Edit" command which shipped with Workbench 2.0-3.1 suffered from several bugs and limitations which rendered it mostly unsafe for use. For example, the DTA, SA and SB commands never worked at all, the WIDTH and PREVIOUS arguments didn't work either, lines longer than 120 characters could cause Edit to slip up badly and path names longer than 120 characters would trash memory before even loading the respective file.
When I got curious after I ran into the "Edit" bugs I took the plunge and fixed the bugs, using the original BCPL implementation as a reference. The updated version is available in a form usable within the context of Workbench 3.1.4. As far as I can tell it's now on the same level as the Workbench 1.3 version (last updated in 1985) and "only" suffers from the same design limitations.
However, this is a Catch-22 situation bordering on satire: if "Edit" saw limited use because it was rarely safe to use in the first place, replacing it with a version which actually does what it's supposed to will accomplish exactly what? :(
-
Legally speaking 3.1, and post 3.1 code are two entirely different worlds apart.
I would say that depends entirely on whether it is CBM or post CBM, but whatever - doesn't look like anything of the v42 stuff from CBM ever went to H&P's OS3.5.
So who has rights/ownership to the CBM v42 code?
-
if "Edit" saw limited use because it was rarely safe to use in the first place, replacing it with a version which actually does what it's supposed to will accomplish exactly what? :(
This is AmigaOS, what's this "safe to use" thing you speak of? :laughing:
I think it is great that Edit has been worked on, a standard scriptable editor is in my opinions quite important and useful for the OS. If it now is more stable and reliable, then the worst that can happen is that it will be used more often.
-
I would say that depends entirely on whether it is CBM or post CBM, but whatever - doesn't look like anything of the v42 stuff from CBM ever went to H&P's OS3.5.
That is correct. Work on V42 stopped when development was ongoing, and we were in no position to evaluate if the current state was preferrable to what the V40 code was in. Even the V40 code was still being worked on when Commodore went out of business. So we stuck with the V40 code.
So who has rights/ownership to the CBM v42 code?
Does it matter? As far as the shell commands, etc. are concerned a rewrite based upon the V40 code isn't such a demanding task if you wanted to implement the same functionality or even something better. The shell commands were the "long hanging fruit" anyway. Just look at how the "Sort" command does its job. It can be improved merely by randomizing the order in which the individual lines are added to the list. With only very few exceptions none of these commands had been updated since 1990.
-
This is AmigaOS, what's this "safe to use" thing you speak of? :laughing:
How about lack of constant embarrassment as the next best thing? ;) Much of the code which received the long overdue upgrade in Workbench 2.0 was never updated, its limitations and failures known for a very long time indeed. Not much happened here in the next 3-4 years, and software such as "HDToolBox" and "prodprep" arguably became less stable and robust as development "progressed" on them.
I think it is great that Edit has been worked on, a standard scriptable editor is in my opinions quite important and useful for the OS. If it now is more stable and reliable, then the worst that can happen is that it will be used more often.
One small problem remains to be resolved: how does a script file figure out if it's using the more well-behaved "Edit" command or its more embarrassing predecessor?
-
One small problem remains to be resolved: how does a script file figure out if it's using the more well-behaved "Edit" command or its more embarrassing predecessor?
Same as with shell scripts - ask the "interpreter" what version it is, and bail out if the answer is not satisfying?
-
Better yet - ask using the Version command :)
-
Quite frankly, I believe you should not really depend on edit anymore. It would probably more advisable to create something more robust and reliable in first place, or fall back to another solution for the same problem.
REXX comes to my mind.
Otherwise, any attempt to write a script that depends on such commands becomes a nightmare in first place as the script first has to go through hoops to check for "which version of edit to we work with today?". This is not creating a more robust solution, but a less robust one. It might just crash on the "lesser working versions" of it.
Deprecating the beast is not the worst option, really.
-
Well, playing "roborally" in a text file using arexx isn't exactly honkadory either. In addition, it requires rexxmast to be running. OS4 comes with an edit version 53.4, what about that?
-
Well, playing "roborally" in a text file using arexx isn't exactly honkadory either. In addition, it requires rexxmast to be running.
Yes, that's the uncomfortable truth: the "Edit" command is completely self-contained, free of dependencies, and ought to be the smallest solution to the problem (provided it doesn't crash, the editing commands you need are actually implemented and don't cause trouble).
String manipulation is one of the core features of the REXX language, so ARexx should be the more powerful tool. The Installer program can launch ARexx scripts through the REXX command, but it requires the RexxMast program to be already running, of course.
OS4 comes with an edit version 53.4, what about that?
That's the version which I mentioned, and which I recently backported.
-
That's the version which I mentioned, and which I recently backported.
Cool - bring it on :) It's good to have some consistency between OS3 and OS4, and the extra bonus - online manuals - http://wiki.amigaos.net/wiki/AmigaOS_Manual:_AmigaDOS_Using_the_Editors#EDIT :)
-
At last, some sense. :)
-
Thanks for the OS update Thomas 'Thor' Richter and Olaf 'Olsen' Barthel.
-
Yes, it's a cool initiative, big thanks to those involved. - if only the "right holders" could allow a development model that could be less "restrictive", so more developers and testers could get involved.
-
I have *really* enjoyed reading this thread. Any further updates to share? :)
-
I have *really* enjoyed reading this thread. Any further updates to share? :)
Not much from my side. I was traveling in the last weeks, which brought me to Salt Lake and San Diego, and I have not had much time to work in this. I will continue now, having returned on Monday.
However, there are more developers, so we get also nicely reworked preferences. As we don't have reaction, everything is gadtools based again, but 3.1 did not have any prefs for the workbench, so all of this was redone. We also get a drilled-up screen mode prefs editor, again with a test screen (i.e. more advanced than 3.1, but not quite as fancy as 3.9).
So yes, we are making progress here.
-
I have *really* enjoyed reading this thread. Any further updates to share? :)
Um, since you've asked: The major contribution I am making is the new Disk Doctor, and the "third leg" of the feature set (1. Examine the volume to gather information for recovery, 2. Recover data from the volume, 3. Repair the volume) has finally taken shape.
At the moment I am tinkering with the repair process, and this is slow going. Part of the challenge is in figuring out how to deal with damage. The current plan is, to keep things simple for a first test release, to restore the volume to full working condition. This approach has side-effects, because it may mean deleting corrupted files, links and drawers from the volume altogether. Note that the affected data still remains on the volume, it's just that you can no longer access it once the repair process has concluded. Due to how the new Disk Doctor works, you will still be able to recover the data deleted by the repair process from the volume later if you change your mind.
Another challenge here is to find real world examples of damaged volumes which the recovery/repair operation can be tested with. Disk Doctor can simulate media damage as part of its test rig, but there's nothing like the real thing.
Because repairing the volume is already sufficiently complicated as it is, I made a decision on how to deal with DCFS (directory cache mode) volumes. For simplicity, the repair process will convert them to the respective international mode OFS/FFS format. This can be done without loss of data and is almost instant. It saves the time to rebuild all the affected directory caches, which for DCFS volumes easily takes up 50% of the total repair time.
Other repair tools left the job of rebuilding the directory cache and the block allocation information to the file system validator, which was never a popular choice. It always took too long, you never knew when it was finished, and if the repairs were insufficient the validation process could get stuck, even crash. The new Disk Doctor will, if repairs are possible, always leave the volume in a proper, validated state.
Disk Doctor aside, I have backported a few more shell commands to Workbench 3.1.4 in the hope that they may prove useful. This includes the "Sort" command, for example, which is interesting because it does not use the same sorting algorithm as the current Workbench 3.1.4 version (which is essentially an implementation of Quicksort, performed on a list).
Fun fact (for those who are into algorithms and not easily bored): the original Workbench 1.x "Sort" command would read a file one line at a time and then stuck that line into a binary tree, making no attempt to balance the tree. The sort operation then involved walking through the tree "in-order". Whatever could go wrong?
The backported "Sort" command brings back the binary tree idea, this time using the same algorithm which the ASL file requester and the Workbench use to keep a list sorted at all times, and in real time while it is being filled with data (without using recursion). In my tests I found that the new algorithm made the "Sort" command twice as fast.
-
Totally expect MEmacs updates, haha
3.12 binaries for the Amiga can be found here :)
http://www.mtxia.com/js/Downloads/Editors/MicroEMACS/index.shtml
-
I have *really* enjoyed reading this thread.
Me too! I really wish more Amiga development worked this way. Even better a github link would be nice. Too bad getting github source to an Amiga is hard enough without git support, let alone porting git.
I feel like there needs to be better source control on the Amiga. I think there is a SVN client for accelerated, memory capable, Amigas.
-
I feel like there needs to be better source control on the Amiga. I think there is a SVN client for accelerated, memory capable, Amigas.
Perhaps you mean Subversion (http://aminet.net/package/dev/misc/subversion-1.1.4)
I have used it a little, but only against local repositories.
-
Honestly, either patreon or bounty system. You guys should just create a consortium to manage bounties, declare how much money it would take for development of certain bounties, then when it's met, work...then get paid.
To heck with "official releases"...
...before someone makes a better 68k compiler for AROS...
-
Me too! I really wish more Amiga development worked this way. Even better a github link would be nice. Too bad getting github source to an Amiga is hard enough without git support, let alone porting git.
I feel like there needs to be better source control on the Amiga. I think there is a SVN client for accelerated, memory capable, Amigas.
https://github.com/widelec-BB/git-morphos
Probably a good place to start if you want to port git to 68k.
-
I feel like there needs to be better source control on the Amiga. I think there is a SVN client for accelerated, memory capable, Amigas.
I personally do not use the Amiga for development. It's a vamos-based build chain, which means that I can depend on all the revision control systems from Linux.
-
Not ironic at all :)
-
Me too! I really wish more Amiga development worked this way. Even better a github link would be nice. Too bad getting github source to an Amiga is hard enough without git support, let alone porting git.
I feel like there needs to be better source control on the Amiga. I think there is a SVN client for accelerated, memory capable, Amigas.
Ported by yours truly, this is still version 1.1.4, and it badly needs an update to handle TLS 1.2, now that nobody really deploys SSL/TLS 1.0/TLS 1.1 any more. With TLS 1.2 support you could access GitHub again. This is on my ever-growing TODO list...
-
Perhaps you mean Subversion (http://aminet.net/package/dev/misc/subversion-1.1.4)
I have used it a little, but only against local repositories.
We have been using that SVN client for AmigaOS development since around 2008, when the CVS repository of AmigaOS4 was eventually migrated (which was quite the adventure -- this is when I found out how many corrupted RCS files were part of the Amiga operating system source code tree, owing to ancient bugs in the rcs tools).
-
Not ironic at all :)
Careful, the irony in this has so many layers, it might actually be recursive by now, and nobody noticed.
Back in the 1990'ies when I was working on the AmigaOS 3.1 build, the foundation for the development work were RCS files which eventually came together in a single CVS repository through a tedious and thoroughly grinding process of massaging the files until the CVS server stopped choking on them. Building the operating system on my Amiga 3000UX took hours, but it worked. Turnaround times for fixing build/runtime errors were epically bad (but then the build times for intuition.library under NetBSD were even worse).
Things changed by the time Amithlon came around, which cut the build time to under an hour. When I upgraded my old laptop, I discovered that I could run WinUAE on it, and with the new JIT the whole setup was faster and more convenient than the Linux setup I was struggling with. While I still had an A4000T at the office, the combination laptop+WinUAE made me much more productive.
There haven't been that many changes since then. The build tools are still all 68k (no cross-compilation is involved), but now they either run within WinUAE or through the vamos emulation layer. The major limitations of building everything natively on 68k hardware were available memory and I/O bandwidth. Emulation and virtualization remove these boundaries. You still have to test the results on actual hardware, though (some things you cannot conveniently debug on emulated hardware; actual hardware will always manage to kick your butt and make you feel generally miserable).
The compounded irony is in that we still use Amiga-native tools to build the Amiga operating system, only that the tools are no longer running natively on Amiga hardware.
-
actual hardware will always manage to kick your butt and make you feel generally miserable
Most true words I have read in a while.
-
Careful, the irony in this has so many layers, it might actually be recursive by now, and nobody noticed.
...
The compounded irony is in that we still use Amiga-native tools to build the Amiga operating system, only that the tools are no longer running natively on Amiga hardware.
Indeed. So yes, it is still SAS/C building the tools, and GNUmake ported to AmigaOs, and the H68X assembler, and SLink, all as it used to be. So, I haven't attempted to port anything to gcc and cross-compile. Just that my editor is now emacs, and the console is called mrxvt. Even the shell is the native Amiga Shell, just running in an mrxvt-console, and not in a CON: window.
Works nicely. Well. Most of the time. "ReadArgs()" is one of the functions that really persist proper emulation. I just fixed "the last bug"(tm) yesterday night. You can always get my branch of "qualified to build AmigaOs" here:
https://github.com/thorfdbg/amitools
It is certainly a very cut-down version of the AmigaOs API, and I had to add a couple of custom tools to make it work right, for example adding a new compiler front-end for Lattice C (which, unfortunately, some minor components still depend upon until I finally get my hand on them).
-
Wasn't AmigaOS built on other systems most of its lifespan anyways? :)
What I find ironic here is that ThoR uses Linux, of all things, to get work done.
-
Wasn't AmigaOS built on other systems most of its lifespan anyways? :)
What I find ironic here is that ThoR uses Linux, of all things, to get work done.
Why? Just because I believe that a closed source AmigaOs works better? Look, there is open source, there is closed source... unlike what you might believe, I am not a "true follower" of any religion, and I'm not in particular a fan of GPL. However, depending on the needs, I pick the right development model that fits best. For AmigaOs, Open Source is not the right model. For others, it is. If you check, there is open source on my github as well, so no worries.
I'm only pragmatic, but I have a strong opposition against people who are trying to sell me that a particular model is "evil" and I should stick to their definition of "free-ness". Thanks, I rather pick this myself.
-
Why? Because you typically bring out Linux as something you really dislike, and despite claiming that AmigaOS doesn't "fit" open source models, your entire build environment relies on open source. No open source, no AmigaOS development. That is irony.
-
Wonder if OS 3.1.4 will use AROS code for a certain component, like OS 3.9 does :)
-
Wonder if OS 3.1.4 will use AROS code for a certain component, like OS 3.9 does :)
Oh, another conspiracy theory then? Which component of 3.9 did use AROS components then?
Concerning Linux: I believe I told you very well what I dislike about it, namely that the developers - insead of stabilizing the platform - continue to re-invent new solutions for old problems that have long been solved. Linux makes programmers happy - not users. I do not want this to happen with AmigaOs.
X11 vs. Wayland. Cups vs. lpr. Alsa vs. jack. initv vs. systemd. A lot of wasted resources.
-
...
Concerning Linux: I believe I told you very well what I dislike about it, namely that the developers - insead of stabilizing the platform - continue to re-invent new solutions for old problems that have long been solved. Linux makes programmers happy - not users. I do not want this to happen with AmigaOs.
X11 vs. Wayland. Cups vs. lpr. Alsa vs. jack. initv vs. systemd. A lot of wasted resources.
+1 :hammer:
-
Wasn't AmigaOS built on other systems most of its lifespan anyways? :)
I think it's closer to 55:45 given the whole time span between 1983-1994 (assuming that the operating system took shape around 1983 and not 1984).
At Commodore they used Sun 2 and Sun 3 machines for development, but I don't remember what was in use at Hi Toro/Amiga: there was a reason why the Sun workstations were preferred, and it may have had something to do with how expensive they were.
Native Amiga development tools continued to improve through 1987/1988, and work on what became Kickstart 2.0 did use the native Lattice 'C' compiler, several versions of which were used during the development of the subsequent 2.04, 2.1, 3.0 and 3.1 operating system versions. The CDTV project most prominently used the Aztec 'C' compiler.
It could have been Commodore's penny pinching which drove the developers to native tools, but the improved performance of Amiga hardware, along with the better quality of the native development tools did yield better quality software. A whole battery of tools for QA work was created specifically for Kickstart/Workbench 2.0 which the original operating system developers could not use (due to lack of MMUs, for example).
One downside of this move from cross-development to native development was that the ability to build the entire operating system on a single machine was lost. The local builds (still using makefiles) drifted apart, and by 1994 you could expect that no two operating system components were built similarly. In fact, you probably had to wrangle three different compilers, two different assemblers and start the respective build manually. While it was still used in production work (1989-1994) that "build process" must have produced and lead to the resolution of integration problems on a major scale :(
What I find ironic here is that ThoR uses Linux, of all things, to get work done.
Actually, one of the reasons why this approach was picked was the idea of having a build server which at the end of the day would crank out a complete AmigaOS build, or stop and complain if this didn't work out ("the daily build & smoke test"). We couldn't conveniently do this with an Amiga, but with the vamos setup it became possible.
I'm assuming you've done your lot software development work. One of the most important aspects of software development productivity is to be able to build and rebuild the product as quickly as possible. If you have to wait hours just to find an integration error, chances are that the whole development process will make you utterly miserable.
Eating your own dogfood and everything which building the Amiga operating system on an Amiga, and testing it in this context brings with it, there's no single tool which can do everything well. I'm accepting that a build done on any POSIX system through vamos is now part of the process of building the 68k Amiga operating system. Irony be damned ;)
-
but I don't remember what was in use at Hi Toro/Amiga:
https://en.wikipedia.org/wiki/SAGE_Computer_Technology
-
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.
For now it is an accelerator maybe, so what you're saying is right, but SAGA/Pamela add new customs registers like the original Amiga in the $DFFxxx space...so it seems logical that it could be part of the OS instead of having a solution like P96 or CGX no?
-
https://en.wikipedia.org/wiki/SAGE_Computer_Technology
Yes, SAGE was my first idea (the SAGE II and SAGE IV models), but I know next to nothing about the roles these machines played during development of the Amiga operating system precursor. If I remember correctly, they were both suitable for software development and for hardware prototyping, but less powerful than the workstations of its age. But: CP/M 68k as a software development system? I can't quite picture that.
I don't know how expensive the SAGE machines were in comparison to the IBM-PCs of the same time. What I do know is that the firmware for the Amiga keyboard processor was written in 6502 assembly language, translated into production code using an MS-DOS based assembler program.
It's very well possible that SAGE machines were in use all over the place during the Hi Toro/Amiga days (one of the company's founders mentioned this in an interview which I read), but it's also possible that other computers available more cheaply could have played an important part, too.
For example, when Electronic Arts committed to the Amiga, their developers would use MS-DOS for development work. The source code to "Prism" (precursor to "Deluxe Paint") shows that the MS-DOS Lattice 'C' compiler was used to build it. IBM-PCs of the time (1984/1985) were probably much cheaper than the Sun 2/3 machines available then.
-
Wonder if OS 3.1.4 will use AROS code for a certain component, like OS 3.9 does :)
The code in question was the v44 colorwheel gadget. It was actually developed for 3.5 and then donated to AROS aswell. Nothing to see here.
Yes, SAGE was my first idea (the SAGE II and SAGE IV models), but I know next to nothing about the roles these machines played during development of the Amiga operating system precursor.
According to Bagnalls "The Amiga Years", Amiga started assembling a software team in August 83 and had bought a bunch of SAGE IV machines for them to use. I'm assuming these were only used as terminals though, because Mical is quoted in the book that later on (when Commodore bought Amiga), each Software Engineer got "his own powerful SUN workstation, with his own harddisk and CPU".
-
Linux makes programmers happy - not users. I do not want this to happen with AmigaOs.
X11 vs. Wayland. Cups vs. lpr. Alsa vs. jack. initv vs. systemd. A lot of wasted resources.
I think that boat sailed a long time ago already.
EGS v Picasso96 v CyberGraphX, Gadtools v Triton v ClassAct/Reaction v MUI/Zune, WarpOS v PowerUp. Hell even CAMD v midi.library and I only know that one because I used it to make an ultra low overhead tool for realtime midi remapping so my pre GM real kit could be used in a more standard setting.
-
EGS v Picasso96 v CyberGraphX, Gadtools v Triton v ClassAct/Reaction v MUI/Zune, WarpOS v PowerUp.
There is an important difference here. If this would be Linux, I would say now "Ditch CGfx, it is in our way for developing intuition (which is true), P96 is the better system (which is what at least I believe), users need to migrate (which I do not believe)".
However, this is not Linux. Our intention cannot be to loose 50% of the RTG user base just to make developers happy. The right decision is: We freeze intuition at V40 so CGfx and P96 remain working. Intution V40 does not have serious bugs, so we can just continue to use it. That will cost a couple of features V45 has, but so might it be. Stability and consistency are more important than features.
-
Thomas, I obviously don't agree with you about P96 (probably because it only builds on something Mariak and his partner started), BUT, since you can't get a license to further develop Cybergraphics I understand why you favor P96.
Although...I absolutely LOVED this comment about, ""the last bug"(tm)".
Hammering out ""the last bug"(tm)", yes!
You and Olsen keep wackamoling!
I actually think that cleaning up OS3.1 is an extremely noble idea and worthwhile goal.
And regardless of what everyone thinks of as "the real" 3.1...you've got MY full support.
-
Stability and consistency are more important than features.
Mmmm. Then what's the point in developing a new version at all? As the saying goes, you've gotta break a few eggs to make an omelet. :lol:
-
Thomas, I obviously don't agree with you about P96 (probably because it only builds on something Mariak and his partner started), BUT, since you can't get a license to further develop Cybergraphics I understand why you favor P96.
We can discuss this forever, and probably in another thread. Fact is that Frank does no longer supports it - yes, we did ask, but not cigar, this was a dead-end. No matter what, this is one of the situations where you need to set your private preferences back.
There are other hard decisions like this. We will neither get Tab expansion in 3.1.4. The way how Tab-expansion is handled by multiple third-party extensions and the Os 4 con-handler - is ill-designed as it requires the console to second-guess the shell syntax. This goes at least wrong as soon as the shell is replaced by a user shell, and the shell syntax is complex enough already. Continuing this path would introduce subtle bugs I do not want to hunt down later.
There is a better design, though implementing it at this time would delay 3.1.4 noticably and would risk instabilities. So, not now.
-
Mmmm. Then what's the point in developing a new version at all? As the saying goes, you've gotta break a few eggs to make an omelet. :lol:
A new version of what? Anyhow, how we continue from here depends also on how 3.1.4 is received. If this goes well, we may probably plan for a major release (3.14?).
Anyhow, this is all speculation at this time.
-
Mmmm. Then what's the point in developing a new version at all? As the saying goes, you've gotta break a few eggs to make an omelet. :lol:
I don't see much new software appearing anymore. If 3.1.4 is not mindful of backward compatibility, who's going to patch the existing applications for this release?
I'd rather have a bug-fixed and compatible OS instead of one that adds features that breaks software. All of the other Amiga flavors are still in existence. If I want a really different tasting omelet, I can always turn on the Mac, Windows or a Rasberry Pi, etc. The alternatives are almost endless.
My 2 cents...
-
A new version of what? Anyhow, how we continue from here depends also on how 3.1.4 is received. If this goes well, we may probably plan for a major release (3.14?).
Anyhow, this is all speculation at this time.
This is actually chicken and egg problem. There is no point to buy 3.1.4 if it is not full replacement of OS3.9 AND/OR there is no clear path to future. And the future can't be guaranteed due unknown 3.1.4 profitability AND Hyperion (possible profit can go to other projects like OS4 or litigation...)
-
This is actually chicken and egg problem. There is no point to buy 3.1.4 if it is not full replacement of OS3.9 AND/OR there is no clear path to future.
Sorry to disappoint you. Just to make one thing clear: 3.1.4 is not supposed to be a replacement for Os 3.9. It cannot. We do not have Reaction, and a lot of other distributions for 3.9. Nor is it supposed to be. You can certainly install it on top of 3.9 if you like.
In particular: 3.1.4 will not come with Reaction. It will not come with Reaction-based preferences. It will not come with Genesis. It will not come with BenchTrash, ZipTools or ViNCEd. It will not come with AmiDock, WarpOs, the xpk-libraries or AsyncWB, or AWeb. There will be no MP3 player, no CD-Player, no AVI-Player. It will not come with the mmulib.
This is a bare-bone core operating system, same bare-bone as 3.1 was. If you need further components, you'll find plenty in Aminet. Actually, part of the goal is to leave "distribution building" to third parties, as we have really limited development capacity.
Furthermore, nobody is willing to guarantee you anything in Amigaland, how can we possibly do that? We're doing the best we can, that is all I can promise.
Thus, if you expect a new, fully blown distribution, you are wrong here. All I am going to promise is a bug-fixed release of Os 3.1. It was never announced as anything beyond that.
Thus, if you expect the best invention since deep dishes (as we say in Germany) - no, it's not. But it is the latest, newest and most robust deep dish anyone can possibly sell you. You probably have to fill it yourself, though.
-
Concerning Linux: I believe I told you very well what I dislike about it, namely that the developers - insead of stabilizing the platform - continue to re-invent new solutions for old problems that have long been solved. Linux makes programmers happy - not users. I do not want this to happen with AmigaOs.
Who are these unhappy Linux users you speak of? Apart from yourself, a programmer.
Your fear that AmigaOS will make programmers happy is rather funny - have you not noticed yet, that programmers left a long time ago? I *wish* for an AmigaOS that would make programmers happy, so they could come back. Happy programmers are a must if you want happy users. If you ONLY want happy Amiga users, you should work with people of bling-bling distros like ApolloOS, AmiKit, BetterWB, ClassicWB etc.
X11 vs. Wayland. Cups vs. lpr. Alsa vs. jack. initv vs. systemd. A lot of wasted resources.
You mean X11 vs. SunView, Athena vs Motif, MIR vs Wayland, IPP vs LPD, ALSA vs. OSS, JACK vs PulseAudio, sysv init (+ openrc and many others) vs systemd - why stop here? Linux vs. UNIX, GNU vs BSD, Windows vs MacOS, Atari vs Amiga... oh, talking about wasting resources - MorphOS vs OS4 vs AROS, CGFx vs P96, AS225 vs AmiTCP vs Miami vs Roadshow, BGUI vs. gtlayout vs. MUI vs ClassAct vs whatever, Reqtools vs ASL vs ...
The goal of re-inventing the wheel is obviously to get a better wheel, sometimes that happens, other times not.
-
I'm accepting that a build done on any POSIX system through vamos is now part of the process of building the 68k Amiga operating system. Irony be damned ;)
Again, that is not what I find ironic, lots of AmigaOS work was done on SunOS anyways.
What I find ironic, is that of all the systems out there to use, ThoR uses Linux, an OS kernel he never fails to go out of his way to bash around (presumably after being butt-hurt over his own kernel code stopped working as he failed to maintain it over time - a concept the Linux project strives for, keeping upper layer programmers happy rather than kernel coders). You would think ThoR would be much happier with a more conservative and less change-happy environment, such as most of the BSDs are.
-
Just love this Idea !
as long as my beloved ScalaIC, VideoTracker, VidiAmiga12 still work then iam all for it..
Good luck Thom !!
Now iam going back to lurking for another 8 years :))
-
Sorry to disappoint you. Just to make one thing clear: 3.1.4 is not supposed to be a replacement for Os 3.9. It cannot. We do not have Reaction, and a lot of other distributions for 3.9. Nor is it supposed to be. You can certainly install it on top of 3.9 if you like.
In particular: 3.1.4 will not come with Reaction. It will not come with Reaction-based preferences. It will not come with Genesis. It will not come with BenchTrash, ZipTools or ViNCEd. It will not come with AmiDock, WarpOs, the xpk-libraries or AsyncWB, or AWeb. There will be no MP3 player, no CD-Player, no AVI-Player. It will not come with the mmulib.
This is a bare-bone core operating system, same bare-bone as 3.1 was. If you need further components, you'll find plenty in Aminet. Actually, part of the goal is to leave "distribution building" to third parties, as we have really limited development capacity.
Furthermore, nobody is willing to guarantee you anything in Amigaland, how can we possibly do that? We're doing the best we can, that is all I can promise.
Thus, if you expect a new, fully blown distribution, you are wrong here. All I am going to promise is a bug-fixed release of Os 3.1. It was never announced as anything beyond that.
Thus, if you expect the best invention since deep dishes (as we say in Germany) - no, it's not. But it is the latest, newest and most robust deep dish anyone can possibly sell you. You probably have to fill it yourself, though.
Thom, dont get caught up replying to angst ridden Amiga folks that would slam you for doing the rest of the community a favor. I have always appreciated your explanations and training and any updates will be appreciated by those that use the system.
There will always be trolls and those with troll like behavior who will slam those who offer what is seen by them as a less than perfect solution. Oh well, everyone gets an opinion I suppose.
Thank you any your teammates for all your hard work. I look forward to spending some money on the released product if it is not free. :)
-
Fully agree with her on this! I've learned recently in Amiga land that people can be pure jerks. The A4000 project I have going to remake boards got me a few angry emails because i didnt use eagle to do it, but i am paying to have them professionally done. Show me a professional shop using eagle over Altium or Mentor PADs.
-
Haven't read all 17 pages (seems like a lot of moaning for no reason), but am very much looking forward to an OS3.1 update! The use of larger HD's without patching this or that or using a 3rd party file system is extremely convenient and appealing to me. These days, I prefer to run my Amiga's fairly light to keep things simple, reliable and quick. Love me some 3.1. :)
When I want bloat that cripples the performance of a machine, a million useless so-called "features" I'll never use, or get things done in a convoluted way, I use my modern Mac's. ;)
-
Yes Thomas,
After all the noise quiets down, people will realize what you've done.
Cleaning up 3.1 is a very valid goal.
First there was all the contention over whether Hyperion had the right to do this or not, and now all these additional (non) "issues".
-
I will buy this. I woun't install it, I would copy some libs and commands over OS3.9 equalents.
-
I will buy this. I woun't install it, I would copy some libs and commands over OS3.9 equalents.
Probably the best way to utilize the libraries for a system like yours.
-
I will buy this. I woun't install it, I would copy some libs and commands over OS3.9 equalents.
Just note, however, that there will be no support if you do not install with the provided script, you are then on your own. In particular, a couple of components depend on each other, as provided in the distribution.
Just to give you an idea: There will be a new queue-handler, and pipe-support in the shell. Pipe-support will not work fully with other queue-handlers, for example when aborting a pipeline with ^C.
Support for the new mount-flags such as DirectSCSI will not work if you do not use the file systems that come with the distribution. For example, FAT95 from Aminet will *not* support this flag, but CrossDos will.
Hence, if there are complaints about "xyz is not working!", then the first question will be "Did you install from the disks", and if the answer is "no", then there will be slicence.
So, you are certainly welcome to install as you like, but do not expect that you get help for solving the problems this may cause. We try of course our best to avoid such problems, but it is not always possible.
-
I think the worry that some people will have is that they will be downgrading some components if they install 3.1.4 over 3.9. I'm sure that when the release date nears the proper way to install the upgrade will be made clear.
-
I think the worry that some people will have is that they will be downgrading some components if they install 3.1.4 over 3.9. I'm sure that when the release date nears the proper way to install the upgrade will be made clear.
For me, this update will be going on my modest Amigas (A500, A600, A2000), at least until I'm comfortable with it. The A3000 (with 68060, Picasso graphics, Ethernet, etc.) will continue with OS3.9. It does this OS well. Now that I no longer surf on-line with Amigas, I seem to appreciate the original, less patched and hacked rigs.
At this point, the remaining faithful have acquired (rescued) all the Amigas varieties that they want, right? Are there still people screaming the H word?
Thank you Thomas and Olsen for your hard work. While I still enjoy my A3000, I very much appreciate the direction you are taking this. Your effort feels more official and sober than a "feature only" update.
-
...Are there still people screaming the H word?
H word? Verb, Company, or Name?
-
I think the worry that some people will have is that they will be downgrading some components if they install 3.1.4 over 3.9. I'm sure that when the release date nears the proper way to install the upgrade will be made clear.
I can assure you it is pretty simple to upgrade a 3.9 system with 3.1.4 components. You only need to take care of a few precautions.
-
I can assure you it is pretty simple to upgrade a 3.9 system with 3.1.4 components. You only need to take care of a few precautions.
I'm in. Shut up and take my money :)
-
Fully agree with her on this! I've learned recently in Amiga land that people can be pure jerks. The A4000 project I have going to remake boards got me a few angry emails because i didnt use eagle to do it, but i am paying to have them professionally done. Show me a professional shop using eagle over Altium or Mentor PADs.
I've had similar reactions to my own projects, Paul.
Eagle can't even load the files created by most big companies.
Trying to load the files Freescale/NAP provides for their evaluation boards on anything that low end is pointless, it won't work.
-
I'm in. Shut up and take my money :)
+1 :hammer:
I guess the real world question to this will be, when you say "It doesn't include Reaction, etc." - will it take some steps to remove them from an already configured 3.9 system? Will it overwrite the 3.9 Reaction-based tools with something (arguably) inferior? Etc. Guess we will have to wait and see, eh? ;)
-
I guess the real world question to this will be, when you say "It doesn't include Reaction, etc." - will it take some steps to remove them from an already configured 3.9 system?
No.
Will it overwrite the 3.9 Reaction-based tools with something (arguably) inferior? Etc. Guess we will have to wait and see, eh? ;)
Yes. And Yes. Our prefs are GadTools based.
-
Is it possible to create an OS 3.91 and let it be a replacement for OS 3.9? This could replace all the IP that is not licensed to have.
-
I am all for this 3.1.4 initiative. It is getting harder to get <8Gb CFs or DOMs. So to have that all handled natively will be great. To have info and dir report big sizes correctly would be wonderful. Os3.9 looks great with little work but I like my lean and mean 3.1 as well.
-
Yes. And Yes. Our prefs are GadTools based.
Make a complete backup before running the install script. Got it. :biglaugh:
-
I'm not sure if I saw this explicitly answered. Is it planned that physical Kickstart chips and floppies or just files that we have to burn ourselves? Is there any estimate of when the work will be completed? I know there's basically just the two of you doing all the work and the truest answer is probably "when it's finished" but I was wondering if you had a rough idea in mind.
FWIW I really like the idea of fixing 3.1 vs 3.9. I prefer the clean vs "bulky" and letting me install whatever else I want.
-
I'm not sure if I saw this explicitly answered. Is it planned that physical Kickstart chips and floppies or just files that we have to burn ourselves?
This is a question on the business model. I can really not answer that, I am only doing the software. At this time, it is really not even clear whether there will be ROMs in first place. Testing ROMs and updating ROMs is much harder than just updating software. Is there any estimate of when the work will be completed?
Actually, I was hoping that we would be done already. As far as the number of components is concerned, it is already more than what I had planned initially, which is both good and bad. Good, because there is more progress than planned, bad because there is also more to test. At some point, you must simply say that it is complete enough.
-
I'm to tired to read the entire thread. I just want to ask if this conflicts with OS 3.9? Not that I would live or die with 3.9, I just would prefer not to start all over with a fresh install.
-
I'm to tired to read the entire thread. I just want to ask if this conflicts with OS 3.9? Not that I would live or die with 3.9, I just would prefer not to start all over with a fresh install.
Just read the last page worth of comments, then. They all refer to 3.9. :smack:
-
Now that I have an Amiga system with 4 devices hanging from the IDE port, and rely on IDEFix for them to at all show up - will the OS 3.1.4 scsi.device support 2 IDE channels out of the box, or will IDEFix97 (Or IDEMax??) scsi.device (119.16?) still be needed?
(http://www.amiga.org/forums/picture.php?albumid=215&pictureid=1446)