Just some pondering and I don't know if this has been discussed before, but I'm in the process of making myself a little 6502 system and wondered about a dual-banked memory system - ie. 2 banks of 64K of RAM (or one ROM, one RAM), using the SYNC output on the 65c02 with some logic to let code run from one bank and data in the other.

(I'll use the word ROM & RAM here just to separate the 2 banks - it could conceivably be ram in both banks loaded in some manner)

And that's about it, really. Echoes of the pdp11 split I+D space, maybe? Obviously some glue logic to allow code to get in to the ROM area, copying static data into the RAM would be easy, but it assumes SYNC goes high only at the opcode fetch and not the data fetch (which is correct if I interpret the data sheet correctly).

Anyway, it was just something that crossed my mind earlier - I'm not really looking to implement it, but if it did work then it might be an interesting way to give yourself 64K of code and 64K of data without too much work - especially if you already have CPLD or some such as part of the address decodings...

Cheers,

-Gordon

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

Something like this can certainly be done: the final 6502-based edition of the BBC Micro, namely the Master, has some video RAM which is mapped in only when accessed by OS routines. One thing to watch is that SYNC only signifies the opcode fetch - any operand bytes will need to be read from the same bank, and then the operation accesses (read, write, or read-modify-write) will need to go to the other bank. I think you pretty much need a state machine which tracks the lengths and cycle usages of all opcodes.

(With an '816 it's a bit easier, as you have the VPA and VDA signals to help.)

I see that BigEd managed to say most of what I was going to before I could, plus provide an example that I was unaware of. Well played, BigEd.

As far as "has been discussed before", the KimKlone by forum member Dr Jefyll takes this idea a bit further than you've just outlined.

The idea drogon mentioned certainly could be exploited, yielding 64K of code space and another 64K of data space. Another person to independently arrive at this idea is forum member Hugh Aguilar, who proposed a 6502-like CPU implemented with Verilog and an FPGA. This'd make it fairly straightforward to incorporate such a feature.

The idea would also be fairly straightforward if a 65816 were used, thanks to the VPA and VDA outputs which Ed mentioned. The key point is that these identify when a data access occurs, as opposed to code accesses and dummy cycles. In other words it's timing information. There are two 64K spaces, and it's timing info that indicates which space should be selected. (For the record, I don't know whether this scheme really satisfies the definition of a Harvard architecture. Certainly there are Harvard machines which have separate buses that allow simultaneous code and data accesses.)

With BigEd's and nyef''s remarks the discussion became broader -- ie, more to do with address-space expansion in general, rather than two spaces segregated on a code vs data basis.

Ed, the BBC Master you mentioned sounds like a variation on a ubiquitous mapping scheme used for 6502 / 65C02 and other CPU's -- schemes which have a bank aka page register that allows an arbitrarily large amount of memory to be accessed. But timing info is still central. Lacking VPA / VDA, the solution is to use a fraction of the address space -- 8K or 16K, perhaps -- as a window. Then a simple address decoder can detect when the window is accessed, thus supplying the timing information. It's a very widely used scheme, and its defining feature is its use of an address decoder to cue -- to time -- an action by the mapping hardware.

( The variation with the BBC Master... correct me if I'm wrong, please, Ed... is there's another address test also performed by the system, one which -- together with SYNC -- reveals whether or not an OS routine is executing. This yes/no result is stored until the subsequent SYNC pulse, and during the intervening interval the yes/no will determine which of two values will appear in the bank aka page register if it becomes active (ie, if the window gets touched). Clever! And challenging to explain; I hope I'm not just muddying the water. )

Thanks for the mention of my KK Computer, nyef. Although it uses a 65C02 (and thus lacks VPA / VDA), neither is there any 8K or 16K window involved. Ie; KK doesn't use an address decoder to time actions of the mapping hardware. Instead, the mechanism is as Ed described: a state machine which tracks the lengths and cycle usages of all opcodes. One of the advantages is having blocks which are not 8K or 16k but a full 64K (as with an '816).

An earlier 'C02 machine of mine lacks KK's bells and whistles but nevertheless does use 64K blocks. In this case timing was derived basically from a shift register. In other words you don't need a fancy state machine to go the 64K-block route.

-- Jeff

_________________
In 1988 my 65C02 got six new registers and 44 new full-speed instructions!
https://laughtonelectronics.com/Arcana/ ... mmary.html

The W65C816 & W65C265 implement multiple spaces internally.
They have a program bank & data bank register. Program bank is prefixed to the address for program (I) accesses. Data bank is prefixed to the address for data (D) accesses. Direct page, stack & interrupt vector accesses are always to bank 0, so the program actually has 3 default spaces.
The program can use the long addressing modes to access other banks, so cross bank operations are easy.

Indeed, Jeff, although the implementation probably isn't quite as you sketch, the behaviour in the Master for video-space overlay works as you say. (The Master inherits the straightforward banking of the original BBC Micro, with a single 16k area and a 4-bit or wider selection register in I/O space. There's a second fiddle which allows video RAM. See p20 or so in this pdf)



Note that the Master has it easy: the overlaid memory doesn't overlap the code memory in this case, so there's no need to watch for each cycle of each specially-handled instruction.

For the 64k+64k scheme, there would be a need to model instruction lengths. This mightn't be too bad, because (I think) there are only two lengths: 2 and 3. 2 covers all the single-byte instructions which always do a dummy operand fetch. And 3 covers oddities like JSR, which does 3 reads from opcode space, but interleaved with a write to page zero. So, count reads, and it might be fine.

The Apple III, I think, did something wonderfully complicated and flexible with three-byte pointers, as did Acorn's in-house and never-seen-since Turbo machine, not to be confused with the Master Turbo. See this thread for more:
viewtopic.php?p=53768#p53768