This thread is about implementing virtual computers with a single 65xx chip.

The design of a "full RAM" 6502 computer has been seen many times, with people interfacing the RAM with another M/CPU that fill in the blank RAM with code and then kickstarting the 6502 to take control from there.

I know that the zero page and first page are used by the processor for its inner workings. What I don't really know is where the Main, Index, Program Counter and Status registers are phisically stored. Are they in the chip itself or in one of the locations of the zero page?

And I make that question because I'm wondering (and again, just theorizing) about how to implement several virtual computers with a single 6502 chip.

My theory of operation would be this:

• First, and external M/CPU would load a 256K RAM chip with 64K of data in a first bank, as the 6502 would need to run (reset, irq, nmi vector values and code that would run).
• This operation would be repeated with the second, third and fourth banks, with the same or different values or code.
• And then, have that first 64K bank mapped to the 6502 and reset it, having it to take control.

Well, more or less what some SBCs are doing right now.

The fancy thing would be that that external M/CPU would be able to

• Pause the 6502.
• Save all the Main, Index, Program Counter and Status registers.
• Change the memory mapping by setting registers in external glue logic, so the 6502 would be mapped to the second 64K bank of the same 256K RAM chip.
• Reset the 6502 and have it to take control again, but this time acting as a different computer because all the memory is different (actually in a different location of the same chip) and the CPU registers are different as the ones the computer previously had.

And a fancier thing would be that the external M/CPU would be able to switch between the first virtual computer and the second virtual computer just by

• pausing the 6502
• saving the cpu registers somewhere
• changing the memory mapping
• loading the previously saved cpu registers that would correspond to the desired virtual computer
• make the 6502 run again with that newly loaded, previously saved state

What do you think? doable? already done? useful? worthless?

Thanks for replies.

_________________
x86?  We ain't got no x86.  We don't NEED no stinking x86!

Ok. What about the rest?

Something like what you suggest could be done: what you're building on is the idea that what a computer is doing is entirely captured by the contents of the memory map, and the registers and other processor state.

However, a computer also has I/O, and that would also need to be dealt with, and that's not so easy. If one of the virtual machines sets a timer, then at some point the timer will finish and send an interrupt. If there's a serial port and data is incoming, it will need to be directed to one VM consistently.

The net result is that the problem is harder than it appears, and more importantly, some software somewhere needs to be orchestrating what is happening, and that software is quite complex and will take some debugging.

By opening a conversation like this, you're inviting people to share in your pipedream, and to the extent that you're unlikely to bring this to a practical build, it's not really compelling - to me - to spend much brainpower on it.

There is something which is somewhat near this idea, and which is actually practical to build and useful, and that's a 6502 emulator which runs on the 6502, with the intent of being able to single-step a program to help debug it. A particularly talented friend of mine wrote such a thing, as many others probably have too, back in the day when probably about 20 years old and having been programming for only a couple of years.

Writing a single-stepper is not only practical and useful, it would be very educational. You would refine and improve your mental model of the 6502, and what it means to execute code, enormously. It wouldn't be the first one, but it would be your first one.

It's doable, and been done (see below), but is it useful and/or worthwhile? Personally, I don't think so, however in idle moments I like to think of the "what if I build a retro computer with what I know today" (sort of thing), so as an academic exercise, then that might be worth something.

As for "prior art" then look at multi-user CP/M or MP/M. The system I used back in the early 80's had a 64KB memory card per user with one Z80 being shared and a serial terminal per user. ... But (to my knowledge) there were never really any terminal style 6502 systems that ran a sort of CP/M / command-line type of operating system back then - they really were personal computers as in one-person systems, so you're starting something new.

-Gordon

_________________
--
Gordon Henderson.
See my Ruby 6502 and 65816 SBC projects here: https://projects.drogon.net/ruby/

_________________
http://WilsonMinesCo.com/ lots of 6502 resources
The "second front page" is http://wilsonminesco.com/links.html .
What's an additional VIA among friends, anyhow?

See also the es65, a multi-user machine with a RAM board for each user:
https://obsolescence.wixsite.com/obsolescence/es65

Thanks all for your replies.

Well, there could be said that the 6502 has a couple of bytes of memory that is that where the internal registers (not the hardware stack or pointers for subroutines) are stored.

I appreciate all the comments you add to the subject.

Multitasking seems to me that of the same master process doing different things with the feeling of them being done at the same time. My question was more or less separate entities controlled by the same CPU. Imagine that everyone of those entities could be running different languages: BASIC, Forth and so... (although all of them would be running machine code anyway...)

Regarding I/O, yes... A machine setup this way should not be doing I/O any of the standard ways, or any way.

As I said in the beginning, this is all theorizing, to have everyone interested to put words about it.

_________________
http://WilsonMinesCo.com/ lots of 6502 resources
The "second front page" is http://wilsonminesco.com/links.html .
What's an additional VIA among friends, anyhow?

..and all of this leads me to think about a more complex setup where a single '816 could be be acting as master controller of several 6502, all of them with their own full set of 64K ram, shared with the '816, and mastered by it by using multiplexers instead of dual port RAM chips.

The '816 would run main code, and any of the 6502 subsystems would run code sent by the '816, processing data also sent by the '816, or generated by itself (the subsytem) by running the received code.

Or even better: have dedicated 6502 chips for intensive I/O tasks that would run by themselves in separated hardware spaces, but that could be inspected by the main '816 when required.

Like those NES clones where a 6502 core runs the game code, and another one generates sound.

But then it would be no more "several virtual computers with a single 65xx chip".

Some good ideas here. What would be interesting, I think, would be to extend the memory map over a high speed serial link (think: SPI clocked at 200MHz, providing an effective memory bandwidth of around 16MB/s). The idea could be that you capture the PHI2 cycle when the address is being output, then stop the clock while the SPI engine serializes the transaction to external memory.
You could imaging hooking a serial engine like this as a memory-mapped device, and the circult that issues PHI2 hold generates an NMI and an interrupt handler can walk the transaction through. Using an NMI is superior so this will work WITHIN interrupt handlers, which I don't think has ever been done before.
Going back to the virtual computer idea; the whole of page 1 can be virtualized via an MMU like page-table scheme with, say, 32-byte pages (only poorly written programs use more than 32 bytes of stack), so that's a good way to go. If you can afford a second processor, like a Z80, to essentially implement hardware page table walking, then the same PHI2 cycle hold from above can be used to synchronize all this (which is important otherwise you could have coherency problems).
On the subject of coherency, I don't think you'd need a full MOESI protocol, as most of those states are useless, even in directory implementations, and if you've read Hennesy you know what I mean.

Good luck with this. I'll monitor the thread to see how you get on.

Not usually a useful way to look it. If you're creating a new implementation of a 6502, you certainly need a plan for the registers - by which we normally mean the programmer-visible registers. But the storage in the chip is not addressable memory, whereas the memory outside the chip is addressable memory. If you don't make a distinction, you're likely to get a confusing train of thought.

Likewise, when you said upthread

that feels to me like a confused statement. It's possible you've never written much 6502 assembly language: once you have, you'll gain a better grasp of how memory is used and what defines that: there's the processor; there's the operating system, monitor, or language; and there's the application code. Ideally you'll have seen how a variety of systems work, so you can see how different conventions work.

It's probably not going to be fruitful to speculate about advanced architectures if you're not yet familiar with some commonplace architectures.

No, I'm not a coder or have wrote code for the 6502 beyond what I did >30 years ago with BASIC in my Commodore 64.

I read about 6502 registers and memory requirements here: https://wilsonminesco.com/6502primer/MemMapReqs.html

As I see it, the 6502 is both a data and signals processor: moves data between memory and i/o chips by using its address and data buses, turn on or off signals lines (its address and data buses could be said that are also signal lines), or gets affected by those signals lines (hardware interrupts are that: signals that affect what or when the chip does things).

The chip can also process data by doing things like increasing, decreasing, shifting bits... And more complex operations can be done by combining that basic data processing instructions.

As I see it, it's nothing more than that. Beyond that point, coders can do up to what Michelangelo did with his mallet and chisels: took the tools and got David out of the marble.

Thanks again for your replies and advise.

You might enjoy the easy6502 tutorial - it takes you from zero to a simple game.
https://skilldrick.github.io/easy6502/

Also Bob's diagram is rather good, but it's a reference, not a practical exercise. I think practical exercise is crucial.
viewtopic.php?p=42766#p42766