New Kickstart 3.9.1 68k on the way

[Cosmos]

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.

I found the source of a CD driver for A1200. Should works on A600 too. On 4000D/T ? Don't know...

One kickstart for all amigas sounds like a nightmare to get right

No, the easiest part.

With no downloads available, I dont see a reason to update or even test something that I cannot even lay my hands upon

All my releases are now private.

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

Commodore ingenieers were paid. Me no... Another big troll...

Uhm, why old shell and ram-handler?

Because these updates from the 3.9 were from SuperTroller : he will cause me trouble later...

[olsen]

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

So... what exactly is your justification for picking one component over another, considering its qualities and origins?

It's not as if the components of Kickstart 3.1 were flawless, and neither is the case for the 3.0 components. For example, bugs in the 68k scsi.device V40 are the reason why scsi.device V39 is used in the V40 A600/A500/A2000 ROM.

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?

Knowing what went into building the original ROMs, compatibility issues, hardware dependencies and space constraints, I consider your goals extremely ambitious. Good luck! This is certainly going to be interesting to watch

[guest11527]

I guess you could say that everyone stole from Alan Touring, or something like that.

Hardly. But AmigaOs is proprietary, and like it or not, it is not available without license, and not available for reverse engineering either. There would be no problem if the corresponding code had been rewritten from scratch, BTW, but apparently that's too much a challenge and beyond capabilities - I guess it's just much easier to take the hard work of others, patch it up to the liking and post it into the internet without asking - and what an irony - complain if somebody else does the same.  I guess I had pointed this out before, but there *is* an Open Source AmigaOs project, and I would believe that they would welcome contributions. That would require, however, that this work is genuine.

[Cosmos]

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?

Again, I tried in the past (8/8/2010 at 18:52 and another email at 21h32, I still have the emails here) : the answer was no about making the 680x0.library and mmu.library romable...

So, I give up... I have zero money in my pockets to give for this Kickstart & copyright & licence, sorry...


Anyways, I wanna absolutly the TLSF memory organisation into my new exec.library... Ok here, I'm afraid to ask the bear Chris Hodge, I don't want he eats me...

Anyone here skilled enough to build a new version in C/C++ ? After, I'll adapt in asm...

[guest11527]

Because these updates from the 3.9 were from SuperTroller : he will cause me trouble later...

Your research is lousy, actually, and I thank you for at least not touching Heinz' and my copyright. (RAM was made by Heinz Wrobel, FYI.) I hope you have permission from the other authors, don't you? For example, I read the following in Kingkong's guide: "Everything in this distribution must be kept together, in original unmodified form." Did you?

If the whole affair is showing one thing then at least that you're not even willing to take five minutes of time to check who owns what, and probably approach the corresponding owners for permission, even if that would have been only a formal step.

[biggun]

Easy people.
Please please be easy. :-)

Lets phrase it this way:

There are few people left in the scene which spend time to improve the system still.


Whether these people develop new CPU cards,
or develop new chipsets, or try to write or port games,
or develop a new OS alternative
or whether they try to patch old OS.

The intention to help and keep the platform living as shared by all of us.

So lets please try not to fight but be happy that people have the will to improve our system.



I see great motivation in the work that Cosmos does.

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.

[olsen]

I see great motivation in the work that Cosmos does.

I agree, but as far as I can tell this is a hobby project, meaning that it will be finished when it will be finished, with no guaranteed feature list, with properties determined solely by what Cosmos considers appropriate. Nothing wrong with that, I'd say, as long as you do not expect more, such as bug fixes or changes for the better that would involve major rewrites of the existing software.

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.

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.

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.

Any such team effort will require motivation, time and likely money. Vote with your wallet if you want to see this type of thing happening. If you don't consider this worthwhile, which certainly is a valid choice, you may have to accept the constraints under which Cosmos' project evolves, and which results is produces.

[biggun]

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.

You are certainly right here.
And developing OS upgrades in ASM is certainly not an easy task too.


On the other hand I can see areas where an ASM Hero could do great stuff on AMIGA.

For example the Phoenix Core we play around already includes
a number of new features and we will include more to strengthen it.

Options to code memory reads 100% latency free!
Options to write branches with will never mispredict!
And SIMD instructions.

An ASM hero who uses these well and is willing to count clockcycles for optimization
could certainly write stuff like new JPEG databtypes with this
which will run 10 times faster than the fastest 68060 does run today.

I know its a bold statement but I'm sure a good coder could do stuff like this.
I also think that good video playback will be possible with this.

Of course we won't compete with latest x86 cores.
But these would be "isolated" coding areas where an ASM expert could really change something.

[wawrzon]

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.

yes the controllers are included in aros kickstart that could be put in a flash and then you have all that accessible at boot time including cd-rom. just none does it currently, but that is the reason to have it in kickstart of course.

[kamelito]

There's more Amiga users under emulation than real HW. Seeing how Win/FS(UAE) are improving on PPC emulation, I suppose that these users will go that way instead of staying in pure 68k land. We just need to wait for a Cloanto deal with AmigaOS 4.1 Final.
I still think however that an improved 68k based Amiga OS has a future for real HW but most importantly to FPGA implementation.

Kamelito

[kolla]

I still dont see what workbench.library and icon.library does in kickstart, unless you also throw in loadwb.

[olsen]

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.

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.

[guest11527]

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?

What is currently killing boot performance is the second boot, required for the kick-tags to jump in. If the components required for kicktags could be *removed* from ROM, this second reboot would be unnecessary, and the components could be safely loaded from harddisk in at most two seconds. Why is that a problem?

Stuff that currently is in ROM and that could be easily removed are mathffp, mathieeesingbas and the audio device. Stuff that should be replaced by minimalistic stub-routines, and that should rather be bootstrapped are gfx,intuition,gadtools,input,layers, shell, ram...  

The benefit would be that it would offer the opportunity for an evolutionary progression of AmigaOs,nobody would require to ever stick a new ROM into the machine for new features in a system component.  It would be enough to publish the components.

[biggun]

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?

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

[Cosmos]

a time getting the basic three "scsi.device" variations to work together in ROM: one of them will always crash.

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

I still dont see what workbench.library and icon.library does in kickstart

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

The ROM read physically limited to 3.5 MB/sec on classic

The exec.library at power on build only the jmp tables in ram, and the functions are still in rom and execute from the rom...

[olsen]

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