Discussion:
Modern instant-on systems
(too old to reply)
Daniel
2020-04-20 10:46:00 UTC
Permalink
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
Tom Lake
2020-04-21 16:56:15 UTC
Permalink
Post by Daniel
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.
Daniel
2020-05-30 21:01:00 UTC
Permalink
-=> Tom Lake wrote to Daniel <=-

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

Thank you for the reply. Let met phrase the question a different way because I
don't think I properly conveyed the question.

Imagine if Commodore continued releasing faster and more advanced versions of
the C64. System still loads on ROM and, with a flip of a switch the user is
welcomed with either a basic screen or a basic menu UI.

David, of the 8 bit guy, is actually building a souped up Vic 20 with off the
shelf components and getting help on his pursuit from a variety of people
including an old Commodore engineer. His dream machine, as he calls it. I think
he's naming it the Commander X16. He's intending to mass produce it for the
retro computing scene. Yeah he's a small guy with very little funding but the
pursuit is similar in concept to my question the one i asked about. Every copy
will be on identical hardware and software so OS complexity shouldn't be much
more complex than the original system.

while he's building a modern 8bit machine, I'm wondering if it would be
possible to do this very thing with a modern 32 or 64 bit processor with modern
storage, memory, video/audio, and input/output yet be instant on. And the
developer would be responsible for the look and feel of the application.

Daniel Traechin
... Visit me at gopher://gcpp.world
Tom Lake
2020-06-01 03:21:07 UTC
Permalink
Post by Daniel
-=> Tom Lake wrote to Daniel <=-
As long as there are no variations in the hardware, there's absolutely no reason why you couldn't have an instant-on modern system.

Tom L
Computer Nerd Kev
2020-04-21 23:00:15 UTC
Permalink
Post by Daniel
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?
--
__ __
#_ < |\| |< _#
Computer Nerd Kev
2020-04-22 00:57:45 UTC
Permalink
Post by Computer Nerd Kev
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:

--
__ __
#_ < |\| |< _#
Daniel
2020-07-16 19:12:00 UTC
Permalink
-=> Computer Nerd Kev wrote to Computer Nerd Kev <=-
Post by Computer Nerd Kev
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.
CNK> 4sec isn't much time wasted from your day.

CNK> Booting KolibriOS on ASRock E350M1 from Coreboot and SeaBIOS:
CNK> http://youtu.be/LvZRK1y0VYs

A few things have come up since this thread took a break

1. I played with kolibriOS. Impressive and full of promise
2. I discovered the Color Maximite 2. Started another thread about it. So I'm
inspired to port some of the kolibriOS apps to the maximite 2.

It's really exciting to me. That device is powerful enough to do many
mainstream
things due to the lack of operation system drag.

I had been designing a trilogy fantasy rpg for the C64 but, maybe, it'll go to
the maximite.

Daniel Traechin

... Visit me at gopher://gcpp.world
Computer Nerd Kev
2020-07-18 05:19:55 UTC
Permalink
Post by Daniel
-=> Computer Nerd Kev wrote to Computer Nerd Kev <=-
Post by Computer Nerd Kev
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.
CNK> 4sec isn't much time wasted from your day.
CNK> http://youtu.be/LvZRK1y0VYs
A few things have come up since this thread took a break
1. I played with kolibriOS. Impressive and full of promise
2. I discovered the Color Maximite 2. Started another thread about it. So I'm
inspired to port some of the kolibriOS apps to the maximite 2.
The issue there is that KolibriOS-specific software is generally
written in x86 assembly, but the Maximite 2 uses an ARM CPU. So it
would be more like rewriting the software than porting it.

Still, if you've got some specific things in mind then it could be
good for inspiration.
--
__ __
#_ < |\| |< _#
Daniel
2020-07-17 20:01:00 UTC
Permalink
-=> Computer Nerd Kev wrote to Daniel <=-
Post by Daniel
-=> Computer Nerd Kev wrote to Computer Nerd Kev <=-
Post by Computer Nerd Kev
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.
CNK> 4sec isn't much time wasted from your day.
CNK> http://youtu.be/LvZRK1y0VYs
A few things have come up since this thread took a break
1. I played with kolibriOS. Impressive and full of promise
2. I discovered the Color Maximite 2. Started another thread about it. So I'm
inspired to port some of the kolibriOS apps to the maximite 2.
CNK> The issue there is that KolibriOS-specific software is generally
CNK> written in x86 assembly, but the Maximite 2 uses an ARM CPU. So it
CNK> would be more like rewriting the software than porting it.

Oh

CNK> Still, if you've got some specific things in mind then it could be
CNK> good for inspiration.

We'll see.

Daniel Traechin

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

MikeS
2020-04-22 21:01:10 UTC
Permalink
Post by Daniel
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
Loading...