• Modern instant-on systems

    From Daniel@1:340/7 to All on Mon Apr 20 23:46:00 2020
    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?

    I only ask these questions just to get a better understanding of it
    all. My daily laptop is a TRS-80 M200 laptop and, unlike any other
    system in the house, it's instant-on. It's ready to dance a moment
    after depressing the power button.

    It would be utterly BOSS if a modern system could be created in the
    same tact. Could someone enlighten me?

    ... Visit me at: gopher://gcpp.world

    --- MultiMail/Linux v0.49
    * Origin: Digital Distortion: digdist.synchro.net (1:340/7)
  • From Tom Lake@3:770/3 to Daniel on Tue Apr 21 09:56:15 2020
    On Tuesday, April 21, 2020 at 4:15:02 AM UTC-4, 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?

    I only ask these questions just to get a better understanding of it
    all. My daily laptop is a TRS-80 M200 laptop and, unlike any other
    system in the house, it's instant-on. It's ready to dance a moment
    after depressing the power button.

    It would be utterly BOSS if a modern system could be created in the
    same tact. Could someone enlighten me?

    ... Visit me at: gopher://gcpp.world

    You can get almost instant-on by turning on a fast boot switch which is available in most BIOS. Fast boot eliminates a lot of the checking (such as a RAM test) the regular boot does. Remember, for the old systems, the ROM was written for just that
    particular hardware. There was no need to try to identify all sorts of different hard drives, USB devices, etc. The ROM knew exactly what was there and only needed to start BASIC or an rudimentary menu. Modern systems then have to load a very complex OS
    from some device. When everything is in ROM, there's no need to do that.

    --- SoupGate-Win32 v1.05
    * Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)
  • From Computer Nerd Kev@3:770/3 to Daniel on Tue Apr 21 23:00:15 2020
    Daniel <nospam.Daniel@f1.n770.z3139.fidonet.org> 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)
  • From MikeS@3:770/3 to Daniel on Wed Apr 22 14:01:10 2020
    On Tuesday, April 21, 2020 at 4:15:02 AM UTC-4, 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?

    I only ask these questions just to get a better understanding of it
    all. My daily laptop is a TRS-80 M200 laptop and, unlike any other
    system in the house, it's instant-on. It's ready to dance a moment
    after depressing the power button.

    It would be utterly BOSS if a modern system could be created in the
    same tact. Could someone enlighten me?

    ... Visit me at: gopher://gcpp.world

    No problem: just use sleep/suspend mode. That's equivalent to your T200, but you'll need a bigger battery to maintain a suspended multi-core CPU and a million times larger memory...

    m

    --- SoupGate-Win32 v1.05
    * Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)
  • From Computer Nerd Kev@3:770/3 to Computer Nerd Kev on Wed Apr 22 00:57:45 2020
    Computer Nerd Kev <not@telling.you.invalid> wrote:
    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.

    4sec isn't much time wasted from your day.

    Booting KolibriOS on ASRock E350M1 from Coreboot and SeaBIOS: https://www.youtube.com/watch?v=LvZRK1y0VYs

    --
    __ __
    #_ < |\| |< _#

    --- SoupGate-Win32 v1.05
    * Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)