@itix

I never said anything about surviving reboot.

_________________
This weeks pet peeve:
Using "voltage" instead of "potential", which leads to inventing new words like "amperage" instead of "current" (I, measured in A) or possible "charge" (amperehours, Ah or Coulomb, C). Sometimes I don't even know what people mean.

What this video lacks is the bios. You already have a computer up and runnning and run another system on top. When booting the very same system, even from some fancy RAD you still will be stuck for seconds in the bios, which gathers information on connected devices and hardware.

Post bios our systems are quite fast. Using some SSD even my old Pegasos2 boots into MorphOS in about a second. Cannot tell the exact value as the display needs longer to adjust frequency from bios resolution to desktop resolution.

In addition to an SSD a proper RAM cache is very useful. MorphOS has a flexible RAM cache for all drives build in, which is far more important than boot times. Especially when compiling stuff. Starting with the second compile even the slowest harddrive competes well with the fastest SSD, as there are basically zero actual drive cycles and just the cpu and the memory speed counts.

Here on my main system with a crappy 16GB CF drive compiling Ambient gets speed up from over 15 minutes to less than 7 on the second run. For the fun I copied GG: and sources to RAM: once and compared, but the result was not worth it compared to second run.

You also need to copy the data into RAM at least once anyway. With a proper caching mechanism you only copy the data you need and not the entire system everytime you turn your system on. The result would be some windowish quickloader for shit you use once a month mostly wasting memory all time, even if it is beyond some unrechable memory boundary. In case this boundary is gone (64bit OS) all effort gone into that driver is more or less useless anyway.

I personally added some LoadLib command loading all mui and reggae classes while the system is on the log in screen as many of them are needed anyway and they get flushed away automatically if not and memory runs out.

Geit

Last edited by geit on 20-Apr-2016 at 12:01 PM.

@olegil

If RAD can't survive reboot you can't boot from RAD. You could just use vanilla Amiga RAM DISK for the job unless you really want to emulate sector based disk access.

_________________
Amiga Developer
Amiga 500, Efika, Mac Mini and PowerBook

@itix

And how is that different than the original post? I know for a fact it works on SOME AmigaOne hardware, but obviously not for hard reset, only soft resets.

_________________
This weeks pet peeve:
Using "voltage" instead of "potential", which leads to inventing new words like "amperage" instead of "current" (I, measured in A) or possible "charge" (amperehours, Ah or Coulomb, C). Sometimes I don't even know what people mean.

@paolone

Quote:

paolone wrote: @Massi Yeah, but I was thinking about practical solutions for this hot water. A presistent RAM drive (which might store datas on a SSD or a hard drive at shutdown or, even better, when idling) would allow mounting, on a 64 bit OS, a whole system drive of various GBs of size on RAM, including all needed files and applications. Making the most responsive OS solution ever.

Exactly what Puppy linux does. only that Puppy runs native

_________________
No PowerPC, No Fun
Make Amiga Great Again

@olegil

Quote:

And how is that different than the original post?

The RAD is available right away from the cold boot. Normally you would have to copy your system partition to RAD on the first boot or when RAD becomes corrupt.

Of course you have to copy disk image to Windows RAM disk first but if you never restart Windows it never goes away. It survives even if AROS crashes badly (assuming the filesystem integrity is never compromised due to crashes).

If you made the filesystem read only you probably could even use same boot partition in multiple AROS instances.

_________________
Amiga Developer
Amiga 500, Efika, Mac Mini and PowerBook