Virtual Memory on an 8-bit?

[+Larry]

I'm curious if this has been done successfully to any degree on the A8. There was a program (whose name I've forgotten) that would swap several Basic? programs in memory and do "sort of" multi-processing. But with accelerators, large expanded memory, and very fast hard drives, it might not be so far-fetched. I guess since I mentioned "accelerators" that I should also recognize that large linear memory would probably be a whole lot more useful. But still, anyone recall any attempts?

 

-Larry

[+Gemintronic]

Sounds like you're talking about a paging file like Windows or Linux. Maybe the UNIX-like OS for CoCo does that. Sorry I can't think of the name.

[+David_P]

Both were by Tom Hunt: MTOS multi-tasked several apps, and Snapshot switched between full memory to swap apps in and out.

[JamesD]

Sounds like you're talking about a paging file like Windows or Linux. Maybe the UNIX-like OS for CoCo does that. Sorry I can't think of the name.

Nope. It does multitasking and handles memory management but it doesn't handle virtual memory.

You pretty much need hardware to do that or run PCode like Apple Pascal.

 

Some sort of cooperative task swapping could be done without hardware or completely swap all program RAM for every task. Something like that would work.

Edited November 10, 2013 by JamesD

[Rybags]

VM can't be implemented in a direct way on Atari, the 6502 wasn't designed with it in mind, in fact home/small office machines didn't really have a proper way of doing it until the 80386.

 

Proper VM setups use tables which point to where memory pages (often 4K blocks) reside in either real Ram or off on disk. The process is also automated to the point where the CPU will automatically perform the fetches if the address points to Ram and generate a page fault if the address doesn't exist (in which case the OS can go off and move the page from disk to RAM).

 

Various ways to implement a half-baked VM on machines who don't support it. IIRC, Alternate Reality had a sort of VM philosophy - some of the imbedded comments (in the backup program ?) mentioned it.

 

Swapping entire programs as mentioned in and out of main memory on Atari is possible although it falls more into multitasking than virtual memory, although "proper multitasking" benefits greatly on machines that can do VM. Having to switch an entire program on Atari from main to extended RAM would be slow - probably talking in the order of minimum 1/3rd of a second to swap between two 40K programs areas.

[flashjazzcat]

That's why pre-emptive multitasking is only a realistic proposition if the software is written with the context switching in mind: i.e. keeping everything inside the banking window to avoid unnecessary copying. As for virtual memory: without a page fault facility, obviously the mechanism can't be transparent. A sensible method would (will) be to substitute hard disk for extended RAM when performing an explicit request for a chunk of extended RAM. If the calling program code is in the banked region, it follows that some kind of indirect method of fetching extended memory will be needed, so that's an ideal time to delegate requests to virtual memory. It's also worth mentioning that in light of the profusion of hard disk devices for the A8 in recent years, Drac030 has written a virtual memory library for SpartaDOS X, and IIRC it's already (optionally) used in some of the SDX toolkit applications.

 

The above notwithstanding, 1MB RAM expansions are just as ubiquitous as hard disks nowadays...

[+Gemintronic]

No dice on Contiki?

http://www.contiki-os.org/

[Rybags]

Since we have the nice 16K 130XE style bank size, it would be possible to do a quick/dirty multitasking system using the $4000-$7FFF area.

 

In the context of Basic, somewhat easy - just set MEMLO such that the program starts @ $4000. Switching then becomes an easy task of swapping which bank is visible there and pasting in the relevant z-page Basic variables and could be done very quickly (in the order of several scanlines time). In the case the Basic program extends beyond $8000 a block copy could take care of the extra.

 

For Asm programs, if the programs were written such that they executed from those addresses then it makes task-switching somewhat easier.

 

Another weakness of 6502 though that I didn't really touch on - more advanced CPUs like x86, 68000 have the base register concept wherein a program can be written such that it can execute from whatever address the system decides to load it at.

On 6502 we don't have that, it can be fudged to a degree by having structured load modules with relocation directories so instruction operands can be changed to reflect where in memory the program resides. But weakness #2 is within z-page/indirect addressing. These types are much harder to modify and the program would have to be written with relocation in mind.

[+Larry]

Interesting answers!

 

I was unaware that Drac030 had already entered this area. The 130XE concept was along the lines of what I was thinking. Can all of a 1 MB expansion be addressed in 16K chunks? I presume so, since I remember using a Newell 1 MB upgraded XE, but had to have a manual switch for internal Basic. Pretty large "chunks" but I'm sure an adept coder could work their way around that without too much difficulty.

 

Contiki OS sounds interesting. Don't think I'd ever heard of it before. Any examples of things done with it for the A8?

 

-Larry

[Rybags]

The 1 Meg expansion is seen in 16K chunks @ $4000-$7FFF.

 

As an example a multitasking environment on the A8 might be setup such that the low memory $600-$3FFF contains core parts of the file system management, $4000-$7FFF is the window where the programs execute, $8000-$BFFF could contain common areas and small workspaces for programs which exist in more than one 16K page. Ram under the OS might contain file buffers and a few lesser used filing system routines.

 

The thing is, it's a non-existent standard - Jon's GUI OS I imagine will have some standards expected of programs such that they can coexist and not destroy memory used by or containing other programs and the GUI itself.

 

Another thing that modern VM systems have which is valuable from a security and stability standpoint is storage fencing/protection. Such examples are storage key on mainframes, definable data only areas, fencing of storage to disallow writes outside certain boundaries. Of course, no provision for such things on our old machines but evolution of those ideas on mainframes and PCs have increased reliability and decreased the risk (slightly) of Malware/viruses.

[+Gemintronic]

Interesting answers!

 

I was unaware that Drac030 had already entered this area. The 130XE concept was along the lines of what I was thinking. Can all of a 1 MB expansion be addressed in 16K chunks? I presume so, since I remember using a Newell 1 MB upgraded XE, but had to have a manual switch for internal Basic. Pretty large "chunks" but I'm sure an adept coder could work their way around that without too much difficulty.

 

Contiki OS sounds interesting. Don't think I'd ever heard of it before. Any examples of things done with it for the A8?

 

-Larry

 

Here's a link to a Contiki 1.0 port:

http://hitmen.c02.at/html/tools_contiki.html

 

UPDATE: Oops, I guess Contiki was a red herring. It looks like it does some cool stuff but might not do virtual memory.

http://www.cc65.org/mailarchive/2003-03/2795.html

[thorfdbg]

While one typically expects a MMU to do that type of "virtual memory" thing, with proper programming and proper design it also works without. Does anyone remember the first Macintosh with a MC68K in it? It did *something* like that: If you allocated memory from the Os, you did not get a pointer, you got a "handle" which was a pointer to a pointer. If you wanted to access this object, you first had to "lock it" in memory, then work on it, then release it again. By that construction, the Os could move the objects in its RAM space around, by adjusting the handles, or simply remove them from memory and reload them from disk as soon as the program was trying to lock the handle again. All dialogs, windows, buttons, the whole GUI basically was designed around "resources" that were represented as "external objects" that could be referenced by handles.

 

It was a pretty smart construction, but of course it costed quite some performance with the relatively underpowered CPU it depended on.

[flashjazzcat]

Yeah - I read all about the double-indirection a couple of years back and even considered using the idea for a while. I eventually decided it was more trouble than it was worth, however, and that a page allocator with a bitmap would be more efficient. The indirect handles were a source of application errors on the Mac because developers would tend to forget the pointers were indirect. I could imagine them being a bugger to debug... Still, it did seem a nifty solution at the time.