Amiga.org
Amiga computer related discussion => Amiga Software Issues and Discussion => Topic started by: utri007 on October 21, 2009, 08:45:20 AM
-
Hi
I recently bought Blizzard 68060 accelerator, its overclocked to 66mhz.
I currently use latesta Phase5 68060 library, cyberpatcher and blizkick. Setpatch is from boingbag2
It seems to be not so much faster than my previous 68040 40mhz apollo accelerator.
What paches I should install to get it faster?? ie. Duke 3d is totally unplayable, was at least 50% faster with apollo.
WB screen refreshing seems allso slower etc.
Games like DOom, quake, napalm runs only little bit faster 10%-15%
I'm allso interested to know what options I should enable/disable from CyberGraph options?
-
There is no way even without patches that 060 at 66mhz is slower than 040 at @ 40.
There would appear to be something wrong with your card .
-
I currently use latesta Phase5 68060 library
Are you sure you've installed it correctly?
-
try fblit and blazewcp
-
Oxypatcher might be better than Cyberpatcher in some cases, it has more supported instructions.
-
I'm sure 68040.dummy named to 68040.library and 68060 library.
They are from here http://phase5.a1k.org/
FBlit and blazewb are for those who doesn't have grapihics card
-
If you are gaming thru ZorroII bus, it does max. 3.5 MB/s, in effect just 2 -2.5 MB/s crippling screen refresh and making everything more than 320x240 impractical. So making the difference between 040 and 060 smaller.
-
I know, realizm is that with zorro II graphics card I get that 10-15% speed up with my 060 compared to 040
BUT why duke nukem is totally unplayable and why wb seems to be slower
-
I would uninstall cybpergraphix and re-install selecting 060 as the processor, should install the 060 versions of the libs
-
I know, realizm is that with zorro II graphics card I get that 10-15% speed up with my 060 compared to 040
BUT why duke nukem is totally unplayable and why wb seems to be slower
About Duke:
- to get the framerate, type inside a running game "dnrate"
320x200 should do about 15 fps (PicassoIV in A4000), what's your figure?
Have you tried Picasso96? Which RTG card do you have? Have you tried direct access in graphic config menu - it should give a speedup with CGX - if it works...
I don't know how well Duke is optimized for 060. Probably I have it installed - must have a look at it with my A4000. I used to play it via Shapeshifter, where it was quite playable.
-
If you are gaming thru ZorroII bus, it does max. 3.5 MB/s, in effect just 2 -2.5 MB/s crippling screen refresh and making everything more than 320x240 impractical. So making the difference between 040 and 060 smaller.
With the PIV there's little practical difference - less than 1 FPS in the Quake timedemo between my A2000 and A3000 (both '060 50MHz), dropping to around .5 FPS difference at higher resolutions. (Overclocking the A2000 to 60MHz gives it a few FPS advantage.) *edit* -- are the A1200 busboards are slower than real Z2?
With the TekMagic at least, writes across the Z2 bus hit 3.6 MB/sec (according to bustest), reading is 2.8 MB/s at 50MHz, 3.6 MB/s at 60MHz. (Reading from the PIV directly is a bit slower.) Benchmarks are roughly equal up until a 24-bit 1024x768 screen is selected, where the A2000 is finally measurably slower.
-
bump!
I just had this issue as well with a Blizzard 1260/66Mhz. Was dissapointed in the speed. I then did the following from my research:
-Latest libs! (040_060Libs.lha)
-BlizKick
-FBlit
-FText
-BlazeWCP
-CopyMem060
-UtilPatch060
-CyberPatcher
and it has made a big difference! 52 mips on SysInfo.
-
-Latest libs! (040_060Libs.lha) : I currently use mmu libs
-BlizKick : I can't use this, I have 1mb kickstart/rom and blizkick soesn't support them, only 512kb roms is supported. I use CPU Fast command. Better solution would be nice.
-FBlit : It is towerized system with RTG
-FText : - " " -
-BlazeWCP : I'm running this, it doesn't affect Picasso96
-CopyMem060 : I use MPC's
-UtilPatch060 : Need to check this
-CyberPatcher : Most of apps/games are for 040/060 anyway?
-
Oxypatcher might be better than Cyberpatcher in some cases, it has more supported instructions.
Oxypatcher has bugs and patches some instructions into nonsense. FBDcc is, for example, one of them. Besides... It only helps for programs that use the FPU heavily, and then also require that the software in question does not keep a checksum on its code. Which some copy protected code may do. *If* you want to run such a program (for example for raytracing), I would suggest MuRedox.
-
-Latest libs! (040_060Libs.lha) : I currently use mmu libs
-BlizKick : I can't use this, I have 1mb kickstart/rom and blizkick soesn't support them, only 512kb roms is supported. I use CPU Fast command. Better solution would be nice.
-FBlit : It is towerized system with RTG
-FText : - " " -
-BlazeWCP : I'm running this, it doesn't affect Picasso96
-CopyMem060 : I use MPC's
-UtilPatch060 : Need to check this
-CyberPatcher : Most of apps/games are for 040/060 anyway?
To be frank, most of this is not really helping much. "CPU Fast" is nonsense and does not work for a 060 at all since it does not support it. If you want to mirror the ROM into RAM and have the mmu libs, use "MuFastROM". Not any third party program. Additionally, depending on the board, "MuFastZero" might also help to mirror execbase into fast memory. "FBlit" is nonsense if you have an RTG system anyhow (in such a case, blits are executed by the CPU in first place, through the RGB system, and you don't need an additional source of instability in first place). The same goes for FText. All this is already run through the RTG System in first place, no patch needed - and not exactly helping either. I don't know what BlazeWCP is, but it falls probably into the same category. CopyMem060 is most likely not helping, only damaging a perfectly fine copy. Besides, how much software are you aware of that copies huge amounts of memory around so that this would create a measurable difference? Seriously, the 060 should - out of the box - reach approximately twice the speed of the 040. If it does not, none of the above programs will help either. Something is then seriously wrong, for example the CPU caches are off. (No, the *CPU* command does not help here. It is the processor library, i.e. the 68060.library that is then not loaded. The CPU command is a legacy program that has not been updated and that does not support the 68060.).
-
God... I love this guy! :)
To be frank, most of this is not really helping much. "CPU Fast" is nonsense and does not work for a 060 at all since it does not support it. If you want to mirror the ROM into RAM and have the mmu libs, use "MuFastROM". Not any third party program. Additionally, depending on the board, "MuFastZero" might also help to mirror execbase into fast memory. "FBlit" is nonsense if you have an RTG system anyhow (in such a case, blits are executed by the CPU in first place, through the RGB system, and you don't need an additional source of instability in first place). The same goes for FText. All this is already run through the RTG System in first place, no patch needed - and not exactly helping either. I don't know what BlazeWCP is, but it falls probably into the same category. CopyMem060 is most likely not helping, only damaging a perfectly fine copy. Besides, how much software are you aware of that copies huge amounts of memory around so that this would create a measurable difference? Seriously, the 060 should - out of the box - reach approximately twice the speed of the 040. If it does not, none of the above programs will help either. Something is then seriously wrong, for example the CPU caches are off. (No, the *CPU* command does not help here. It is the processor library, i.e. the 68060.library that is then not loaded. The CPU command is a legacy program that has not been updated and that does not support the 68060.).
-
LOL. I was thinking the same thing when I saw that list. Although I will admit that I still run a couple of those utilities, it's probably more of a placebo effect - they're not really helping anything. ;)
Thomas - I did have one thing that I've always kind of wondered about though. Even on an RTG system, wouldn't Fblit still help for non-RTG screenmodes? For example, system-friendly games and apps that aren't promoted to an RTG screenmode (but use NTSC 640x200, for example)?
Would love to hear your thoughts on this. Thanks! :)
-
LOL. I was thinking the same thing when I saw that list. Although I will admit that I still run a couple of those utilities, it's probably more of a placebo effect - they're not really helping anything. ;)
Thomas - I did have one thing that I've always kind of wondered about though. Even on an RTG system, wouldn't Fblit still help for non-RTG screenmodes? For example, system-friendly games and apps that aren't promoted to an RTG screenmode (but use NTSC 640x200, for example)?
Would love to hear your thoughts on this. Thanks! :)
I'm not Thomas but going off ancient memories my understanding is that the entire point of ftext and fblit-moving functions that happen in Amiga chip ram in to fast ram. Which is why you should- I do- see more chip ram available with those patches. The screens data on an RTG system with RTG screens is held in the graphics ram. Amiga screens are held in chip ram unless fblit shifts them into fast ram. So the answer in my experience is" "yes".
-
To be frank, most of this is not really helping much. "CPU Fast" is nonsense and does not work for a 060 at all since it does not support it. If you want to mirror the ROM into RAM and have the mmu libs, use "MuFastROM". Not any third party program. Additionally, depending on the board, "MuFastZero" might also help to mirror execbase into fast memory. "FBlit" is nonsense if you have an RTG system anyhow (in such a case, blits are executed by the CPU in first place, through the RGB system, and you don't need an additional source of instability in first place). The same goes for FText. All this is already run through the RTG System in first place, no patch needed - and not exactly helping either. I don't know what BlazeWCP is, but it falls probably into the same category. CopyMem060 is most likely not helping, only damaging a perfectly fine copy. Besides, how much software are you aware of that copies huge amounts of memory around so that this would create a measurable difference? Seriously, the 060 should - out of the box - reach approximately twice the speed of the 040. If it does not, none of the above programs will help either. Something is then seriously wrong, for example the CPU caches are off. (No, the *CPU* command does not help here. It is the processor library, i.e. the 68060.library that is then not loaded. The CPU command is a legacy program that has not been updated and that does not support the 68060.).
This is very old thread, that time I didn't have a RTG.
BUT, problem was that Apollo's non standard fast chip ram access made very visible difference when using AGA and Hires Laced workbench compared to Blizzard.
I don't have FBLit and FText running.
I tried MuFastRom but I had some problems with it, can't remember what? Does it support 1mb physical kickstart? I have 1mb kickstart, with all the BB2 rom updates, filesystems and scsi.device.
PS. I just mentioned you name in another thread, maybe you could comment there also? http://www.amiga.org/forums/showthread.php?t=70260&page=6
Is CopyMem060 equalent to MCP's copy mem quick?
I ques that I have just been happy that system boots up very fast, without additional reboot.
-
BUT, problem was that Apollo's non standard fast chip ram access made very visible difference when using AGA and Hires Laced workbench compared to Blizzard.
Access to chipram is limited by the bandwidth, not by the CPU power. Hence, for chipram it makes barely any difference whether this is a 68030 or a 68060 - or anything in between for that matter. I tried MuFastRom but I had some problems with it, can't remember what? Does it support 1mb physical kickstart?
Probably not. There are no 1MB Kickstart ROMs, CBM didn't made them, so that makes them unsupported. Unless we get an official 1MB kickstart, I see little reason to support them. Is CopyMem060 equalent to MCP's copy mem quick?
Equivalent in the sense that it makes barely any difference? Likely yes. Equivalent in the sense that the implementation is identical? I do not know. (-:
-
The screens data on an RTG system with RTG screens is held in the graphics ram.
It's a bit more complicated than that. While I do not know how cybergraphics works, P96 tries to keep graphics data "on the board", but has no problem to off-load graphics data to fast RAM if on-board ram is getting tight. The native graphics system is not capable of doing that, i.e. any native bitplane will stay in chip RAM forever, no matter how tight it gets.
-
Thomas - I did have one thing that I've always kind of wondered about though. Even on an RTG system, wouldn't Fblit still help for non-RTG screenmodes? For example, system-friendly games and apps that aren't promoted to an RTG screenmode (but use NTSC 640x200, for example)?
Likely, though it is not unlikely that it also conflicts with the RTG system (and some other stuff, too). Thus, for example, P96 "marks" its BitMap structure by a "magic word" to be able to tell "native" bitplanes from "RTG bitplanes" apart. This tagging may potentially conflict with FBlit and other hacks.
FBlit has also a couple of bugs, for example it writes into some custom chip locations that are not to be supposed to be written into, for example in its QSBlit patch. In specific, this causes screen corruption with third party hardware extensions like the Indivision. So all I can say is that would currently really not recommend such programs.
It would be much nicer to offer the same functionality through P96 which could, in principle, support the native chipset as a possible graphics output device as well. Unfortunately, this feature is currently not available.
-
Of course Fblit corrupts RTG - at least what I experienced ; freezes and corrupted windows. And Quake needs a patcher on 060 due to missing FPU instructions - without (MuRedox) the fps drops from about 15 to 5.
-
FBlit does make a huge dirrerence if hires interlaced modes are used, it increases screen scrolling etc a lot. It is nice to have pimped up workbench, without low chipram problems with whdload games.
FBLit is now opensourced, so everyone capable can make fixes to it.
https://github.com/SamuraiCrow/fblit
Apollo accelerators read/write chip ram faster than other accelerators, that is done using some hacks. At least Jens S said something like that. Personally I don't know what but diffrence is noticeable.
-
interesting thread as I can't get WHDload working at all on my 1200T, Apollo 060, Mediator setup and just wondering which, if any, of these patches mentioned might help or interfere with WHDLoad on my system?
-tried disabling the USB stack & various no cache, no mmu etc. but no go.
it's actually not a big deal for me as my 1200 desktop with 030 is amazing with WHDload, more curiosity then necessity for my 1200T
-
interesting thread as I can't get WHDload working at all on my 1200T, Apollo 060, Mediator setup and just wondering which, if any, of these patches mentioned might help or interfere with WHDLoad on my system?
-tried disabling the USB stack & various no cache, no mmu etc. but no go.
it's actually not a big deal for me as my 1200 desktop with 030 is amazing with WHDload, more curiosity then necessity for my 1200T
If you REALY have the same WHDLoad setup on both machines then it sounds like trying to run PAL Games on an NTSC Machine... or vice-versa.. you could try the PAL tooltype to FORCE the screenmode ! the PAL Monitorfile must be in Devs:Monitors/
-
If you REALY have the same WHDLoad setup on both machines then it sounds like trying to run PAL Games on an NTSC Machine... or vice-versa.. you could try the PAL tooltype to FORCE the screenmode ! the PAL Monitorfile must be in Devs:Monitors/
ah in fact you are correct in that my 1200T is NTSC and my desktop is PAL, I'll have a look at the PAL monitor tooltype in the 1200T?
-
Unless we get an official 1MB kickstart, I see little reason to support them.
So no joy if you manage to expand a CD32?
-
ah in fact you are correct in that my 1200T is NTSC and my desktop is PAL, I'll have a look at the PAL monitor tooltype in the 1200T?
Just put PAL in the tooltypes of the WHDLoad game. It helps some. I too, have problems with some games on my 2000 that work fine on my 500. Obviously much more expanded system, etc. Try disabling your TCP/IP stack and switching to a non-RTG screenmode before running the game. I've found those things can help, also. :)
-
I used this guide, there is one mistake. http://www.mfilos.com/2010/12/guide-create-and-burn-custom-kickstart.html
DummyCDtrap is need with acceleratos wich has a MMU not just Cyberstorms. Other vice MMU blocks direct memory Access to extended 512kb part and make it slow.
There is some very nice points to have that kind of kickstart. Biggest advantage is with hard drives.
-
So no joy if you manage to expand a CD32?
The point is really that: I don't want to support piracy. If, at some point, someone provides a legal and valid way to create a 1MB kickstart, without requiring any go-arounds or loop-holes, I'm happy to support it. Right now, I have a very mood feeling about such ROMs. So for example, how can one relocate the existing ROM modules to other areas in a 1MB ROM space, without trying to reverse-engineer or go around the copyright?
All that sounds pretty fishy to me, it's a dubious task, and I would prefer to stay away from such "home-brewed" ROMs. If we get, at some point, a valid, legal, licensed 1MB kickstart in some device - ok, no problem.
-
BlizKick had the biggest impact (mapping KS to Fast RAM), some of the other patches do help a bit too. FBlit and FText do help, without them I was only getting 51 mips. (I know not the best way to test, but it is noticeable)
BlazeWCP only helps in some games, like ScummVM. Cyberpatcher helped in apps that use a FPU. (like Mand2000) without it the program would crawl.
-
-BlizKick : I can't use this, I have 1mb kickstart/rom and blizkick soesn't support them, only 512kb roms is supported.
So why do you use a 1MB kickstart??
-
There are no 1MB Kickstart ROMs, CBM didn't made them, so that makes them unsupported.
Enters CDTV and CD32... :hammer:
-
FBLit is now opensourced, so everyone capable can make fixes to it.
https://github.com/SamuraiCrow/fblit
Let us not forget that Amiga OS 3.1 also is de-facto open source these days :laughing:
-
The point is really that: I don't want to support piracy.
In essence you are saying that you only support piracy up to 512kB, and supporting 1MB kickstarts would make you feel twice as bad. Pardon me for not taking your argumentation seriously. :roflmao:
-
Let us not forget that Amiga OS 3.1 also is de-facto open source these days :laughing:
No, it isn't. Just because somebody pirated it does not mean it is open source. If I would rob your home, would you agree that all your belongings are mine just because I could break in?
-
In essence you are saying that you only support piracy up to 512kB, and supporting 1MB kickstarts would make you feel twice as bad. Pardon me for not taking your argumentation seriously. :roflmao:
Hence, in future, do you suggest I should keep checksums about ROMs and exclude those that are not valid?
You know, there is a difference between "actively supporting piracy" by providing a feature that only supports pirated software and does not add functionality for valid machines - or providing a feature that works on a legal system and - unfortunately, due to the structure of the problem - works also on pirated versions, and where I would need extra code to actively defeat its usage?
One way or another: If you currently use a 1MB "kickrom", you're on your own. Don't expect any support from anyone, unless I see a way how to legally obtain such a ROM. I'm not against supporting it. I'm just against providing a feature that would help in case you do *not* use an original ROM.
-
Legally valid way to obtain such rom?
Like many current Amiga users, I had a physical kickstart 3.1 (CBM original), and the original AmigaOS 3.9 cdrom in my A1200. I threw away the old rom, as it was having issues (some corrosion), and built an AmigaOS 3.9 rom with the legally valid content of such rom and the rom updates present in my also legally valid 3.9 cdrom.
Many have done the same. It is not piracy whatsoever, and this rom, unless you leave stuff out of it, requires a 1MB chip to be burnt into.
-
There are sevaral valid reasons to build such a rom. Please note, that we who have actual benefits with it have real amiga. There is no such a benefit using custom rom with emulator, where Amiga piracy is nowadays..
-Any IDE hard drive work with it.
-Reinstall is much easier.
-If workbench.library is left out, any boot floppy doesn't do.
PS. Are those modules located to 32 bit fast ram in picture?
-
ah in fact you are correct in that my 1200T is NTSC and my desktop is PAL, I'll have a look at the PAL monitor tooltype in the 1200T?
you clould also set this option in the global startup-File in s: ! Also switch of any USB-Stack (it will not work with it!) and any tcp-ip Stack! Don´t forget to put the PAL Monitorfile from Storage/Monitors to Devs:Monitors/ !
WHDLOAD overtakes the System and usb-Stacks and tcp-ip-Stacks are using interupts to control the devices wich is not possible while whdload is running. So the system crashes if you do not switch of these stacks! Hope it helps!
-
Also Picasso96 have those interrupts problem, with some RTG cards, but not all. GVP Spectrum has a that problem and xPert Merlin doesn't have.
There is script files in SYS:S what whdload does when it start and quits. TCP/IP stack can be started and terminat with tem, same with USB stack
-
Strange, I put Thor's mmu.lib and 68060.lib in my libs drawer and it locks up my system just before WB shows up, it just gets to the point of showing the window and menubar but no icons.
Does it not like a CSPPC?
-
Strange, I put Thor's mmu.lib and 68060.lib in my libs drawer and it locks up my system just before WB shows up, it just gets to the point of showing the window and menubar but no icons.
Does it not like a CSPPC?
It does! You MUST use the expert-Installation! There you can answer the Quetion "do you have Phase5 Hardware" with YES ! Then the P5emu.library will be installed. This works....
the p5emu.library is temporarily, it ist created in RAM on startup... you will not find it in libs: also pretty much settings are missing in envarc:
to copy only these two libraries is not enough for a Cyberstorm PPC :laughing:
-
It is possible to map 1mb kickstart to fast ram with CPU command, just checked it works.
-
It is possible to map 1mb kickstart to fast ram with CPU command, just checked it works.
Nope. Not with the mmu.lib based libraries, and not for a sane definition of "works". Believe me. The setup you'll get is very fragile because the MMU table modification the CPU command does is bypassing the mmu.lib protocol. Hence, any other tool that modifies the MMU tables by the library will overwrite the modifications the CPU command performed.
DO NOT ATTEMPT THIS. IT MIGHT SEEM TO WORK AT FIRST, BUT WILL FIRE BACK AT YOU. USE MuFastRom FOR ROM TO RAM MAPPING.
-
Strange, I put Thor's mmu.lib and 68060.lib in my libs drawer and it locks up my system just before WB shows up, it just gets to the point of showing the window and menubar but no icons.
Does it not like a CSPPC?
CSPPC is ignoring some CBM specifications - in particular, it's not autoconfiguring its hardware through expansion.library, leaving the system unaware of its hardware resources (i.e. no "autoconfig").
However, you can do the following: Edit and/or create the file "ENVARC:MMU-Configuration", with an editor of your choice, and place there the following two lines:
ClearTTX
P5Init
The latter is a short tool in LIBS:MMU which will be copied there by the installation process (you did you the installer, did you?) and will scan for P5 hardware and add them to the system.
Sorry for the hassle. I would have hoped P5 would have followed autoconfig, but they don't.
-
Legally valid way to obtain such rom?
Like many current Amiga users, I had a physical kickstart 3.1 (CBM original), and the original AmigaOS 3.9 cdrom in my A1200. I threw away the old rom, as it was having issues (some corrosion), and built an AmigaOS 3.9 rom with the legally valid content of such rom.
Then you get a standard 512K ROM image that is supported. Full stop. If you modify your ROM, you need to relocate modules, and relocation information is not part of the ROM. ROM-Updates is a RAM-module, and that's were it belongs until a valid ROM is published. You can get an updated ROM from Cloanto. It's only 512K as far as I know, and it will work fine. It's published under license, so it's legit.
-
CSPPC is ignoring some CBM specifications - in particular, it's not autoconfiguring its hardware through expansion.library, leaving the system unaware of its hardware resources (i.e. no "autoconfig").
However, you can do the following: Edit and/or create the file "ENVARC:MMU-Configuration", with an editor of your choice, and place there the following two lines:
ClearTTX
P5Init
The latter is a short tool in LIBS:MMU which will be copied there by the installation process (you did you the installer, did you?) and will scan for P5 hardware and add them to the system.
Sorry for the hassle. I would have hoped P5 would have followed autoconfig, but they don't.
I did not use an installer. I dont even remember seeing one in the package I downloaded from aminet. Maybe it was the wrong one? Which is the latest up to date archive to use?
-
I did not use an installer. I dont even remember seeing one in the package I downloaded from aminet. Maybe it was the wrong one? Which is the latest up to date archive to use?
http://aminet.net/package/util/libs/MMULib
There is a folder called Install !
-
No, it isn't. Just because somebody pirated it does not mean it is open source.
Yes it is, the sources are now easily available to anyone who bother to look for them. Whether sources are "open" or not is not a matter of legality, it is a matter of logistics. In most of the world, it is not illegal to be in possession of the sources, or to do whatever you want with them. Hence de-facto open source.
If I would rob your home, would you agree that all your belongings are mine just because I could break in?
Flawed analogy. If you come to my home and copy everything I got, I honestly would not mind, even when you copy work I had spent years on.
-
Hence, in future, do you suggest I should keep checksums about ROMs and exclude those that are not valid?
I do not care one way or the other what you support, I do not have any need for that piece of software.
You know, there is a difference between "actively supporting piracy" by providing a feature that only supports pirated software and does not add functionality for valid machines - or providing a feature that works on a legal system and - unfortunately, due to the structure of the problem - works also on pirated versions, and where I would need extra code to actively defeat its usage?
So, you are saying anyone using a 1MB kickstart is a software pirate? That only pirates have any use of 1MB kickstarts? Interesting :)
One way or another: If you currently use a 1MB "kickrom", you're on your own. Don't expect any support from anyone, unless I see a way how to legally obtain such a ROM. I'm not against supporting it. I'm just against providing a feature that would help in case you do *not* use an original ROM.
Define "original" - do kickstarts from Cloanto count as "original" for you? What do you do the day Cloanto builds a 1MB kickstart? Also, you are aware that Cloanto are using the same "piracy aiding" software as the rest of us to compile their kickstarts?
-
Yes it is, the sources are now easily available to anyone who bother to look for them. Whether sources are "open" or not is not a matter of legality, it is a matter of logistics.
Stealing source code doesn't make it open.
In most of the world, it is not illegal to be in possession of the sources, or to do whatever you want with them. Hence de-facto open source.
In most of the world it is a copyright violation.
https://en.wikipedia.org/wiki/Berne_Convention
You most certainly cannot do whatever you want with them.
-
Define "original" - do kickstarts from Cloanto count as "original" for you?
Yes, because they are properly licensed.
What do you do the day Cloanto builds a 1MB kickstart?
Yes.
Also, you are aware that Cloanto are using the same "piracy aiding" software as the rest of us to compile their kickstarts?
The question is not which software they use. The question is whether the resulting software or ROM is properly licensed and hence legal.
-
All right you guys, stop picking fights. We already know you're not going to change Thomas's mind, and he's not going to change yours. The original thread about patches, etc., was pretty good. Let's get back to that, eh? :hammer:
-
All right you guys, stop picking fights. We already know you're not going to change Thomas's mind, and he's not going to change yours. The original thread about patches, etc., was pretty good. Let's get back to that, eh? :hammer:
Yes please
-
Also Picasso96 have those interrupts problem, with some RTG cards, but not all. GVP Spectrum has a that problem and xPert Merlin doesn't have.
This is probably side-tracking this thread, but just for curiousity: What is exactly this interrupt problem? I do have a GVP spectrum, with P96, and that's working just fine. So I wonder what the problem is.
-
As said there is plenty of good reasons to use 1mb rom.
Any IDE hard drive work with it.
I have this http://aminet.net/package/driver/media/SCSI4345p 3 well konwn and respected amiga coders has made it. With original kickstart I had lost of problems to found working IDE hard drive. With that prety much every IDE drive works out of the box
Reinstall is much easier.
No hard drive problems is great. But I can also mount CD rom drive without any other driver, using scsi.device from rom. OR I can mount my compactflsh adapter from rom, there is a compactflash.device.
I also have all possible filesystems on ROM FFS. SFS and PFS
If workbench.library is left out, any boot floppy doesn't do.
I have found diffuclt to use floppies, they broke and drives are untrustable. With my current machine, I can start to install OS with ANY floppy, like Deluxe Paint IV floppy. Otherwise I need a floppy, copy workbench library to it just to boot SHELL. I wouldn't trust emergency boot disk made 5 years ago or 10 years ago.
As a bonus, I don't need to run any PCMCIA fixes from startup-sequence. I have a Piru's excellent exec on rom etc.
-
Yes please
So, did my above hint help?
-
This is probably side-tracking this thread, but just for curiousity: What is exactly this interrupt problem? I do have a GVP spectrum, with P96, and that's working just fine. So I wonder what the problem is.
TCP/IP stack and USB stack makes WHDLoad games unstable. Thats why there is commented out options to disable most TCP/IP stacks and USB on s:whdloadstartup file. Same with latest versions of Picasso96 and some cards. You don't play?
http://whdload.de/docs/en/bugs.html
Using Picasso96 versions equal or greater than release 1.36 also the graphics card Spectrum creates such interrupts. To avoid this the Picasso96 software must be reverted to a pre 1.36 release or the gfxcard driver must be disabled.
-
I haven't had any problem with Poseidon running in the background when I start WHDLoad games. Obviously USB mice and keyboards aren't supported by games, but I haven't had to shut anything down.
My Spectrum card, on the other hand, some games will just start with a black screen unless I switch to a non-P96 screenmode prior to starting them. That /bugs link looks interesting, will have to research further. Thanks! :)
-
TCP/IP stack and USB stack makes WHDLoad games unstable. Thats why there is commented out options to disable most TCP/IP stacks and USB on s:whdloadstartup file. Same with latest versions of Picasso96 and some cards. You don't play?
http://whdload.de/docs/en/bugs.html
Using Picasso96 versions equal or greater than release 1.36 also the graphics card Spectrum creates such interrupts. To avoid this the Picasso96 software must be reverted to a pre 1.36 release or the gfxcard driver must be disabled.
Would this patch help perhaps?
http://aminet.net/package/util/boot/BK_IntAckFix
-
So, did my above hint help?
Havent had a chance to try installing again with the installer this time :) I did get the linked MMUlib package this morning. I plan to try again when I get home from work. Stupid work getting in the way of my fun!!
-
I haven't had any problem with Poseidon running in the background when I start WHDLoad games. Obviously USB mice and keyboards aren't supported by games, but I haven't had to shut anything down.
My Spectrum card, on the other hand, some games will just start with a black screen unless I switch to a non-P96 screenmode prior to starting them. That /bugs link looks interesting, will have to research further. Thanks! :)
It is possible to but required parts of poseidon to ROM and then mouse and keyboard would be supported.
I had Spectrum and I had that problem with Picasso96 and Whdload, but not with my xPert Merlin.
By the way I made some speed test and Merlin is quite much faster. Got some 2fps more to Quake with Merlin. That is interesting because it is possible to get xPert Merlin for very economy price. It has it problems, but most of them are cured with fixes. Karl Werner Riedel still supports card. Unsolvable problem is with 24bit screens, but compared to Spectrum it is OK have 16 bit workbench, as Spectrum can't do better and 16bit works just fine with Merlin.
-
My Spectrum card, on the other hand, some games will just start with a black screen unless I switch to a non-P96 screenmode prior to starting them. That /bugs link looks interesting, will have to research further.
If that's a bug, it's the bug of the game(s) not using the Os.
Let me explain: The GVP spectrum has a video switch on its board. This switch can either switch the output from the Cirrus chip on the GVP board to the VGA output, or the VGA input comming from the pass-through cable from the chipset. The video switch is driven by a register on the GVP board, and the P96 triggers this switch whenever intuition switches between a native and a GVP (Cirrus) screen.
Now, if a program bypasses the Os and writes into the Custom chip addresses directly without using Intution (or Graphics, to be precise), then the video output switch remains in the position that redirects the Cirrus output to the VGA out.
So it's not at all related to P96 (which is not used by these games) nor Graphics (which is neither used by the games) nor by the hardware (the video switch is very much necessary for a video pass-through, and how else than by software should it be triggered?).
It is the fault of lazy programmers not using graphics and intuition - where P96 would be able to redirect video output properly.
-
TCP/IP stack and USB stack makes WHDLoad games unstable.
While I don't know the details, it doesn't surprise me. A "WHDLoad" game is something that bypasses the Os, and that expects pretty much a bare-bone system without anything unexpected in it. Now you add hardware on top that requires regular servicing through the Os, or rather, their corresponding device drivers. A "WHDLoad game" will usually disable all the Os services, including interrupts. No surprise the hardware runs amok.
In other words: Bad programming. Such games program a complex system (the Amiga) as if the hardware is a C64, in the tradition of the 8-bit systems where you just went directly to the hardware. (Un)fortunately, the Amiga system is an expansible system to which hardware resources can be added, but it has an Os that can be told to service these devices. If you don't use the Os... well, bad luck.
Thats why there is commented out options to disable most TCP/IP stacks and USB on s:whdloadstartup file. Same with latest versions of Picasso96 and some cards.
Not surprising, and not at all the fault of the TCP/IP stack, nor Picasso96, nor the USB stack. "WHDLoad" tries to shut down the system safely, but you cannot simply expect to shut down some parts of the system while keeping others working. The Os keeps the whole thing working together - you shut it down - the system falls apart.
You don't play?
My games on the amiga are called "DevPac" and "SAS/C". Oh, you mean, games? Well, not anymore these days. Back then, I was (and still am) into adventures. Never had problems with extensions like P96. If I wanted to play a game: Reboot the system, boot directly from the disk.
What you're saying is not surprising: It says mainly "WHLoad does not work". Certainly not - it cannot. For making WHLoad to work, it would need to know all possible extensions that could be connected to the Amiga, and how to shut them down or restore them safely. If this is possible at all.
WHDLoad is a hack. It works "mostly", but of course not if it hits something unexpected and something that has not been built into WHDLoad.
Using Picasso96 versions equal or greater than release 1.36 also the graphics card Spectrum creates such interrupts. To avoid this the Picasso96 software must be reverted to a pre 1.36 release or the gfxcard driver must be disabled.
P96 has no interface to disable board interrupts. Mostly because the Os does not require such a feature. It is not P96 which "breaks the interface". You rather expect that WHDload should reconfigure the graphics card bypassing P96. Since there are many graphics cards, this type of solution does not scale - essentially WHDLoad would need to know all available graphics cards. And all TCP/IP stacks. And all USB stacks.
I hope this explains a bit what is so terribly wrong about this program. You cannot hold together the system while shutting only parts down, and you cannot scale it up to the list of possible hardware extensions because every possible extension requires manual care in WHDLoad. You can only boot up the system without ever having initialized the extensions so they cannot interfere with such ancient software.
-
Would this patch help perhaps?
http://aminet.net/package/util/boot/BK_IntAckFix
thanks for the link! interested to test out if my 060 has the interrupt issue Harry talks about
-
I hope this explains a bit what is so terribly wrong about this program.
Hey now, it does work perfectly a majority of the time. The number of games that have been successfully updated is a testament to the WHDLoad team. And I'm sure all the programmers of those horrible, hardware-banging, non-system-friendly games certainly didn't foresee a bunch of crazy fanatics still wanting to play them, 30 years later. :laughing:
-
Let me explain: The GVP spectrum has a video switch on its board. This switch can either switch the output from the Cirrus chip on the GVP board to the VGA output, or the VGA input comming from the pass-through cable from the chipset. The video switch is driven by a register on the GVP board, and the P96 triggers this switch whenever intuition switches between a native and a GVP (Cirrus) screen.
Now, if a program bypasses the Os and writes into the Custom chip addresses directly without using Intution (or Graphics, to be precise), then the video output switch remains in the position that redirects the Cirrus output to the VGA out.
So it's not at all related to P96 (which is not used by these games) nor Graphics (which is neither used by the games) nor by the hardware (the video switch is very much necessary for a video pass-through, and how else than by software should it be triggered?).
It is the fault of lazy programmers not using graphics and intuition - where P96 would be able to redirect video output properly.
Perfect explanation! Thanks! :pint:
-
Well using the installer for MMULib was a disaster! I am glad I backup my boot partition before I make any big install like this! After going through all the stuff using expert mode it completly killed my system. I realy dont think it like being installed to a machine with a Mediator and the RTG system it uses. I ended up having to format my boot partition and restore it back to pre MMULib.
-
Well using the installer for MMULib was a disaster! I am glad I backup my boot partition before I make any big install like this! After going through all the stuff using expert mode it completly killed my system. I realy dont think it like being installed to a machine with a Mediator and the RTG system it uses. I ended up having to format my boot partition and restore it back to pre MMULib.
The installer keeps a backup of all your files... No need to format anything to restore, you just need to copy them back to place.
-
@thomas. My memory of history is that Amiga Inc *wanted* to release a 1 MB ROM with 3.5 but it was too costly for them to have the chips manufactured, not that it was technically difficult. Hence the "into fast ram instead" solution users got stuck with.
Personally what i loved about Amiga was the fast boot. OS 3.5 took that feature away with the reset on cold boot. This reset only existed because Amiga Inc didn't provide the physical 1 MB ROMS.
I see nothing immoral if someone goes the expense, time and effort of making a 1 MB ROM. My argument would be that it was what the owners of 3.5 and 3.9 should have done anyway.
The fact people will go to the trouble of doing all this tells us they would gladly pay for an official 1 MB. If the copyright owner won't shut up and take their money, who is to blame.
-
(Double post, removed)
-
@thomas. My memory of history is that Amiga Inc *wanted* to release a 1 MB ROM with 3.5 but it was too costly for them to have the chips manufactured, not that it was technically difficult. Hence the "into fast ram instead" solution users got stuck with.
Well, that is not entirely correct. The problem is that it is not ony too costy, it is also too risky. Is the software really stable enough to be put in ROM, once and forever? Once it sits there, it is very hard to fix bugs. Looking at the history of 3.5 and also 3.9, it showed that it is not. It took four BoingBags to get the entire system approximately stable, and I'm myself still updating the shell from time to time.
A software large enough contains at least one bug...
So, the conclusion is that this ROM-image of the kickstart is really a nightmare in terms of flexibility. You cannot update. There are reasons by PCs run with a Bios - and UEFI is approximately as bad as an idea as the Kickstart was, even though it is much less complex. Look at all the UEFI bugs that were discovered in the last years, including some bugs that could brick your entire system...
So, ROMs are really bad solutions, and if they exist, they should only include a minimal image that is barely enough to boot up the system, and get everything else done by software that is easily replaced and upgraded.
Personally what i loved about Amiga was the fast boot. OS 3.5 took that feature away with the reset on cold boot. This reset only existed because Amiga Inc didn't provide the physical 1 MB ROMS.
I see nothing immoral if someone goes the expense, time and effort of making a 1 MB ROM. My argument would be that it was what the owners of 3.5 and 3.9 should have done anyway.
I don't agree with this argument. Actually, what should *really* have been done is to replace all the ROM cruft with a minimal boot rom, just large enough to support the hard disk firmware, and to initiate a soft-boot from the RDB which could include the necessary ROM modules. This would have avoided the second reset itself (because it would not have been necessary to replace anything that is not in the ROM itself), and it would have only taken approximately two additional seconds - or something in this magnitude.
How long does it take to load one MB from the harddisk? I have not measured, but I would guess about this time.
With any ROM, it would have been impossible or very expensive to provide boing bags.
Concerning the "morality" of the story: The question is not whether it is "morally OK", the question is whether it is covered by the license you got from Amiga(?) whomever(?) with the ROM. While I'm not a lawyer, I would typically expect that it disallows disecting the entire work and reproduce it.
The fact people will go to the trouble of doing all this tells us they would gladly pay for an official 1 MB. If the copyright owner won't shut up and take their money, who is to blame.
I actually come to quite the opposide conclusion. People in Amiga land want everything for free, and moan if it is not for free. In specific, a ROM solution would have meant that the boing bags would not have been for free. And I can clearly imagine the %&$#?@!%&$#?@!%&$#?@!%&$#?@!-storm that would have breaken loose if people would have to pay for an upgrade ROM for correcting other's people's faults. Including my own errors.
I like to roll out new releases to users *that have already paid* with no additional costs implied. It was my fault, and I correct it for you, and you don't have to pay to get it fixed because you already paid. Having had a ROM would have made this impossible (or at least, very hard).
-
It did make the old drawer, but the problem was with the assigns it made for all the tools it added. When I rebooted it didnt like my picasso96 screens any more, couldnt find ENV and asked for it, so restoring my files was pain in the butt. It was easier to just format and reboot with my backup drive. I plan to try again and see if I selected something in the install I shouldnt have.
-
Thomas : You were right about 15 years ago. Now regular amiga user is about 45 years old male, most of us have a work etc. No problem to pay kickstart.
There are still those who whine about money because they are used to that, but still they have money.
Another thing is those who have found amiga again becuase of cheap gotek drives, they might thing that anything over 20%&$#?@!%&$#?@!%&$#?@!8364;/$ is too much. BUT they wouldn't have any use to 1mb official rom.
Those who like to have it are hardcore hobbyists whit all possible expansions. Money is not a problem. I spend some 500-1500%&$#?@!%&$#?@!%&$#?@!8364; per year to my hobby.
-
Ahh Utri, TR is right. Amiga users are cheap and want everything for free. Jens released a special edition ACA accelerator a month or so ago for just over $300. Didn't you read all the comments on the thread from people crying about the price? In 1995 that same item would have sold for $1300. Look at the people who don't want to pay for the HS math libs and the Warp datatypes. MUI development stopped because nobody wanted to pay for it. Why do you think very little is being developed new for Amiga's? Because nobody wants to pay. I notice that you have a very nice Amiga collection and mine is similar but we are in the minority.
-
There are reasons by PCs run with a Bios - and UEFI is approximately as bad as an idea as the Kickstart was, even though it is much less complex. Look at all the UEFI bugs that were discovered in the last years, including some bugs that could brick your entire system...
I don't agree that kickstart is a particularly bad idea. If you had a flash chip instead of a rom, like every PC available today, then it would solve most of the issues.
-
I don't agree that kickstart is a particularly bad idea. If you had a flash chip instead of a rom, like every PC available today, then it would solve most of the issues.
Hmm, nice idea :-) Anyone got a ROM to flash adapter with images?
-
It did make the old drawer, but the problem was with the assigns it made for all the tools it added.
Assigns? Which assigns? None of the tools requires any assign, actually. There is only one temporary assign ("..MU..:") added during installation, but only to facilitate the installation process. The startup-sequence is backed up, and the user-startup is not touched. When I rebooted it didnt like my picasso96 screens any more,
It is not too unlikely that the mediator is the source of the problem. This is another hardware that does not use autoconfig to add its resources to the system.
-
I don't agree that kickstart is a particularly bad idea. If you had a flash chip instead of a rom, like every PC available today, then it would solve most of the issues.
Could we please stop this "what-if" game? A flash chip was not available back then, and would have been even more expensive to ship the kickstart with it. Besides, it does not solve the licensing issue, as there is neither a licensed 1MB ROM *image* you could flash.
The software solution allows easy upgrade, with the machines available today, and with no hassle, and no extra cost for the user.
-
bump!
I just had this issue as well with a Blizzard 1260/66Mhz. Was dissapointed in the speed. I then did the following from my research:
-Latest libs! (040_060Libs.lha)
-BlizKick
-FBlit
-FText
-BlazeWCP
-CopyMem060
-UtilPatch060
-CyberPatcher
and it has made a big difference! 52 mips on SysInfo.
Hi there!
With a very similar config. (http://www.chingu.asia/wiki/index.php?title=GibChingu+Hardware), but a few different patches (http://www.chingu.asia/wiki/index.php?title=GibChingu+Startup-Sequence), I reach slightly better raw performances...
(http://www.chingu.asia/wiki/userfiles/image/GibChingu/SysInfo.small.jpg) (http://www.chingu.asia/wiki/userfiles/image/GibChingu/SysInfo.large.jpg)
Cheers!
-
Could we please stop this "what-if" game? A flash chip was not available back then, and would have been even more expensive to ship the kickstart with it. Besides, it does not solve the licensing issue, as there is neither a licensed 1MB ROM *image* you could flash.
The software solution allows easy upgrade, with the machines available today, and with no hassle, and no extra cost for the user.
I actually think for those users who now do have a way to make their own 1 MB ROM the current system IS a hassle.
They are not depriving you or any author of any revenue, and if it fails, no-one is demanding anything from you. They simply want all the patches and fuctionality available at first boot.
Does it really matter if someone uses a different medium ie ROM as opposed to hard drive and RAM to load the same information if thats what they want, knowing the risks of bugs in ROM?
-
Hi there!
With a very similar config. (http://www.chingu.asia/wiki/index.php?title=GibChingu+Hardware), but a few different patches (http://www.chingu.asia/wiki/index.php?title=GibChingu+Startup-Sequence), I reach slightly better raw performances...
(http://www.chingu.asia/wiki/userfiles/image/GibChingu/SysInfo.small.jpg)
Cheers!
Can't read your SysInfo screen! Too small I think it says 54 mips?
Do you mind posting your Startup-Sequence?
-
I actually think for those users who now do have a way to make their own 1 MB ROM the current system IS a hassle.
And the hassle is exactly what? SetPatch keeps care of it, or LoadModule. They are not depriving you or any author of any revenue, and if it fails, no-one is demanding anything from you. They simply want all the patches and fuctionality available at first boot.
Yes, all the functionality, at no charge. That is what Amiga users want. Sorry, won't go. The ROMs generate no revenue for me, instead they would require a new ROM every year, or every time someone fixes a bug or moves out a new version. This doesn't scale and it is completely unpractical. In reality, how much are users expected to pay for a reduction of boot time of 15 seconds or so?
If you want a half-way decent ROM with *some* patches in place, get the one from Cloanto. What, too expensive? Not completely up to date? See, this is the drawback of the ROM. Have *YOU* in specific bought this product? No? Why not?
You cannot get both. Cheap, updated - or slow upgrade policy and expensive. Pick one of two. But don't complain to me. I support both versions. The Cloanto ROM works perfectly fine with MuFastROM. LoadModule works perfectly fine if you use the RAM-Upgrade path. If you don't trust me, Heinz' ROM-Updates also work fine.
Now what is exactly your problem? That you cannot pirate existing software and create your own ROM and have it supported for free? I'm sorry, I won't offer that. Does it really matter if someone uses a different medium ie ROM as opposed to hard drive and RAM to load the same information if thats what they want, knowing the risks of bugs in ROM?
*Sigh*. Once again: The *medium* does not matter. The process of dissecting the existing ROM matters, and the integration of RAM-based modules into the ROM matters.
INAL, but this is as far as I see and understand it not covered by the license. I do not know the precise conditions off my head concerning the kickstart, but if you'll look at my own software as an example, it's license clearly says "Everything must be kept together in original unmodified form". I would be astonished if CBM/Hpyerion/Cloanto would allow you to rip their products apart to create something new. But again, don't ask me. Ask Hyperion or Cloantom and please post the response here. I'm happy to change my mind if they indicate positive feedback and allow this process - for whatever use they seem fit.
-
And the hassle is exactly what? SetPatch keeps care of it, or LoadModule.
I've actually got so many modules patched by LoadModule that I've hit the "Line too long" error in Ed. Not to mention that one typo could hose the entire house of cards... but other than that, meh. It works. ;)
-
Reinstalling Amiga 1200/600 can be real pain, without a 1mb rom.
Any hard drive works, compared that needs to test about 5 diffrent IDE hard drives to found one wich actually works. My current hard drive didn't work at all with original kickstart 3.1.
There is a official kickstart 3.1 with newer scsi.device, but workbench library is left out. That could also be dead end with real amiga.
With 1mb rom any hard drive works to reinstall, I could start with it Deluxe Pain program floppy, need just text editor (ed) and shell.
-
And the hassle is exactly what? SetPatch keeps care of it, or LoadModule. Yes, all the functionality, at no charge.
What? The 3.5/3.9 updates are paid for with OS 3.5/3.9 CD, as are the Boings 1 and 2, and Boings 3 and 4 are PD and need the official 3.5/3.9 CD to work
[That is what Amiga users want. Sorry, won't go. The ROMs generate no revenue for me, instead they would require a new ROM every year, or every time someone fixes a bug or moves out a new version. This doesn't scale and it is completely unpractical. In reality, how much are users expected to pay for a reduction of boot time of 15 seconds or so?
You don't need to do anything additional than what you already are. The user can burn their own ROM at their expense.
If you want a half-way decent ROM with *some* patches in place, get the one from Cloanto. What, too expensive? Not completely up to date? See, this is the drawback of the ROM. Have *YOU* in specific bought this product? No? Why not?
No I haven't bought the Cloanto ROM because this is the first time I heard of it. Its not on a ROM chip so it still leaves me with a double reset which i detest so much. Instead I have created a 3.1 environment with PD off aminet with enough of the 3.9 functionality that i don't notice that i'm not on 3.9
You cannot get both. Cheap, updated - or slow upgrade policy and expensive. Pick one of two. But don't complain to me. I support both versions. The Cloanto ROM works perfectly fine with MuFastROM. LoadModule works perfectly fine if you use the RAM-Upgrade path. If you don't trust me, Heinz' ROM-Updates also work fine.
No disrespect to you or your work but I have never used it....knowingly.
Now what is exactly your problem? That you cannot pirate existing software and create your own ROM and have it supported for free? I'm sorry, I won't offer that.
My problem is that the licensing is unncessarily closed to people who simply want to use software they have paid for ina more efficient form that they are willing to create for themselves and at their won risk
*Sigh*. Once again: The *medium* does not matter. The process of dissecting the existing ROM matters, and the integration of RAM-based modules into the ROM matters.
In what sense does it matter? Licensing? Functionality? Stability?
INAL, but this is as far as I see and understand it not covered by the license. I do not know the precise conditions off my head concerning the kickstart, but if you'll look at my own software as an example, it's license clearly says "Everything must be kept together in original unmodified form".
Whoch is fine- i don't use it as i said earlier
I would be astonished if CBM/Hpyerion/Cloanto would allow you to rip their products apart to create something new. But again, don't ask me. Ask Hyperion or Cloantom and please post the response here. I'm happy to change my mind if they indicate positive feedback and allow this process - for whatever use they seem fit.
People having been using rom2fast and numerous other system patches that were not official since the very first amiga. They've paid for the system software, they are using it for their own purposes, they are not expecting any additional support, they are not depriving anyone of any revenue nor passing the work off as their own. They simply want another way to run it different to the original design.
-
I've actually got so many modules patched by LoadModule that I've hit the "Line too long" error in Ed. Not to mention that one typo could hose the entire house of cards... but other than that, meh. It works. ;)
Well, ROM-Updates solves at least this problem... One possible extension I had in mind is that LoadModule goes through the list of ROM-Modules and updates every module for which it finds a similar name in LIBS:, DEVS: or L:.
Whould this solve your problem?
It is however not quite that simple: A couple of modules exist more than once, i.e. there is more than one exec.library and there is more than one scsi.device so this idea still requires some thought.
-
Reinstalling Amiga 1200/600 can be real pain, without a 1mb rom.
Any hard drive works, compared that needs to test about 5 diffrent IDE hard drives to found one wich actually works. My current hard drive didn't work at all with original kickstart 3.1.
Why does that correlate to the ROM size, and why does the Cloanto ROM not work? If you want to "install" an Amiga, this hardly depends on the ROM, or leave alone its size. It depends on the availability of the medium containing all necessary files. If workbench.library is on it - no problem.
So please don't try to find excuses if you want to be cheap.
-
INAL, but this is as far as I see and understand it not covered by the license.
Btw, I thought you were an *ex* AmigaOS developer?
Does your contract/license/whatever allow you to work on AmigaOS stuff/keep a copy of complete AmigaOS sources on HD/etc. even as ex developer?
Is it the same for all/most ~recent "post Commodore era" ex developers?
-
In what sense does it matter? Licensing? Functionality? Stability?
Legality. I said this in first place. Or how do you get hands on - say - the graphics.library to place it in an alternative ROM? You need to reverse-engineer the original ROM, extract it from there, possibly relocate it and place it in your ROM image. And again, IANAL, most licenses do not allow you to do so. This disection step is the problematic part.
People having been using rom2fast and numerous other system patches that were not official since the very first amiga. They've paid for the system software,
Hold on, no! They/you paid for a software license that comes with certain restrictions and responsibilities. Do not ask me, but disecting a work to create a derived work is IMHO not covered by the original software license. And you don't need to believe me or trust me. You'd better ask the owner.
They simply want another way to run it different to the original design.
Except that dissecting the original system ROM may not be admissible. Is this really so hard to understand? I'm not saying this the first time. Please ask Cloanto or Hyperion to get a definite answer, do not ask me. Until this is clarified, I will not support such "ROMs", and there is no "provably legit" ROM of 1MB.
-
Why does that correlate to the ROM size, and why does the Cloanto ROM not work? If you want to "install" an Amiga, this hardly depends on the ROM, or leave alone its size. It depends on the availability of the medium containing all necessary files. If workbench.library is on it - no problem.
So please don't try to find excuses if you want to be cheap.
If you quote me, please do it correctly / complete. Official rom with newer scsi.device is useless. Do not say what I think or what are my reasons, especially if you have just quote another people point just partially.
There is a official kickstart 3.1 with newer scsi.device, but workbench library is left out. That could also be dead end with real amiga.
[edit] Dead end means that reinstalling requires floppy wich has a workbench.library. If there isn't one how to get one? Floppies are not trustworthy, it is importnt that installing OS doesn't have any special requirements. With my current kickstart, any flpppy wich boots to dos is OK to install OS3.9 or 3.5
Another point is, is even possible to have all filesystems in official rom? like FFS, SFS and PFS? Latter two are now free, but selling them might be impossible?
-
Dead end means that reinstalling requires floppy wich has a workbench.library. If there isn't one how to get one?
While I haven't checked, I would assume that Cloanto would be happy to sell you one, i.e. a disk including the workbench. Thus, I don't quite see where your problem is. Another point is, is even possible to have all filesystems in official rom? like FFS, SFS and PFS? Latter two are now free, but selling them might be impossible?
The FFS is surely ROM-able, and at least the 40.x version is licensed by Cloanto, including a full source code license as I came into learning. I would hope that they have obtained all necessary rights on the updated version they provide, though I do not know how it was created - but that's at least their problem and not mine. I hope their lawyers checked...
The V45 version was done by Heinz for 3.9, and while I do not know his contracts, I would assume that it is still his source and it was only licensed to H&P. So whether this could be put into ROM from a legal perspective, or whether Heinz would be willing to provide his source for such an activity I do not know.
As far as the SFS and PFS is concerned, I neither know. I do not know whether it is technically possible (i.e. is the code ROM-able) and under which license they are available (so, what level of "free" your "free" actually means). I was never interested much in either of them, so I did not check.
Anyhow, any RDB-aware host adapter will be able to load a filing system from harddisk, so there is really not much trouble using an alternative or newer filing system even without the ROM given there is a suitably simple installation process for the filing system. From a technical perspective, it is entirely unnecessary to put the FFS, the SFS or the PFS into ROM.
One thing that irritates me is that you're so much playing with the "ease of installation" argument, leaving aside that is much harder to actually *prepare* a custom ROM in first place than to install an Amiga from its native ROMs using software updates. Unless you imply that "somehow" the user willing to make an installation gets his "custom ROM image for simple installation" from "somewhere".
That, however, is quite clearly piracy, without any argument, my friend!
-
Well, Since Cloanto holds the rights, could they not make custom flash ROM's for a fee and make money instead of giving things away? they have access to almost every patch known to the world.
-
Can't read your SysInfo screen! Too small I think it says 54 mips?
Do you mind posting your Startup-Sequence?
Oops, sorry about the image, I updated my post (http://www.amiga.org/forums/showpost.php?p=802293&postcount=82) to have a "clickable" image (http://www.chingu.asia/wiki/userfiles/image/GibChingu/SysInfo.large.jpg)... There was a link to Startup-Sequence in my post too (http://www.chingu.asia/wiki/index.php?title=GibChingu+Startup-Sequence) :)
Enjoy!