17 Aug
2020
17 Aug
'20
12:43 a.m.
Has SIMH been ported to a low overhead (instant-on) platform?
I ask the question because the startup time of Linux is distracting when
powering on a PiDP-11/70 or similar clone systems based on SIMH.
Thanks
Tom Hunter
17 Aug
17 Aug
1:16 a.m.
On 17/08/2020 08:43, Tom Hunter via cctalk wrote:
Has SIMH been ported to a low overhead (instant-on)
platform?
I ask the question because the startup time of Linux is distracting when
powering on a PiDP-11/70 or similar clone systems based on SIMH.
Haven't seen anything, but Linux can be made to boot much faster, e.g.
if you have hardware which supports Coreboot firmware/BIOS, Linux can
also be loaded from flash along with this, as its payload. So maybe this
and a very minimal filesystem generated with something like
OpenEmbedded, could be one approach.
Also wondered if SimH could be ported to a UEFI application. The
environment seems to provide some O/S like features, but no idea how
much would be missing or significantly different.
Andrew
2:08 a.m.
Andrew Back wrote:
Also wondered if SimH could be ported to a UEFI
application. The
environment seems to provide some O/S like features, but no idea how
much would be missing or significantly different.
I made a set of stubs to compile and link a simulator without the SIMH
framework. Empty stubs only, so it will not actually work. But they
point to what kind of facilities would have to be provided to run a
simulator on some other platform.
8:13 a.m.
On Mon, 17 Aug 2020 at 09:43, Tom Hunter via cctalk
<cctalk at classiccmp.org> wrote:
Has SIMH been ported to a low overhead (instant-on) platform?
I ask the question because the startup time of Linux is distracting when
powering on a PiDP-11/70 or similar clone systems based on SIMH.
Not that I know of.
I have been looking thoughtfully at Ultibo:
https://ultibo.org/
It is a bare-metal FreePascal development environment for the RasPi 1 to 3B.
I have not actually tried to build anything yet and my Pascal skills
are 30y rusty now (and they were never that great anyway, but they're
better than my C skills ever were).
I believe it is possible to get Ultibo to load and execute a
monolithic ARM binary, so long as it meets some requirements. I was
pondering trying to built a statically-linked executable of Aranym:
https://aranym.github.io/
Aranym already runs on the RasPi using Rasbian:
https://sites.google.com/site/beebox68k/news/beepi10
But by the same token it ought to be possible to do this with SimH or
anything else...
--
Liam Proven ? Profile: https://about.me/liamproven
Email: lproven at cix.co.uk ? gMail/gTalk/gHangouts: lproven at gmail.com
Twitter/Facebook/LinkedIn/Flickr: lproven ? Skype: liamproven
UK: +44 7939-087884 ? ?R (+ WhatsApp/Telegram/Signal): +420 702 829 053
9:30 a.m.
There are multiple libraries for bare metal execution on the Pi, there are
trade offs with device support.
Circle comes to mind
https://github.com/rsta2/circle
On Mon, Aug 17, 2020, 11:14 AM Liam Proven via cctalk <cctalk at classiccmp.org>
wrote:
On Mon, 17 Aug 2020 at 09:43, Tom Hunter via cctalk
<cctalk at classiccmp.org> wrote:
Has SIMH been ported to a low overhead (instant-on) platform?
I ask the question because the startup time of Linux is distracting when
powering on a PiDP-11/70 or similar clone systems based on SIMH.
Not that I know of.
I have been looking thoughtfully at Ultibo:
https://ultibo.org/
It is a bare-metal FreePascal development environment for the RasPi 1 to
3B.
I have not actually tried to build anything yet and my Pascal skills
are 30y rusty now (and they were never that great anyway, but they're
better than my C skills ever were).
I believe it is possible to get Ultibo to load and execute a
monolithic ARM binary, so long as it meets some requirements. I was
pondering trying to built a statically-linked executable of Aranym:
https://aranym.github.io/
Aranym already runs on the RasPi using Rasbian:
https://sites.google.com/site/beebox68k/news/beepi10
But by the same token it ought to be possible to do this with SimH or
anything else...
--
Liam Proven ? Profile: https://about.me/liamproven
Email: lproven at cix.co.uk ? gMail/gTalk/gHangouts: lproven at gmail.com
Twitter/Facebook/LinkedIn/Flickr: lproven ? Skype: liamproven
UK: +44 7939-087884 ? ?R (+ WhatsApp/Telegram/Signal): +420 702 829 053
10:34 a.m.
On Aug 17, 2020, at 3:43 AM, Tom Hunter via cctalk
<cctalk at classiccmp.org> wrote:
Has SIMH been ported to a low overhead (instant-on) platform?
I ask the question because the startup time of Linux is distracting when
powering on a PiDP-11/70 or similar clone systems based on SIMH.
Thanks
Tom Hunter
I work with some storage systems (SAN arrays) that are layered on Linux and start in a
small number of seconds. I haven't actually timed how fast, but it's pretty
quick.
NetBSD can also be made to start quite fast.
So I would think you could take your favorite Unix-style OS and trim out all the
unnecessary cruft from the startup. As an experiment, how fast does it start in
single-user mode? You should certainly be able to go that quickly.
Other options includes various RTOS. There are some supported on BeagleBone, that might
be an option.
I have wondered about running a minimal SIMH on Arduino. The newer ones use ARM-32 cores
of one kind or another. I/O would be more limited, but it would be an interesting
experiment to see if a small RT11 type system could run on a Trinket M0. The specs
suggest it might be doable: 256 kB flash, 32 kB RAM, 5 GPIO including UART capability.
Not a lot but certainly more than the small PDP-11 systems I ran RT11 V2 on.
paul
10:50 a.m.
On 8/17/20 12:43 AM, Tom Hunter via cctalk wrote:
Has SIMH been ported to a low overhead (instant-on)
platform?
I ask the question because the startup time of Linux is distracting when
powering on a PiDP-11/70 or similar clone systems based on SIMH.
There are some very small versions of Linux that load quickly,
particularly if you don't need GUI support. For example, BusyBox is a
"stripped to the bones" Linux that finds its way into many (if not most)
'net appliances, such as modems and routers.
I don't know if SIMH will run on it, but there are many other "small"
Linuces.
FWIW,
Chuck
12:53 p.m.
August 17, 2020 7:50 PM, "Chuck Guzis via cctalk" <cctalk at
classiccmp.org> wrote:
On 8/17/20 12:43 AM, Tom Hunter via cctalk wrote:
Until about a year ago, I had a home made device which was an interface between a modified
version SIMH and
a real 11/70 console.
SIMH did run on a mini-itx PC with a 1GHz via processor running ttylinux.
Ttylinux did consist of a V2 or V3 linux kernel, busybox for the commandset and dropbear
for ssh.
To get the bash prompt (no login was required) it only took 15 seconds to boot from a
flash memory card.
Unfortunately, the maintainer of ttylinux has stopped the development for the
buildenvironment, but I
have the version 14 and 16. It has support for the Beaglebone, but not for the Rpi. Still
it might not be
too difficult to create the config files and other build stuff to make it work.
If anyone want to give it a shot, let me know and I'll place it on my website for
download (about 24Mb).
Ed
--
Ik email, dus ik besta 😆
Has SIMH been ported to a low overhead
(instant-on) platform?
I ask the question because the startup time of Linux is distracting when
powering on a PiDP-11/70 or similar clone systems based on SIMH.
There are some very small versions of Linux that load quickly,
particularly if you don't need GUI support. For example, BusyBox is a
"stripped to the bones" Linux that finds its way into many (if not most)
'net appliances, such as modems and routers.
I don't know if SIMH will run on it, but there are many other "smal
Linuces.
FWIW,
Chuck 
4:28 p.m.
On Aug 17, 2020, at 12:43 AM, Tom Hunter via cctalk <cctalk at classiccmp.org>
wrote:
Has SIMH been ported to a low overhead (instant-on) platform?
I ask the question because the startup time of Linux is distracting when
powering on a PiDP-11/70 or similar clone systems based on SIMH.
NetBSD runs SIMH just fine and can be made to boot extremely quickly.
I use NetBSD on a surplus HP ProLiant DL360p Gen8, NetBSD 9.0-stable boots in just a few
seconds. The hardware itself takes a couple minutes to go through its bootstrap process,
however. (I should have considered setting up ESXi and installing NetBSD atop that to
avoid the hardware boot process, since I'm regularly rebuilding and updating NetBSD?)
-- Chris
4:36 p.m.
On Aug 17, 2020, at 4:28 PM, Chris Hanson via cctalk <cctalk at classiccmp.org>
wrote:
NetBSD runs SIMH just fine and can be made to boot extremely quickly.
Oh yeah, NetBSD 9.0-stable 64-bit also only takes a few seconds to boot on a Raspberry Pi
3B+. It's easy enough to just throw on an SD card and try out. Alas the Raspberry Pi 4
isn't supported yet by NetBSD, though I think it's coming along. An RPi4 with 4 or
8GB of RAM should be a very nice turnkey SIMH server.
-- Chris
4:34 p.m.
One thing that would make it much easier to experiment with SIMH in scenarios like this is
if its build system wasn't horribly redundant. It genuinely looks like someone looked
at make and said "How can I turn this into a procedural scripting system?" and
then wrote the SIMH makefile in that style.
It should only take a couple seconds to build SIMH but instead it takes a couple minutes,
rebuilds a ton of things redundantly, and runs all sorts of testing as a side-effect
(instead of having that under a separate target).
At one point I worked out that most of the preprocessor macros fall into just a couple of
buckets so building SIMH could be separated into building just a couple of libsimh
libraries from the same sources (one for 32-bit simulated pointers, one for 64-bit
simulated pointers) and then most of the rest of the targets could *just* be the
target-specific sources plus the right libsimh.
Unfortunately (1) I can't contribute back that change if I make it without jumping
through a lot of bureaucratic hoops (employment agreement) and (2) the current maintainer
appears to not want to hear any criticism whatsoever of SIMH's build system.
-- Chris
18 Aug
18 Aug
5:50 p.m.
On 8/17/20 5:34 PM, Chris Hanson via cctalk wrote:
One thing that would make it much easier to experiment
with SIMH in
scenarios like this is if its build system wasn't horribly redundant.
Why are you mentioning SIMH's /build/ system in a thread discussion boot
times?
I wouldn't object if SIMH's /build/ took 20 minutes if it's something
that only happens every 3-12 months while starting on a tiny Linux /
*BSD / et al. system that /boots/ in a low number of seconds.
--
Grant. . . .
unix || die
7:52 p.m.
On Aug 18, 2020, at 5:50 PM, Grant Taylor via cctalk <cctalk at classiccmp.org>
wrote:
On 8/17/20 5:34 PM, Chris Hanson via cctalk wrote:
Did you miss the part where I said it would make it much easier to experiment with it if
the build system was better? For example, switching between different networking
implementations can require a rebuild.
One thing that would make it much easier to
experiment with SIMH in scenarios like this is if its build system wasn't horribly
redundant.
Why are you mentioning SIMH's /build/ system in a thread discussion boot times?
I wouldn't object if SIMH's /build/ took 20
minutes if it's something that only happens every 3-12 months while starting on a tiny
Linux / *BSD / et al. system that /boots/ in a low number of seconds.
SIMH improves quickly enough that you won't want to do a 20 minute build every 3-12
months, but instead perform new builds with some regularity.
Between that and ease of experimenting (or the lack thereof) a bad build system can really
hold back a project.
-- Chris
20 Aug
20 Aug
4:30 a.m.
On Tue, 2020-08-18 19:52:47 -0700, Chris Hanson via cctalk <cctalk at
classiccmp.org> wrote:
On my laptop, a `make -j4' (building all simulators and running
their tests) takes some 6min 20sec. Fair enough. Building just one
(ie. ,/BIN/vax aka. vax3900 which I care the most about personally) is
a matter of 21 seconds. Sure, that could be faster with careful
dependency tracking, but that's okay for me.
(What bugs me more is that Debian doesn't have up-to-date SIMH
packages, so I have to either use that stuff from stone age or package
it myself...)
On Aug 18, 2020, at 5:50 PM, Grant Taylor via cctalk
<cctalk at classiccmp.org> wrote:
It's debateable whether or not the all-in-one builds are good or bad.
Ie. GCC went into quite some development effort to gain LTO (link-time
optimization) up'n'running, which was built quite exactly to allow
optimizations that would otherwise only be possible if all sources are
compiled in one run.
With any halfway modern hardware, build times probably don't really
matter. Sure, if you're sitting in front of it waiting to finish a
build, every second feels like ... ages.
However, in my experience speed isn't really all that important.
Correctness is. And the Makefile quite works, even without pulling in
all the GNU autoconf or CMake stuff.
On 8/17/20 5:34 PM, Chris Hanson via cctalk
wrote:
Did you miss the part where I said it would make it much easier to
experiment with it if the build system was better? For example,
switching between different networking implementations can require a
rebuild. One thing that would make it much easier to
experiment with SIMH
in scenarios like this is if its build system wasn't horribly
redundant.
Why are you mentioning SIMH's /build/ system in a thread
discussion boot times? I wouldn't
object if SIMH's /build/ took 20 minutes if it's
something that only happens every 3-12 months while starting on a
tiny Linux / *BSD / et al. system that /boots/ in a low number of
seconds.
SIMH improves quickly enough that you won't want to do a 20 minute
build every 3-12 months, but instead perform new builds with some
regularity. Between that and ease of experimenting (or the lack
thereof) a bad
build system can really hold back a project.
I suspect that any one user probably only uses one or two
simulators, not all of them. They compile in a timeframe of some
20 seconds. Most of all users won't be active SIMH hackers, so they
will have that just once in a while when they `git pull'.
If I were to start "from scratch" with SIMH, the steepest part in my
learning curve was to get it properly configured to run something
"useful." Building isn't a real issue IMHO. What would be worth a lot
would be a repository of well-crafted configs along with proper
startup and download scripts (for OS tapes / disk images.)
MfG, JBG
--
10:09 a.m.
New subject: IBM and Calcomp gear rescue in Toronto area
<https://www.reddit.com/r/vintagecomputing/comments/id17d2/i_need_vintagecomputings_help_in_the_early_1980s/>https://www.reddit.com/r/vintagecomputing/comments/id17d2/i_need_vintagecomputings_help_in_the_early_1980s/
IBM 29 card punch
IBM 2501 card reader
IBM 3420 magnetic tape unit
IBM 3803 tape control unit
Calcomp 663 plotter
Calcomp 770 plotter tape storage
Remington tabulator
and some relatively more modern printers, two daisywheels and a laser printer.
11:15 a.m.
New subject: IBM and Calcomp gear rescue in Toronto area
Ugh, those tape drives are gorgeous.
--
Anders Nelson
+1 (517) 775-6129
www.erogear.com
On Thu, Aug 20, 2020 at 1:10 PM John Foust via cctalk <cctalk at classiccmp.org>
wrote:
<
https://www.reddit.com/r/vintagecomputing/comments/id17d2/i_need_vintagecom…
https://www.reddit.com/r/vintagecomputing/comments/id17d2/i_need_vintagecom…
IBM 29 card punch
IBM 2501 card reader
IBM 3420 magnetic tape unit
IBM 3803 tape control unit
Calcomp 663 plotter
Calcomp 770 plotter tape storage
Remington tabulator
and some relatively more modern printers, two daisywheels and a laser
printer.
5:02 p.m.
New subject: IBM and Calcomp gear rescue in Toronto area
My aunt worked at Calcomp (not sure for how long but defintely in the
late 70s), I think in QA. She sent me a couple test plots on some
plastic back then and I still have them.
I think it would be funny to rescue the plotter and send it to her, but
it would probably need to be rescued again soon afterward.
alan
On 8/20/20 11:15 AM, Anders Nelson via cctech wrote:
Ugh, those tape drives are gorgeous.
--
Anders Nelson
+1 (517) 775-6129
www.erogear.com
On Thu, Aug 20, 2020 at 1:10 PM John Foust via cctalk <cctalk at classiccmp.org>
wrote:
>
> <
>
https://www.reddit.com/r/vintagecomputing/comments/id17d2/i_need_vintagecom…
>>
>
https://www.reddit.com/r/vintagecomputing/comments/id17d2/i_need_vintagecom…
>
> IBM 29 card punch
> IBM 2501 card reader
> IBM 3420 magnetic tape unit
> IBM 3803 tape control unit
> Calcomp 663 plotter
> Calcomp 770 plotter tape storage
> Remington tabulator
> and some relatively more modern printers, two daisywheels and a laser
> printer.
>
>
3:39 p.m.
New subject: IBM and Calcomp gear rescue in Toronto area
Please tell me someone is going to save this stuff so I don't have to annoy any
of my Canadian friends :-)
mcl
12:10 p.m.
On Aug 20, 2020, at 4:30 AM, Jan-Benedict Glaw <jbglaw at lug-owl.de> wrote:
It's debateable whether or not the all-in-one
builds are good or bad.
Ie. GCC went into quite some development effort to gain LTO (link-time
optimization) up'n'running, which was built quite exactly to allow
optimizations that would otherwise only be possible if all sources are
compiled in one run.
Link-time optimization has been a thing for a few decades, independent of whether GCC
& GNU ld supported it. And very few compilers actually do anything any differently
when all of the sources are passed in one go; to follow the spec, the compiler must
consider each compilation unit independently, which it'll typically do by spawning one
compilation process per compilation unit.
This also means the build system can't manage the build's parallelism, which is
something you really want on a large project.
With any halfway modern hardware, build times
probably don't really
matter. Sure, if you're sitting in front of it waiting to finish a
build, every second feels like ... ages.
Build times really do still matter. On my modern hardware SIMH still takes long enough to
build that it's a hassle.
However, in my experience speed isn't really all
that important.
Correctness is. And the Makefile quite works, even without pulling in
all the GNU autoconf or CMake stuff.
In my experience the more complex the Makefile, the less likely it is to be correct, and
there's an enormous amount of unnecessary complexity in SIMH's Makefile?especially
since it doesn't just build the simulators but also runs their tests without being
instructed to. SIMH's Makefile results in a lot of unnecessary rebuilding and
waiting.
On my laptop, a `make -j4' (building all
simulators and running
their tests) takes some 6min 20sec. Fair enough. Building just one
(ie. ,/BIN/vax aka. vax3900 which I care the most about personally) is
a matter of 21 seconds. Sure, that could be faster with careful
dependency tracking, but that's okay for me.
You don't even need careful dependency tracking to improve this, just regular make
behavior. What's more, the way the Makefile is currently constructed interferes with
your use of `make -j4` by producing unnecessary output.
In short, cleaning up the build to work like any other make-based project would result in
faster builds and make SIMH easier to work on for people interested in doing so.
-- Chris
1584
days inactive
1588
days old
18 comments
15 participants
participants (15)
-
anders.k.nelson＠gmail.com -
andrew＠carrierdetect.com -
aperry＠snowmoose.com -
cclist＠sydex.com -
cctalk＠gtaylor.tnetconsulting.net -
ccth6600＠gmail.com -
cmhanson＠eschatologist.net -
dk＠thewaffleiron.net -
eg90804＠groenenberg.net -
jbglaw＠lug-owl.de -
jfoust＠threedee.com -
lars＠nocrew.org -
linimon＠lonesome.com -
lproven＠gmail.com -
paulkoning＠comcast.net