Amiga.org
Amiga News and Community Announcements => Amiga News and Community Announcements => Amiga Software News => Topic started by: eliyahu on October 13, 2016, 07:00:04 PM
-
via hyperion-entertainment.biz....
Brussels, October 13, 2016
Hyperion Entertainment is pleased to announce the first official Workbench 3.1 and Kickstart 3.1 updates in over twenty years for Classic Amiga systems. The new versions, which have have been re-built from the original source code, include a number of enhancements and bug fixes and are fully compatible with both real Amiga hardware and Classic Amiga emulation software.
Each update can be purchased for only EUR 9.95 (incl. VAT) via the "Buy now!" links on their respective product pages (http://hyperion-entertainment.biz/index.php/where-to-buy/direct-downloads). Buyers of both updates will get a 10% discount!
Workbench 3.1 (v40.43) update for Amiga desktops
(for Amiga 500/600/1200/2000/3000/4000(T) computers and Amiga emulation software)
The Workbench 3.1 (v40.43) images can be written to real Amiga floppy diskettes or used in Amiga emulation software. The changes include:
- Compatibility with A4000T
- Installer fixed to use proper assigns which allows installation from other media in addition to the 6 floppy disk set
Workbench 3.1 (v40.43) is also supplied with a FREE updated licensed copy of Workbench 1.3.3 which incorporates the following changes:
- C/SetClock v34.3 by Olaf Barthel, which fixes Y2K issues and also works on newer Kickstart versions. (Note: the old SetClock command has been renamed and left on disk for reference purposes)
- Deactivated "FF" program in Startup-Sequence to prevent problems on 68020/030 processors
Kickstart 3.1 (40.72) update for Amiga desktops
(for Amiga 500/600/1200/2000/3000/4000(T) computers and Amiga emulation software)
The Kickstart 3.1 (40.72) image is the first test release and can written to EEPROM chips for use in real Amiga computers or used with Amiga emulation software. It contains the following new components:
exec.library 40.12
- Updated copyright information text
- Fixed a small bug in the memory pools code which mirrors the same bug fix in the same code that was used in amiga.lib.
strap 40.3
- Added the Boingball logo which replaces the rainbow-coloured checkmark logo.
- Slightly brighter background colour.
workbench.library 40.6
- Rebuilt with SAS/C 6.59 to free up more ROM space because the copyright text in the updated exec.library. No other functional changes.
scsi.device 40.21 for A600 and A1200
- Small bug fix to the IDE task initialization making it compatible with the A600. (Note: older Kickstart ROMs used scsi.device version 39, because unlike version 40, it did not crash on the A600)
As a special bonus Kickstart 3.1 (v40.72) is supplied with a FREE licensed copy of Kickstart 1.3. For more information visit Hyperion Entertainment (http://www.hyperion-entertainment.biz/index.php/where-to-buy/direct-downloads).
Screenshots
(http://www.hyperion-entertainment.biz/images/stories/kick31prod.jpg)
(http://www.hyperion-entertainment.biz/images/stories/a1200workbench3-real-1610112053-01.png)
-
:hammer:crazy April fools stuff but it's October:) If this just isn't a superficial money grab I'll happily treat my classics to a new WB & kickstart (hmmm though I assume they'll be selling REAL kickstart chips for us REAL classic users)
-
@klx300r
i would have thought so as well, especially since they'd already produced kickstart ROMs in the past (link (http://amigakit.leamancomputing.com/catalog/product_info.php?cPath=40&products_id=157)). so i hope this is just the beginning of future updates to AOS3.1!
-- eliyahu
-
What are features of scsi.device? Does it support larger IDE drives than 128gb? How about FFS, wich version on rom?
Nothing has left out? What is size of rom? 512kb?
-
:hammer:crazy April fools stuff but it's October:) If this just isn't a superficial money grab I'll happily treat my classics to a new WB & kickstart (hmmm though I assume they'll be selling REAL kickstart chips for us REAL classic users)
If you already have 3.1 it' not worth bothering. It's more for people upgrading or using emulation and FPGA based systems.
-
That's some crazy/awesome news. Will have to show some support with my $$$$ once the rom chips are available.
-
Where's the sense in it? Cloanto is providing these ROMs since ages and has provided a few updates. 68k is actively maintained by Cloanto. No need for Hyperion in this domain. Splits the market even further and I doubt it's perfectly legal.
-
Cloanto's version doesn't have workbench.library inside of rom. I makes some problems in certain situations.
With good version of scsi.device and fast file system inside of ROM solves a lots of problems. Think! You could pick ANY ide drive and it just works. No hasling with old and small ide drives, or trying to find bigger drive wich works that much that you can actually install it.
-
Where's the sense in it? Cloanto is providing these ROMs since ages and has provided a few updates. 68k is actively maintained by Cloanto. No need for Hyperion in this domain. Splits the market even further and I doubt it's perfectly legal.
I think it's covered in the settlement with Amiga Inc. They even sub-licensed the source for the IDE driver to Individual Computers.
I don't think the updates from either Hyperion or Cloanto are significant enough to cause any kind of split.
-
Great news but im confused a little. Does the new rom have Both 1.3 and 3.1? Its selectable like a rom switcher?
-
I'm all about supporting 68k development, so I'm buying them.
I would like more details on what is in here though. IDE and SCSI changes especially. FFS version would be nice to know too.
Did the layers.library update make it in?
-
I'm all about supporting 68k development, so I'm buying them.
I would like more details on what is in here though. IDE and SCSI changes especially. FFS version would be nice to know too.
Did the layers.library update make it in?
same here. it sounds like olaf barthel was the one driving this set of updates. i hope he's able to respond to this thread to give us some more background, if there are any additional changes not mentioned in the press release, and if this is a one-off, or if hyperion is planning on making additional updates in the future.
-- eliyahu
-
This is in a text file included with the ROMs. This is from the a500/600, etc version.
Building kickstart 40.72 from BuildList : 22-Feb-16 18:20:18
exec 40.12 @ $F80000-$F8383C Size: 14396 (22.2.2016)
expansion 40.2 @ $F8383C-$F842AC Size: 2672 (9.3.93)
mathieeesingbas 40.4 @ $F842AC-$F85384 Size: 4312 (16.3.93)
graphics 40.24 @ $F85384-$F9E410 Size: 102540 (18.5.93)
dos 40.3 @ $F9E410-$FA801C Size: 39948 (1.4.93)
fs 40.1 @ $FA801C-$FADFBC Size: 24480 (15.2.93)
console 40.2 @ $FADFBC-$FB1C40 Size: 15492 (5.3.93)
layers 40.1 @ $FB1C40-$FB4DF4 Size: 12724 (15.2.93)
a600 40.21 @ $FB4DF4-$FB7850 Size: 10844 (19.4.1998)
con-handler 40.2 @ $FB7850-$FBA014 Size: 10180 (12.5.93)
bootmenu 40.5 @ $FBA014-$FBB624 Size: 5648 (17.3.93)
audio 37.10 @ $FBB624-$FBC6C4 Size: 4256 (26.4.91)
cardres 40.4 @ $FBC6C4-$FBD2A8 Size: 3044 (4.5.93)
utility 40.1 @ $FBD2A8-$FBDDA0 Size: 2808 (10.2.93)
battclock 39.3 @ $FBDDA0-$FBE70C Size: 2412 (20.4.92)
carddisk 40.1 @ $FBE70C-$FBF03C Size: 2352 (12.2.93)
ramdrive 39.35 @ $FBF03C-$FBF630 Size: 1524 (21.5.92)
mathffp 40.1 @ $FBF630-$FBFACC Size: 1180 (16.3.93)
cia 39.1 @ $FBFACC-$FBFEBC Size: 1008 (10.3.92)
battmem 39.2 @ $FBFEBC-$FC00A0 Size: 484 (6.3.92)
potgo 37.4 @ $FC00A0-$FC01D8 Size: 312 (28.1.91)
filesysres 40.1 @ $FC01D8-$FC0378 Size: 416 (15.2.93)
misc 37.1 @ $FC0378-$FC0428 Size: 176 (8.1.91)
disk 37.2 @ $FC0428-$FC0770 Size: 840 (21.4.91)
ramlib 40.2 @ $FC0770-$FC0B94 Size: 1060 (5.3.93)
keymap 40.4 @ $FC0B94-$FC1814 Size: 3200 (12.3.93)
timer 39.4 @ $FC1814-$FC2600 Size: 3564 (29.7.92)
strap 40.3 @ $FC2600-$FC362C Size: 4140 (13.2.2016)
rawinput 40.1 @ $FC362C-$FC4C60 Size: 5684 (8.3.93)
trackdisk 40.1 @ $FC4C60-$FC6968 Size: 7432 (12.3.93)
icon 40.1 @ $FC6968-$FC8D98 Size: 9264 (15.2.93)
ram 39.4 @ $FC8D98-$FCB210 Size: 9336 (9.8.92)
shell 40.2 @ $FCB210-$FCF6F0 Size: 17632 (4.3.93)
intuition 40.85 @ $FCF6F0-$FE9090 Size: 104864 (5.5.93)
gadtools 40.4 @ $FE9090-$FEEC24 Size: 23444 (24.5.93)
wb 40.6 @ $FEEC24-$FFFBF8 Size: 69588 (22.2.2016)
wbtag 39.1 @ $FFFBF8-$FFFCBC Size: 196 (20.4.92)
Build of kickstart 40.72 completed at : 22-Feb-16 18:20:18
-
I'm all about supporting 68k development, so I'm buying them.
I would like more details on what is in here though. IDE and SCSI changes especially. FFS version would be nice to know too.
Did the layers.library update make it in?
you do have changelog right there. not much to read. think twice whom actually to reward for a honest support all these years.
-
This is in a text file included with the ROMs. This is from the a500/600, etc version.
Building kickstart 40.72 from BuildList : 22-Feb-16 18:20:18
exec 40.12 @ $F80000-$F8383C Size: 14396 (22.2.2016)
expansion 40.2 @ $F8383C-$F842AC Size: 2672 (9.3.93)
mathieeesingbas 40.4 @ $F842AC-$F85384 Size: 4312 (16.3.93)
graphics 40.24 @ $F85384-$F9E410 Size: 102540 (18.5.93)
dos 40.3 @ $F9E410-$FA801C Size: 39948 (1.4.93)
fs 40.1 @ $FA801C-$FADFBC Size: 24480 (15.2.93)
console 40.2 @ $FADFBC-$FB1C40 Size: 15492 (5.3.93)
layers 40.1 @ $FB1C40-$FB4DF4 Size: 12724 (15.2.93)
a600 40.21 @ $FB4DF4-$FB7850 Size: 10844 (19.4.1998)
con-handler 40.2 @ $FB7850-$FBA014 Size: 10180 (12.5.93)
bootmenu 40.5 @ $FBA014-$FBB624 Size: 5648 (17.3.93)
audio 37.10 @ $FBB624-$FBC6C4 Size: 4256 (26.4.91)
cardres 40.4 @ $FBC6C4-$FBD2A8 Size: 3044 (4.5.93)
utility 40.1 @ $FBD2A8-$FBDDA0 Size: 2808 (10.2.93)
battclock 39.3 @ $FBDDA0-$FBE70C Size: 2412 (20.4.92)
carddisk 40.1 @ $FBE70C-$FBF03C Size: 2352 (12.2.93)
ramdrive 39.35 @ $FBF03C-$FBF630 Size: 1524 (21.5.92)
mathffp 40.1 @ $FBF630-$FBFACC Size: 1180 (16.3.93)
cia 39.1 @ $FBFACC-$FBFEBC Size: 1008 (10.3.92)
battmem 39.2 @ $FBFEBC-$FC00A0 Size: 484 (6.3.92)
potgo 37.4 @ $FC00A0-$FC01D8 Size: 312 (28.1.91)
filesysres 40.1 @ $FC01D8-$FC0378 Size: 416 (15.2.93)
misc 37.1 @ $FC0378-$FC0428 Size: 176 (8.1.91)
disk 37.2 @ $FC0428-$FC0770 Size: 840 (21.4.91)
ramlib 40.2 @ $FC0770-$FC0B94 Size: 1060 (5.3.93)
keymap 40.4 @ $FC0B94-$FC1814 Size: 3200 (12.3.93)
timer 39.4 @ $FC1814-$FC2600 Size: 3564 (29.7.92)
strap 40.3 @ $FC2600-$FC362C Size: 4140 (13.2.2016)
rawinput 40.1 @ $FC362C-$FC4C60 Size: 5684 (8.3.93)
trackdisk 40.1 @ $FC4C60-$FC6968 Size: 7432 (12.3.93)
icon 40.1 @ $FC6968-$FC8D98 Size: 9264 (15.2.93)
ram 39.4 @ $FC8D98-$FCB210 Size: 9336 (9.8.92)
shell 40.2 @ $FCB210-$FCF6F0 Size: 17632 (4.3.93)
intuition 40.85 @ $FCF6F0-$FE9090 Size: 104864 (5.5.93)
gadtools 40.4 @ $FE9090-$FEEC24 Size: 23444 (24.5.93)
wb 40.6 @ $FEEC24-$FFFBF8 Size: 69588 (22.2.2016)
wbtag 39.1 @ $FFFBF8-$FFFCBC Size: 196 (20.4.92)
Build of kickstart 40.72 completed at : 22-Feb-16 18:20:18
lol..
-
you do have changelog right there. not much to read. think twice whom actually to reward for a honest support all these years.
At this point, I really don't care.
If they want to sell 68k software, I'll give anyone a second chance.
Maybe they will do something with it, if not, I'm no worse off than I was yesterday.
Edit: That said, that's a really weak list of version numbers.
-
I'm all about supporting 68k development, so I'm buying them.
I would like more details on what is in here though. IDE and SCSI changes especially. FFS version would be nice to know too.
Did the layers.library update make it in?
Same here. I didn't expect much based on the press release so it's no big deal to me what was updated. I just want to see some continued development in the 68k 3.x series.
However, I'd be nice if the interest in this generated the desire for them to do a more robust update next.
-
Agreed. Voting with my $$$ on 68k.
I wonder why they sat on this since February and why now?
-
It's a nice gesture, but...
The most important thing that could be done to polish up 3.1 would be 4GB+ support for scsi.device, FFS, and HDToolbox. Other nice things would be additional (http://aminet.net/package/util/dtype/ams) datatypes (http://aminet.net/package/util/dtype/picdt_42_1), additional BOOPSI gadgets (http://aminet.net/package/dev/gui/GI1_led_ic), restoration/update of narrator.device/translator.library/speak-handler/Say, font sensitivity in Prefs editors and other system utilities, and completion of specialfx.library.
I hope we see some more development in the 3.1 line. A SuperKickstart image for 3000s with 1.4 chips would be nice, too.
-
same here. it sounds like olaf barthel was the one driving this set of updates. i hope he's able to respond to this thread to give us some more background, if there are any additional changes not mentioned in the press release, and if this is a one-off, or if hyperion is planning on making additional updates in the future.
-- eliyahu
What we have here is a straight recompile from the last 3.1 sources, so nothing else has been updated and no code from 3.9 has been integrated here. It is just a straight compile of the kickstart sources in the subversion. Some of the fixes here are actually superfluous with 3.9. For example, the bug in the exec memory pools is typically patched over by SetPatch which replaces the rather simplistic pool algorithm in the ROM by a completely different and smarter algorithm. Nevertheless, we have to see whether there will be a follow-up update. I still have a couple of fixes in the drawer, along with the newer shell and the newer layers.
-
That they had to shrink workbench.library only to give space for new copyright text says a lot about their priorities. Anyways, my kickstart says 3.10, the next will be 3.11 for Workgroups, haha :D
-
What we have here is a straight recompile from the last 3.1 sources, so nothing else has been updated and no code from 3.9 has been integrated here. It is just a straight compile of the kickstart sources in the subversion. Some of the fixes here are actually superfluous with 3.9. For example, the bug in the exec memory pools is typically patched over by SetPatch which replaces the rather simplistic pool algorithm in the ROM by a completely different and smarter algorithm. Nevertheless, we have to see whether there will be a follow-up update. I still have a couple of fixes in the drawer, along with the newer shell and the newer layers.
I am wondering why didn´t Olaf Barthel include the already available 68k binaries that Hyperion had developed for OS4. There are a lot of components of AmigaOS 3.1 which could have been updated this way:
cpu 50.4 (that can detect 68060 and ppc processors)
iconedit 44.20 (that can edit glowicons)
playcd 50.5 (that can access cd databases online to identify discs)
ContextMenus 51.3 (a kind of non blocking configurable magicmenu clone)
Atapiismajik 52.1 (a kind of idefix97 clone)
And of course there are, between other things a couple of math libraries and scsi.devices that could have been pretty usefull.
So why didnt he include them if they are already compiled, tested, released, and property of Hyperion?
-
Updated scsi.device and fastfilesystem is not only "useful", but rather crucial. Without that I don't see the point of this "update" at all, other than Hyperion going toe-to-toe with Cloanto over "who has copyrights".
-
Updated scsi.device and fastfilesystem is not only "useful", but rather crucial. Without that I don't see the point of this "update" at all, other than Hyperion going toe-to-toe with Cloanto over "who has copyrights".
We are currently enjoying some wonderful developments on the Amiga scene, both hardware and software. It saddens me that were not talking to each other. Vampire will ship with a whole host of features that "could" be supported in new ROMs . There are new motherboards on the horizon from Jens and Apollo Team and other options (FPGA Arcade + friends) .
We also have A-Eon taking a different direction with the PPC Boards.
Wouldnt it be great if we could unify all these developments that eliminated the worry about finding hard to find parts both custom chips (can be implemented in FPGA) or other components (replace a1200 edge connectors with something future proof).
Will A1200 reloaded and Vampire/Alone Standalone share common i/o interfaces? - historically the likelihood is not. Its time to realise that strength is in collaboration.
-
Shouldn't Hyperion be spending their time finishing OS4 instead of things like this? And I thought it was settled that Cloanto had OS3 and Hyperion had OS4. Does anyone really want to go through another round of Hyperion getting into another pissing match? Leave this stuff alone and finish the work you should have finished a decade ago!
-
That they had to shrink workbench.library only to give space for new copyright text says a lot about their priorities.
You make this sound less weird than it actually is ;)
The copyright text had to be updated, but due to how the Kickstart ROM layout works out, this required changes in the fixed-size area of the ROM which precedes the exec coldstart code. The copyright text sits within what's called the "manufacturing pattern" area, which is quite clever because it's right at the beginning of the ROM. There is just enough room for the copyright text, too.
Now there's a problem: the new copyright text was a bit longer than the old one, and it would no longer fit into the "manufacturing pattern" area. My solution to this problem was to place it in the coldstart code, with a branch instruction skipping over the text.
Well, that was some kludgy hack work, if I say so myself, but my troubles were only beginning...
This change made the exec module a bit larger because the copyright text now used up space which was not needed before. The consequence of this being that the A1200 ROM no longer had enough space left for everything to fit into it.
This is why there is a "workbench.library" in the ROM which was rebuilt using SAS/C 6.59 rather than Lattice 'C' 5.04, which was used in the original 1993/1994 build. The SAS/C version is quite a bit smaller than the Lattice 'C' version, and everything would fit.
Anyways, my kickstart says 3.10, the next will be 3.11 for Workgroups, haha :D
I'm still very much in favour of the TeX and Metafont version number schemes. Kickstart 3.1 is closer to Pi than to e, so maybe we're going to get Kickstart/Workbench 3.14, followed by 3.141, then 3.1415, etc.
-
same here. it sounds like olaf barthel was the one driving this set of updates. i hope he's able to respond to this thread to give us some more background, if there are any additional changes not mentioned in the press release, and if this is a one-off, or if hyperion is planning on making additional updates in the future.
-- eliyahu
From what gunnar said in public he negotiated with Hyperion and the answer was very honest that they are not interested in 68k. So either they changed mind since that or they just want to make some easy money without investing to much efforts in it. Before I do not see anything different I would bet on the second.
-
From what gunnar said in public he negotiated with Hyperion and the answer was very honest that they are not interested in 68k. So either they changed mind since that or they just want to make some easy money without investing to much efforts in it. Before I do not see anything different I would bet on the second.
I do not often comment on issues such as these, because there's enough trouble either way if you say something. Not saying anything proved to be less troublesome.
So anyway... I would like to add that business negotiations do break down for any number of reasons, and the parties involved are usually very reluctant to explain in public as to what went wrong. This in itself is a tactical decision.
Sometimes negotiation tactics fail because the negotiating parties are unable to make their respective points and find common ground.
The short term tactics may have no direct relation to long term strategy.
This is "normal" in this business, in any business.
Things change, and the change is not a indication of poor performance or lack of confidence on the side of any party involved.
-
I do not often comment on issues such as these, because there's enough trouble either way if you say something. Not saying anything proved to be less troublesome.
So anyway... I would like to add that business negotiations do break down for any number of reasons, and the parties involved are usually very reluctant to explain in public as to what went wrong. This in itself is a tactical decision.
Sometimes negotiation tactics fail because the negotiating parties are unable to make their respective points and find common ground.
The short term tactics may have no direct relation to long term strategy.
This is "normal" in this business, in any business.
Things change, and the change is not a indication of poor performance or lack of confidence on the side of any party involved.
I am not sure what you are wanting to say without saying it (almost politician like)
they want to make some quick bucks in "classic market" because they see that there is movement at the moment, jump the train so to say. But if Gunnars comments are not totally wrong there is no interest in really investing in this market, for them the "classic users" obviously always were a resource for potential 4.X buyers, not a real market on its own. I doubt that this suddenly has changed. If they are really offering new software and improvements they can proof me wrong. For a start they could lift artifical ram limitations on "4.X for classics" that causes problems on UAE. By that they would show signs of customer orientation. Until that I do not believe that. Here some start to become euphoric and buy to "support development". For such a conclusion it is much too early.
-
Things change, and the change is not a indication of poor performance or lack of confidence on the side of any party involved.
Wearing my decoder ring I am choosing to interpret this as "We see there may be a decent market for OS 3.1 updates after all."
Could you elaborate on any future plans for this new 3.1 distribution? Is this a one-shot release? Is there any sort of roadmap? Are you testing the waters for demand before making that decision?
I also don't see the issue with any "conflict of interests" with Hyperion maintaining both OS3.1 and OS4.x distributions. The OS 4.x camp (which is basically A-EON) is creating OS3 software so surely they would be happy to see OS 3.1 updates.
Myself I have feet in both camps, owning both classic and PPC systems. Very happy to see updates on both.
-
Things change, and the change is not a indication of poor performance or lack of confidence on the side of any party involved.
Wearing my decoder ring I am choosing to interpret this as "We see there may be a decent market for OS 3.1 updates after all."
Could you elaborate on any future plans for this new 3.1 distribution? Is this a one-shot release? Is there any sort of roadmap? Are you testing the waters for demand before making that decision?
I also don't see the issue with any "conflict of interests" with Hyperion maintaining both OS3.1 and OS4.x distributions. Myself I have feet in both camps, owning both classic and PPC systems. Very happy to see updates on both. After all, Hyperion is in the business of selling software, so go where the demand is. :)
-
Wearing my decoder ring I am choosing to interpret this as "We see there may be a decent market for OS 3.1 updates after all."
Could you elaborate on any future plans for this new 3.1 distribution? Is this a one-shot release? Is there any sort of roadmap? Are you testing the waters for demand before making that decision?
I also don't see the issue with any "conflict of interests" with Hyperion maintaining both OS3.1 and OS4.x distributions. Myself I have feet in both camps, owning both classic and PPC systems. Very happy to see updates on both. After all, Hyperion is in the business of selling software, so go where the demand is. :)
if that is true why do they not make "AmigaOS for Classic" more useful to their existing users (mostly use it on UAE i would guess). They even have the patch to do that.
-
Well done, supplying new 68k software is great.
Maybe this is just the first step in a series of 68k software updates.
-
What the deuce? :huh:
-
So this is Hyperion's Halloween trick, rather than treat, right? :lol:
-
Could you elaborate on any future plans for this new 3.1 distribution? Is this a one-shot release? Is there any sort of roadmap? Are you testing the waters for demand before making that decision?
shouldnt we wait till after the roadmap dor os4 is actually delivered, which subject is open since a decade at least? do you really need to think there is some master plan, a strategy, behind this release, other than just a tactical opportunity? follow the occams instead to create theories beyond necessity, and your life will be easier. in this case buy the rom if it offers functionality you currently need, but dont buy it upon assumption about what you imagine your purchase might led to eventually one day.
-
At this point, I really don't care.
If they want to sell 68k software, I'll give anyone a second chance.
Maybe they will do something with it, if not, I'm no worse off than I was yesterday.
Edit: That said, that's a really weak list of version numbers.
+1
-
From what gunnar said in public he negotiated with Hyperion and the answer was very honest that they are not interested in 68k. So either they changed mind since that or they just want to make some easy money without investing to much efforts in it. Before I do not see anything different I would bet on the second.
This was a long phone conference, and it's not that simple to summarize it in a single sentence. I was not participating, but I also talked to Hyperion later on to see what was the issue.
Part of the problem on the Hyperion side was also that Gunnar wanted to get control on the Kickstart and wanted to include there custom modules or patches for his particular hardware. You should also know that a vendor does not easily give away control over his assets, and that this request was also quite unnecessary as the Kickstart has enough options to address custom hardware such as autoconfig that is known since ever. Gunnar's approach is not a wise decision from a software engineering approach, and while I do not agree with much Hyperion does, I at least agree with that keeping the Kickstart sources free of custom patches for third-party hardware.
So every story has to sides, and at that point of time, the two parties did not come together, not due to the fault of a single party alone. Partially because Hyperion did not yet fully understand what they were really seeing and which market chances they were missing, partially because Gunnar was also expecting too much from such a deal. The story is a bit longer than simply "they had no interest in 68K".
This does not mean that the story ended there. We're just observing that it is going on. There are still, as said, a couple of improvements in the drawer, and I really hope I find the time to put a couple of my contributions back to where they belong. It's just that JPEG keeps me very busy these days - just being at another meeting in Chengdu, China, BTW.
-
I am not sure what you are wanting to say without saying it (almost politician like)
Ouch - I was trying for "diplomat".
In the past 25 years we all saw great plans and eagerly awaited announcements which came to nothing. At times I resented the grandstanding, later I learned that this is how business is conducted in a high risk market. The Amiga certainly qualified for that term.
We tend to view the ambitions and the failure to deliver on them as dishonest, as display of incompetence, if not outright malicious intent. It's the easiest explanation, I suppose. The more uncomfortable explanation is that the ambition and dedication is real, it's just that in the Amiga market it takes very little to make a big impact, and also very little to derail even modest efforts. This is the nature of this business: it's very volatile.
Big changes happened in the 68k hardware field very recently which could help to boost operating system development work, beause there is now a genuine foundation to build upon: somebody might actually pay for that work to be done, and the requirements of the hardware could drive operating system development.
I believe we may have crossed an important threshold.
-
Nevertheless, we have to see whether there will be a follow-up update. I still have a couple of fixes in the drawer, along with the newer shell and the newer layers.
Updates confirmed by SSolie here " http://amigaworld.net/modules/newbb/viewtopic.php?mode=viewtopic&topic_id=41399&forum=27&start=60&viewmode=flat&order=0 "
-
Edit: That said, that's a really weak list of version numbers.
+2
Without really digging into it, I don't really see how this would be of any use to someone already running a fully patched 3.9. But I suspect I'm not their target market. Thoughts?
-
The big advantage for a 3000 user will be the scsi device update (assuming it is on the rom).
Getting a new drive working in a 3000 with the stock controller is a challenge.
I can see this saving time and energy, you can start a new install of 3.9 without using another system to configure the drive ahead of time.
That would be my thought.
+2
Without really digging into it, I don't really see how this would be of any use to someone already running a fully patched 3.9. But I suspect I'm not their target market. Thoughts?
-
The big advantage for a 3000 user will be the scsi device update (assuming it is on the rom).
Getting a new drive working in a 3000 with the stock controller is a challenge.
I can see this saving time and energy, you can start a new install of 3.9 without using another system to configure the drive ahead of time.
That would be my thought.
I don't see any indication that this is the case, although I could be wrong.
It seems to be 99% copyright notice and availability.
I'm still holding out hope that this is just getting the process started and not just fulfilling some legal requirement to hold onto the license or something of that nature.
-
Matt: i have installed 3.1 on amiga 3000s no problem... also 2.04. default install disks work fine no need for another computer.
-
@Olsen
IFAIK 6.58 was the last 68k sas/c is there a 6.59? What are the difference between the two?
https://www.warped.com/amiga/
Kamelito
-
@Olsen
IFAIK 6.58 was the last 68k sas/c is there a 6.59? What are the difference between the two?
Really nothing substantial. The 6.59 had some very preliminary support for PPC binaries, or rather the binary format around it. The code generator is exactly the same, and the bugs are also exactly the same. In essence, it also only supports 68K, and it doesn't generate any better code. Thus, for the very purpose of this update, the 6.58 and 6.59 are exactly the same.
-
Really nothing substantial. The 6.59 had some very preliminary support for PPC binaries, or rather the binary format around it. The code generator is exactly the same, and the bugs are also exactly the same. In essence, it also only supports 68K, and it doesn't generate any better code. Thus, for the very purpose of this update, the 6.58 and 6.59 are exactly the same.
It would have been great to have the SAS/C toolchain source code and all bought by some Amiga company. Parts that are licenced could have been rewritten.
Kamelito
-
Matt: i have installed 3.1 on amiga 3000s no problem... also 2.04. default install disks work fine no need for another computer.
Hey Magnetic,
I have installed large ssd via adapter and large scsi drive that can't be recognized or use large partitions on the old scsi.device over the years. I would think that the new scsi device would aid in large disk partitioning at least. Have you been able to set large partitions booting on a stock install?
-
It would have been great to have the SAS/C toolchain source code and all bought by some Amiga company. Parts that are licenced could have been rewritten.
Kamelito
Well, wishful thinking. The first question is whether Steve Krueger (right?) is still reachable. The second question is whether anyone at SAS institute (or Steve) actually still *have* the source. Last but not least, whether they are willing to give the sources out.
Given how big companies like SAS operate, this requires a lot of decision makers to make decisions on products they do not know. If you ask me, these are a lot of "if's", and chances are pretty slim.
-
+2
Without really digging into it, I don't really see how this would be of any use to someone already running a fully patched 3.9. But I suspect I'm not their target market. Thoughts?
This was intended to be a robust Kickstart/Workbench 3.1 version which would correct as many defects as possible while at the same time minimizing the possible negative impact of the changes on existing software and hardware solutions.
These are quite strict constraints, which unfortunately result in this somewhat lackluster list of changes. This is the kind of small scope upgrade Commodore could have made back in 1994, if it had been possible.
If you are running a fully upgraded AmigaOS 3.9 system, then the changes made in this updated Kickstart/Workbench combination are not needed because the scsi.device and SetPatch you already have installed take care of the problems which the Kickstart/Workbench update address.
-
It would have been great to have the SAS/C toolchain source code and all bought by some Amiga company.
Amen to that.
However, SAS Institute is a really, really big shop. One would have to be very lucky to find the right person to ask about this legacy product, and maybe the same amount of luck to convince the company to part with the material. It does not seem to be relevant to the company's core business.
SAS Institute bought Lattice, Inc. in the late 1980'ies because their compiler technology allowed for the SAS stochastic analysis platform to be ported more easily to more computer/hardware platforms.
The Amiga compiler did benefit from this greatly, but it sold very poorly (especially compared to the other SAS Institute products).
Well, you never know... Let's make a wish :)
-
The big advantage for a 3000 user will be the scsi device update (assuming it is on the rom).
Getting a new drive working in a 3000 with the stock controller is a challenge.
I can see this saving time and energy, you can start a new install of 3.9 without using another system to configure the drive ahead of time.
That would be my thought.
The scsi.device in this updated Kickstart 3.1 ROM is still version 40, not version 43, which sports large disk support and a multitude of enhancements and bug fixes.
The problem with scsi.device V43 and, for that matter, FastFileSystem V43 is that they are both significantly larger than the V40 versions. Hence, if you put the V43 versions into ROM, you would have to take something out of the ROM.
While this is technically feasible (see the A4000T ROM, which has special support code in it that will find and use the "workbench.library" located on any currently mounted volume, if the library cannot be found in "LIBS:"), it was important for this updated Kickstart 3.1 ROM set to contain all components which the 1994 ROM versions would.
-
@olsen
for what i know there are simple solutions for 1mb kickstart on amiga. i dont remember technical details though. ít could be googled i guess.
but how it stands, the kickstarts here being simply images not actual roms, the 512k limit doesnt apply anyway, since winuae and fs-uae can take advantage of split images, and so far i know even some aca accelerators can be fed with 1mb kickstart replacements.
-
@olsen
for what i know there are simple solutions for 1mb kickstart on amiga. i dont remember technical details though. ít could be googled i guess.
but how it stands, the kickstarts here being simply images not actual roms, the 512k limit doesnt apply anyway, since winuae and fs-uae can take advantage of split images, and so far i know even some aca accelerators can be fed with 1mb kickstart replacements.
The updated Kickstart ROM image was intended to be a replacement for actual hardware ROMs, which limits further what could be done about its contents without rocking the boat.
Once it's in a physical ROM (or rather something in the same package as the ROM; they don't make the kind of ROMs any more which were used in the 1980'ies and 1990'ies) any bugs (or "unintended side-effects") will be doubly embarrassing.
That said, flash ROM-based solutions which allow great flexibility have been available for a long time. This is what might be a possible target for a follow-up to this Kickstart 3.1 release.
-
Can someone please clear this up once and for all?
Who the hell owns the 68k OS?
Commodore?
Amiga Inc?
Cloanto?
Hyperion?
-
Can someone please clear this up once and for all?
Who the hell owns the 68k OS?
Commodore?
Amiga Inc?
Cloanto?
Hyperion?
Commodore - Doesn't exist except as a trademark.
Amiga Inc - Probably never owned anything except a trademark, but as a settlement in lawsuits brought by Hyperion has granted a license to Hyperion for the exclusive right to continue to develop operating systems from OS3.1.
Cloanto - Former licensee of the software, continued distribute its software after dissolution of original licensor, which as of late has made multiple arrangements with various parties to strengthen its claim to ownership.
Hyperion - See Amiga Inc.
So what's confusing? ;)
That the Amiga curse taints everything like a wish granted by a cursed money's fist? ;)
-
The scsi.device in this updated Kickstart 3.1 ROM is still version 40, not version 43, which sports large disk support and a multitude of enhancements and bug fixes.
The problem with scsi.device V43 and, for that matter, FastFileSystem V43 is that they are both significantly larger than the V40 versions. Hence, if you put the V43 versions into ROM, you would have to take something out of the ROM.
While this is technically feasible (see the A4000T ROM, which has special support code in it that will find and use the "workbench.library" located on any currently mounted volume, if the library cannot be found in "LIBS:"), it was important for this updated Kickstart 3.1 ROM set to contain all components which the 1994 ROM versions would.
Instead of putting in v43 scsi.device/FFS, could 64bit support be added to a new revision of v40? i.e., what I'm wondering with this line of inquiry is whether present day coding/compiling methods could achieve 64bit functionality in a smaller package than the ~1999 v43. Doesn't v43 also have all that NSD stuff (that I never really understood)? I would imagine that uses up some space and wouldn't be necessary for 3.1.
-
Instead of putting in v43 scsi.device/FFS, could 64bit support be added to a new revision of v40? i.e., what I'm wondering with this line of inquiry is whether present day coding/compiling methods could achieve 64bit functionality in a smaller package than the ~1999 v43. Doesn't v43 also have all that NSD stuff (that I never really understood)? I would imagine that uses up some space and wouldn't be necessary for 3.1.
It should be possible to add 64 bit support to the V40 version of scsi.device and the FFS, but then again, it has been done already as well as it could be done. In my book, if Heinz Wrobel rose the challenge, the job is done and need not be tackled again. Possibly for the next few decades.
Both scsi.device and the FFS are written entirely in hand-crafted assembly language (with the exception of the Fast SCSI variant of scsi.device, which contains 'C' code and firmware bytecode for the SCSI microcontroller). This is, in my opinion, some of the most complex code in the entire Amiga operating system. And it was originally written by Randell Jesup, to whom I ever so humbly doff my cap. I forgot: the FFS and scsi.device are built on top of code written by Steve Beats.
While retrofitting 64 bit support is clearly possible, it's a really challenging task. Arguably, FFS may be easier to upgrade, but the real challenge is in making scsi.device work. Not only do you have to safely support the 64 bit I/O command set (NSD), you also have to support the gaggle of different hardware platforms which scsi.device works with.
The scsi.device still contains code to support ST and XT devices (as commonly used in 1987/1988 such as in the A590; I think this code is "dormant", though), the WD SCSI hardware (A590, A3000, etc.), the IDE hardware in the A1200, A4000 and A4000T, as well as the LSI Fast SCSI hardware used by the A4000T. The V43 scsi.device upgraded the ATA support as well as the Fast SCSI support, which along with the 64 bit I/O support accounts for the increased size of the driver binary.
If you ask me (well, you did ask me, didn't you?), this is the kind of code I'd rather find an excellent excuse not to modify. That level of complexity takes a very special kind of person to approach it. I had my brush with glory at this level of complexity with the FFS reimplementation which is part of AmigaOS4 and MorphOS. While the driving force behind this project was my own curiousity, I would not want to repeat the exercise. In particular not if the exercise involves writing faultless 68000 assembly language. This screams to me "run away!", in Graham Chapman's voice ;)
Bottom line is, I believe that the V43 scsi.device and FFS are the best possible solutions for the problem at hand, although they create problems with ROM space.
-
@ olsen
Wow, thanks for that answer. I had no idea it was that complicated. I suppose v43 would still be too large even with some of the compiler trickery you used on other components of this release?
[edit] Actually, now that I think about it, and if I'm remembering correctly, didn't the different version numbers of the original 3.1 (40.63/68/70) have to do with bugs/problems with scsi.device depending on platform? Now I see why! [/edit]
Looks like we need to start moving to 1MB ROMs across the board :) (although I know that means additional hardware/mods will be required...)
-
Since assembly based modules are not really going to get smaller, what about shrinking more of the C based modules by using the new compiler?
The new layers.library for example was a backport from OS4 changes if I'm not mistaken, so would probably be C.
I would assume that there would be a few like that.
-
@ olsen
Wow, thanks for that answer. I had no idea it was that complicated.
Others may have a different point of view on the subject of rewriting scsi.device and the FFS. My personal opinion of assembly language at this scale and at this level of complexity is that I would rather write this in 'C', if possible. Alas, this is not an option here.
I suppose v43 would still be too large even with some of the compiler trickery you used on other components of this release?
I honestly have not checked this yet, but there there is room for experimentation: the boot menu (which appears when you hold down both mouse buttons during the system startup), the con-handler (which implements the CON: device), gadtools.library, icon.library, layers.library, ram-handler (which, as the name says, implements the RAM: device) and the ROM shell are written almost entirely in 'C' and would most certainly shrink when rebuilt using SAS/C.
There is something of a catch, though. Commodore chose not to use SAS/C 6 back in 1993/1994 because it was felt that the code generation was not yet sufficiently mature for ROM code. While SAS/C kept maturing after Commodore had collapsed, it was never used on a larger scale for a production ROM build. The 'C' language portion of the A4000T (and A4091) scsi.device was built using SAS/C 6, but it was the exception.
I am not that knowledgeable about the quality of the code generated, and the bugs that might still be present in it. This means that additional testing would be required before more ROM components could be rebuilt with SAS/C 6.59, falling back onto the original SAS/C 5.04 compiler where needed.
[edit] Actually, now that I think about it, and if I'm remembering correctly, didn't the different version numbers of the original 3.1 (40.63/68/70) have to do with bugs/problems with scsi.device depending on platform? Now I see why! [/edit]
The A3000 build of scsi.device did cause problems in Kickstart 40.70 for some SCSI devices, if I remember correctly. This is why (and which is where I learned about it) Village Tronic went back to the Kickstart 40.68 ROM for the A3000 and A3000T.
What exactly did not work properly was very difficult to tell, because the code change history of scsi.device between versions 40.63 and 40.70 is incomplete. These were among the last changes made to the operation system before Commodore eventually shut down in April 1994. Heinz Wrobel told me that these issues had been successfully resolved in scsi.device V43, which he had prepared.
-
One does note the lack of any 68060 handling.
Notwithstanding a library(s) at SetPatch time, that would be (at my count/understanding) 11 instructions more.
Kudos for making more options available.
Funnily enough I think what frustrates "hobby-hackers" like myself is that the OS is simple and clear enough to understand so that we feel like we could contribute to the improvement of it, but there is no-one to talk to about it and there isn't anything being produced anyway. (Though from time to time you see the odd the odd "vigilante" slogging through the battle alone and produce something.)
-
@Olsen
Thank you for describing so elaborate how the closed source model doesn't work :)
-
@olsen
Aros has a corresponding device weitten in c. I think its called ata.device. However there is some finetuning actually causing problems. Like it isnt working dependably with the internal a4k ide. You might take look if you need (i guess not) the sources are open, no nda..
-
@Olsen
Thank you for describing so elaborate how the closed source model doesn't work :)
And yet the two most popular NG OS' are closed source, while AROS is a distant third.
And Windows and OSX dominate the desktop market while Linux systems are a single digit percentage of the market (and that estimate is being kind).
Its simple economics, professional programmers need to earn a living, there is no profit in open software to generate an income to pay the programmers.
Open software is free, but you get what you pay for.
Which explains why when I recently needed to uses a spreadsheet, even though I already had Open Office on my system, I paid for an Office365 license so I could have access to Excel.
It's just a better program than its equivalent in OO.
-
Bought both 17,91 euros that is bargain.
A600 and A1200 can use 1mb rom without any modification.
-
@Olsen
Thank you for describing so elaborate how the closed source model doesn't work :)
Could be... but it's hard to tell which contributes more to the somewhat disfunctional state of the art: the lack of development process, the lack of contributors, the use of a very old toolchain, the use 68000 language in complex subsystems, the need to remain backwards compatible with any changes made, the lack of documentation for ancient hardware, the age of the target platform itself.
Fix any two of these issues and you might just find that the others remain as stubbornly intractable as before :(
-
Could be... but it's hard to tell which contributes more to the somewhat disfunctional state of the art: the lack of development process, the lack of contributors, the use of a very old toolchain, the use 68000 language in complex subsystems, the need to remain backwards compatible with any changes made, the lack of documentation for ancient hardware, the age of the target platform itself.
Fix any two of these issues and you might just find that the others remain as stubbornly intractable as before :(
Could all be solved i guess, but it would involve opening the sources, collaboration with the community and perhaps involving some aros solutions like up to date compilers and unified build system. i suspect some years ago you could have some valuable contributors like that. The problem is the uncertaim legal situation of software in question. And of course the will of some parties to be rewarded upon just everything like sole posession of licenses, copyright notices and some minor fixes. This attitude and any notable development is imho mutually exclusive. Wehave to be aware of this.
-
solutions like up to date compilers and unified build system.
You might be astonished how much AmigaOs depends on the nature of the compilers and assemblers. It is a very non-trivial task to port this to any different compiler. For example, many parts of the sources compile with the SAS/C, but some shabby areas (especially graphics) require the even older lattice compiler because nobody dared to touch the sources and fix them up. The build process is really very delicate. On the good part, you no longer depend on ancient hardware. The whole build process works now fully automatic on the Unix command line, using the ancient compiler tools.
-
You want a REAL challenge?
Take the OS apart a rebuild it using assembly code scrapping the C components and reduce its overall size while improving its performance.
Before anyone says it can't or shouldn't be done, let me explain my logic.
In the '80's and '90s I was using Microware's OS-9 operating system for 68K based commercial and industrial applications.
Microware was promoting CDi and porting its OS to other platforms using C (the 68K version of OS-9 being written virtually entirely with assembly code).
They called this variant OS9000, and as their products evolved, they tried to simplify the naming of all OS' to OS-9 and use the C based code for all versions including the 68K fork.
In the long run, the customers asked for the original version to continue to be developed because it was faster, more efficient and more compact.
No matter what anyone tells you about C, tighter code can be generated by more direct means.
It just takes a lot more work and it isn't portable.
You want retro?
Go full retro, and re-write 3.1 to be tighter, faster and more efficient.
THEN you'll also have the room needed for the improvements you've been discussing.
The only reason this probably can't be done?
Lack of programmer competency.
-
You want a REAL challenge?
No, I want a solution. That requires being pragmatic.
-
You might be astonished how much AmigaOs depends on the nature of the compilers and assemblers. It is a very non-trivial task to port this to any different compiler. For example, many parts of the sources compile with the SAS/C, but some shabby areas (especially graphics) require the even older lattice compiler because nobody dared to touch the sources and fix them up. The build process is really very delicate. On the good part, you no longer depend on ancient hardware. The whole build process works now fully automatic on the Unix command line, using the ancient compiler tools.
thomas, look, idont want to show off, but last week i have made the source of fryingpan compile for 68k target with gcc 6.1.0 with paranoia setting from within aros source tree. i have only received one hint from toni what concerns asm syntax. and while the work isnt finished, i need to debug some issues (luckily aros has gdb, so at least i get some hints as to where to look), i must insist that im a complete ignorant what concerns programming in whichever aspect. so, if a noob can do that kind of work, just because he wants to contribute, a professional with years of experience may well fix something more complicated.
-
No, I want a solution. That requires being pragmatic.
It IS a real solution, you just don't have programmers with enough talent enough to pull it off.
Then again, I'm not sure there is anyone that can still code at this level.
BUT, the ONLY realistic way you are going to shrink the existing code IS to replace the C coded portions of the OS.
-
omg.. there it goes again.
-
The only reason this probably can't be done?
Lack of programmer competency.
You do realize that when you insult the few people interested in doing anything in this space, the less likely they will retain their interest? We already have extremely competent people sacrificing what free time they have - you know after their real jobs that pay their bills, family, education and everything else. The only compensation they get is our thanks. When people stop appreciating what they are able to give us, what reason is there for them to continue? Would you work for free for some ungrateful person who does nothing but insult you, contributes nothing themselves, but continues to demand you do more and to do that more to their personal specifications regardless of the obstacles?
You ungrateful person. Assuming that you are a productive member of society and not the typical, modern, "gimme dat" American (judging from your attitudes and behavior probably not a good assumption), why don't you get off your lazy butt and actually contribute something yourself? Or are you one of "those who can't, criticize those who can"?
Why don't you try to find a few minutes in a busy day to find sources, decipher undocumented code, code that has multiple dependencies on other seemingly unrelated undocumented code, work with hardware that is insufficiently documented itself, try to figure out why someone 30 years ago chose to put THAT command THERE - a place it doesn't make sense for it to be but it is because of some quirk of the hardware or other modules of the software - someone who might be dead and can't explain the reason, and then rewrite it, still trying to maintain it within the extremely limited resources of the hardware. Do you have any concept of how MUCH needs to be in Kickstart and in only 512K? If you think this simplified description of what olsen, Thomas and others have to deal with is overstating the situation, read the experience of the people who rewrote the console.
These people are doing this out of love for the platform and the community. If the community, with people like you, stops appreciating them, goes out of their way to insult them, I would completely understand why they would stop spending their precious time and expertise and go elsewhere. Heck, with ungrateful, rude, crass, offensive jerks like you contributing nothing but bile, I'd go so far as to ENCOURAGE them to leave and let you to fester in your own crap.
Grow up. Act like an adult or go away. Nobody needs or wants your tantrums.
-
thomas, look, idont want to show off, but last week i have made the source of fryingpan compile for 68k target with gcc 6.1.0 with paranoia setting from within aros source tree. i have only received one hint from toni what concerns asm syntax. and while the work isnt finished, i need to debug some issues (luckily aros has gdb, so at least i get some hints as to where to look), i must insist that im a complete ignorant what concerns programming in whichever aspect. so, if a noob can do that kind of work, just because he wants to contribute, a professional with years of experience may well fix something more complicated.
You brag about what you did but by your own admission it is incomplete. Wow! I didn't know that people were supposed to brag until there was some to actually brag about - you know actually completing something.
-
And before anyone asks, I don't have the skills to contribute code. I'm a user, not a programmer unfortunately. My contribution is grateful appreciation and, when asked for, money.
-
And yet the two most popular NG OS' are closed source, while AROS is a distant third.
Do you have numbers to back up this claim?
I am pretty confident that the largest Amiga platforms are WinUAE, FS-UAE and uae4arm - all of which are open source. WinUAE and FS-UAE also come with AROS kickstart built in, who knows how many people out there use that kickstart without even knowing they are using AROS.
And Windows and OSX dominate the desktop market while Linux systems are a single digit percentage of the market (and that estimate is being kind).
You just "forget" to mention how open source fuel both those operating systems, and macOS in particular. If there had not been any BSD licensed software around, there would have been no OSX to talk of, and Windows wouldn't have had a TCP stack for many, many more years.
All Amiga TCP stacks are also based on open source.
Its simple economics, professional programmers need to earn a living, there is no profit in open software to generate an income to pay the programmers.
No profit in open source software, huh? You better tell all those companies that base their existence on open source software then, the companies that keep the Internet running, that provide us with platforms for all the apps people are using these days, that keeps this very site up and running, the made Facebook, Google, Amazon etc possible. No profit, huh?
Open software is free, but you get what you pay for.
Which explains why when I recently needed to uses a spreadsheet, even though I already had Open Office on my system, I paid for an Office365 license so I could have access to Excel. It's just a better program than its equivalent in OO.
Irrelevant anecdotal nonsense. To outweigh your experiences, I can tell you that I find MSOffice and OO both equally braindead and annoying to use. However, there are plenty of options that are much more convenient to use these days.
-
@thread
we've been able to keep this thread civil so far, and i want it to stay that way. refrain from insulting other members, and keep the AROS off-topic stuff out of this thread. i don't want to have to moderate this topic, so please knock it off now. thanks.
-- eliyahu
-
You brag about what you did but by your own admission it is incomplete. Wow! I didn't know that people were supposed to brag until there was some to actually brag about - you know actually completing something.
Wow, you should read to yourself what you wrote to Iggy just above, about insulting those who actually contribute. Wawrzon is doing plenty to contribute, give him your money.
-
Wow, you should read to yourself what you wrote to Iggy just above, about insulting those who actually contribute. Wawrzon is doing plenty to contribute, give him your money.
I'm not insulted, its just a difference of opinion.
And since the market supports MY opinions, why should I care that another open source enthusiast doesn't understand basic economics?
I needed Excel, no alternatives came close, I'm glad I bought it.
I KNOW what my requirement were, so his opinions aren't relevant.
Although, OSX is SO much better than Open BSD, and they regularly feed developments back to the OpenBSD community.
Further, if NextStep hadn't been built on that, it could have easily been based on something else.
Proprietary software IS better than open software.
Its just a fact, one that he apparently can't deal with.
But since the public has spoken with its funding, its irrefutable.
-
I'm not insulted, its just a difference of opinion.
And since the market supports MY opinions, why should I care that another open source enthusiast doesn't understand basic economics?
I needed Excel, no alternatives came close, I'm glad I bought it.
I KNOW what my requirement were, so his opinions aren't relevant.
Although, OSX is SO much better than Open BSD, and they regularly feed developments back to the OpenBSD community.
Further, if NextStep hadn't been built on that, it could have easily been based on something else.
Proprietary software IS better than open software.
Its just a fact, one that he apparently can't deal with.
But since the public has spoken with its funding, its irrefutable.
Um, I haven't said one word about open / closed source at all. I responded to you calling people in a difficult situation incompetent and kolla bragging about an incomplete project.
-
thomas, look, idont want to show off, but last week i have made the source of fryingpan compile for 68k target with gcc 6.1.0 with paranoia setting from within aros source tree.
Look, at this point, let's simply say that you haven't seen it. The make architecture is intertwined enough, but at least it works with the *supplied* tools. I'm not entirely sure how well the Makefiles port over from Olaf's version of GNUmake to the up-to-date version of GNUmake, given the differing path conventions, differing wild-card conventions and many other subtle but important changes.
Sources do not follow the usual convention of .h files, rather depend on a delicate toolchain to generate these from the sources, together with some assembler stubs that depend on implementation details of the compilers, plus several compiler-specific extensions - as for example to put the library base pointer into a specific register - which, even worse, are completely undocumented. I fiddled about a week understanding one particular compiler switch for the Lattice compiler that was nowhere in a manual and that was specifically added for CBMs needs and then left alone....
Now, as always, with sufficient time available, and sufficient people to test it, and a long test plan, all of this can be tackled. But let's face reality: The chance is pretty good that while working on this rather delicate and fragile construction, something is somewhere to break in an unforeseen way, and given the amount of manpower and competence available, it seems unlikely that any workable solution can be obtained in a realistic timespan.
You may complain about the closed source nature of the sources, but you won't change it. It is the way it is, and the only way to handle the problem at this point in a realistic timespan with a realistic amount of testing necessary is to *deal* with the situation and accept the complete toolchain as it is.
In short: Too much to do, too many chances to get break something, with too little people to clean it up => just stick with what you have and of what you know that it does its job.
As said, it compiles under Linux, so it's not that bad anymore, actually.
-
Um, I haven't said one word about open / closed source at all. I responded to you calling people in a difficult situation incompetent and kolla bragging about an incomplete project.
Then you misinterpreted my comment.
When I was referring to competent programmers, I meant competent in coding using assembly, which is no longer a common skill, and certainly the few that still bother ARE no where near as competent as the programmers I worked with decades ago.
I other words, they couldn't do the work.
Further I AM insulted by your latest posts like this:
"You ungrateful person. Assuming that you are a productive member of society and not the typical, modern, "gimme dat" American (judging from your attitudes and behavior probably not a good assumption), why don't you get off your lazy butt and actually contribute something yourself? Or are you one of "those who can't, criticize those who can"?
First, at 55 I contributed MY work years ago.
Second, as a American, and in reference to 'lazy Americans'....
We produced the platform in the first place, per capita we are still some of the most productive people on the planet, and we still design the majority of the computer hardware that is used Worldwide.
Further as far as those "that can", I can and still do code in 68K machine language.
I don't have to justify MY accomplishments to the likes of you, I was part of the management of a company designing and selling 68K based computers decades ago.
I'd rather exchange messages with people like Thomas that I have an honest difference of opinion with than you.
So, don't presume to know what you're talking about when you baselessly attack others.
-
For sh1ts and giggles I uploaded the boot screen of my A1200
http://www.amiga.org/forums/picture.php?albumid=204&pictureid=1382
-
I needed Excel, no alternatives came close, I'm glad I bought it.
I KNOW what my requirement were, so his opinions aren't relevant.
Good for you, I am just happy I do not share your needs, I have my own needs and they are in general much better covered by open source based software.
Although, OSX is SO much better than Open BSD, and they regularly feed developments back to the OpenBSD community.
You probably mean FreeBSD, but whatever - it is the BSD community, of which Apple is a part with their DarwinBSD which is the foundation of OSX, now macOS.
Further, if NextStep hadn't been built on that, it could have easily been based on something else.
No, it could not "easily" have been built on something else, Steve Jobs was very clear about this.
Proprietary software IS better than open software. Its just a fact, one that he apparently can't deal with.
It is not at all a fact, it is at best an illusion.
Quality of code has nothing to with whether it is open source or not, but open source allows _education_ and _participation_, from which great stuff and new opportunities can arise.
-
Um, I haven't said one word about open / closed source at all. I responded to you calling people in a difficult situation incompetent and kolla bragging about an incomplete project.
It wasn't me, it was wawrzon, and he wasn't bragging, he was just providing an anecdotal example from the real world.
-
As said, it compiles under Linux, so it's not that bad anymore, actually.
You should get Iggy to buy you SCO UNIX, the old one, before they started relying on FreeBSD, maybe Xenix! Then it would be so much better! :laughing:
-
For sh1ts and giggles I uploaded the boot screen of my A1200
http://www.amiga.org/forums/picture.php?albumid=204&pictureid=1382
Neat!
I may have to get one of those for my A2000 if only for the new copyright and the difference in the splash screen.
Thanks.
-
Good for you, I am just happy I do not share your needs, I have my own needs and they are in general much better covered by open source based software.
You probably mean FreeBSD, but whatever - it is the BSD community, of which Apple is a part with their DarwinBSD which is the foundation of OSX, now macOS.
No, it could not "easily" have been built on something else, Steve Jobs was very clear about this.
It is not at all a fact, it is at best an illusion.
Quality of code has nothing to with whether it is open source or not, but open source allows _education_ and _participation_, from which great stuff and new opportunities can arise.
Bah! Free BSD, OpenBSD, both OS' with less market than Linux, and Linux is pretty dreadful.
OSX/DarwinBSD - Which is the better of the two? Oh yeah, the COMMERCIAL version.
So, what you think of as an illusion is a fact in the marketplace.
Serious users don't rely on open source software (well, anywhere outside Germany).
AND, Excel is significantly better than the spreadsheets offered in open software.
Again, you get what you pay for.
-
Sources do not follow the usual convention of .h files, rather depend on a delicate toolchain to generate these from the sources,
im not sure what you are talking about, but we have some similar kind of mechanism on aros too, to define library interface, and even building a regular third party amiga library is involving generating something like that from sources, so it shouldnt be unthinkable of by a regular amiga coder.
together with some assembler stubs that depend on implementation details of the compilers, plus several compiler-specific extensions - as for example to put the library base pointer into a specific register - which, even worse, are completely undocumented.
yes, libbase goes on68k in a particular register, was it a6? aros has a set of macros for that. there are complaints it isnt directly supported by the compiler and that the macro solution is ugly, yet i dont understand enough of this to tell why and how to make it better. however with some entity behind it, it might be easier to convince the gcc maintenance team to at least review the proposals of the patches pushed upstream for an obsolete os for an almost obsolete cpu architecture. i dont place much hopes with it, but if anything maybe apollo softcores may have some significance here.
I fiddled about a week understanding one particular compiler switch for the Lattice compiler that was nowhere in a manual and that was specifically added for CBMs needs and then left alone....
therefore im not sure if sticking to abandoned tools is always better than switching to currently used ones. but im noob in programming as i said.
In short: Too much to do, too many chances to get break something, with too little people to clean it up => just stick with what you have and of what you know that it does its job.
As said, it compiles under Linux, so it's not that bad anymore, actually.
right, or at least one step at a time. however i was only loosely mentioning that there could be ways to consider if the general attitude was not to keep everything behind the closed doors. as it is, this way people will never learn, and there are ocassional gifted newcomers, only not to os4 camp, where they would have to sign nda beforehand. that is really killing all the spirit. but lets them have it their way.
-
Serious users don't rely on open source software
So which router are you using? And which operating system? There are quite a few open source based components in Windows too, you know.
-
You should get Iggy to buy you SCO UNIX, the old one, before they started relying on FreeBSD, maybe Xenix! Then it would be so much better! :laughing:
Thomas mentioned Linux as a build platform with regard to a different application.
The Amiga V40 operating system can be built completely natively, using tools which only run on the Amiga operating system itself. That's nice, but not so nice if you wanted to perform automated build verification / smoke testing / integration testing. This is best performed automatically, regularly on a dedicated build server.
How do you do that? Thomas found a solution for that problem, and it involves Linux (but could also run on FreeBSD/NetBSD/OpenBSD/MacOS X/CygWin/AmigaOS).
And, no, SCO Unix will not do, due to its age.
-
So which router are you using? And which operating system? There are quite a few open source based components in Windows too, you know.
I'm sure there are pieces of open source software in many proprietary OS'.
I just don't feel comfortable relying on an entirely open OS.
I've had much better experiences with closed operating systems, AND I can get support without having to go to a forum and asking for advice.
As to my router, who really cares?
I was using one when I purchased my internet service from Comcast.
That's shelved as I'm using a higher tier FIOS connection (and Verizon supplied to hardware, so...).
Look, I used to work with OS' that were often found in embedded applications, that's actually where I developed my intense dislike for Linux.
So you're not going to sell me on open source OS' with an argument focused in that direction.
And I must admit that I've occasionally considered exploring BSD, but its not a practical primary OS for me (any more than Linux would be).
Now when I buy an X5000, I'll admit that I will be running Linux on it part of the time.
BUT, that's a hobbyist system for me, so I'll accept some compromises.
-
No, it could not "easily" have been built on something else, Steve Jobs was very clear about this.
Steve Jobs was very clear about anything that would result in more money for Apple. His reality distortion field was strong.
-
I'm sure there are pieces of open source software in many proprietary OS'.
I just don't feel comfortable relying on an entirely open OS.
I've had much better experiences with closed operating systems, AND I can get support without having to go to a forum and asking for advice.
From where do you get the idea that you have to go to a forum? Most open source software has bugtrackers where you submit bugs you encounter, and patches are welcome too. It was just two days ago I submitted a bug-report and a patch to have a piece of software build on non-x86 hardware, and this morning I got report saying the patch was accepted, appreciated and pushed upstream for next release.
As to my router, who really cares?
You, according to yourself - "Serious users don't rely on open source software"
Maybe you do not rely on being online? Maybe you do not rely on service providers online?
I was using one when I purchased my internet service from Comcast.
That's shelved as I'm using a higher tier FIOS connection (and Verizon supplied to hardware, so...).
What are the odds of that running Linux and busybox, do you think?
Look, I used to work with OS' that were often found in embedded applications, that's actually where I developed my intense dislike for Linux.
So you're not going to sell me on open source OS' with an argument focused in that direction.
I see, it is very personal, you worked with embedded, embedded moved to Linux, you got a dislike for it (which I can fully appreciate), and now you have a dislike for all open source just because "linux took my job".
And I must admit that I've occasionally considered exploring BSD, but its not a practical primary OS for me (any more than Linux would be).
macOS is pretty great as desktop. You could also look at TrueOS and GhostBSD. But, if Windows is your home, you will not feel at home anywhere else... well, maybe ReactOS.
Now when I buy an X5000, I'll admit that I will be running Linux on it part of the time.
Then maybe you can send people like me some good vibes, who make sure software builds and works on that (and other) architectures that not at all "mainstream" for desktop use.
BUT, that's a hobbyist system for me, so I'll accept some compromises.
Well, this hobby of yours is what runs the intertubes these days.
-
The Amiga V40 operating system can be built completely natively, using tools which only run on the Amiga operating system itself. That's nice, but not so nice if you wanted to perform automated build verification / smoke testing / integration testing.
Indeed, I fully appreciate that.
This is best performed automatically, regularly on a dedicated build server.
How do you do that? Thomas found a solution for that problem, and it involves Linux (but could also run on FreeBSD/NetBSD/OpenBSD/MacOS X/CygWin/AmigaOS).
It relies on the emulator (cannot recall the name) he has been working on, I suppose. This is great for future development, simplifies things a lot. The next steps would be to bit-by-bit replace the pieces of code that relies on "exotic" compiler options. This will most likely mean that you have to break the 512kB barrier for the kickstart - but so be it, at least temporary.
How do aspiring young developers, students etc, get to learn about how things work and how they can participate in improving the OS? No-one is getting any younger here.
And, no, SCO Unix will not do, due to its age.
Well, it is now called OpenServer and is based on FreeBSD, so I am sure it would work :laughing:
-
It relies on the emulator (cannot recall the name) he has been working on, I suppose. This is great for future development, simplifies things a lot.
If anyone wants to know, most of the credits go to Christian Vogelsang, who set this project up. Its name is "vamos", and you find my branch here:
https://github.com/thorfdbg/amitools
Modifications I make there go back into Christian's repository, so don't worry. I don't want to separate this repository from his.
In addition to vamos, you need the V45 shell. Oh, and of course the Os sources.
The next steps would be to bit-by-bit replace the pieces of code that relies on "exotic" compiler options.
Actually, the next step should be to collect all the pieces together and create a consistent Os source. That is, to fit back the "known good" upgrades back into the sources. From my side, this is layer, shell, "more", mathieee, - and what is not yet out - audio, keymap and keyboard (all from my side).
There are other components out there I would *like* to merge back, but of which I do not have the latest sources. SetPatch, FFS, scsi.
Once that is done, one can think on how to proceed from there. So first things first, please.
-
@Thomas Richter
I suppose that this is a kind of dream come true to you ;-)
Kamelito
-
If anyone wants to know, most of the credits go to Christian Vogelsang, who set this project up. Its name is "vamos", and you find my branch here:
https://github.com/thorfdbg/amitools
Modifications I make there go back into Christian's repository, so don't worry. I don't want to separate this repository from his.
I must look into that, still have a few projects that have been "stalled" for years since I haven't bothered to keep a functional ADE/GG toolchain around on any of my Amiga systems. It would be great to just move it all into the "usual" workflow I have these days (git, jenkins+docker, repos).
In addition to vamos, you need the V45 shell. Oh, and of course the Os sources.
All available :)
Actually, the next step should be to collect all the pieces together and create a consistent Os source. That is, to fit back the "known good" upgrades back into the sources. From my side, this is layer, shell, "more", mathieee, - and what is not yet out - audio, keymap and keyboard (all from my side).
Actually, I would rather do it the other way around - first create consistent OS source of 3.1 as it was (and if possible, so one can "easily" build "clean" 3.1 from that), and then update the various components to their later incarnations, and add new components in a timely and tidy fashion. But, of course that is my opinion, you probably have compelling arguments for not doing it like this.
There are other components out there I would *like* to merge back, but of which I do not have the latest sources. SetPatch, FFS, scsi.
Why not start with what you do have, surely the processes can work in parallel?
Once that is done, one can think on how to proceed from there. So first things first, please.
Right, don't let us amateur thumb twiddlers slow you down :) :laughing:
-
Actually, I would rather do it the other way around - first create consistent OS source of 3.1 as it was (and if possible, so one can "easily" build "clean" 3.1 from that), and then update the various components to their later incarnations, and add new components in a timely and tidy fashion. But, of course that is my opinion, you probably have compelling arguments for not doing it like this.
Just to be precise here: There is absolutely no problem building the Os. Type "make", and wait. So the build system works, and the Os sources work correctly. Don't worry about that.
The problem with the Os sources is that they delicately depend on the tools in the toolchain, so you cannot just take "a generic C compiler" and a generic 68K assembler. Instead, there are two compilers (lattice C and SAS 6.59), one assembler, a specific version of "gnuMake" and some other binaries that are compiled from scratch using the tools. Which is already an improvement given that intuition originally required a third compiler.
Cleaning this up, in particular cleaning up graphics, is a non-trivial task. Since it compiles and works stable, this is not an issue at this very moment.
The point is: Given the delicate nature of the system, it is very likely that a seemingly triival change breaks the messy parts of Os. If it ain't broken, don't fix it.
-
The problem with the Os sources is that they delicately depend on the tools in the toolchain, so you cannot just take "a generic C compiler" and a generic 68K assembler. Instead, there are two compilers (lattice C and SAS 6.59), one assembler, a specific version of "gnuMake" and some other binaries that are compiled from scratch using the tools. Which is already an improvement given that intuition originally required a third compiler.
I would like to add that the build tools which are used to orchestrate the entire build process, as well as those specialist tools which knit together the Kickstart and Workbench contents, are available with full source code. The AmigaOS 3.1 build is almost entirely self-contained.
The only exceptions are the two compilers and the 68k assembler being used. I am not the expert, but it appears likely to me that the specific 68k assembler could be replaced. Which leaves the Amiga-platform-specific compilers as the biggest stumbling block. Please note that the compilers are not just used for building executable code, their respective debugging tools are important, too. The debuggers are really hard to replace.
-
Two things i'd like to see in a future update is Peter Ks excellent rewritten icon.library included as default if possible (and allowed by him), and maybe pfs as a default filesystem (with PFSIO maybe) and an updated hdinstalltools.
-
Two things i'd like to see in a future update is Peter Ks excellent rewritten icon.library included as default if possible (and allowed by him)
The workbench.library/icon.library combo has, in my opinion, hit the wall so hard by now that it's coming out on the other side. The way in which workbench.library and icon.library interact with directory scanning is something I hesitate to call a self-inflicted injury. It certainly is not helpful. It is not helpful either to use large icon files. The interaction between the three parties (workbench, icon, dos) sort of works, but it works no better than it did in 1986: only the storage devices have become larger, and the CPUs have become faster.
Finally, I doubt the wisdom in including such a large (it's one single file), complex assembly language implementation in the operating system. It's bad enough that we have to deal with the FFS and the scsi.device driver family, and even dos.library. There is a place for assembly language code in the operating system, but in my opinion the solution should match the problem at hand in terms of complexity and maintainability.
-
Finally, I doubt the wisdom in including such a large (it's one single file), complex assembly language implementation in the operating system. It's bad enough that we have to deal with the FFS and the scsi.device driver family, and even dos.library. There is a place for assembly language code in the operating system, but in my opinion the solution should match the problem at hand in terms of complexity and maintainability.
In the end who cares about maintainability when you havent released a single patch to fix all the shortcomings of icon.library in more than a decade.
Maintainability is of no use if no one maintains it (which is pretty much what you did). Which is casually the opposite of what PeterK has been doing for a couple of years, despite it is in assembler, despite he had no sources to start with, despite he hadnt earn a dime during that process, and despite he added lots of advanced features to it, he still maintains it and takes care of any bug reports.
Of course, using assembler, does not apply in all situations, like components which have been actively maintained by Thomas Richter. But in the particular case of icon.library, PeterK`s solution is indeed much better in both features and performance than your own implementation of icon.library 45.x which has been unmaintained for more than a decade.
Assembler is not the best solution, but it is certainly better than unmaintained, buggy and slow C code.
-
The workbench.library/icon.library combo has, in my opinion, hit the wall so hard by now that it's coming out on the other side. The way in which workbench.library and icon.library interact with directory scanning is something I hesitate to call a self-inflicted injury.
One of the many examples of something that would be better to reimplement from scratch - though that would most likely also mean incompatibility with lots of existing "bedroom" software. Likewise, con-handler vs. console.device vs. shell, would be great to have that mess cleaned up.
-
Maintainability is of no use if no one maintains it
Exactly, maintainability also means availability.
-
Exactly, maintainability also means availability.
Apple was working in secret on an X86/X64 version of Mac OSX since the beginning it was not available yet it was maintained...
It was probably a mistake to do not update the 68k branch as it is where most users are. We also know that the so called Classic users, the hardcore one will never take the PPC route. Jedi tricks do not work on them.
Better later than never though.
Kamelito
-
@thor, olsen
alright, sounds like you are stepping in right direction. even if the build system relies on particular versions of make and more than one compiler the sources are not available for, it is fine as long as binaries are freely available to all invloved.
i applaud your effort, guys. the thing is, that as long as solutions proposed by you cost more and deliver less than third party replacements, they still are supposed to be met with criticism. especially, as its been mentioned already, that the target audience has been left outside, standing in the rain for years and had to look for alternatives, and also that the updates are being published under a label with known track of record of ignorance against the genuine amiga hardware and scene, and also been known for not delivering on announcements.
-
One of the many examples of something that would be better to reimplement from scratch - though that would most likely also mean incompatibility with lots of existing "bedroom" software. Likewise, con-handler vs. console.device vs. shell, would be great to have that mess cleaned up.
The workbench.library/icon.library combo has resisted change for almost 30 years.
By now I am inclined to accept that it cannot be changed, only replaced by a solution that is API-compatible with it.
As long as workbench.library/icon.library continue to exist and are maintained, they will suck up developer effort best spent somewhere (make that "anywhere") else, just like space vacuum acts as a heat sink.
If you get too close to it, you will be sucked into creating enhancements which only burden the already over-overloaded architecture. My (so far) final contribution to this series of unwisely chosen enhancements was the Workbench ARexx interface.
By comparison the console.device/con-handler/shell combo seems charmingly 'whacky' and ultimatively redeemable ;)
We shall see...
-
i applaud your effort, guys. the thing is, that as long as solutions proposed by you cost more and deliver less than third party replacements, they still are supposed to be met with criticism. especially, as its been mentioned already, that the target audience has been left outside, standing in the rain for years and had to look for alternatives, and also that the updates are being published under a label with known track of record of ignorance against the genuine amiga hardware and scene, and also been known for not delivering on announcements.
Call me uncharacteristically optimistic. I believe that changes made to the AmigaOS V40 code will be beneficial, although they are likely to be considered too little, too late.
The work that went into making the AmigaOS 3.5 update was intended to open up the platform by introducing new APIs, so that developers could build upon them, and by integrating functionality into the operating system which up until then had to be added through patches, which were fighting among each other for control.
In my opinion, this is the direction in which future development work should continue.
It won't be terribly exciting (excitement is something you would be well-advised not to seek in software development), but it seems reasonably likely to succeed to me at advancing the state of the Amiga operating system and getting more Amiga developers involved. It must be considerably less fun to "play" with what was last updated and polished in 1999.
-
By comparison the console.device/con-handler/shell combo seems charmingly 'whacky' and ultimatively redeemable ;)
It's really bad enough. Moving the history handling into the console still seems somewhat logical, but the whole idea of having the TAB expansion handled in the console is ultimately broken, even more so for job control. Luckely, there are enough precautions taken to get rid of this nonsense in ViNCEd, and finally move that code where it belongs - the Shell namely.
CON: is just a very thin interface layer around the console.device. Or rather, should be.
-
Call me uncharacteristically optimistic.[...] getting more Amiga developers involved.
thats exactly a part im sceptical about. you want to eat a cake and keep it. but i bet you wont get people involved if you dont open up. and you dont seem to plan to.
-
thats exactly a part im sceptical about. you want to eat a cake and keep it. but i bet you wont get people involved if you dont open up. and you dont seem to plan to.
You do know that you're complaining to the wrong people. You keep griping about opening the source code but the people you're griping to don't have the rights to do so. They are individuals working on parts of the code, either under contract or volunteer. They don't own it and so can't make the decision to open it.
I know that this has been pointed out several times to you and the other open source "demanders" in this and many other threads. You need to understand that you are making impossible demands of these people. They can NOT do what you are demanding.
This is an example of what I meant above about not being appreciative and grateful for what they are able to accomplish. Look, these people are doing what they can in their spare time and for little or no compensation. How many people do you think have the knowledge, skills, access to the source code, and more importantly the desire to do this work on a long dead computer platform? If people continue to make impossible demands of them, question their ability or insult them, how much longer do you think that desire will last?
These guys don't owe us anything. They have expended a great deal of time and effort to give us what they have. They could just as easily turned away and pursued something profitable. Honestly, with the negativity they get from some of the community, I'm surprised that they haven't and that anyone remains willing to work on a dead product for obnoxious and ungrateful users.
Try saying "Thank you" instead to these guys.
If you have issues about the source code, take it up with the rights holder, please.
-
+ infinity :hammer:
-
You do know that you're complaining to the wrong people. You keep griping about opening the source code but the people you're griping to don't have the rights to do so. They are individuals working on parts of the code, either under contract or volunteer. They don't own it and so can't make the decision to open it.
I know that this has been pointed out several times to you and the other open source "demanders" in this and many other threads. You need to understand that you are making impossible demands of these people. They can NOT do what you are demanding.
This is an example of what I meant above about not being appreciative and grateful for what they are able to accomplish. Look, these people are doing what they can in their spare time and for little or no compensation. How many people do you think have the knowledge, skills, access to the source code, and more importantly the desire to do this work on a long dead computer platform? If people continue to make impossible demands of them, question their ability or insult them, how much longer do you think that desire will last?
These guys don't owe us anything. They have expended a great deal of time and effort to give us what they have. They could just as easily turned away and pursued something profitable. Honestly, with the negativity they get from some of the community, I'm surprised that they haven't and that anyone remains willing to work on a dead product for obnoxious and ungrateful users.
Try saying "Thank you" instead to these guys.
If you have issues about the source code, take it up with the rights holder, please.
yawn.. its not a complaint. i wrote that im fond of what olaf does, simply it wont lead far, i fear, given the circumstances. there is nothing in your post that wouldnt be obvious to almost anybody here, if you are being just grateful and you dont have anything to add, then its fine too.
-
It's really bad enough. Moving the history handling into the console still seems somewhat logical, but the whole idea of having the TAB expansion handled in the console is ultimately broken, even more so for job control. Luckely, there are enough precautions taken to get rid of this nonsense in ViNCEd, and finally move that code where it belongs - the Shell namely.
CON: is just a very thin interface layer around the console.device. Or rather, should be.
Tony has a couple of nice blogs on his adventures in this area:
http://blog.hyperion-entertainment.biz/?p=1220
http://blog.hyperion-entertainment.biz/?p=1227
-
yawn.. its not a complaint. i wrote that im fond of what olaf does, simply it wont lead far, i fear, given the circumstances. there is nothing in your post that wouldnt be obvious to almost anybody here, if you are being just grateful and you dont have anything to add, then its fine too.
You really do only see what you want to, don't you? It's such a shame that your reality isn't a happier one. TTFN
-
You do know that you're complaining to the wrong people. You keep griping about opening the source code but the people you're griping to don't have the rights to do so. They are individuals working on parts of the code, either under contract or volunteer. They don't own it and so can't make the decision to open it.
I know that this has been pointed out several times to you and the other open source "demanders" in this and many other threads. You need to understand that you are making impossible demands of these people. They can NOT do what you are demanding.
This is an example of what I meant above about not being appreciative and grateful for what they are able to accomplish. Look, these people are doing what they can in their spare time and for little or no compensation. How many people do you think have the knowledge, skills, access to the source code, and more importantly the desire to do this work on a long dead computer platform? If people continue to make impossible demands of them, question their ability or insult them, how much longer do you think that desire will last?
These guys don't owe us anything. They have expended a great deal of time and effort to give us what they have. They could just as easily turned away and pursued something profitable. Honestly, with the negativity they get from some of the community, I'm surprised that they haven't and that anyone remains willing to work on a dead product for obnoxious and ungrateful users.
Try saying "Thank you" instead to these guys.
If you have issues about the source code, take it up with the rights holder, please.
+Word!! Thanks to ALL updating the code for out beloved platform, in whatever way. Of course Hyperion should have some pocketmoney if they update it, now and then. I would also like to see it open sourced one day, but I'm not sure that is a silverbullet. We got AROS already and anyone feeling that they would like to contribute are free to do so there. And Olsen, Thomas et al, please continue sharing as much nuggets and insights as you do into the code and history of it - have you considered blogging about it now and then.
-
Tony has a couple of nice blogs on his adventures in this area...
That's really only the internal design of the console.device. FYI, ViNCEd works completely different from that and has two internal representations of lines: A "packed" line where each line is broken up into "words" that share the same attributes, with blanks in between, and an unpacked version with a one-byte glyph and a two-byte attribute per character in the line. Whenever the cursor enters a line, this line is unpacked, the user makes edits, and when the cursor leaves the line, it is packed again.
The internal representation is all fine, but the problem is how the console interacts with the shell. ViNCed somehow "hijacks" the CLI structure of the I/O streams that reach the handler, and from that "guesses" (it's a bit better than this, but let's make it simple) what the corresponding CLI is, from there figures out what the path is, and from there runs the TAB-expansion, and from there places the expansion back into the window. Actually, a separate side-thread is responsible for that.
It works, but the bad part about is the lack of isolation. Essentially, the console has to mess with data structures (the CLI) it should really not care about. The CLI structure is frozen, so nothing bad can happen, but it's still not how it is supposed to work. The shell should care about its own structures, and do the expansion, and the console should inform the shell when the user needs an expansion.
On the ViNCEd side (not the "ROM console") everything is there to support such an improved operation, but from the Shell side it is not.
-
The shell should care about its own structures, and do the expansion, and the console should inform the shell when the user needs an expansion.
OTOH with expansion being done in console handler it also works inside programs started from shell. So if you type "list ?" you can still enter a directory name with tab expansion which you could not if expansion was (only) done by shell itself.
-
thats exactly a part im sceptical about. you want to eat a cake and keep it. but i bet you wont get people involved if you dont open up. and you dont seem to plan to.
I understand this as being an unsatisfying solution for you. The situation as it is means that all of us, who are trying to get AmigaOS 3.1 into a maintainable state and beyond, are limited by the legal framework currently in place.
That framework (leaving aside for a moment why it is subject of criticism) at least allows for the work to be done such that it can be published without being challenged, that money can be earned by selling it and the publisher is legally required to honor the contracts being made with the participants of the project.
One downside to that framework is that the rightsholder (of the Amiga operating system as it is) requires that the material being worked on be treated as confidential. That's how it is for now. This would be a dealbreaker for many people who would otherwise feel more motivated to join in.
The Amiga community today is what is is: a community. It follows (at least from my point of view) that the same dedication should be extended to Amiga operating system development in the form of a community-driven project. I can agree to that. As things are, it's not going to happen like that, with the existing legal framework governing the Amiga operating system in place.
This could change. I doubt that it will change in the short term.
While we are waiting for the change to come, there's something we can do that makes a difference.
One: figure out how the Amiga operating system might be made suitable in the context of a community-driven project (this will take time, knowledge of the legal framework, talking to the right people and convincing them), making the change happen.
Two: work on Amiga operating system development as it is possible right now - at the very least you could get insights into how it works, how to develop it, and that is information you could in time pass on to others when the operating system development becomes more open (even NDAs elapse). You cannot be expected to gain all that working knowledge solely from studying source code ;)
-
I bought kickstart and wb mostly for a support. But I started to make a new 1mb custom kickstart and I can't split this kickstart. RomSplit just says unsupported kickstart, what other tools are for that?
-
OTOH with expansion being done in console handler it also works inside programs started from shell. So if you type "list ?" you can still enter a directory name with tab expansion which you could not if expansion was (only) done by shell itself.
Yes, though is this really a good approach? If this is, for example, some sort of program is running in the shell, then TAB should just do the natural thing, namely move to the next tab position, and not do anything beyond.
I remember having written a program that expects some sort of matrix input (a 3x3 matrix), entered row by row, where each column is separated by TAB. If the Shell would run an expansion on this program, it would not only misunderstand the input, it would also mess it up.
Currently, ViNCEd goes in circles to find out when it can do what. For example ^Z (the magic "give me a new job") works only if a program is currently holding the shell, and TAB only works if the shell is visible and no program is running.
For that, the *console* analyzes whether a Shell is running in it, and if so, checks its structures. Instead, the shell should say what it needs, and not the other way around.
-
I understand this as being an unsatisfying solution for you. The situation as it is means that all of us, who are trying to get AmigaOS 3.1 into a maintainable state and beyond, are limited by the legal framework currently in place.
thx for understanding. ;) and explanation. one important thing i see, is mention, that this way the publisher is obliged to honour the agreements with you, the developers. this of course is an understandable reason to the status quo as present. i think, i understand very well your and thors idea how to advance and would really welcome that succeed.
This could change. I doubt that it will change in the short term.
While we are waiting for the change to come, there's something we can do that makes a difference.
exactly, alas, and since effectively a third of human life has passed with us waiting and nothing changed, i must say my expectation as it is probably with quite a few among the remaining community has hit the bottom.
One: figure out how the Amiga operating system might be made suitable in the context of a community-driven project (this will take time, knowledge of the legal framework, talking to the right people and convincing them), making the change happen.
sorry, but i dont see how the community can help with this. even if it could, it would require a willing partner on the other side, who is actually the only instance that can declare terms. i simply dont see a possibility to open the content we are speaking of. others might try, but given the attitude in communication it usually remains just useless talk on the forums.
Two: work on Amiga operating system development as it is possible right now - at the very least you could get insights into how it works, how to develop it, and that is information you could in time pass on to others when the operating system development becomes more open (even NDAs elapse). You cannot be expected to gain all that working knowledge solely from studying source code ;)
[/QUOTE]
im sure many do that anyway. there are people replacing the whole components of the system with their code, there is a huge number of patches, the third party software, that could be considered today a necessary contributions is being actively developed. this all for better or worse, with more or less skill, with no supervision, not particularly much communication, with efforts being doubled or quadrupled in the same area. i think its likely to remain like this.
-
I bought kickstart and wb mostly for a support. But I started to make a new 1mb custom kickstart and I can't split this kickstart. RomSplit just says unsupported kickstart, what other tools are for that?
of course. romsplit can only disassemble the kickstart it knows. it wont disassemble just any of your custom kickstarts, even though remus can assemble such. im not aware of any other tools to do that, even though an experienced coder could probably extract the modules by hand. your alternative is to take this kickstart as is or to stick to the patched one.
-
If you have issues about the source code, take it up with the rights holder, please.
Who are they?
Cloanto claim ownership of the whole OS, Hyperion claim to own a licence to distribute it from the latest shell company that McEwen is passing off as the original Amiga Inc.
So who should he take it up with?
-
Who are they?
Cloanto claim ownership of the whole OS, Hyperion claim to own a licence to distribute it from the latest shell company that McEwen is passing off as the original Amiga Inc.
So who should he take it up with?
I am not a lawyer nor do I play one on TV so I don't know. I certainly don't think that Thomas and all are the ones. Complaining to or about them is just a waste of time and can't accomplish anything positive.
-
I am not a lawyer nor do I play one on TV so I don't know. I certainly don't think that Thomas and all are the ones. Complaining to or about them is just a waste of time and can't accomplish anything positive.
there might be some "the lawyers" around, but it is not us. therefore i say, that it is not our job to figure out a solution that would allow for some developments on amiga front. even though im rather impressed that someone like olaf did the work to rearrange sources for better maintainability, as i imagine how much hassle it might be, without a single patch applied. then again, neither this or the few patches to kickstart isnt what the future developments depend on. im not complaining that olaf does this work. i rather fear that it is in vain. and not because of my complaints, but rather because of the so called objective difficulties.
-
Now this is starting to get weird:
Now both Hyperion and Cloanto are developing independent AmigaOS 3.1 continuation branches.
They are both actively selling kickstart licenses.
And have provided affordable disk versions.
So:
At least we got two companies developing the OS for Amigas.
Would this state of affairs fragmentate (yet again) the Amiga scene?
Seems, at last, they both realized money is available in the 68k world.
Food for thought. :)
-
Now this is starting to get weird:
Now both Hyperion and Cloanto are developing independent AmigaOS 3.1 continuation branches.
They are both actively selling kickstart licenses.
And have provided affordable disk versions.
So:
At least we got two companies developing the OS for Amigas.
Would this state of affairs fragmentate (yet again) the Amiga scene?
Seems, at last, they both realized money is available in the 68k world.
Food for thought. :)
It's called division = to sink the Classic definitively...
-
I'm hoping for the following
KickStart 3.10
All the latest modules and bug fixes for all known issues which supersedes OS 3.9 rom updates
Full support for disks up to 128GB
Supports all hardware
1 MB Rom(yes i know this causes issues for A4000\A3000)
Support for re flash-able roms
WorkBench 3.2
all Bug fixes in 3.1
Support for KickStart 3.10
WorkBench 3.10
All Bug fixes known for 3.9
merge all boing bags
Common
Fix HDTOOLS
-
of course. romsplit can only disassemble the kickstart it knows. it wont disassemble just any of your custom kickstarts, even though remus can assemble such. im not aware of any other tools to do that, even though an experienced coder could probably extract the modules by hand. your alternative is to take this kickstart as is or to stick to the patched one.
Didn't the page of Hyperion have that information?
EDIT: Ah, it was here (http://www.amiga.org/forums/showpost.php?p=815260&postcount=13) :)
Btw - to mentioned something I would have thought was obvious, it would be nice if Remus could also save split data for the kickstarts it builds. Also, it is worth mentioning that there is an alternative to Remus, romtool, written in python - https://github.com/cnvogelg/amitools/tree/master/amitools/rom :)
-
I'm hoping for the following
KickStart 3.10
All the latest modules and bug fixes for all known issues which supersedes OS 3.9 rom updates
Full support for disks up to 128GB
Supports all hardware
1 MB Rom(yes i know this causes issues for A4000\A3000)
Support for re flash-able roms
WorkBench 3.2
all Bug fixes in 3.1
Support for KickStart 3.10
WorkBench 3.10
All Bug fixes known for 3.9
merge all boing bags
Common
Fix HDTOOLS
Exactly!!
@Olsen - thanks for your feedback on this thread so far. As you can see there is a lot of interest in getting a new supported OS3.x distribution going. Hopefully the rights/IP holders can be convinced to help open things up to advancement.
-
I'm hoping for the following
KickStart 3.10
All the latest modules and bug fixes for all known issues which supersedes OS 3.9 rom updates
Full support for disks up to 128GB
Supports all hardware
1 MB Rom(yes i know this causes issues for A4000\A3000)
Support for re flash-able roms
WorkBench 3.2
all Bug fixes in 3.1
Support for KickStart 3.10
WorkBench 3.10
All Bug fixes known for 3.9
merge all boing bags
Common
Fix HDTOOLS
There is at least a 1meg flash rom available. Can all we need squeeze into 1Meg?. Would be nice to have an image of it.
-
Purchased (for no reason in particular), thank you!
-
At least we got two companies developing the OS for Amigas.
Would this state of affairs fragmentate (yet again) the Amiga scene?
Things are weird. I'm not exactly clear how Cloanto operates, and how their process for ROM generation works. I have the impression - but I might be wrong - that they are just collecting a couple of third-party extensions, without integrating them into the overall software repository, and just build ROMs by placing modules "near to each other".
This is kind of how Os 3.9 development worked. External "hackers" (including me) contributing updated sources to the Os, as independent contributers. Unfortunately, the "big picture" gets lost this way. As did some souces. )-:
Frankly, it's not exactly how I believe it should work. The current model for this ROM is just a much saner one: One central repository, a common build-process, and an experienced AmigaOs developer keeping control on the "global picture" (Olsen).
I've learned a lot on software development since 3.9 happened, more on the management and deployment side than the actual hacking, and my firm believe is that the second model Olsen is currently trying to implement is the better one.
That this turns out to be a "Hyperion vs. Cloanto" fight is just sad. It would make much more sense to keep development under a common umbrella.
-
Things are weird. I'm not exactly clear how Cloanto operates, and how their process for ROM generation works. I have the impression - but I might be wrong - that they are just collecting a couple of third-party extensions, without integrating them into the overall software repository, and just build ROMs by placing modules "near to each other".
This is kind of how Os 3.9 development worked. External "hackers" (including me) contributing updated sources to the Os, as independent contributers. Unfortunately, the "big picture" gets lost this way. As did some souces. )-:
Frankly, it's not exactly how I believe it should work. The current model for this ROM is just a much saner one: One central repository, a common build-process, and an experienced AmigaOs developer keeping control on the "global picture" (Olsen).
I've learned a lot on software development since 3.9 happened, more on the management and deployment side than the actual hacking, and my firm believe is that the second model Olsen is currently trying to implement is the better one.
That this turns out to be a "Hyperion vs. Cloanto" fight is just sad. It would make much more sense to keep development under a common umbrella.
In the past, you were ALWAYS against romabiliy... And now you want to work on the Kickstart ?
You change your mind because now you smell money (V2, new P5 boards...) with Kick ?
You are a clown...
I'm very curious to know how much money Microsoft (or other...) give you to destroy the Amiga by the inside using division and different directions between us...
edit by eliyahu: OK, i've had enough of your insults, conspiracy theories, and accusations. if you can't abide by the rules of this site, leave. you have a ten-day vacation to consider. enjoy.
-
@Cosmos
Sheesh, that is so lame, stop the lunatic conspiracy nonsense. No-one outside the community cares one bit about Amiga, let alone destroying it from the inside. It is just us and there is no money in this.
-
I agree that hacking and patching are not tidy or desirable solutions for long term development, they are just a quick fix, nothing more.
Hopefully kickstart development can catch up with what 3.9 offered and grow from there. Because right now it is a little poor in that area, so we are still better of with the hacks&patches from 3.9 and third parties, which is not the ideal solution.
I also wonder why didnt Olsen integrate his Roadshow TCP stack with this release, as it could have made the update much more interesting, and I guess many people could have happily agreed to even pay a bit more for the workbench disks if it was included/added to them. After all, Roadshow is also the TCP stack of OS4, so I guess negotiations with Hyperion would have been pretty easy to acomplish since they have been already done for the OS4 version.
Furthermore, there is a lot of 68k material from Hyperion that could have been included to enrich this release, at no cost of development at all. It was just a matter of collecting it from OS4 releases and prereleases.
-
Furthermore, there is a lot of 68k material from Hyperion that could have been included to enrich this release
the thing is that it would probably be much more work porting anything os4 to amiga, than simply fixing some known memory leaks in scsi.device. os4 seems to have whole different philosophy in different areas like library interface. note how much hassle its been to make chris os4 netsurf version to work on amiga half a way.
also, what would that material be, that amiga might require from hyperion. i cant think of awful lot.
and also considering the cost, like memory consumption, question is, is it worth it?
-
the thing is that it would probably be much more work porting anything os4 to amiga, than simply fixing some known memory leaks in scsi.device. os4 seems to have whole different philosophy in different areas like library interface. note how much hassle its been to make chris os4 netsurf version to work on amiga half a way.
also, what would that material be, that amiga might require from hyperion. i cant think of awful lot.
and also considering the cost, like memory consumption, question is, is it worth it?
I'd like to see the whole of OS4.1 back ported to 68k. Obviously it'd be slow as hell on even an 060 but emulators won't have that problem.
-
Things are weird. I'm not exactly clear how Cloanto operates, and how their process for ROM generation works. I have the impression - but I might be wrong - that they are just collecting a couple of third-party extensions, without integrating them into the overall software repository, and just build ROMs by placing modules "near to each other".
This is kind of how Os 3.9 development worked. External "hackers" (including me) contributing updated sources to the Os, as independent contributers. Unfortunately, the "big picture" gets lost this way. As did some souces. )-:
Frankly, it's not exactly how I believe it should work. The current model for this ROM is just a much saner one: One central repository, a common build-process, and an experienced AmigaOs developer keeping control on the "global picture" (Olsen).
I've learned a lot on software development since 3.9 happened, more on the management and deployment side than the actual hacking, and my firm believe is that the second model Olsen is currently trying to implement is the better one.
That this turns out to be a "Hyperion vs. Cloanto" fight is just sad. It would make much more sense to keep development under a common umbrella.
Hyperion have ”earned” a lot of suspicion compared to Cloanto. I can't see them selling more product than Cloanto do to the likes of your average EAB or A1K poster tbh.
-
I'd like to see the whole of OS4.1 back ported to 68k. Obviously it'd be slow as hell on even an 060 but emulators won't have that problem.
Emulators are already running AmigaOS 4.1, but I agree 68k with FPGA will be faster over time so a backport could be possible, desirable even. They will probably made more money than on NG I guess.
Kamelito
-
Gulliver was talking about 68k components already existing in OS4, that one can find especially a lot of on the 4.0 for classic release.
-
I agree that hacking and patching are not tidy or desirable solutions for long term development, they are just a quick fix, nothing more.
Hopefully kickstart development can catch up with what 3.9 offered and grow from there. Because right now it is a little poor in that area, so we are still better of with the hacks&patches from 3.9 and third parties, which is not the ideal solution.
For the moment, the 3.1 operating system is in "consolidation & cleanup" mode. The baseline which future work should build upon is arguably in not that much better shape than it was in 1994. Some bugs have been fixed, but in order to reduce the risk of breaking anything at all, the changes made so far have been very modest.
Changes that were made for the AmigaOS 3.5 and 3.9 updates should be possible, but even these would need reviewing again: they are barely 5-6 years "younger" than the original 3.1 release.
I also wonder why didnt Olsen integrate his Roadshow TCP stack with this release, as it could have made the update much more interesting, and I guess many people could have happily agreed to even pay a bit more for the workbench disks if it was included/added to them. After all, Roadshow is also the TCP stack of OS4, so I guess negotiations with Hyperion would have been pretty easy to acomplish since they have been already done for the OS4 version.
Considering that I had a really hard time making the updates to Roadshow 1.11 which I had planned (most of the interesting stuff didn't happen), then lost a lot of time testing the results because my only 68000 machine had failed, I expect that integrating Roadshow into Workbench would have delayed everything into 2017.
That's one reason why there is no Roadshow in this Workbench update.
The biggest reason is that this Workbench update sticks very close to the original 3.1 release in order to make sure that it actually worked well enough without having to spend the same amount of QA work as Commodore and Village Tronic did in their time. The fewer changes, the lower the risk to ship an update that breaks in subtle and/or baffling ways.
That said, this update did suffer from subtle problems: the installation script has a problem with copying the contents of the "Fonts" disk, and the Workbench disk should have been bootable. Both issues are fixable, and a fix should be available shortly.
Furthermore, there is a lot of 68k material from Hyperion that could have been included to enrich this release, at no cost of development at all. It was just a matter of collecting it from OS4 releases and prereleases.
You are onto something... Still, the deliberately limited scope of this update took priority.
-
Emulators are already running AmigaOS 4.1, but I agree 68k with FPGA will be faster over time so a backport could be possible, desirable even. They will probably made more money than on NG I guess.
Kamelito
I'd just like to have it running on Amithlon. :)
-
@olsen
Thank you, I now understand the desitions that went into this release. They sound reasonable considering longer term goals.
BTW, I am glad that you are planing on addressing current release bugs and thinking on a viable future.
All this sounds like comitment to me, which gives me confidence and hope. And of course, more importantly, makes me a willing customer :)
-
Q: if there will be future updates will they be free for people purchasing the ROM now ?
-
In the past, you were ALWAYS against romabiliy... And now you want to work on the Kickstart ?
No, I want to work on the *operating system*. Note the difference. The build process creates ROM modules along with the ROM, if you want to. The modules you can then load with LoadModule - same as ever. The most likely outcome of this process is anyhow that the updated modules will likely not fit into the ROM space, so something has to go there.
Traditionally, this has been the workbench.library, though I believe mathieeesing should also better be RAM-based as its proper setup requires the processor libraries anyhow, and the audio.device is another prime candidate to be moved out of ROM since it is really not needed for bootstrap.
One way or another, this is not a decision I will make, and the primary and next goal is to integrate the fixes I have and then see how to move forward from there. You change your mind because now you smell money (V2, new P5 boards...) with Kick ?
Are you serious? There is no money in Amiga, and that's not why I'm doing this in first place. Remember, I already have a job. Or rather, something close to two jobs. I don't have a contract with Hyperion, and I don't get any money for this. I'm neither expecting anything here. I'm very curious to know how much money Microsoft (or other...) give you to destroy the Amiga by the inside using division and different directions between us...
Whoha! If Microsoft research would offer me a position, I would take it... They are doing pretty cool stuff over there.
But seriously: No, I don't get money from Microsoft, and I pretty much doubt that they see in AmigaOs any sort of threat for their business. If they are even aware of our little toy operating system in first place.
-
then lost a lot of time testing the results because my only 68000 machine had failed.
I find this... astonishing :confused:
Between a handful of emulators, FPGA, Minimig and rather cheap systems from ebay...how hard is it to get access to a 68000 system? Don't you at least have people who can run tests for you?
-
I find this... astonishing :confused:
Between a handful of emulators, FPGA, Minimig and rather cheap systems from ebay...how hard is it to get access to a 68000 system?
Until very, very recently WinUAE support for SANA-II hardware was very limited. Roadshow needs to be able to send and receive Ethernet packets for a test to be in any way representatitive of what problems it might encounter on real hardware (e.g. A600 with cnet.device + NE2000-compatible PCMCIA hardware). In fact, it wasn't until yesterday that I was able to use the A2065 support in WinUAE public beta #13 and have Roadshow run through a complete DHCP exchange, assigning it an IPv4 address from my local network.
So far I tried to get by with "real" vintage hardware and did not see the need to with a Minimig.
The (so far) last 68000 machine I bought on eBay was the A600HD which failed in 2015. I did not repeat the exercise, because this year 2016 has been the most stressful and busy in a very long time. My priorities had shifted elsewhere, and something had to give... It happens to all of us, I suppose.
Don't you at least have people who can run tests for you?
In the mean time I managed to ask for help, the end result being the Roadshow 1.12 update, whose README file credits the testers.
I consider it likely that future 68000 testing can be conducted primarily in emulation, now that the A2065 support in WinUAE finally seems to put all the necessary pieces together.
-
@Olsen
I believe if you need resources such as a working A600 (either replaced or repaired) or some cash to get some testing machines a simple PayPal account or some way to show support would likely yield some good results.
There are a lot of motivated users wanting to see OS3.x move forward. You just need to ask.
Have a great day!
-
@Olsen
I believe if you need resources such as a working A600 (either replaced or repaired) or some cash to get some testing machines a simple PayPal account or some way to show support would likely yield some good results.
There are a lot of motivated users wanting to see OS3.x move forward. You just need to ask.
Have a great day!
The A600HD issue (which seems to have gained a life on its own by now, it seems) was not a question of money, but of a different type of resource: spare time. Had that been available in 2015/2016 to a larger degree, Roadshow 1.12 might have shipped earlier ;) I just lacked the necessary time to see it through.
But I'll have to look into how one might get that A600HD repaired here in Germany. With the exception of my first Amiga (a 1987 A500, the type with a red keyboard LED) and of course the A600HD, all other 68000 machines which I own are still in good working order. However, none of these other 68000 machines can be conveniently fitted with networking hardware.
I do appreciate the offer to help :)
-
@thread
there's a brief update from hyperion (http://www.hyperion-entertainment.biz/). apparently a few customers had difficulty booting from the workbench images on some systems....
Bugfix update for Workbench 3.1 (40.43)
Brussels, October 25, 2016
Hyperion is pleased to announce the immediate availability of an update to the recently released Workbench 3.1 (http://www.hyperion-entertainment.biz/index.php/where-to-buy/direct-downloads/171-workbench-31-4043-for-desktop-amiga) (40.43) to address a few reported issues.
Registered customers can download the free update from the restricted download area (http://www.hyperion-entertainment.biz/index.php/downloads) on the Hyperion Entertainment website, new customers will automatically get the fixed version via our fulfillment partner avangate.
-- eliyahu
-
apparently a few customers had difficulty booting from the workbench images on some systems....
Wonder if it's a similar problem to what Cloanto had with their "3.X" ROM's?
-
Wonder if it's a similar problem to what Cloanto had with their "3.X" ROM's?
If you look at the description of the problems, its rather that the boot block has not been written in one of the floppies and the protection bits have not been set correctly. I'd call this harmless. As said, this is not a "all new" ROM, but its a minor update of the current 3.1 ROM from the latest CBM sources, with bug fixes only.
-
Wonder if it's a similar problem to what Cloanto had with their "3.X" ROM's?
If there are similarities, I expect they resulted from changing what used to work back in 1994 and finding that subtle problems slipped through the testing process.
In the case of this Workbench/Kickstart 3.1 update, the changes made were deliberately kept small so as to reduce the risk of breaking anything. That was the plan, but what caused the troubles was for one part the build process itself, and the subtleties of writing installation scripts.
The build process cranks out ready-made Kickstart ROM images and a set of drawers whose contents correspond exactly to the Extras/Fonts/Install/Locale/Storage/Workbench disks. In order to create those disks, the respective contents are copied to RAD: and the result then goes into an .adf image, one disk at a time. The Install/Workbench disks are special in that they both need to be bootable (they have been since the original 1994 release), and that the respective disk boot blocks need to be installed manually (ever tried "install rad:"?). Lack of automation of this process kept the Workbench disk from being bootable (the A4000T has its own issues with the Workbench disk; see below).
The contents of the Workbench disk set in this update are peculiar in that their contents were slightly rearranged so as to make one single set which can be used both on the A4000T and all other Amiga models. Because the A4000T does not have workbench.library in ROM, Commodore shipped a special variant of the Workbench 3.1 installation disk set, and that wasn't going to fly.
Making an installation disk set which works with all Amiga models resulted in disk space constraints, i.e. you can boot off the Install disk, but due to Workbench disk lacking the workbench.library, booting from it is not an easy option on the A4000T. Something had to give :(
What broke the installation script, which ended up copying the contents of the Install disk to the newly installed Workbench "fonts" drawer, was a change made so that you could more easily install everything from a single disk: just copy all the disk contents into drawers on the installation medium, set up assignments to those drawers and launch the installation script: no more prompting to insert a disk.
Because the Installer tool allows/needs very strict control over whether installation is permitted from an assignment rather than a volume, this caused trouble with the "Fonts" disk. If the Fonts disk was not present, then the installation script would copy the contents of the drawer which "FONTS:" was bound to. Because there is no "fonts" drawer on the Install disk, the "FONTS:" assignment was bound to the root directory of that disk (this is what the boot process does by default), and hilarity ensued... How do you fix that? You can actually test if "Fonts:" is an assignment, and you can test if that assignment refers to the boot disk's root directory. If so, then you can tell the Installer to prompt for the Fonts disk to be inserted and the assignment to be ignored. Even back in the day there was little love for Installer scripts. Now you know why.
Bottom line is: you will likely miss something important if you change anything at all, no matter how little the change was :(
-
The fonts disk was always a strange one. The other disks all have a 3.1 suffix - Workbench3.1, Storage3.1, etc. but Fonts doesn't. Was that so floppy-only users could simply insert the disk and not have to worry about an assign? (Come to think of it, I think the Locale disk behaves the same way). Kinda strange that they didn't do an "assign fonts: fonts3.1: add defer" line in the floppy startup-sequence instead...
-
The 4000 and 1200 KS ROMs are a single 512KB file. What can I use to break these KS ROMs into two parts for the even and odd ROMs? Or, can these motherboards accept a single 512K ROM?
-
The 4000 and 1200 KS ROMs are a single 512KB file. What can I use to break these KS ROMs into two parts for the even and odd ROMs? Or, can these motherboards accept a single 512K ROM?
Didn't find (or look, really) for anything for Windows/Linux/Mac, but I found
http://aminet.net/package/util/boot/splitkick13
-
The fonts disk was always a strange one. The other disks all have a 3.1 suffix - Workbench3.1, Storage3.1, etc. but Fonts doesn't. Was that so floppy-only users could simply insert the disk and not have to worry about an assign? (Come to think of it, I think the Locale disk behaves the same way). Kinda strange that they didn't do an "assign fonts: fonts3.1: add defer" line in the floppy startup-sequence instead...
The Workbench 3.1 disk set has more than one purpose. My pet theory is that this produces certain requirements and limitations.
The first purpose is to provide a bootable Workbench, and you better have a second floppy disk drive handy, because you are going to need it. You will end swapping the Fonts/Locale disks in and out time and again.
The second purpose is to install the contents of the disk set to hard disk. One floppy disk drive is sufficient for that.
The Fonts/Locale disks can be conveniently used both by the Workbench and the Install disks without having to tinker with the Locale and Fonts assignments. It simplifies things a bit. Furthermore, the installation script is using the default Installer command for prompting a disk to be inserted, which is hard-wired not to accept an assignment as a substitute for a volume (you can override this default behaviour, of course). This is really the least complex solution that works.
The updated Workbench disk set, which allows you to use assignments in place of volumes, is comparatively more complex because it overrides the default behaviour of the Installer "prompt for disk" command, which in turn caused further complications.
-
The 4000 and 1200 KS ROMs are a single 512KB file. What can I use to break these KS ROMs into two parts for the even and odd ROMs? Or, can these motherboards accept a single 512K ROM?
Which layout exactly is needed? Could you describe it?
-
Well look at that - the Register has an article on the update:
http://www.theregister.co.uk/2016/10/26/it_took_20_years_to_get_amiga_workbench_31_an_update_and_only_a_fortnight_to_get_patched/
-
Deactivated "FF" program in Startup-Sequence to prevent problems on 68020/030 processors
FF???
-
FF???
FastFonts. First, v37 already indroduced a faster font renderning, and second, FF only worked with topaz.8 all the time. You'll find my "FastFonts" on Aminet which also speeds up topaz.9 (the larger cousin). Nevertheless, none of these programs is essentially required anymore as text rendering has been improved a lot anyhow.
-
I cannot remember having FastFonts, only SYS:System/FixFonts, and certainly never had it in startup-sequence.
-
FF???
More like WTF, actually...
The "FF" command ("FastFonts, Copyright 1986 by Microsmiths, Inc, Non-exclusive license granted to Commodore Business Machines") accelerates rendering of the "topaz" font family (8, 9 and 11 point sizes) by adding a simpler rendering path on top of graphics.library/Text.
The original graphics.library/Text function deals with all kinds of fonts, fixed-width, variable width, etc. and features only a single all-purpose bitmap glyph extraction/rendering routine.
If you know in advance what you are dealing with, then you can write special case code for the glyph extraction/rendering and on a 7 MHz 68000 machine that change could really matter.
Commodore shipped the "FF" command with Workbench 1.3, as a standard feature. However, it turned out that on machines with an 68030 CPU or better the accelerated glyph extraction showed a curious bug.
How curious? Imagine you wanted to play a prank on a friend by installing a shell command which would perform real-time ROT13 encryption for all text that would be printed on the screen with a "topaz" family font.
While this can be somewhat entertaining for a while, it looked too much like a bug, which is why the "FF" command invocation in the S:Startup-Sequence has been commented out. it's the only way to be sure.
-
Oh... this is Workbench 1.3.3, my eyes must have crossed, thought it was 3.1.
-
More like WTF, actually...
The "FF" command ("FastFonts, Copyright 1986 by Microsmiths, Inc, Non-exclusive license granted to Commodore Business Machines") accelerates rendering of the "topaz" font family (8, 9 and 11 point sizes) by adding a simpler rendering path on top of graphics.library/Text.
Actually, it always *claimed* to accelerate all topaz, but it did not. It only worked for topaz.8 and did nothing for topaz.9 and topaz.11, despite what the command invocation says.
No matter what - the v37 text rendering engine was improved by a lot. It's for topaz.8 not quite as fast as FF (or for topaz.9 for mine), but what's a couple of milliseconds amongst friends if the engine is more flexible.
-
Oh... this is Workbench 1.3.3, my eyes must have crossed, thought it was 3.1.
Two out of three ain't bad ;)
Oops, I just found the source code. It seems that what triggers the bug is that the fast rendering operation involves self-modifying code. Which might have worked sufficiently well on the humble 68000, but less so on the 68030 and beyond.
-
Which layout exactly is needed? Could you describe it?
I believe it is divided into EVEN and ODD ROMs, but I do not know if that is bytes or words. I read somewhere that WinHex will work for this application in EVEN/ODD words.
I need to pull out the 1200 and 4000 schematics. I am curious if I can go larger. 512k in two ROMs is 256k, but I wonder if I can use 512k ROMs and build a 1MB ROM image, instead -- with the caveat that my CYberStorm will only MapROM up to 512k.
I am pretty stoked, though. I never bothered to build my own ROM, though I have wanted to. In my 4000 that is mostly irrelevant since I have a Deneb with the FlashROM loaded with stuff, but for my 1200, 2000, and 500+, I now have a more up-to-date ROM and may even be inspired to build a custom one to eliminate those annoying power-up reboots.
-
I believe it is divided into EVEN and ODD ROMs, but I do not know if that is bytes or words. I read somewhere that WinHex will work for this application in EVEN/ODD words.
I need to pull out the 1200 and 4000 schematics. I am curious if I can go larger. 512k in two ROMs is 256k, but I wonder if I can use 512k ROMs and build a 1MB ROM image, instead -- with the caveat that my CYberStorm will only MapROM up to 512k.
AFAIR I just saw this conversation somewhere within the past year or two. A1200 can take up to 1MB but A4000 needs something like a ROMY to do it.
In the same thread someone mentioned some MapROM software that could support up to 1MB, but I don't recall what thread off-hand.
More info here: http://www.amiga.org/forums/showthread.php?t=64034
-
Furthermore, there is a lot of 68k material from Hyperion that could have been included to enrich this release, at no cost of development at all. It was just a matter of collecting it from OS4 releases and prereleases.
There's even earlier 68k stuff which could have been included, such as the Y2K fixes (I see the fixed SetClock for 1.3, but IIRC there was something for 3.1 too), the "Euro" update (whether a good idea or not, it's marginally better than not having € available at all on the default fonts), the updated Installer (v43) and - and I'd have thought this would be a shoe-in - SetPatch v43, if not Hyperion's later v50 which works fine on 68k and patches some extra stuff according to the output.
I also get the impression from the OS4 docs, that some parts of OS4's diskfont.library (the outline fonts improved API) date back to before OS4 and presumably were originally for 68k.
Of course there are loads of early 68k components in OS4, a lot of which are updated versions of ones in 3.9.
Lots of scope for future updates for not a lot of effort. Given Hyperion are behind this, getting it feature compatible with 3.9 should be possible, although that's not necessarily the goal.
As a side note, I always thought the naming of 3.5 and 3.9 was terrible. Leaves no scope for newer 3.x versions without resorting to increasingly confusing version numbering.
-
AFAIR I just saw this conversation somewhere within the past year or two. A1200 can take up to 1MB but A4000 needs something like a ROMY to do it.
In the same thread someone mentioned some MapROM software that could support up to 1MB, but I don't recall what thread off-hand.
More info here: http://www.amiga.org/forums/showthread.php?t=64034
Nice, thank you. I wonder why Hyperion chose then to limit the 1200 ROM to 512k with the sacrifice of workbench.library in ROM. I like the ROMY, and will have to see if Cosmos has any available should I decide to build a custom ROM. I suppose from reading further up someone would have to update a ROM splitter to help pull out the updates from the new ROMs, provided that would be my starting point, anyway.
As a side note, I always thought the naming of 3.5 and 3.9 was terrible. Leaves no scope for newer 3.x versions without resorting to increasingly confusing version numbering.
Always wondered about this. 3.9 always seemed too final. I suppose we were hoping 4.x would be 68k, as well, but with new bang-up features.
-
They probably wanted to suggest some quantity update in the perspective, justifying major version number jump. However i see nothing inconsistent if there was 3.10..
-
Nice, thank you. I wonder why Hyperion chose then to limit the 1200 ROM to 512k with the sacrifice of workbench.library in ROM.
Because 512K is the ROM size of the machine that can be provably addressed. Only the cd32 had a 1MB ROM, and the lower ROM contained some specific cd32 features, so even there it was not exactly part of the kickstart.
Actually, the ROM creation tools get this wrong, too. They write "1MB" as ROM size into the ROM code, but that's incorrect. A 1MB "ROM" consists of a 512K Kickstart, indicated in that size, and the overflow area, which is nowhere indicated in the kickstart itself.
One way or another, the 1MB ROMs may cause trouble as far as compatibility is concerned, so it's just understandable that this route was not taken and the safer and cleaner alternative of offloading some modules was picked.
I like the ROMY, and will have to see if Cosmos has any available should I decide to build a custom ROM.
Except that the tool is not indicating the ROM size correctly...
Always wondered about this. 3.9 always seemed too final. I suppose we were hoping 4.x would be 68k, as well, but with new bang-up features.
I agree. The naming was not logical. The "3.5" should have really been 3.2beta, and the 3.9 should have been "3.2 final", but you cannot sell it as such. One might guess that 3.9 was picked as an indicator that back then the players didn't want to provide another update for the 68Ks.
-
There's even earlier 68k stuff which could have been included, such as the Y2K fixes (I see the fixed SetClock for 1.3, but IIRC there was something for 3.1 too), the "Euro" update (whether a good idea or not, it's marginally better than not having € available at all on the default fonts), the updated Installer (v43) and - and I'd have thought this would be a shoe-in - SetPatch v43, if not Hyperion's later v50 which works fine on 68k and patches some extra stuff according to the output.
The copyright situation is there a bit delicate, which is likely why it wasn't done. As far as the 3.9 components go, in my case I have a copyright "on the modifications"(!) I did (not on the original source). While that grants me not much (I cannot publish the code or make it available - my code isn't workable without the CBM code, despite it's very hard to separate what is mine and what is theirs), it neither grants Hyperion (or H&P) much (they don't have the right on my modifications either). I guess this also holds for other developments that came into 3.9.
One way or another: Heinz is the contributor of the above components, and he needs to be in the boat to get those updates. Quite frankly: I would be happier without NSDPatch, with a better ROM patch mechanism and with native TD64 support in the FFS and would rather update those two by myself...
I also get the impression from the OS4 docs, that some parts of OS4's diskfont.library (the outline fonts improved API) date back to before OS4 and presumably were originally for 68k.
Same problem, likely. There were also improvements in diskfont for 3.9, namely the disk font cache. Same problem again: Partially my code, my copyright. Base code is not my code, so I cannot distribute it either. Bummer!
I don't have a contract at this point, so it cannot go in. Not that I'm unwilling to change that.... I hope I can. I'm really happy that something is moving, and I hope I'll be able to contribute.
Lots of scope for future updates for not a lot of effort. Given Hyperion are behind this, getting it feature compatible with 3.9 should be possible, although that's not necessarily the goal.
I believe a lot is possible if you can get hold of the corresponding authors and get them together. I see a market here, so it is very much in anyone's interest.
As a side note, I always thought the naming of 3.5 and 3.9 was terrible.
You are not alone.
-
Using 1mb rom hasn't caused any problems to me. I have had them inside of my two A1200 Computer some years.
Creating 1mb rom with remus / romsplit is requires some studies, but is simple task after that.
First rom is standard 512kb rom $F80000 and second one is extended 512kb rom $E00000
I have bought both of those, sadly rom split doesn't support them.
-
As a side note, I always thought the naming of 3.5 and 3.9 was terrible. Leaves no scope for newer 3.x versions without resorting to increasingly confusing version numbering.
What's wrong with 3.10? And then 3.11 for Workgroups - aka built in Envoy? :)
-
What's wrong with 3.10? And then 3.11 for Workgroups - aka built in Envoy? :)
For a start, in 1993 Commodore disbanded the networking group which at the time had been responsible both for the AS225R2 TCP/IP stack (derived from 4.3 BSD Reno, if I remember correctly) and Envoy.
Development of both projects stalled and was never completed in-house. Years later INet-225 and Envoy 2.0 would surface as polished commercial products.
-
Development of both projects stalled and was never completed in-house. Years later INet-225 and Envoy 2.0 would surface as polished commercial products.
Yes, at some point we were a bunch of students who tried to have the university sponsor us Inet-225, but it wasn't successful :) I did buy Envoy 3.0 eventually, which could use existing TCP-stack, but I recall a lot of hassle because of Envoy using different uid/gid scheme (with "nobody" instead of "root" being uid/gid 0? I don't recall...)
-
Does anyone know if the Winbond W29C040 can be used to hold a Kickstart for the 500/2000 as a drop-in replacement for a 512k EPROM?
-
Hi everyone, i use 3.1 workbench. I want to know how big of a hard drive can use this drive size 2.1Gb and 2.15 Gb hard drive. But i am useing a gvp controller card my computer is useing a 68040 Cpu. How can i get a set of those disk?. Can you mail me the set to this address
Kenny smith
10460 EL Mercado Dr Apt 67
Rancho Cordova ca 94670 usa.
-
Hi everyone, i use 3.1 workbench. I want to know how big of a hard drive can use this drive size 2.1Gb and 2.15 Gb hard drive. But i am useing a gvp controller card my computer is useing a 68040 Cpu. How can i get a set of those disk?. Can you mail me the set to this address
Kenny smith
10460 EL Mercado Dr Apt 67
Rancho Cordova ca 94670 usa.
Theoretical limit for your boot partition is 4GB, under 3.1. You can have extra partitions, but the max limit for those is 8GB.
It makes sense to use a little less than the maximum limit.
GVPTools is what you seek, same software for all GVP SCSI controllers... BUT... some of them have 68040s, and most don't.
Even with a ROM upgrade to 3.9, you will still be limited to an overall maximum of about 128GB for total drive size.
It is a bit difficult to answer WHICH vesion of GVP software you need without more information about your setup - which Amiga? Which GVP expansion?
For instance, is the SCSI interface part of the 68040 accelerator card, or is a separate card?
It makes a difference, as there is no point posting links to stuff that is irrelevent to your needs.
-
Does anyone know if the Winbond W29C040 can be used to hold a Kickstart for the 500/2000 as a drop-in replacement for a 512k EPROM?
Chip can hold the data but will not physically fit, as it is not a DIL (Dual InLine) package.
It is available in TSOP and PLCC form, but not DIL, sometimes called DIP (DualInlinePackage).
-
GVPTools is what you seek
GVP FaaastPrep software is horribly outdated. Even if you can get it to not trash your hard drive, I think it freaks out with drives much larger than 1GB. Dude should be using the latest version of HDtoolbox, just like most of us... and not spamming on unrelated threads, lol. ;)
-
Fast prep sucks rocks. Threw out the disk when I got my A2000 that came with it.
-
Chip can hold the data but will not physically fit, as it is not a DIL (Dual InLine) package.
It is available in TSOP and PLCC form, but not DIL, sometimes called DIP (DualInlinePackage).
I have ten of them in DIP form-factor sitting here which would disagree with you. In the TI world there is a special setting on the home-brew cart boards which are required to make it work similarly to a 512k EPROM. My guess is the 500/600/2000 have the same problem and it won't be a drop-in replacement. If no one else has tried it I will have to at some point in the near future. I will make one using the purchased ROM files, though I would rather build my own.
-
GVP FaaastPrep software is horribly outdated. Even if you can get it to not trash your hard drive, I think it freaks out with drives much larger than 1GB. Dude should be using the latest version of HDtoolbox, just like most of us... and not spamming on unrelated threads, lol. ;)
Good God, I haven't seen or used FaaastPrep since WB1.3 days. Yeah, no, and yeah, as Gold Five says: "Stay on target."
-
as Gold Five says: "Stay on target."
:laughing:
-
I have ten of them in DIP form-factor sitting here which would disagree with you. In the TI world there is a special setting on the home-brew cart boards which are required to make it work similarly to a 512k EPROM. My guess is the 500/600/2000 have the same problem and it won't be a drop-in replacement. If no one else has tried it I will have to at some point in the near future. I will make one using the purchased ROM files, though I would rather build my own.
Don't shoot the messenger if the datasheet is plain wrong.
-
as Gold Five says: "Stay on target."
Shortly before being blown out of the sky, as I recall. :)
But yeah, OK, it started as a necropost and went pear shaped very quickly. Fair play.