With no downloads available, I dont see a reason to update or even test something that I cannot even lay my hands upon.
Now, what an irony. Here comes the ignorant of licences, and he's irritated by somebody ignoring "his hard work" he has stolen by ignoring somebody else's hard work... Oh boy...From his website:
"Update :
I just saw some %&$#?@!%&$#?@!%&$#?@!%&$#?@!ers sell my hard work on EAB,so no more release here."
One kickstart for all amigas sounds like a nightmare to get right :)
There are probably lots things on everyone's wish list. The first item on mine would be the ability to boot from CD. This would make preserving our favorite system a lot more foolproof and user friendly going forward.
aros kickstart is the answer;)
Does it come with a scsci.device that detects and supports all the different disk controllers?
There are probably lots things on everyone's wish list. The first item on mine would be the ability to boot from CD. This would make preserving our favorite system a lot more foolproof and user friendly going forward.
One kickstart for all amigas sounds like a nightmare to get right
With no downloads available, I dont see a reason to update or even test something that I cannot even lay my hands upon
Now, what an irony. Here comes the ignorant of licences, and he's irritated by somebody ignoring "his hard work" he has stolen by ignoring somebody else's hard work... Oh boy...
Uhm, why old shell and ram-handler?
Commodore ingenieers were paid. Me no... Another big troll...
...
Because these updates from the 3.9 were from SuperTroller : he will cause me trouble later...
I guess you could say that everyone stole from Alan Touring, or something like that.
Are you going to pick an older component, with known issues, because you don't want the hassle of dealing with a developer who worked on a more recent version because he questions your choices?
Because these updates from the 3.9 were from SuperTroller : he will cause me trouble later...
:)
I see great motivation in the work that Cosmos does.
I doubt that this is going go happen, seeing how Cosmos has picked his priorities, and how he engages with other developers who may not share his outlook on the work being done.
I also Thomas point here that if this effort of Cosmos would be coordinated more with the OS4 guys or with the AROS guys the end result might even be better.
Updating the Amiga operating system is a tough task to begin with, and if it is to be taken beyond a hobby project, the work will have to involve a plan as to what goals should be achieved, a development work schedule, documentation, testing, collecting feedback and a release schedule. This calls for a coordinated team, and a one-man-army approach is likely to be overwhelmed by the workload.
I meant the internal controllers provided with scsi.device in kickstart, like A600, A1200, A4000, A3000, A4000T and I have probably forgotten some. Those are mainly the reason why there are different kickstarts in the first place.
I meant the internal controllers provided with scsi.device in kickstart, like A600, A1200, A4000, A3000, A4000T and I have probably forgotten some. Those are mainly the reason why there are different kickstarts in the first place.You are correct.
I still dont see what workbench.library and icon.library does in kickstart, unless you also throw in loadwb.
There are many things that shouldn't really belong into kickstart. In fact, the kickstart should be as small as possible to ease upgrading and replacing components. Let's be realistic: Assume that we have a hard disk controller which can read at 1.5MB/sec (slow) behind a filing system, so you probably get 500k/second. That means that the entire kickstart could be loaded in a second. Give it maybe two seconds. Is two seconds boot time worth the effort of placing stuff in ROM?
a time getting the basic three "scsi.device" variations to work together in ROM: one of them will always crash.
I still dont see what workbench.library and icon.library does in kickstart
The ROM read physically limited to 3.5 MB/sec on classic
Quote from: Cosmos;779281No. If for example an A3000 is not detected, the scsi_3000.device inside my kickstart won't init... You really take me for a beginner in coding...Please don't assume that I make assumptions about your abilities.
How do you detect the A3000 hardware, as opposed to the A4000 hardware? As far as I could claim to understand the specs, the A3000 hardware was not designed to support auto-detection of features, as opposed to the Gary/Gail hardware used in the A4000/A1200/A600, respectively.
How do you detect the A3000 hardware, as opposed to the A4000 hardware?
I want a fully system ready at power on. No more SetPatch, no more boring and slow loading on HD or CF. The goal is like the old computers : Oric, Amstrad, Atari ST...
You are correct.
The SCSI "scsi.device" versions in the A3000 and A4000T ROMs are built to assume that the hardware required for SCSI operations (DMA controller, WD or NCR SCSI chip, respectively) is present. This built-in hardware is not placed in AutoConfig space.
The IDE "scsi.device" present in the A600HD, A1200HD and A4000/A4000T can auto-detect the presence of the required Gayle/Gary hardware, which as far as I know is not a given for the A3000/A4000T specific SCSI hardware.
The other reason why there are ROMs specific to the A3000 and A4000 models is in that the RAM controller (Ramsey) may have to be asked to support page mode for the peculiar type of DRAM that may be installed in these machines. As far as I can tell this does not seem to be necessary, though. Support for page mode (also called "static column mode") was intended to improve DRAM performance on the A3000, using the 68030 under certain circumstances. In practice the gains were not as significant. If I read my A3000T service manual correctly, Ramsey should boot with safe defaults, which makes switching to page mode unnecessary; it's also quite difficult to do without crashing, because you have to fiddle with the Ramsey configuration while not running afoul of ongoing DRAM refresh and other flaming hoops to jump through.
Finally, different types of ROMs are required by different machines, with respect to where the kernel is to look for ROMTags, how much stack space it may use, etc. If I remember correctly, the big difference here is between the machines built around the architecture of the A3000 (which includes the A4000 and A1200 models) and those which precede it (this being the A2000 and the A500; I think the A600 belongs here, too).
In a nutshell, if you're going to bootstrap the system, from the bare metal, in a real Amiga, then you will have a devil of a time getting the basic three "scsi.device" variations to work together in ROM: one of them will always crash.
TBH, a lot of these things get updated frequently, however. A new version of icon.library was just released two days ago. It's going to be hard to keep current, if you want "the latest and greatest" in your ROM
QuoteHow do you detect the A3000 hardware, as opposed to the A4000 hardware?
With Ramsey !
Olsen, i may be reading this wrong,but static column ram and page mode are 2 different things. static column is just that static ram,and page mode ram is more akin to the fpm style ram. the ramsey revision 4 had a bug in it where when the a3000 is used with a A3640, it will not detect and use static column ram properly,hence page mode zips must be in the first bank to thwart this bug(page mode and static column can be mixed in this situation still-but all runs in pagemode). This was fixed in ramsey 7 which detects the ram correctly as i understand. This has been my real life experience using the real machines.
This makes sense.
The ROM read physically limited to 3.5 MB/sec on classic
To fastmem on a CPU card the read speed would be over a magnitude faster.
This means for performance reasons we want to put the Kick in fastmem anyway.
So A1000 design to have a small bootrom and the KICK then placed into WOM-Ram is ideally for this.
A noble goal. I missed that when I went from C64 to Amiga. We've all just gotten used to requiring a disk to boot with "modern" computers.And where precisely is the problem with that? I've here a SSD in a modern system, boots up in probably ten seconds, makes no noise. You can also bootstrap the Amiga from an SD-card, much simpler, fast enough for the purpose, no noise, takes almost no space. The advantage is that is so simple to exchange system components. Read it as "flash RAM containing the kickstart files" if that makes it sound better.
If you want a faster Kickstart for 68000 base machines than why not remap it in to 32 bit Fast RAM?
Finally, different types of ROMs are required by different machines, with respect to where the kernel is to look for ROMTags, how much stack space it may use, etc. If I remember correctly, the big difference here is between the machines built around the architecture of the A3000 (which includes the A4000 and A1200 models) and those which precede it (this being the A2000 and the A500; I think the A600 belongs here, too).
And where precisely is the problem with that? I've here a SSD in a modern system, boots up in probably ten seconds, makes no noise. You can also bootstrap the Amiga from an SD-card, much simpler, fast enough for the purpose, no noise, takes almost no space. The advantage is that is so simple to exchange system components. Read it as "flash RAM containing the kickstart files" if that makes it sound better.
There are probably lots things on everyone's wish list. The first item on mine would be the ability to boot from CD. This would make preserving our favorite system a lot more foolproof and user friendly going forward.
For Kickstart 3.1 there were different versions for different hardware because there wasn't enough time to fix all the bugs (they'd fix one and it would break something else) and also due to rom size (A4000T needing both scsi & ide for example). They could have pushed workbench.library onto disk for everybody and included all the devices with auto detection, but there wasn't a business case for it.
Thats not true.
There are different hardwarespecific versions of exec, expansion and devices.
The A1200,A3000,A4000 & CD32 versions are 020+ optimized .. not working on 68000.
The A3000 is very special .. the ONLY rom with real FPU-code inside !!!
A600/A1200 includes some PCMCIA-code.
A3000/4000 includes "bonus" for onboard fastmem.
It's true that back in the day I ran Kickstart 3.0 from an A1200 on an A500 with a phase vi 14mhz 68000 (I didn't try 3.1 as I bought the a500 upgrade). It's true that they cherry picked different releases for each platform based on which worked at the time they submitted the 3.1 roms to manufacturing (I'm sure that years ago there was an description written by someone at commodore about why they picked each one). it's true that they could have produced one that worked in them all if there was a financial reason to.
Now, what an irony. Here comes the ignorant of licences, and he's irritated by somebody ignoring "his hard work" he has stolen by ignoring somebody else's hard work... Oh boy...[/LEFT]
[/CENTER]
That's just plain ignorant. When someone takes someone else's work and appropriates it for profit without a word of acknowledgement, that's BAD. Simple.
Is he making a profit off it somehow?
That does not matter for legal aspects. It's using somebody's original work and releasing it to the public without having any rights on the work. Exec and Intuition did not fall from the sky. These are copyrighted protected works, owned by whomever has rights on it. Stealing a book from a bookstore and offering it for free for everyone on the street is still illegal, no matter whether he's selling the work or giving it away for free.
But it's really quite simple. If he believes that the owner has no interest in the work - get in touch with the owner and find out. I would consider that at least two parties would be interested here. Did he?
The A1200,A3000,A4000 & CD32 versions are 020+ optimized .. not working on 68000.I did not check the details just yet, but the use of '020 specific code is rare in the bulk of the operating system, which would be components such as intuition.library, graphics.library, workbench.library, etc. The 'C' compilers used at the time were not considered sufficiently mature to produce '020 code suitable for ROM code.
The A3000 is very special .. the ONLY rom with real FPU-code inside !!!I would expect that this is in "mathieeesingbas.library".
A600/A1200 includes some PCMCIA-code.Yes, and the operating system auto-detects the presence of the hardware. For example, the A600 ROM is used in the A500+, the A600 and the A2000, if I remember correctly. Of these only the A600 has the necessary hardware to support PCMCIA devices.
A3000/4000 includes "bonus" for onboard fastmem.Yes, and it may be that this could be safely omitted, or the necessary hardware could be auto-detected. As it is, the "bonus" module is hard-coded to expect the Ramsey chip to be present and acts accordingly.
Why are you so stupid ?Because you misunderstand one central point. These are *not* *your* sources. They belong to somebody else. Whether you give them away for free or not is completely irrelevant for the question.
All my releases were for free download ! And my sources are private.
AmigaOS 68k is abandonned since many years...That does not make them open source. Just for your information, a "creative work" becomes "public" 70 years after the death of its creator. IOW, we'll still have to wait a long time until AmigaOs becomes "free".
The AFA project was supposed to update AmigaOS for 68k but failed at this point it seems, but the idea is actually good.Failed?
Kamelito
Why are you so stupid ?
Because you misunderstand one central point. These are *not* *your* sources. They belong to somebody else. Whether you give them away for free or not is completely irrelevant for the question. That does not make them open source. Just for your information, a "creative work" becomes "public" 70 years after the death of its creator. IOW, we'll still have to wait a long time until AmigaOs becomes "free".
Again, what's your problem of simply approaching the right holders and ask them a very simple question. "Can I use your sources in my hobby project"? The way you're acting right now does violate the rights of these partners. You can either develop from scratch (which you don't), or you can ask for a licence (which you didn't either).
That's not stupid - that's just what the situation is.
Thomas isn't stupid, he's simply stating copyright law... If you don't like the law, you need to take that up with the elected representive for your country's government.
Let me clear some points up for you:
1. I'm not sure what you mean by "creative work" but if you are referring to a copyright it is 70 years after the death of the author. Creator is vague and has different meanings in copyright.
2. If you mean "Creative Commons" then you are going to be really surprised.
3. Finally, none of this applies to Cosmos. He is French. Viva la France!
The words "stupid" and "copyright law" tend to go awfully well together these days, though. But just because one fails to take the laws seriously it does not follow that they do not apply in this case.
@Cosmos
can you please clarify whether you are merely distributing patches to commercial software or the commercial software itself already patched? if the former that's one thing, but if you're actually distributing components like exec.library and so forth, that is illegal. period.
-- eliyahu
I must have a half dozen of his patches on my system. Every single one has been just the patch file, and required a copy of the original file to work. I've also got some of @Thomas Richter's stuff on my system, as well. With the way these two go at it, it's a wonder my Amiga hasn't exploded! ;)i know, i know. :lol:
You guys are making a mountain out of a molehill, here, IMHO. Bunch of cranky old men arguing about copyright law for long-dead software. Life is too short! :furious:
Have there yet been any legal dispute over such things in "amiga land"? No? If noone takes any action to upheld the copyrights of the works, then for all practical purposes there is no longer any copyright on the works, regardless of the 70 years mickey mouse law.From what I gather, it is not quite so straightforward. Copyright persists even if the owner does not enforce it. It persists even if the owner cannot be found (orphaned works).
I must have a half dozen of his patches on my system. Every single one has been just the patch file, and required a copy of the original file to work. I've also got some of @Thomas Richter's stuff on my system, as well. With the way these two go at it, it's a wonder my Amiga hasn't exploded! ;)
You guys are making a mountain out of a molehill, here, IMHO. Bunch of cranky old men arguing about copyright law for long-dead software. Life is too short! :furious:
You can't sell it, you cannot sell derivate works, you're basically reduced to bootlegging.
Even if we accepted that the law's authority is rather shaky and has negative side-effects (orphaned works, no motive to preserve them, etc.), our position will be weaker if we work against the rules of the law. You can't sell it, you cannot sell derivate works, you're basically reduced to bootlegging. This is not how you care for the Amiga, in my opinion.
I am not a lawyer. The last time I had a look at how these things play out my impression was as follows:
1) There's the Berne convention, which covers works created by authors and those created for and owned by corporations. Protection covers 70 years after the death of the author, and 120 years after the creation of the work as owned by a corporation.
2) The protection/restrictions given by this legal framework do apply to citizens of the member states of the European Union.
3) Ownership of the Amiga operating system and its components, as well as works created for the AmigaOS updates 3.5 and 3.9 which may be relevant here is rather well-defined.
4) Authors and owners of said Amiga operating system and AmigaOS update 3.5/3.9 components may not want to enforce these rights, or may not be in a position to do so. It does not follow that their rights, in particular the moral rights of the authors, are forfeit if they do not enforce them.
Have there yet been any legal dispute over such things in "amiga land"? No? If noone takes any action to upheld the copyrights of the works, then for all practical purposes there is no longer any copyright on the works, regardless of the 70 years mickey mouse law.
It's true that back in the day I ran Kickstart 3.0 from an A1200 on an A500 with a phase vi 14mhz 68000 (I didn't try 3.1 as I bought the a500 upgrade). It's true that they cherry picked different releases for each platform based on which worked at the time they submitted the 3.1 roms to manufacturing (I'm sure that years ago there was an description written by someone at commodore about why they picked each one). it's true that they could have produced one that worked in them all if there was a financial reason to.
The 'C' compilers used at the time were not considered sufficiently mature to produce '020 code suitable for ROM code.
Olsen,Yes, this is a complicated subject. As a layperson I can barely hope to avoid misinterpreting the state of affairs, so what I picked up is probably no better than an opinion.
As a University Professor I had to teach basic copyright and patent law. They are very complicated with an endless list of exceptions depending on certain situations. I could list all the ones that come to mind but I just don't care enough about this thread. :-)
However, without comparing and contrasting French and American copyright laws I have no idea what parts of copyright law are the same in both countries. However, I can tell you from starting my own company that patents laws are very different from the US and Europe. Having experienced that, I am skeptical copyright laws in the US are the same in France.
My super objective was really pointing out that one cannot blindly apply US Law to the rest of the world. Though, it does seem like we do that too often.
Thanks for the reply though!
-P
Who's selling anything here? As Cosmos has stated multiple times, all his patches are free to download. He only pulled them recently because (as the quote on his website said, anyway) someone else was selling them over on EAB.I have a dog in this fight, because I'm actually selling Amiga software, specially made for the platform. As nice as it is to create software, it's one thing to do it as a hobby or for personal enjoyment, but it's another thing to be able to take time off your regular job and use that time to build something complex that might call for a larger audience.
Hell, I've been downloading his patches for years. After all this kerfluffle, I feel like I should probably send the guy a donation or something, LOL. ;)
................................................
IMHO it's because of all of this public slagging that developers get fed up and leave our community. So, a round of applause, everyone. Good job! :(
If i remember correctly ... you were the last person who compiled a complete 3.1 rom out of the sources, with the latest compiler versions ... saving some bytes here and there.I believe Heinz Wrobel worked on those parts, and he also built a special ROM image for the "Walker" machine, using existing components and modifications made which were needed to use the machine.
with exec.library v40.11 and "escom ag copyright" text ... including a 40.68/40.70 for a500/600/2000 models (not that 40.63 stuff).
did you know the current owner of the "rights" on aos 3.x-sources?I believe that Hyperion owns these rights, as a result of the lawsuit between Amiga, Inc. and Hyperion.
escom -> gateway -> and now acer ?
I believe that Hyperion owns these rights, as a result of the lawsuit between Amiga, Inc. and Hyperion.
isn´t layers.library v45 partially based on commodore-sources ?
It most definitely is. Actually, it is a version that is half-way between the 3.1 V40 release and the version in AOS 4.x. The big difference is here, however, that I approached the owner (or at least, the owner "to the best of my knowledge" - what else can you say these days) and asked specifically whether they would be ok with publication. IOW, I tried to back up myself as much as possible to avoid any conflict to begin with.
As for other components, i.e. the Shell, it was part of the contract with H&P what will happen with the copyright after two years, and I'm still trying to ensure that those that can apply these patches have at least the 3.9 version - whether legit or not I cannot verify, of course.
This is pretty much why I said in the beginning - there is probably no problem if Cosmos would just communicate better and would have just *asked*. The worst thing that could possibly happen is a "No". But the current way of acting makes the situation actually worse, not better. It creates a diverse universe of some "almost but not quite" AmigaOs components with slight incompatibilities and no ensured "software contract" that everything fits together as it should.
What I would really prefer would be a somewhat more coordinated activity, as in a project (let it be for paid or unpaid for developers) to create a framework where we can ensure that all components really work well together. That's currently not possible, and it's even less possible with people that cannot simply "play team". I'm trying to ensure that Olaf gets my updates, and that the functions for "layers" are in sync with AOS 4.x such that we don't create branches as far as possible.
Yes, it means making compromises, and it requires a somewhat different development style - and a massively different communication style. If you observe my rather "rough tone" here then that's because I'm personally *p&ss@d" by the amount of unprofessionalism that rather *prevents* than *supports* any coordinated activity. It simply doesn't work like this. It is damaging AmigaOs rather than moving anything foreward.
There isn't much of any type of project management for the "old" classic systems, and it would be so badly needed. It's part of the lack of responsibility of the owners to take these systems serious, most likely based on a return-of-investment reasoning. If the community ever wants to be taken serious, namely that such an investment might possibly worth it, then we should act more professional as a group and not as a collection of freaks (not excluding myself here).
Did AmigaInc. ever owned the rights?I'm sorry, this is not my field of expertise. I could only speculate that if a product is sold which requires the assent of the brand owner, then that assent must have been given. Whoever owns the brands and the trademarks must be public information, and is likely available online. I wouldn't where to start looking, though.
I thought, they only owned the brand.
It's been more than 20 years since Commodore folded. Assuming that Commodore was granted patents in that final year, then these patents have likely expired by now.
As a sideeffect, the rights and patents are still at escom (acquired by gateway, acquired by acer).
It may be a nit to pick, but there's really little difference between Cosmos saying, "Take your Kickstart file and apply these patches", which nobody can ever possibly say is wrong, versus actually providing the Kickstart file with those patches, which is debatable, but only slightly. I don't know anything about French copyright law, but I do know that US copyright law isn't the same as French copyright law and shouldn't be assumes to be the same.
Not the same, but still seems illegal.
http://en.wikipedia.org/wiki/DADVSI#Sharing_of_copyrighted_works_over_peer-to-peer_networks
There are certainly bigger fish to fry though. Although with TPB down the amount of piracy has dropped considerably, which might put you on the radar.
TPB is no longer down ;)
http://thepiratebay.cr/
Anyone willing to do 68000 KingCON ROMable? The things I want in kickstart are the things I want available when booting to shell without startup-sequence.I do not know if this applies to KingCON, but not everything is fit for inclusion in a ROM. The libraries, devices, file systems and handlers in the ROM (obviously) cannot modify static data or code. However, if such software is loaded from disk then there are no such restrictions. Stranger still, the respective author may not even realize that his software modifies data intended to be read-only (buffer overflows, subtle bugs, etc.), and that his software stops working correctly if that data cannot be modified.
KingCON has been ROMable for quite some time, but only for 020+.That might be more difficult to fix. Sounds like a partial rewrite/patch to me :(
TPB is no longer down ;)
http://thepiratebay.cr/
http://www.reddit.com/r/torrents/comments/2ouk92/thepiratebaycr_is_not_the_new_pirate_bay/
Not the same, but still seems illegal.
http://en.wikipedia.org/wiki/DADVSI#Sharing_of_copyrighted_works_over_peer-to-peer_networks
There are certainly bigger fish to fry though. Although with TPB down the amount of piracy has dropped considerably, which might put you on the radar.
WOuld it be possible to integrate CF card drivers somehow? I.E. a way to be able to detect and read CF cards right off the bat without requiring extras software on your boot disk and what not?I had a quick look at Torsten Jager's "compactflash.device", and I think that there are no technical reasons why it could not be put into ROM.
Although with TPB down the amount of piracy has dropped considerably, which might put you on the radar.
3. Use AROS equivalents for components you can't get approval for.
Simple :-)
This is supposed to be 3.9.1. AROS is only equivalent to 3.1, at best, and much less tightly written. So using AROS as a source for a "3.9.1" just won't cut it.
Would you seriously stop talking about what you have no clue about? There's a huge difference between claiming to be 3.1 compliant and being a 3.1 clone. AROS already surpasses 3.1 in many ways.
This is supposed to be 3.9.1. AROS is only equivalent to 3.1, at best, and much less tightly written. So using AROS as a source for a "3.9.1" just won't cut it.
You have no idea what's in an OS3.9 kickstart do you - it is all just relatively small updates to what's in an OS3.1 kickstart, they are essentially the same.
...
- added mathieeedoubtrans 45.6
- added mathtrans.library 37.2
These two libraries are used extremely rarely, and then only by disk-based applications which already take their time loading and running. Software which requires high performance math uses inline FPU instructions, and not this.
There is very little benefit of putting these two libraries into ROM, and you may find much better uses for the space occupied by them.
Sorry, but not in a real Amiga, over there, it is crappy shame.
In x86 or high speed emulation it is pretty good and I can agree that it surpasses 3.1. But in an Amiga is a big "NO".
The mathieeedoubtrans.library is important because of his sin & cos... Compilators must use it for getting only one programm for all 020+ (the 68060.library patch this mathieeedoubtrans.library).Yes, it's important for applications which cannot use inline FPU instructions, and actually use the transcendental math libraries (if I remember correctly, most applications used the compiler-supplied link libraries instead; the only serious user of the IEEE math libraries was ixemul.library).
This brings us back to the start! Replace the old stuff with the new stuff and you eliminate the reboot patch. Perfect sense.This is pretty much what I say. Nothing requires patching anything. What had to be written is only a small bootstrap loader that loads the libraries, devices and resources that are usually in ROM from the flash, and off you go. The bootstrap loader could be put in ROM, but would not require regular updating, unlike the system libraries which could be maintained independently. This is a much more flexible approach than any other "ROM update". It would boot rather quickly, and would allow system components to be upgraded without ever touching the ROM based bootloader. Simpler, easier, quicker...
The problem with the math libraries is worse, actually. The math libraries do not work "out of the box", they require CPU specific support. Actually, using the FPU requires CPU specific support, this is what the 680?0.libraries are good for. It is more than adding support for unsupported instructions - it is support for "non-normalized" IEEE numbers. IOW, if you want to use the IEEE code, *or* the FPU, you need the 68060/68040 library. Just "not using unimplemented instructions" does not help here at all - "unimplemented data formats" also exist.To add some more grist for the mill: there are several variants of the ROM-based mathieeedoubbas.library which need to be handled with care. One works on all 68k systems but does not use inline FPU operations, one works on everything that has an 68020 CPU or better installed but does not use inline FPU operations and one works on the A3000 where it assumes that both an 68020 CPU or better and an 68881 FPU are installed (no, it doesn't check if the hardware is there).
Sorry, but I don't like that... I want a computer fully operational at power on... Final point !
Quote
Originally Posted by Cosmos View Post
Sorry, but I don't like that... I want a computer fully operational at power on... Final point !
Well, as already said, there are multiple CPU libraries out in the world, and they are pretty hardware and vendor dependent. Olaf already said this.
But anyhow. Here's a deal. I'm happy to provide my versions, and make them even ROM-able if you can get them to work on *all* hardware variants you get. This is, in fact, the major show-stopper of placing anything of this in ROM since it creates a kickstart that will no longer work on some boards.
This is pretty much what I say. Nothing requires patching anything. What had to be written is only a small bootstrap loader that loads the libraries, devices and resources that are usually in ROM from the flash, and off you go. The bootstrap loader could be put in ROM, but would not require regular updating, unlike the system libraries which could be maintained independently. This is a much more flexible approach than any other "ROM update". It would boot rather quickly, and would allow system components to be upgraded without ever touching the ROM based bootloader. Simpler, easier, quicker...
I had a quick look at Torsten Jager's "compactflash.device", and I think that there are no technical reasons why it could not be put into ROM.
The harder part is in mounting the file system (such as Torsten Jager's "fat95"), and mounting it early enough so that it becomes available at boot time.
As far as I can tell the "fat95" file system is not suitable for ROM use, but small changes might make it so. I did not check, but if I remember correctly the "CrossDOSFileSystem", which would serve a similar purpose, is not fit to be put into ROM because it was always intended to be loaded from disk. So a modified "fat95" file system suitable for ROM use might be the only option right now.
That leaves the somewhat nontrivial matter of mounting the "CF0:" device. It's doable, though: "carddisk.device" in the A600/A1200 ROM is capable of it, and you can even boot off the volume once it has been mounted, if I remember correctly.
Whatever happened to pOS from ProDAD? :)
Why do we have to use fat95 with compactflash.device?I am sorry, I did not mean to imply that the "fat95" file system were mandatory. It just so happens that it is used in the default setup for "compactflash.device", as available from Aminet.
Why can't we use our CF cards with FFS, PFS or SFS? Am I missing something here? If I wanted to boot differing Amiga OS's/configs from differing CF cards then why would I want it to be using FAT? I don't want to use FAT, except when exchanging files with my Windows PC.Short answer: the operating system makes the "default ROM file system" responsible for a volume mounted on a storage device, and changing this default behaviour to pick a file system of your choice instead does not work out of the box.
Or you need to add additional code which reads the RDB (Rigit Disk Block) from the device, interprets it, bootstraps the filing system, and boots the device this way.Some more context in case the term "Rigid disk block" does not ring a bell: this is what the "HDToolBox" program in "SYS:Tools" is for. It allows you to manage the partition information, which file systems should be installed, etc. This information is written to hard disk in a specific layout and structure.
This is more complicated, allows partitionas, alternative filing systems... Interestingly, this work has to be done by the device driver, it's not part of the strap functionality.Yes, and that's a bad thing. The documentation for the partition data, how to read the contents correctly, etc. is quite good and robust, but it's possible to introduce your own subtle or less than subtle bugs if you have to write the code all by yourself. To the best of my knowledge there exists no reference implementation for processing the "Rigid disk block" contents at the device driver level.
How does booting from CD drives work, in comparison? CDTV and CD32.It's the same principle as for booting off a floppy disk. The "strap" module does more work here, though. It shows a much more elaborate "insert disk" animation, for a start ;) Hey, it even has a built-in screen saver.
Yes, thanks for history lesson :) Only want to point out that CD32 actually came with kickstart 3.1, it was the first and AFAIK only product before CBM collapsed with 3.1 from the day it shipped :)Blimey, one always gets something wrong :(
The A3000 is very special .. the ONLY rom with real FPU-code inside !!!
A3000/4000 includes "bonus" for onboard fastmem
A600/A1200 includes some PCMCIA-code.
Blimey, one always gets something wrong :(
Well, as already said, there are multiple CPU libraries out in the world, and they are pretty hardware and vendor dependent. Olaf already said this.
But anyhow. Here's a deal. I'm happy to provide my versions, and make them even ROM-able if you can get them to work on *all* hardware variants you get. This is, in fact, the major show-stopper of placing anything of this in ROM since it creates a kickstart that will no longer work on some boards.
My current libs work on pretty many, but not all of them, mostly because some vendors did not publish what kind of support they need in their code. To give you some idea where the trouble is: All the P5 PPC boards do not play nice because their libraries include some vendor specific code that remained undocumented. Some SCSI controllers go directly to the MMU list, without using the appropriate Os functions (CachePreDMA, CachePostDMA), causing trouble with any other program working the same resources.
Thus, *IF* you really want to go this route, let me know. What I can certainly give you is the code of P5Init, which is only "half of the deal" (it performs *some* P5 specific initialization, but it does not include the P5 library interface, whatever this may be). Once you tell me that you understand the P5 interface logic and have a description ready how *that* works, I can give you even more.
Explain again why you have workbench.library and icon.library in kickstart.
The first thing to do is to take the 68060.library and patch it if a 68040 is detected : stack frame, mul64 removed and div64 removed... Easy to do I guess : this little trick will save about 43 precious Kb...No, hard to do. There is much more to do in the FPSP than just emulate the instructions. I suggest that you download the sources of the fpsp and isp from Motorola/Freescale. They should be freely available, and then take a look. The majority of code is really exception processing and instruction decoding, and *that* works entirely different on the 060. The 040 has a rich stack frame from which you can retrieve a lot of information on the instruction pipeline. The 060 does not, you have to decode the instruction yourself and fetch source operands yourself. You also have to write out destination operands yourself. Also, the ISP emulates more than just DIV and MUL (you'll find out, check yourself), and the FPSP has more to do than just to emulate instructions.
After that, I have the specific 040/060 code from P5 : I will rip it, I know the authors will yell, but I cannot see any other solution...I can. As always, ask them...
This new 68060.library will be packed of course and only depacked in ram if a 040 or a 060 is detected !And what about the 68030?
This new kickstart is for me the very last chance of the Amiga Classics. Must be fantastic. If I fail, it will be the very end of our beloved computer...Except that this goes into a completely wrong direction... but as you wish.
After that, I have the specific 040/060 code from P5 : I will use it, I know the authors will yell, but I cannot see any other solution...
Do you really intend to put entire OS in kickstart? And boot from what, a RAD disk?Good question ;)
I can think of one good reason - backwards compatibility with existing floppy based software (even some games).The A4000T Kickstart ROM, which for lack of space does not contain a "workbench.library", contains a special component "wbfind" whose single purpose it is to locate "workbench.library" on any currently mounted volume at the time the system startup attempts to open that library. Thus, if you boot off a disk which does not contain "workbench.library", opening the library will trigger a search on your hard disk (unless you chose not to mount it through the early startup menu).
Without those two library's these disks would not boot anymore...they would hang as soon as the LoadWB command is run and a requester saying something like "Unable to open workbench.library" would appear. Same goes for icon.library. It would only serve to confuse users...
Imagine that: you could just boot off the ROM itself, which could contain as much data as would be needed to run a minimal Workbench, space permitting.
For a quick moment, I want to come back to the math libraries. As Olaf already said, they are rarely used, but for floating point intensive applications, it does make a difference. FPU intensive: JPEG decoding is one nice example where a FPU is beneficial. I haven't had the time to compile my JPEG on Amiga, thus I took the freedom of choosing another benchmark to show the point - Mandelbrot computation. Here I have a program available (DMandel) which comes with various (assembler optimized) computing kernels, IEEE Doubbas, and FPU (and others). Everthing on my 68060@50, note that IEEEDoubBas *also* uses the FPU, but requires register ping-pong to do the work.
Numbers for a zoomed in Mandelbrot: With IEEEDoubBas: 5:15 minutes, with raw FPU, 1:15 min. I believe that's a non-neglibigle difference. I'm usually not much a fan of "optimizing pointless register moves away", but when it makes a difference, it makes a difference. It is probably an artificial benchmark, but it shows one thing: If you *need* to do numerics, it's probably best to go directly on the FPU.
The reason why I'm against that ROM-idea is simply because it does not allow users to exchange components. If I have to fiddle-open my machine every time I'm updating a component, chances are better than even that I'll break the ROM socket at some time. A minimal bootstrap ROM could be very stable and would not require a lot of updating. Everything else can be placed on flash, and can be upgraded easily by writing on a regular file system.
Given that you get such Flash-ROMs in GB size today for pennies, there's no reason to allocate an entire partition just for system components, write-lock it in regular operating mode, or even unmount if if it is no longer needed.
Imagine that: you could just boot off the ROM itself, which could contain as much data as would be needed to run a minimal Workbench, space permitting.
The reason why I'm against that ROM-idea is simply because it does not allow users to exchange components. If I have to fiddle-open my machine every time I'm updating a component, chances are better than even that I'll break the ROM socket at some time.
A minimal bootstrap ROM could be very stable and would not require a lot of updating. Everything else can be placed on flash, and can be upgraded easily by writing on a regular file system.
Given that you get such Flash-ROMs in GB size today for pennies, there's no reason to allocate an entire partition just for system components, write-lock it in regular operating mode, or even unmount if if it is no longer needed.
Yes, I remember reading about that. I also vaguely remember some solution to boot off network filesystem, with one specific zorro NIC that had some boot functionality? Hmmm.I believe that this was the Hydra Ethernet card, but I may be wrong.
Direct FPU support on the 68060 is likely using many software 6888x instructions through traps for Mandrelbot calculations since most compilers don't avoid the traps (except new unleased vbcc) vs the handicapped IEEE library functions using mostly software also. Or did you use MuRedox for your stats?No, the mandelbrot computations only use add,sub and multiplication. Thus, MuRedox makes no difference here. The only traps that may occur are due to non-normalized results where the FPU requires some help. IEEE uses the same instructions, but includes software overhead to load the numbers from the CPU registers into the FPU registers and back. While that makes typically no difference (the called function is long, the register ping-pong is short - intuition!) it makes a difference here. The called function is short (a single add, or sub, or mul) and the overhead is large compared to the actual function.
I guess this tells us that less software and more hardware fp usage is probably faster. Direct FPU use probably won't become more common until FPUs are more common. The new fpga processors are not getting them yet. It looks like the IEEE libraries will be around for awhile. Using the IEEE libraries really isn't that bad for non-CPU intensive multi-68k processor distributions, with a FPU.For your average all-day purpose, it will hardly make any difference, indeed. But for that purpose, you don't need an FPU in first place either.
The IEEE support in vbcc works surprising well. The default vbcc 68k distribution uses IEEE instead of direct floating point. I have compiled my own 68060+FPU version which is significantly faster though.Do you mean, it uses IEEE for compiling - or IEEE for the running program? The latter is switchable, but the former is pretty critical. To parse floating point constants in C code correctly, you need a *higher* precision than that used for computing in the program (otherwise, you get an additional loss in the compilation phase you want to avoid). For optimizing, you should run in the C compiler exactly the same computations as the code would have performed, so that's not good news either. Gcc has its own math library for emulating various FPUs and math models, and yes - for good compilation and optimization, this is really required.
You shouldn't have to exchange ROMs with the new fpga hardware. Installing a kickstart to a flash slot could be nearly as easy as installing any other file.True, except that handling of the files or exchanging modules within the kickstart is harder, i.e. the overall user experience is not quite as good for updates. Otherwise, when I remember the Natami here, it booted so fast it made no difference whether it went through another reset or not, so I don't need an updated rom for this machine in first place. Protecting modules can be done easily by MuProtectModules, no need for a ROM actually.
The reason why I'm against that ROM-idea is simply because it does not allow users to exchange components. If I have to fiddle-open my machine every time I'm updating a component, chances are better than even that I'll break the ROM socket at some time. A minimal bootstrap ROM could be very stable and would not require a lot of updating. Everything else can be placed on flash, and can be upgraded easily by writing on a regular file system.The reason why I am skeptical of moving components and in an out of ROM space is that the approach is beholden to 1980'ies/1990'ies design constraints which no longer apply today.
Loading operating system components from floppy disk was slow (even on the original 64K Apple Macintosh, which arguably had even worse disk performance than the Amiga, at half the storage space -- did you know that it would either compress data in memory or swap it to disk in order to make that 64K memory budget possible, at the expense of killing system performance?), which meant that you could get a performance boost out of sticking as much into the Amiga Kickstart ROM as possible.
it is a shame that these parts are "locked away". Even the FFS could be speed up by using a smarter block allocation algorithm, and all the "NSDPatch" madness could also be avoided just by having an auto-detection algorithm for the supported device extensions.Haven't you been able to contact Heinz Wrobel? Jens spoke to him quite "recently".. well... two years ago. However, you might want to ask him for an email adress or a telefone number? http://www.a1k.org/forum/showthread.php?t=35803
Haven't you been able to contact Heinz Wrobel? Jens spoke to him quite "recently".. well... two years ago. However, you might want to ask him for an email adress or a telefone number?Contacting Heinz is not the problem, trust me. Having known Heinz since 1995 (we met on what developed into a consulting gig for what became Amiga International GmbH), I expect him to lend his support only to project work which proves to be legally and technically on sound foundations.
No, the mandelbrot computations only use add,sub and multiplication. Thus, MuRedox makes no difference here. The only traps that may occur are due to non-normalized results where the FPU requires some help. IEEE uses the same instructions, but includes software overhead to load the numbers from the CPU registers into the FPU registers and back. While that makes typically no difference (the called function is long, the register ping-pong is short - intuition!) it makes a difference here. The called function is short (a single add, or sub, or mul) and the overhead is large compared to the actual function. For your average all-day purpose, it will hardly make any difference, indeed. But for that purpose, you don't need an FPU in first place either.
Do you mean, it uses IEEE for compiling - or IEEE for the running program? The latter is switchable, but the former is pretty critical. To parse floating point constants in C code correctly, you need a *higher* precision than that used for computing in the program (otherwise, you get an additional loss in the compilation phase you want to avoid). For optimizing, you should run in the C compiler exactly the same computations as the code would have performed, so that's not good news either. Gcc has its own math library for emulating various FPUs and math models, and yes - for good compilation and optimization, this is really required.
True, except that handling of the files or exchanging modules within the kickstart is harder, i.e. the overall user experience is not quite as good for updates. Otherwise, when I remember the Natami here, it booted so fast it made no difference whether it went through another reset or not, so I don't need an updated rom for this machine in first place. Protecting modules can be done easily by MuProtectModules, no need for a ROM actually.
All this aside, updating the system components or recompiling parts of them with more modern (ehem) compilers would still be something that would be worth trying. Moving windows partially off-screen is really a no-brainer with the new layer functions, cleaning up the intuition menu handling to allow a really integrated "Magic Menus" would be doable easily. Whether that's 20msecs faster or slower is nothing I would bother about, but there are so many small, tiny improvements that could be made almost immediately - it is a shame that these parts are "locked away". Even the FFS could be speed up by using a smarter block allocation algorithm, and all the "NSDPatch" madness could also be avoided just by having an auto-detection algorithm for the supported device extensions.
again, all this is a neat thing to hear and my opinion, that it should have been done, as well, but as we know it will never happen nor be a computable risk to invent work into, since there will never be a solution to guarantee a legal base for all these undertakings.
btw with aros(68k) layers implementation you can move windows off screen , no problem. the only limitation for this on unexpanded amigas without rtg card may be low chip ram at times.
again, all this is a neat thing to hear and my opinion, that it should have been done, as well, but as we know it will never happen nor be a computable risk to invent work into, since there will never be a solution to guarantee a legal base for all these undertakings.
@thor
and you are really sure that they are at all actually in a position and beyond that the only ones who can make legal claims about any work you might invest into amiga sources? have you been presented enough evidence to verify this?
besides the stubbornnes with which they have refused any support for amiga in the past doesnt make me think they might reconsider without actually losing the face and they know it.
also, they will want to apply the same market strategies to amiga they have been maintaining with os4, low volumes, high prices, no honest communication, when its done, two weeks, pay in advance and then we will see, half done and abandoned work on the way, broken or useless hardware of only limited capabilities.. all that kind of things. it all doesnt make me exactly wait to throw money at them just for them finally admitting people like me were right all along.
@thor
and you are really sure that they are at all actually in a position and beyond that the only ones who can make legal claims about any work you might invest into amiga sources? have you been presented enough evidence to verify this?
besides the stubbornnes with which they have refused any support for amiga in the past doesnt make me think they might reconsider without actually losing the face and they know it.
and you are really sure that they are at all actually in a position and beyond that the only ones who can make legal claims about any work you might invest into amiga sources? have you been presented enough evidence to verify this?No, I haven't. But I'm not a lawyer in first place, so you're probably expecting a bit much from my side. One way or another, if you attempt such a project, you want at least somebody at your side that can defend your position, and it has been shown that they can, all legal uncertainties aside. If you have other recommendations as for whom to approach for such a project and who could provide licenses - and more important - legal backup, I'm happy to hear them.
besides the stubbornnes with which they have refused any support for amiga in the past doesnt make me think they might reconsider without actually losing the face and they know it.The sole purpose of a company is not keeping their face. The sole purpose is "making money". As soon as there is a chance for making a profit, they would be stupid not to take it. The problem is: Activities like this one - ripping Os components and publishing an "Os" - is showing the unwillingness of the community to invest money into any new Os, hence makes the whole project less likely, not more likely. I believe I said this before. The best you can do is probably setup a web page where you collect voices for such a project, and more specifically, how much individuals would be willing to invest.
also, they will want to apply the same market strategies to amiga they have been maintaining with os4, low volumes, high prices, no honest communication, when its done, two weeks, pay in advance and then we will see, half done and abandoned work on the way, broken or useless hardware of only limited capabilities.. all that kind of things. it all doesnt make me exactly wait to throw money at them just for them finally admitting people like me were right all along.
It doesnt matter if they have the evidence or not. Reality shows that about a week ago they allowed a remastered AmigaOS 3.1 kit to be sold, and no one had proof that they could legaly challenge that action (you can now buy this version at AmigaKit). And most importantly, if I am not wrong, I believe they still have a lawyer that doesnt charge a single penny, and is willing to go all the way (Ben Hermans).I learned that the issue of who owns what and what they can do or cannot do with what they at some point obtained a license for is rather murky for the Amiga in general.
It doesnt matter if they have the evidence or not. Reality shows that about a week ago they allowed a remastered AmigaOS 3.1 kit to be sold, and no one had proof that they could legaly challenge that action (you can now buy this version at AmigaKit). And most importantly, if I am not wrong, I believe they still have a lawyer that doesnt charge a single penny, and is willing to go all the way (Ben Hermans).
I for one, dont care what happens to OS4. It is just another product, that I have tried, and I do not find it interesting all. But on the contrary, a new or recompiled OS for real Amigas sounds really tempting for me.
And most importantly, Hyperion is just like any other company, driven by profit. So if OS4 doesnt give them enough revenue, maybe a 68k AmigaOS might, and it is not a bad move, it is the way that business are (you choose the product you find its more profitable).
Hyperion may not be the company with the best rep out there to do this, but this is certainly better than having nothing at all (because that is what we have now).
And please, lets not talk about Aros on a real Amiga, because for the time being it is just a pain inflicting OS for our Miggies. Maybe that can change in the future, but not now.
AmigaOS 3.1 for 68k machines was not considered a viable product. There was nobody who could have developed it, provided support, documentation, etc. There was nobody who would have wanted to buy it in sufficient numbers to even sustain development, support, etc.
The situation seems to have changed by now. But given the twisted history of the Amiga as it happened in the last 20 years, it would still need capital and manpower to "resuscitate" AmigaOS 3.1 for 68k, which entails quite some risk.
If there is a genuine appetite for an updated AmigaOS 3.1 for the 68k platform ("classic", emulated or reborn in FPGA), it's up to you (well, not you personally: I mean everybody who would want to see such a project happening) to state what they want from it and let Hyperion know that there is sufficient demand for it.
We can swap stories and speculate all day on this forum. But nothing tangible will happen until you convince the people who can make it happen.
No, I haven't. But I'm not a lawyer in first place, so you're probably expecting a bit much from my side. One way or another, if you attempt such a project, you want at least somebody at your side that can defend your position, and it has been shown that they can, all legal uncertainties aside. If you have other recommendations as for whom to approach for such a project and who could provide licenses - and more important - legal backup, I'm happy to hear them. The sole purpose of a company is not keeping their face. The sole purpose is "making money". As soon as there is a chance for making a profit, they would be stupid not to take it. The problem is: Activities like this one - ripping Os components and publishing an "Os" - is showing the unwillingness of the community to invest money into any new Os, hence makes the whole project less likely, not more likely. I believe I said this before. The best you can do is probably setup a web page where you collect voices for such a project, and more specifically, how much individuals would be willing to invest.
It's a small market, so I don't think we can expect "bugdet prices". After all, some people also want to get paid, and rightfully so. The problem I have now is that they sell a "low end product" for "high end prices", and -even worse- a product I'm not at all interested in. At least a couple of factors would have to change: Better engagement in the community would help to lower prices by using man-power that is available for little money right here. And, from the side of the community: Respect for the legal constraints. There is certainly no market if some people believe that AmigaOs is essentially "free to take".
As always, every story has two sides, and there are certainly matters that have to change at Hyperion, but the same goes for this community as well, this thread is exactly a demonstration this problem.
im not sure where anybody has proven to defend their position, as im not sure one needs associate like that so much if one can avoid it.I thought the case against Amiga Inc concerning the rights on AmigaOs for development of Os 4.x should be known in the community. So at least this court case provided the following answers: a) Hyperion has the rights for developing Os 4.x on the basis of the existing Amiga Os, and b) they're willing to fight for this.
to be clear, im not going to try to convince anybody to prove that amiga is commercially viable, let alone to invest money in it up front. those in question need to evaluate their plans for themselves. ot has nothing t do with the attitude of particular individuals in the scene. people are fed up and are taking things in theor own hands, one way or another. whoever let it came to that can now blame himself.
how has the situation changed? os4 market has dried up and one needs to look for something else to ruin? and that needs to be founded yet?The situation has changed insofar as there is new hardware available on which the 68k software can run well, if not extremely well. Personally, I'm wondering why one couldn't do more with the FPGA-based solutions than just to reuse an existing Kickstart ROM -- why not customize it for a specific purpose and go beyond merely reproducing existing functionality (both the CDTV and the CD32 are customized versions of the existing Amiga operating system platform, to give you an idea of what could be possible by building upon the operating system to deliver something new)? It's certainly possible.
t could be done if there were sufficient interest to back an AmigaOS rework if the current technology owner gave its consent,
@olsenI may be wrong on this, since I didn't pay enough attention at the time, but I seem to remember that the settlement between Amiga, Inc. and Hyperion back in 2009 (?) gave Hyperion exclusive and permanent use of AmigaOS 3.1. This may not cover the rights of 3rd parties who provided CrossDOS, bru and the bitmap/outline fonts included on the Workbench, only those parts owned by Commodore.QuoteIt could be done if there were sufficient interest to back an AmigaOS rework if the current technology owner gave its consent,
And who would that be to the best of your knowledge?
(given the understanding that likely only a court could decide this)
#6
I find it hilarious that you guys cannot contribute to AROS, it's just mind blowingly silly.Well, we could try, but there's a risk of tainting the project. AROS is on safer grounds if it's a clean room implementation of the API rather than if people who had access to the original AmigaOS source code had been involved. Personally, I don't want to risk compromising the AROS project.
I thought the case against Amiga Inc concerning the rights on AmigaOs for development of Os 4.x should be known in the community.well, here both sides of the conflict seem to be about to worth the counterpart. an actual proof of ability to defend ones standpoint would be to stand up against a serious threat, not just another pretender.
I may be wrong on this, since I didn't pay enough attention at the time, but I seem to remember that the settlement between Amiga, Inc. and Hyperion back in 2009 (?) gave Hyperion exclusive and permanent use of AmigaOS 3.1. This may not cover the rights of 3rd parties who provided CrossDOS, bru and the bitmap/outline fonts included on the Workbench, only those parts owned by Commodore.
My best guess is that Hyperion would be the party to ask for consent.
Also, please no business advice.
We'll take our advice from people like Trevor, Matthew Leaman, Steven Solie (who came up with the "Hyperion Blog"), Jens S. from Individual, Michael from Cloanto etc. i.e. people and developers who have put their money where their mouth is or have actually contributed significantly to AmigaOS development.
Take a look at Trevor's recent Blog post and the picture he posted from the meeting in Brussels.
Those are the people that Hyperion management relies on for decision making.
And even if you think they are bad decisions, it is our money and we can spend it any way we want, yes, even on AmigaOS development.
I find it hilarious that you guys cannot contribute to AROS, it's just mind blowingly silly.
Anyone from outside your inner circle would have to think twice about offering advice or ideas if we are to take the owner's posts at his word, no?
#6
I don't quite understand what you want to say here. (Neither would I consider myself part of an inner circle - Hyperion never asked me for advice, and if they had, you know what my advice on this would be.) The statement from the owners is certainly correct and justified. These are persons that know the market better than I do, persons I would also listen to for adivice, and its certainly the right of the right holders to do with their property and their money whatever they please.
Funny people such as Thomas and me, who were involved in updating previous operating system versions, haven't exactly unlearned how to do that, so there is an option to actually make profound changes to the operating system if this were called for.
This is all hypothetical, of course. It could be done if there were sufficient interest to back an AmigaOS rework if the current technology owner gave its consent, a plan were made, the time, manpower and funding could be found. None of this is impossible.
There is a new thread with a poll.
It is rather simple:
Would you buy a new OS for 68k Amigas?
;)
This might give the impression (after he clarified that he believed Hyperion was the one to contact) that such ideas might be discussed with Hyperion.Oh certainly, such ideas *should* be discussed. But as said, I don't count myself part of the circle Hyperion would listen to.
Whereas, we're really talking about Hyperion in terms of "consent", as mentioned.
Oh certainly, such ideas *should* be discussed. But as said, I don't count myself part of the circle Hyperion would listen to.
Consider we would. Consider somebody would find a suspicious function in AROS, where a potential rights' owner might consider his rights violated. How can Olaf, or I potentially prove that we haven't contributed this code by copying it from the original, hence violating the rights of the owner? I personally don't want to be in this position. Just in case you believe that this is a constructed case, I give you three letters: S, C and O.
Thor: yeah, and we all know how well that went for SCO.Certainly, but how much money went into paying the lawyers? If I had big companies at my side, or even small ones (like Hyperion) that would be worth trying. But no, I cannot pay such a case from my pocket, no matter whether I would win or not.
Well, we could try, but there's a risk of tainting the project. AROS is on safer grounds if it's a clean room implementation of the API rather than if people who had access to the original AmigaOS source code had been involved. Personally, I don't want to risk compromising the AROS project.
Thor: yeah, and we all know how well that went for SCO.It took 6 or 7 years for the boulder rolling downhill to come to a stop, during which time the status and future prospects of Linux as it existed prior to the case going to court was in doubt.
Flash adapter would be perfect. You could have some different ones on one flash, maybe even boot right in to WHDLoad.
To heck with actual ROM's, plug in a custom flash adapter instead, right in the ROM socket.
http://youtu.be/unqY2QD8uq8
Out side of Kickstart switchers, are there any rom boards that would allow the user to add a user rom that would allow the addition of more rom space?Please note that adding a larger flash ROM than is needed for the Amiga operating system does not by itself allow the Amiga to use the larger space. The flash ROM still needs to fit into the available address space, and the operating system has to know where to look for more operating system components. Where the early system startup looks for components to use is hard-coded.
...so we don't have monstrous startup-sequence files like we currently do."slaapliedje