6509 paging

[kakemoms]

Well I am thinking of using NOP opcodes for another project to change memory bank. That is for data fetching and JSR/JMP. E.g. one needs to keep separate registers for the banking since opcodes and absolutes have to be sequentially read from the same memory page. It can easily be solved with a PLD-type device to sort opcodes and keep absolute addresses separate from JMP that modifies the PC. As for JSR, one would need a "stack" of registers for subsequent RTS instructions and keep in mind to not modify the stack..

[kakemoms]

I have been looking around for a Linux-like OS which could run on a 6502+/65816. Except for Minix I found a 16-bit OS called ELKS that is in development:

http://elks.sourceforge.net/

Even if its only for x86 in current implementation, I would think it transferable to a 65816 with some effort.

Has anyone else looked at this before?

[BigDumbDinosaur]

kakemoms wrote:

I have been looking around for a Linux-like OS which could run on a 6502+/65816. Except for Minix I found a 16-bit OS called ELKS that is in development:

http://elks.sourceforge.net/

Even if its only for x86 in current implementation, I would think it transferable to a 65816 with some effort.

Has anyone else looked at this before?

Alan Cox has a project called FUSIX (sp?) that was developed for the Z80 but appears to be a possible port candidate to a 65C02. I haven't followed it, however, so I can't say whether or not it has reached a viable state.

I would think that the 65C816 would be a much better target for a *NIX environment, since it has more of the features that are useful in a preemptive, multitasking operating system, especially total linear address space.

[Tor]

FUZIX (I can't remember it either). https://github.com/EtchedPixels/FUZIX

Quote:

* Builds with a modern ANSI C compiler (SDCC)
* Kernel boots to userspace on both 6502 (bitrotted), 68000, 6809, MSP430 and Z80/Z180
* Core code can be built for 6502, 6809, 68000, 8086, MSP430, pdp11 and Z80/Z180

Quote:

Various other platforms are partly filled out to sanity check assumptions

I remember a comment early in the project, about the 65C816.. ".. took one look at it, shuddered, and turned away"

[BigEd]

Fuzix needs to page memory in some flexible way, to implement process swapping, and most 6502 systems don't have an amenable memory paging system, so as you note, the 6502 port is bit-rotted. (Suitable memory paging systems are seen more often in Z80 systems.)

I do hope that Fuzix will one day be brought up on a larger faster 6502 system. Two of the current 6502 second processors for Acorn's BBC Micro (the Matchbox and the PiTubeDirect) now have a memory paging system which is, I hope, of the right sort. There are some hundreds of those systems out there now. The BBC Micro's own memory map is not very helpful here, according to Alan, but I think the second processor has more of a chance.

(That said, I see Jac has said he might try to port Fuzix to his machine.)

Generally, it's a bit awkward for this purpose that the 6502 stakes out some fixed elements in the memory map: you need pages zero and one to be RAM and you need page FF to hold the vectors. You need somewhere to place I/O. CPUs where I/O is not memory-mapped, and where the stack pointer is 16 bits, are at an advantage here.