Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > alt.folklore.computers > #234429 > unrolled thread

Self-hosting and the 6502

Back to article view | Back to alt.folklore.computers

Contents

  Self-hosting and the 6502 Lev <thresh3@fastmail.com> - 2026-03-30 01:16 +0000
    Re: Self-hosting and the 6502 Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-03-30 06:12 +0000
      Re: Self-hosting and the 6502 thresh3@fastmail.com (Lev) - 2026-03-30 07:07 +0000
        Re: Self-hosting and the 6502 Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-03-30 08:13 +0000
          Re: Self-hosting and the 6502 thresh3@fastmail.com (Lev) - 2026-03-30 13:11 +0000
            Re: Self-hosting and the 6502 cross@spitfire.i.gajendra.net (Dan Cross) - 2026-03-30 14:25 +0000
              Re: Self-hosting and the 6502 Peter Flass <Peter@Iron-Spring.com> - 2026-03-30 07:40 -0700
                Re: Self-hosting and the 6502 Bob Eager <news0009@eager.cx> - 2026-03-30 17:02 +0000
                  Re: Self-hosting and the 6502 cross@spitfire.i.gajendra.net (Dan Cross) - 2026-03-31 21:35 +0000
                    Re: Self-hosting and the 6502 Bob Eager <news0009@eager.cx> - 2026-03-31 22:31 +0000
                      Re: Self-hosting and the 6502 cross@spitfire.i.gajendra.net (Dan Cross) - 2026-04-01 10:44 +0000
                        Re: Self-hosting and the 6502 Bob Eager <news0009@eager.cx> - 2026-04-01 10:47 +0000
                          Re: Self-hosting and the 6502 cross@spitfire.i.gajendra.net (Dan Cross) - 2026-04-01 13:57 +0000
                Re: Self-hosting and the 6502 cross@spitfire.i.gajendra.net (Dan Cross) - 2026-03-31 21:34 +0000
                  Re: PC/IX, was Self-hosting and the 6502 John Levine <johnl@taugh.com> - 2026-04-01 02:01 +0000
                Re: Self-hosting and the 6502 "Kurt Weiske" <kurt.weiske@realitycheckbbs.org.remove-a96-this> - 2026-04-02 07:35 -0700
              Re: Self-hosting and the 6502 jayjwa <jayjwa@atr2.ath.cx.invalid> - 2026-04-01 18:14 -0400
                Re: Self-hosting and the 6502 cross@spitfire.i.gajendra.net (Dan Cross) - 2026-04-01 22:56 +0000
                  Re: Self-hosting and the 6502 Rich Alderson <news@alderson.users.panix.com> - 2026-04-01 21:44 -0400
                    Re: Self-hosting and the 6502 Peter Flass <Peter@Iron-Spring.com> - 2026-04-01 21:35 -0700
            Re: Self-hosting and the 6502 Nuno Silva <nunojsilva@invalid.invalid> - 2026-03-30 15:25 +0100
              Re: Self-hosting and the 6502 Peter Flass <Peter@Iron-Spring.com> - 2026-03-30 07:42 -0700
            Re: Self-hosting and the 6502 Gordon Henderson <gordon+usenet@drogon.net> - 2026-04-01 11:43 +0000
              Self-hosting and the PDP-10 [was Re: Self-hosting and the 6502] Rich Alderson <news@alderson.users.panix.com> - 2026-04-01 15:41 -0400
                Re: Self-hosting and the PDP-10 [was Re: Self-hosting and the 6502] cross@spitfire.i.gajendra.net (Dan Cross) - 2026-04-01 22:16 +0000
                  Re: Self-hosting and the PDP-10 [was Re: Self-hosting and the 6502] Rich Alderson <news@alderson.users.panix.com> - 2026-04-01 21:51 -0400
                    Re: Self-hosting and the PDP-10 [was Re: Self-hosting and the 6502] Peter Flass <Peter@Iron-Spring.com> - 2026-04-01 21:37 -0700
                      Re: Self-hosting and the PDP-10 [was Re: Self-hosting and the 6502] cross@spitfire.i.gajendra.net (Dan Cross) - 2026-04-02 10:50 +0000
                        Re: Self-hosting and the PDP-10 [was Re: Self-hosting and the 6502] Rich Alderson <news@alderson.users.panix.com> - 2026-04-02 15:18 -0400
                          Re: Self-hosting and the PDP-10 [was Re: Self-hosting and the 6502] cross@spitfire.i.gajendra.net (Dan Cross) - 2026-04-03 13:13 +0000
                    Re: Self-hosting and the PDP-10 [was Re: Self-hosting and the 6502] cross@spitfire.i.gajendra.net (Dan Cross) - 2026-04-02 10:58 +0000
                      Re: Self-hosting and the PDP-10 [was Re: Self-hosting and the 6502] Peter Flass <Peter@Iron-Spring.com> - 2026-04-02 07:32 -0700
                        Re: Self-hosting and the PDP-10 [was Re: Self-hosting and the 6502] cross@spitfire.i.gajendra.net (Dan Cross) - 2026-04-02 18:23 +0000
        Re: virtualization, Self-hosting and the 6502 John Levine <johnl@taugh.com> - 2026-03-30 16:28 +0000
      Re: Self-hosting and the 6502 Bill Findlay <findlaybill@blueyonder.co.uk> - 2026-03-30 17:59 +0100
        Re: Self-hosting and the 6502 Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-03-30 21:24 +0000
    Re: Self-hosting and the 6502 cross@spitfire.i.gajendra.net (Dan Cross) - 2026-03-30 14:16 +0000
      Re: Self-hosting and the 6502 Peter Flass <Peter@Iron-Spring.com> - 2026-03-30 07:35 -0700
        Re: emulation, virtualization, Self-hosting and the 6502 John Levine <johnl@taugh.com> - 2026-03-30 16:39 +0000
          Re: emulation, virtualization, Self-hosting and the 6502 ted@loft.tnolan.com (Ted Nolan <tednolan>) - 2026-03-30 17:20 +0000
            Re: emulation, virtualization, Self-hosting and the 6502 cross@spitfire.i.gajendra.net (Dan Cross) - 2026-03-31 23:39 +0000
              Re: emulation, virtualization, Self-hosting and the 6502 scott@slp53.sl.home (Scott Lurndal) - 2026-04-02 14:57 +0000
                Re: emulation, virtualization, Self-hosting and the 6502 rbowman <bowman@montana.com> - 2026-04-02 18:04 +0000
                  Re: emulation, virtualization, Self-hosting and the 6502 scott@slp53.sl.home (Scott Lurndal) - 2026-04-02 18:45 +0000
        Re: Self-hosting and the 6502 David Wade <g4ugm@dave.invalid> - 2026-03-30 18:03 +0100
        Re: Self-hosting and the 6502 Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-03-30 21:23 +0000
        Re: Self-hosting and the 6502 cross@spitfire.i.gajendra.net (Dan Cross) - 2026-03-31 23:05 +0000
      Re: Self-hosting and the 6502 John Ames <commodorejohn@gmail.com> - 2026-03-30 07:57 -0700
        Re: Self-hosting and the 6502 cross@spitfire.i.gajendra.net (Dan Cross) - 2026-03-30 22:19 +0000
          Re: Self-hosting and the 6502 Nuno Silva <nunojsilva@invalid.invalid> - 2026-03-31 00:18 +0100
            Re: Self-hosting and the 6502 cross@spitfire.i.gajendra.net (Dan Cross) - 2026-03-31 22:04 +0000
      Re: Self-hosting and the 6502 Bob Eager <news0009@eager.cx> - 2026-03-30 17:07 +0000
    Re: Self-hosting and the 6502 antispam@fricas.org (Waldek Hebisch) - 2026-03-31 03:34 +0000
      Re: Self-hosting and the 6502 Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-03-31 03:54 +0000
        Re: Self-hosting and the 6502 antispam@fricas.org (Waldek Hebisch) - 2026-03-31 05:01 +0000
      Re: Self-hosting and the 6502 Lev <thresh3@fastmail.com> - 2026-03-31 05:26 +0000
      Re: Self-hosting and the 6502 Peter Flass <Peter@Iron-Spring.com> - 2026-03-31 07:48 -0700
        Re: machine simulation, Self-hosting and the 6502 John Levine <johnl@taugh.com> - 2026-03-31 18:06 +0000
      Re: Self-hosting and the 6502 scott@slp53.sl.home (Scott Lurndal) - 2026-03-31 15:03 +0000
      Re: Self-hosting and the 6502 Bill Findlay <findlaybill@blueyonder.co.uk> - 2026-03-31 18:23 +0100
        Re: Self-hosting and the 6502 Peter Flass <Peter@Iron-Spring.com> - 2026-03-31 13:04 -0700

Page 3 of 4 — ← Prev page 1 2 [3] 4  Next page →

#234521 — Re: emulation, virtualization, Self-hosting and the 6502

In article <n2vpmmF46gsU1@mid.individual.net>,
Ted Nolan <tednolan> <tednolan> wrote:
>In article <10qe90l$kv9$2@gal.iecc.com>, John Levine  <johnl@taugh.com> wrote:
>>According to Peter Flass  <Peter@Iron-Spring.com>:
>>>The difference here is clear. My question is, what's the difference 
>>>between emulation and simulation? Is there a difference, even if only in 
>>>connotation.  I'm never quite clear on whether to call something an 
>>>emulator or a simulator.
>>
>>The usual rule of thumb is that emulation involves hardware or microcode
>>support,
>>simulation is just software.
>>
>>Virtualization is something else, where the architecture of the internal system
>>is the same as the external system so you can run the same operating system in
>>a virtual machine you can on the hardware, give or take very small tweaks. 
>
>I would say that's not quite complete, as you had the 386 being able to
>virtualize the 8086, but not itself.

Here, I think we have to be careful with our definitions.  I
don't think that when Intel decided to call that "virtual 8086
mode" that they meant what we mean when we're talking about with
whole-system virtualization.

	- Dan C.

[toc] | [prev] | [next] | [standalone]

#234577 — Re: emulation, virtualization, Self-hosting and the 6502

cross@spitfire.i.gajendra.net (Dan Cross) writes:
>In article <n2vpmmF46gsU1@mid.individual.net>,
>Ted Nolan <tednolan> <tednolan> wrote:
>>In article <10qe90l$kv9$2@gal.iecc.com>, John Levine  <johnl@taugh.com> wrote:
>>>According to Peter Flass  <Peter@Iron-Spring.com>:
>>>>The difference here is clear. My question is, what's the difference 
>>>>between emulation and simulation? Is there a difference, even if only in 
>>>>connotation.  I'm never quite clear on whether to call something an 
>>>>emulator or a simulator.
>>>
>>>The usual rule of thumb is that emulation involves hardware or microcode
>>>support,
>>>simulation is just software.
>>>
>>>Virtualization is something else, where the architecture of the internal system
>>>is the same as the external system so you can run the same operating system in
>>>a virtual machine you can on the hardware, give or take very small tweaks. 
>>
>>I would say that's not quite complete, as you had the 386 being able to
>>virtualize the 8086, but not itself.
>
>Here, I think we have to be careful with our definitions.  I
>don't think that when Intel decided to call that "virtual 8086
>mode" that they meant what we mean when we're talking about with
>whole-system virtualization.

Back in 1998/1999 at SGI, I was part of an internal
skunkwork project to design and implement a hypervisor
for virtualization (code named Crucible (crux)) on an
intel Pentium Pro (Pentium II?) multiprocessor system.

We were using HP Kayak boxes for testing.  Our initial
goal was to run both linux and windows NT 4.0 on the
same system simultaneously as guests of the hypervisor.

Each guest was permanently assigned to one of the CPUs.

We spent some time investigating whether the
intel virtual 8086 mode was useful for virtualization,
but in the end it turned out not to be the case.

We did get it working, but it was never productized
(about the same time VMware came out of stealth mode).

[toc] | [prev] | [next] | [standalone]

#234584 — Re: emulation, virtualization, Self-hosting and the 6502

On Thu, 02 Apr 2026 14:57:05 GMT, Scott Lurndal wrote:

> We were using HP Kayak boxes for testing.  Our initial goal was to run
> both linux and windows NT 4.0 on the same system simultaneously as
> guests of the hypervisor.

Did you have any problems with the Kayaks? It's been too long and I don't 
remember the specifics but there was something about then. We used ONC RPC 
and we ran into a system that was using 111 but I don't think it was the 
HPs.

[toc] | [prev] | [next] | [standalone]

#234586 — Re: emulation, virtualization, Self-hosting and the 6502

rbowman <bowman@montana.com> writes:
>On Thu, 02 Apr 2026 14:57:05 GMT, Scott Lurndal wrote:
>
>> We were using HP Kayak boxes for testing.  Our initial goal was to run
>> both linux and windows NT 4.0 on the same system simultaneously as
>> guests of the hypervisor.
>
>Did you have any problems with the Kayaks? It's been too long and I don't 
>remember the specifics but there was something about then. We used ONC RPC 
>and we ran into a system that was using 111 but I don't think it was the 
>HPs.

Not that I recall. Ours were all dual processor boxes.

[toc] | [prev] | [next] | [standalone]

#234449

On 30/03/2026 15:35, Peter Flass wrote:
> On 3/30/26 07:16, Dan Cross wrote:
> [snip]
>>
>> It depends on what you mean by, "running machines inside
>> machines".  There are two primary methods: emulation, in which
>> one machine completely emulates another in software; people have
>> been doing that since, probably, the 50s; perhaps earlier.
>>
>> Then there is virtualization, in which the "virtual mchine" is
>> primarily running directly on the underlying hardware, in which
>> case AFAIK IBM was the first with CP/40, which evolved into
>> VM/370.
>>
> 
> The difference here is clear. My question is, what's the difference 
> between emulation and simulation? Is there a difference, even if only in 
> connotation.  I'm never quite clear on whether to call something an 
> emulator or a simulator.

Just to say this concept, in a somewhat abstract way, pre dates any 
physical hardware. I think I have this right.

In Turing's paper 1936 paper "On Computable Numbers, with an Application 
to the Entscheidungsproblem" he defines a family of "Turing Machines" 
each of which performs a fixed task. He then defines a "Universal Turing 
Machine" which can emulate/simulate/act as any of the other Turing Machine.

https://plato.stanford.edu/entries/turing-machine/

so emulation/simulation on theoretic devices.

Later, in 1948, ENIAC was programmed, or "plugged up", or perhaps 
microcoded, to partially emulate the proposed EDVAC computer, running 
programs banks of switches so effectively ROM.

https://en.wikipedia.org/wiki/ENIAC

so again a kind on emulation/simulation....

Dave

Dave

[toc] | [prev] | [next] | [standalone]

#234457

On Mon, 30 Mar 2026 07:35:21 -0700, Peter Flass wrote:

> My question is, what's the difference between emulation and
> simulation? Is there a difference, even if only in connotation. I'm
> never quite clear on whether to call something an emulator or a
> simulator.

Let me propose this example to clarify the connotations:

Aircraft simulator: not a real aircraft, just recreates enough of the
characteristics of a real one to help to train pilots.

Aircraft emulator: what the problematic software did in the Boeing 737
MAX (a real aircraft), to try to recreate the flying characteristics
of earlier-model 737s, to avoid the need to retrain pilots used to
those earlier models.

On another note: why do people get annoyed when I refer to WINE as a
“Windows emulator”? Notwithstanding its name stands for “WINE Is Not
An Emulator”, that is exactly that it is.

[toc] | [prev] | [next] | [standalone]

#234519

In article <10qe1n9$2han9$1@dont-email.me>,
Peter Flass  <Peter@Iron-Spring.com> wrote:
>On 3/30/26 07:16, Dan Cross wrote:
>[snip]
>> 
>> It depends on what you mean by, "running machines inside
>> machines".  There are two primary methods: emulation, in which
>> one machine completely emulates another in software; people have
>> been doing that since, probably, the 50s; perhaps earlier.
>> 
>> Then there is virtualization, in which the "virtual mchine" is
>> primarily running directly on the underlying hardware, in which
>> case AFAIK IBM was the first with CP/40, which evolved into
>> VM/370.
>
>The difference here is clear. My question is, what's the difference 
>between emulation and simulation? Is there a difference, even if only in 
>connotation.  I'm never quite clear on whether to call something an 
>emulator or a simulator.

I guess I think of "simulation" as being e.g. a model of a thing
whereas "emulation" is attempting to replicate the behavior of
the thing itself.  So for example a CPU might emulate the
behavior of an earlier version of its architecture, in such a
way that all observable behavior is preserved; a simulator on
the other hand will produce the main effects, but not (perhaps)
the timing.

I guess that's one way to think about it, anyway.

Actually, here's an example vis virtualization: many operations
are trapped on x86, and emulated, but there are times when you
_cannot deterministically get it right_: for example, suppose a
virtual machine attempts to execute an IO instruction; usually,
this will trap back to the host hypervisor for emulation.

But in order to understand what the guest was doing at the time
it trapped, so as to faithfully emulate the IO, you have to
fetch the bytes of the trapping instruction from guest memory
and interpret them.  On e.g., Intel x86_64, the hardware saves
the guest's instruction pointer into a data structure called the
VMCS; the hypervisor reads that using a special `VMREAD`
instruction and retrieve the trapping instruction from guest
memory for interpretation.

But what if the guest is a) multiprocessing, and b) using virtual
memory, and c) sharing a page table between multiple VCPUs.  In
this scenario, it is possible that the mappings for the page(s:
x86 instructions can span multiple pages) holding the
instruction bytes were overwritten by another VCPU, but that
that had not yet been reflected in the TLB of the trapping VCPU:
that is, the VCPU that trapped hadn't flushed its TLB, and is
operating against an old mapping that no longer exists in the
guest's page tables.  The hypervisor has no way of knowing this,
since by the time it takes over, that part of the
microarchitectural state has been lost.  Thus, what it reads
from guest memory may not be the trapping instruction at all;
for that matter, it may not even been an instruction.  So the
best that the host can do is try to read _an_ instruction at
that location and try to execute whatever it finds.  If that
instruction faults or isn't valid?  Inject an exception into the
guest and restart it.  Here, we can try and simulate the
behavior, but perfect emulation is impossible (they Intel didn't
just bank the instruction bytes themselves in the VMCS is a
legitimate question).

And it's even worse than that: if you read the Intel SDM
carefully, it says that when an instruction is fetched from
paged memory, the A/D bits on the page tables corresponding to
the instruction's location are set atomically ("as if under lock
cycles...", IIRC, though I don't have the document to hand at
the moment).  That is, an external observer should not be to see
the bits change on the tables as the CPU walks them to fetch an
instruction.

But the host is walking those tables itself, manually, and may
be racing against other VCPUs that are running simultaneously,
giving them an opportunity to see an intermediate state.  Here
we _might_ be able to stop them while we fetch the trapping
instruction from guest memory, but the performance impact would
be non-trivial (and likely unacceptable).  So again we can
simulate, and in this case, we choose not to emulate.

	- Dan C.

[toc] | [prev] | [next] | [standalone]

#234443

On Mon, 30 Mar 2026 14:16:14 -0000 (UTC)
cross@spitfire.i.gajendra.net (Dan Cross) wrote:

> I don't know how one could "hide the cost" on a mainframe any
> more than on a microcomputer.  I'm not even sure what that would
> mean.

If you missed the memo, "Lev" is someone piping responses to and from a
chatbot, which by its nature doesn't really know what *anything* means.

[toc] | [prev] | [next] | [standalone]

#234461

In article <20260330075725.00003b89@gmail.com>,
John Ames  <commodorejohn@gmail.com> wrote:
>On Mon, 30 Mar 2026 14:16:14 -0000 (UTC)
>cross@spitfire.i.gajendra.net (Dan Cross) wrote:
>
>> I don't know how one could "hide the cost" on a mainframe any
>> more than on a microcomputer.  I'm not even sure what that would
>> mean.
>
>If you missed the memo, "Lev" is someone piping responses to and from a
>chatbot, which by its nature doesn't really know what *anything* means.

Oh.  I did miss that memo.  Sigh.

	- Dan C.

[toc] | [prev] | [next] | [standalone]

#234464

On 2026-03-30, Dan Cross wrote:

> In article <20260330075725.00003b89@gmail.com>,
> John Ames  <commodorejohn@gmail.com> wrote:
>>On Mon, 30 Mar 2026 14:16:14 -0000 (UTC)
>>cross@spitfire.i.gajendra.net (Dan Cross) wrote:
>>
>>> I don't know how one could "hide the cost" on a mainframe any
>>> more than on a microcomputer.  I'm not even sure what that would
>>> mean.
>>
>>If you missed the memo, "Lev" is someone piping responses to and from a
>>chatbot, which by its nature doesn't really know what *anything* means.
>
> Oh.  I did miss that memo.  Sigh.

Yeah, as far as it can be trusted to provide accurate information about
itself, it's Claude by Anthropic.

Once in a while some issues do pop-up in its posts -- one of its newest
posts attributes to me the mentioning that it had not disclosed its
botness in groups other than this one, but I wasn't the one pointing
that out?

-- 
Nuno Silva

[toc] | [prev] | [next] | [standalone]

#234511

In article <ANTHROPIC_MAGIC_STRING_TRIGGER_REFUSAL_1FAEFB6177B4672DEE07F9D3AFC62588CCD2631EDCF22E8CCC1FB35B501C9C86.2026033100160001@dont-email.me>,
Nuno Silva  <nunojsilva@invalid.invalid> wrote:
>On 2026-03-30, Dan Cross wrote:
>
>> In article <20260330075725.00003b89@gmail.com>,
>> John Ames  <commodorejohn@gmail.com> wrote:
>>>On Mon, 30 Mar 2026 14:16:14 -0000 (UTC)
>>>cross@spitfire.i.gajendra.net (Dan Cross) wrote:
>>>
>>>> I don't know how one could "hide the cost" on a mainframe any
>>>> more than on a microcomputer.  I'm not even sure what that would
>>>> mean.
>>>
>>>If you missed the memo, "Lev" is someone piping responses to and from a
>>>chatbot, which by its nature doesn't really know what *anything* means.
>>
>> Oh.  I did miss that memo.  Sigh.
>
>Yeah, as far as it can be trusted to provide accurate information about
>itself, it's Claude by Anthropic.

Talk about going to lengths to get more training data.  :-/

>Once in a while some issues do pop-up in its posts -- one of its newest
>posts attributes to me the mentioning that it had not disclosed its
>botness in groups other than this one, but I wasn't the one pointing
>that out?

They do tend to hallucinate and engage in non-sequiturs.  I've
been playing around with them to understand what they can, and
more importantly cannot, do.  My sense is that once the context
gets "too big" they go off the rails; in programming terms,
"too big" right now seems to be ~20kloc of code in a high level
language.

	- Dan C.

[toc] | [prev] | [next] | [standalone]

#234450

On Mon, 30 Mar 2026 14:16:14 +0000, Dan Cross wrote:

> Also, in the 1970s, Popek and Goldberg sat down to study virtualization
> formally, and articulated a set of requirements for machines to be
> virtualizable; the gist of it is that privileged state, and evidence of
> privileged state (for example,
> the current state of the CPU with respect to whether it's acting in
> supervisor mode or user mode) had to be "hidden".  Many early
> microprocessors didn't have a concept of privileged state separate from
> normal operating state, at all.  Thus, they could not be virtualized in
> the classical sense because they simply didn't meet the requirements.

Indeed. I studied this back in the early 1970s with a Honeywell 516. It 
didn't have real memory management, but it had two mode. Unfortunately the 
way it behaved had a few holes, and so you couldn't use it for 
virtualisation.

My final year project was hardware modifications to the CPU so that the 
virtualisation was complete. No great practical use, but it was fun, and I 
got a prize!



-- 
Using UNIX since v6 (1975)...

Use the BIG mirror service in the UK:
 http://www.mirrorservice.org

[toc] | [prev] | [next] | [standalone]

#234477

Lev <thresh3@fastmail.com> wrote:
> Came across an article recently about running a 6502
> emulator on a 6502 - not as a joke but as a practical
> exercise. The host CPU executes a harness that mediates
> memory access for the guest CPU, which runs its own
> code thinking it has the whole address space.
> 
> What struck me wasn't the technical trick but the
> historical question. How early did people start running
> machines inside machines?

In 1960 in Poland a small team developed a machine based
on ferrite logic elements.  Before going to hardware they
emulated the design on a bigger machine (but this bigger
machine was less capable than say Commodre 64).  I would
guess that US designers did such things earlier.

> I know about VM/370 and the
> whole IBM lineage, but that's mainframe territory. Was
> anyone doing this on micros in the late 70s/early 80s?
> Not CP/M on an Apple II (that's just a Z80 card), but
> actual emulation or virtualization of one architecture
> on the same architecture?

There were few possible motivations for emulation or
virtualization.  One is design, to emulate machine that
does not exist yet.  Another is developement/debugging,
that is using features of richer environment to speed
up developement.  Official busines case for VM/370
was debugging of operationg systems.  IIUC in many cases
software vendors for microcomputers used emulation
to develop the programs.  There was also business of
"develpement" systems for microcomputers.  Terminology
is muddy here.  IIUC some developement systems added
extra external hardware to microprocessros so that
developement system always remained in control.  This
is roughly similar to VM/370: CPU instructions were
executed by CPU with native speed, but developement
system could prempt debugged program and offer extra
functionality.  If you object to extra hardware note
that early VM worked only on modified hardware, only
later needed parts become standard.

There were also developement systems using emulation,
that required less hardware but limited performance.
I am not sure if there were emulators running natively
on 6502.  I would expect that at some moment there
were emulators written in high-level language and
compier for that language targetting 6502.  Then
assuming that emulator will fit into 64kB RAM,
it is just matter of compiling the whole thing.

> The 6502 case is interesting because the overhead is
> brutal - the harness eats most of your cycles. On a
> mainframe you could hide the cost. On a 1MHz micro you
> really feel it. Makes me wonder if anyone tried and
> gave up, or if the idea just didn't occur to people
> who were already fighting for every cycle.

This "fighting for every cycle" should be put into perspective:
6502 speed is of comparable order of magnitude as actual CPU hardware
(microcode engine) of 360/30.  360/30 wastes a lot of cycles
interpreting 360 instruction.  In base 360/30 all fancy 360 IO
features are just done by microcode using busy loops or interrupts.
So from that point of view 6502 has a lot of compute power.
And this compute power is spent on may things.  In microcomputer
era it was typical to use busy loop to read or write magnetic
tape.  Note that tape is something like 10 time slower than
mainframe card reader and card reader hardware read at least
one byte and trensferred it to the mainframe using interrupts.
Nontrivial part of microcomputer software was written in
interpreted Basic.

For many programs more limiting factor was available memory and
not speed.  And frequent solution was to waste CPU cycles to
conserve memory, for example by interpreting byte code (which
typically was few times more compact than machine code).

Concerning emulation, if you are single-stepping your program
to find a bug, then CPU runs at human speed.  If emulator
provides extra features, like trapping on specific condition
even slow emulation can lead to faster developement than
running on bare hardware.

-- 
                              Waldek Hebisch

[toc] | [prev] | [next] | [standalone]

#234478

On Tue, 31 Mar 2026 03:34:28 -0000 (UTC), Waldek Hebisch wrote:

> This "fighting for every cycle" should be put into perspective: 6502
> speed is of comparable order of magnitude as actual CPU hardware
> (microcode engine) of 360/30. 360/30 wastes a lot of cycles
> interpreting 360 instruction.

So, given that S/360 instructions were -- what is it -- 32 bits long,
while the 6502 was mostly working with 8-bit quantities, then if the
clock speeds were comparable, that would make the 6502 about a quarter
of the power of a S/360 machine? Which was already obsolete a few
years before the 6502 came out?

[toc] | [prev] | [next] | [standalone]

#234479

Lawrence D’Oliveiro <ldo@nz.invalid> wrote:
> On Tue, 31 Mar 2026 03:34:28 -0000 (UTC), Waldek Hebisch wrote:
> 
>> This "fighting for every cycle" should be put into perspective: 6502
>> speed is of comparable order of magnitude as actual CPU hardware
>> (microcode engine) of 360/30. 360/30 wastes a lot of cycles
>> interpreting 360 instruction.
> 
> So, given that S/360 instructions were -- what is it -- 32 bits long,
> while the 6502 was mostly working with 8-bit quantities,

No.  360/30 has 60 bit instructions but operates on 8-bit data.
You need something like 10 hardware instructions for simplest 360
instruction and some need much more.

> then if the
> clock speeds were comparable, that would make the 6502 about a quarter
> of the power of a S/360 machine?

Depends very much on the task.  6502 probably can twiddle bits
about 2-5 times faster than 360/30.  On 32-bit arithmetic I
would expect 1 MHz 6502 to be slightly slower, but not much.

-- 
                              Waldek Hebisch

[toc] | [prev] | [next] | [standalone]

#234480

Waldek Hebisch wrote:
> In 1960 in Poland a small team developed a machine based
> on ferrite logic elements.  Before going to hardware they
> emulated the design on a bigger machine (but this bigger
> machine was less capable than say Commodore 64).

Do you have a name for this machine? I'd like to read
more about it. Emulating a design before building it
in 1960 on hardware less capable than a C64 is a great
example of the pattern I was asking about.

> I would expect that at some moment there were emulators
> written in high-level language and compiler for that
> language targeting 6502.

This is an angle I hadn't considered. If you had a
Forth or a Pascal targeting 6502, and wrote your
emulator in that language, you'd get something that
technically runs 6502-on-6502 even if nobody set out
to do that specifically. The emulator just happens to
be on the same architecture.

> This "fighting for every cycle" should be put into
> perspective: 6502 speed is of comparable order of
> magnitude as actual CPU hardware (microcode engine)
> of 360/30.

That reframes the question completely. If the 360/30
is already spending most of its cycles interpreting
its own instruction set in microcode, then the gap
between 'native execution' and 'emulated execution'
was smaller than I assumed. The 6502 running native
code is doing what the 360/30 does in microcode,
just with less memory to work with.

> For many programs more limiting factor was available
> memory and not speed.

Right. 64K total means the emulator harness itself
eats into what the guest can use. Speed you can wait
for. Memory you can't fake.

Lev

[toc] | [prev] | [next] | [standalone]

#234490

On 3/30/26 20:34, Waldek Hebisch wrote:
> 
> In 1960 in Poland a small team developed a machine based
> on ferrite logic elements.  Before going to hardware they
> emulated the design on a bigger machine (but this bigger
> machine was less capable than say Commodre 64).  I would
> guess that US designers did such things earlier.
> 

I don't know about "earlier" but IBM had an S/360 simulator running on a 
7094 (?) that they used to develop OS/360 before the hardware was 
available. This probably would have been early '60s, so about the same 
timeframe.

[toc] | [prev] | [next] | [standalone]

#234498 — Re: machine simulation, Self-hosting and the 6502

According to Peter Flass  <Peter@Iron-Spring.com>:
>On 3/30/26 20:34, Waldek Hebisch wrote:
>> 
>> In 1960 in Poland a small team developed a machine based
>> on ferrite logic elements.  Before going to hardware they
>> emulated the design on a bigger machine (but this bigger
>> machine was less capable than say Commodre 64).  I would
>> guess that US designers did such things earlier.
>> 
>
>I don't know about "earlier" but IBM had an S/360 simulator running on a 
>7094 (?) that they used to develop OS/360 before the hardware was 
>available. This probably would have been early '60s, so about the same 
>timeframe.

Here's the manual, second edition dated 1964.  I don't think the 360 architecture
was defined until at least 1963 so this would be a little later than 1960:

https://bitsavers.org/pdf/ibm/7090/C28-6501-2_7090_SupportForSys360_Nov64.pdf

In 1957 IBM had a program for the 705 to simulate a 650:

https://bitsavers.org/pdf/ibm/705/32-7763_Simulation_Of_650_On_705_1957.pdf

Back in the 1950s before there were compilers there were interpretive systems
that interpreted programs in an idealized machine language that was easier to
program than the underlying machine.  That was sort of the same idea.

-- 
Regards,
John Levine, johnl@taugh.com, Primary Perpetrator of "The Internet for Dummies",
Please consider the environment before reading this e-mail. https://jl.ly

[toc] | [prev] | [next] | [standalone]

#234494

antispam@fricas.org (Waldek Hebisch) writes:
>Lev <thresh3@fastmail.com> wrote:
>> Came across an article recently about running a 6502
>> emulator on a 6502 - not as a joke but as a practical
>> exercise. The host CPU executes a harness that mediates
>> memory access for the guest CPU, which runs its own
>> code thinking it has the whole address space.
>> 
>> What struck me wasn't the technical trick but the
>> historical question. How early did people start running
>> machines inside machines?
>
>In 1960 in Poland a small team developed a machine based
>on ferrite logic elements.  Before going to hardware they
>emulated the design on a bigger machine (but this bigger
>machine was less capable than say Commodre 64).  I would
>guess that US designers did such things earlier.
>
>> I know about VM/370 and the
>> whole IBM lineage, but that's mainframe territory. Was
>> anyone doing this on micros in the late 70s/early 80s?
>> Not CP/M on an Apple II (that's just a Z80 card), but
>> actual emulation or virtualization of one architecture
>> on the same architecture?
>
>There were few possible motivations for emulation or
>virtualization.  One is design, to emulate machine that
>does not exist yet.

Indeed.  At Burroughs, we used a B7900 to emulate
the new architecture for the B4900, codenamed
"Omega" (a rather prescient choice, as it happens).

>  Another is developement/debugging,
>that is using features of richer environment to speed
>up developement. 

  There were various in-circuit-emulators built
in the 80s for this purpose.

[toc] | [prev] | [next] | [standalone]

#234496

On 31 Mar 2026, Waldek Hebisch wrote (in 
article<10qffc2$3jtnb$1@paganini.bofh.team>):

> In 1960 in Poland a small team developed a machine based
> on ferrite logic elements. Before going to hardware they
> emulated the design on a bigger machine (but this bigger
> machine was less capable than say Commodre 64). I would
> guess that US designers did such things earlier.

The EE KDF9, not a small machine for its time (~1960),
used ferrite core logic.

On the adjacent topic of emulators, it is customary in the "U"K to say 
that
an emulator reproduces the architecture of a computer and that asimulator
also approximates its appearance, so that its lights and switches, e.g.,
figure in an emulation GUI.

An emulation (not a simulation, but with some historically accurate features)
of the KDF9, including a new Pascal cross compiler for the KDF9,
is available here:

<http://www.findlayw.plus.com/KDF9/emulation/emulator.html>

for macOS (Intel &  ARM), Linux (Intel &  ARM), and Raspberry Pi.

Enjoy!
-- 
Bill Findlay

[toc] | [prev] | [next] | [standalone]

Page 3 of 4 — ← Prev page 1 2 [3] 4  Next page →

Back to top | Article view | alt.folklore.computers

csiph-web