Subj : Re: Modern instant-on systems To : Daniel From : Computer Nerd Kev Date : Tue Apr 21 2020 11:00 pm Daniel wrote: > Before saying anything, I want to point out that there is no pretense > of expertise in this subject. I'm just a curious bean. As the growth > of retro computing matures, projects to resurrect the platforms by > building vice boxes gets more common. The C64-mini, the zx spectrum, > sega.. Otherwise, the 8-bit guy is taking off-the-shelf components to > build himself a modern juiced up Vic20 to sell at some point beyond > vaporware. They're creating the basic interpreter and kernal for their > system. All's well and good. This brought me to an interesting thought > with a similar notion. What stops anyone from doing the same thing > with a modern cpu and memory/bus system? Is it the complexity of the > modern cpu? In retro systems, the developer controlled memory > allocation such. I'd assume the difficult part would be to micromanage > every bit of memory management on a complex system. Am I on the right > track? There are a few things in play that prevent similar start-up times to old 8bit computers being easily acheived. First remember that technically nothing's instant, indeed there's a decidedly perceptible delay between turning on a C64 and seeing a command prompt, it's just not long enough to be inconvenient. Also a C64 only has to read from its own ROM, which is equivalent in performance to RAM and is ready and waiting to be accessed as soon as turned on. PCs almost always have to load their OS from a storage device into RAM, and then begin execution. Storage devices are slower, need initialisation (BIOS code), and limited by an interface bus that does not connect directly to the CPU like RAM/ROM. A more fair comparison is when the C64 is asked to load GEOS from a floppy drive, where of course the results are less in its favour. It is possible for the OS kernel to be included in a custom BIOS (eg. CoreBoot) that is written over the default one. Some of the old PCs actually made by IBM had their own BASIC interpreter in BIOS. But next you have to do all of the detection and initialisation for modern devices, which all have their own little bits of code that need to run on a per-device basis. Here you can compare with MSDOS, which on eg. a fast early 90s PC with a quick BIOS (some were very quick, eg. on laptops) could approach something like the start-up time of a C64. The advantage that DOS had is that it relied on the BIOS to handle the HDD, display, and keyboard initialisation, and for what else the user wanted to use they configured a specific driver that didn't have to do automatic detection because the poor confused user was usually forced to figure out the details and pre-configure it manually. There often wasn't all that much else that needed to be initialised on a typical DOS system either. A modern OS is designed to detect everything automatically, and generally ignores any device interface provided by the BIOS in preference to its own set of device drivers which are probably faster and/or more reliable once they've been loaded. Still there are roads to take if you want to pursue a PC that boots in a non-inconvenient amount of time, albeit maybe a little longer than an old 8bit. I've already mentioned DOS, and while drivers for modern things like networking and USB will slow it down, you can find out for yourself what the limit is with FreeDOS. TinyCore Linux is a very fast minimal Linux distro that loads itself entirely into RAM on start up, and the start-up time is thereby proportional to the packages that you configure to be loaded, after which they run very quickly. KolibriOS is an x86 OS written entirely in assembly - I've only booted it from a Floppy or a CD so I haven't really seen the start-up time from HDD, but it probably has potential. I've already mentioned CoreBoot, which can optimise the first step - loading the OS kernel. I'll ignore stand-by type systems on the basis that they're kind-of cheating. All of those options have potential, but it's not the direction where mainstream OS development has gone. Fact is that it's easier to write an OS that boots slowly, while doing everything that users demand from one today. Said users generally put up with it, so that's what we get. Oh and there are programs for PC like GRUBinvaders that run without an OS at all, using just the BIOS interface to devices. That's akin to a cartridge ROM running on a C64, except that the program has to be loaded from HDD into RAM first. Though you could probably put it in a CoreBoot BIOS image and have a PC that boots really quick but just plays text-mode Space Invaders and nothing else. :) - Idea: Connect the BIOS EPROM socket up to a female edge connector and make cartridges with CoreBoot images for different x86 OS-less games? -- __ __ #_ < |\| |< _# --- SoupGate-Win32 v1.05 * Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3) .