I asked in a thread in the programming section about the amount of memory that would be enough to have as fixed size for programming.

And there I talked about how the Commodore 64 used $0001 and $0002 to handle banking.

I was thinking about that and though about a system that would use $0000 value to set a latch that would set the upper address bits in a chip as bank selection.

If I use 0-14 lanes of address bus, I can only select 32K of RAM, isn't it?

But if I expand the address bus with the value set by $0000 stored in a latch as I said, I would have 23 bits for address selection and that means 8 megabytes of RAM...

...in 256 banks of 32K -- if I'm doing the right maths. Crazy, isn't it?

If I'm right, would that be useful for something? Or is it just out of what's reasonable to think in a 6502 based system with 8 megabytes of memory?

The 65816 is ready to handle up to 24 bits of memory addressing (with no banking), and that's why it has the "long" instructions that allow get benefit of 16 megabytes of memory with no additional logic.

But the 6502 only sees 64K at a time, so maybe having 8 megabytes of memory is not useful at all. Or is 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?

If your banking needs are such that manually writing the bank register is not too bad a cost, then I think that by far the easiest way to make a system like that work is by using part of a 6522 that you probably already have in your system to provide the bank selection bits, rather than adding extra hardware and complicated address decoding.

You can wire the port pins straight into the high address bits of a large RAM module, and allocate a little or a lot of your address space to access this RAM. And you can still use the 6522 for other purposes so long as you reload the bank value before next time you use the banked RAM.

As Garth said, this isn't much good for general purpose code, but it is great for large amounts of data where you can manually control the bank register - I've used it to bank in about a megabyte of video memory in one of my systems, without having to add any dedicated hardware, and it's great for that because video memory accesses are quite often sequential, so the bank doesn't need to change very often.

Agreed - huge memories are generally more likely to be for data rather than code, but that's still sometimes very handy. Especially as data could include a RAM disk - a filesystem. Or, as George notes, a large display memory. Or lots of image data, perhaps for a photo viewer. Or, one of Garth's favourites, large mathematical lookup tables. Or, one of mine, data for a large Life program. Or, as with Acorn, data structures to support assembling large programs. Or large text files for a word processor. Or a large dictionary for a crossword solver or thesaurus. Or, large program files to be interpreted. Or large datastructures for an adventure game or multi-user dungeon. Or sprites and waveforms for a videogame.

And indeed, either a latch at some fixed address, or a VIA or similar, is enough to hold the high bits for some large RAM device. You might not need all of an extra 8 bits, but that's not too important.

You do need to make space in your memory map for the vectors, and at least the stub of an OS, and the I/O devices, and of course you need zero page and the stack. So, "the upper 32k" isn't quite as clean and clear as one would like it to be, and "the lower 32k" isn't easy to just swap around either. You might try the middle 32k, or use a 16k from the middle, or you might just punch out some proportion of the 32k, and have say 28k or 20k. But note that your large memory is now now longer monolithic... unless you increase the hardware complexity a fair bit.

It thought about lower 32k and upper 32k because it seems to me easier to split in memory.

I'm not only thinking in data but also in code that could be loaded in several banks and run as needed taking care always of moving the program counter somewhere in the lower 32k. Those multiload games or apps could be run that way: having them loaded in several banks when code + data would be larger that available memory.

Another thing would be have a virtual memory management unit implemented in the kernel of an OS. Everything that would be run under that OS (I mean... like GEOS or something) would not access memory directly but by calls to the kernel, that would take care of allocating memory and/or paging data and code by using banks, transparent to the application itself.

I know that the 6502 can be whatever the hardware design wants to, but I always end thinking about the standard retro computer experience: keyboard, screen, sound and I/O.

I've also been looking at adding banked memory to a 65C02 system. Looking at what's already been done for Z80 systems (and the Z180 CPU with integrated memory banking), I've looked at the 512KB memory card on the RC2014 systems, which is also supported by Fuzix. It uses a 16KB block where you can easily write to an I/O register and assign any 16KB bank of RAM or ROM to one of the 4- 16KB banks addressable by the CPU. Note that Fuzix on the 6502 also uses this same memory card and banking.

From my view, I would likely prefer either an 8KB bank size or maybe even 4KB. But then again, one needs to design the hardware and write the code to make all of this work. As Fuzix has a lot of compiled C code, 16KB certainly works, but I would hope that an 8KB banking setup could also work and possibly give you additional flexibility, I'm looking at no more than 128KB of ROM on my next system with 8KB banking and either 512KB or 1024KB RAM with similar banking, but I don't quite have a timeframe for getting this done.

_________________
Regards, KM
https://github.com/floobydust

The nice thing about 8k banks is that you can always choose to set them up in pairs, as if you had 16k banks. (It seems unlikely to me that a couple of extra instructions is going to make any noticeable performance difference.) And the same for 4k banks, of course. Although, the maximum overall RAM gets smaller if you maintain an 8 bit bank selection.

It's excellent that Fuzix is a worked example.

Once we have large and fast solid state storage I tend not to worry so much about having lots of ROM: one can always load the OS, extra modules, applications from mass storage, either at boot time or on demand.

(tokafondo, you made a previous thread here which has some useful ideas, I think, as well as some sidetracking.)

With 4k pages (or even 8k), if you can map any of them anywhere from a larger physical RAM, can make a great base for task switching, if you also map the lowest page.

I used 4k pages here http://www.6502.org/users/andre/csa/cpu/index.html and built a multitasking operating system on top of it http://www.6502.org/users/andre/osa/index.html

_________________
Author of the GeckOS multitasking operating system, the usb65 stack, designer of the Micro-PET and many more 6502 content: http://6502.org/users/andre/

Edit - it looks like this crossed in the post with Andre's. His system was my inspiration for the below...

You can also go completely overboard with this stuff. A couple of years ago I was experimenting with a preemptive multitasking system using the 6502, where the address space was split into pages and in user mode every page could be mapped to anywhere in RAM. I ran several programs in parallel, and in addition to each having their own zero page, stack, etc, each also had a page of video memory to output to the screen.

User mode programs didn't have access to ROM or I/O at all, only RAM, and couldn't map memory directly, that was up to the OS. There was also nothing special about page FF - just normal RAM mapped there. The system automatically went to supervisor mode, with memory address translation disabled and ROM and I/O decoding enabled, if an interrupt or BRK occurred. NMI was connected to some signal from my video circuit to send ticks to the OS and trigger preemptive task switching.

As usual I was trying to do it in a fairly minimalist fashion, I think it needed a RAM chip for use as a page table and an 8-bit flipflop to track whether it was in supervisor mode or which process ID was active, as that affects the address mapping.

It's not a particularly practical system but it was interesting to think about and see what can be done without needing either CPU level support or a complex memory controller.

great to hear!


If you could describe that schematics that would be great! I'm wondering how you detected BRK or when the Interrupt was actually being executed? Did you use a WDC chip and the Vector Pull output? Also, how did you return to user mode - the OS must reset to disable mapping, but from code that would then be mapped out...?



Indeed!

André

_________________
Author of the GeckOS multitasking operating system, the usb65 stack, designer of the Micro-PET and many more 6502 content: http://6502.org/users/andre/

My memory is terrible so take this with a pinch of salt, but I maintained a Hackaday page here about it that should have the details: https://hackaday.io/project/174866-prot ... er/details

As usual I stopped well short of achieving all my goals, probably because I think I achieved the most interesting ones and then found something else to do instead!

I think I used the vector pull pin as you said, I had wanted to also support non-WDC and figured I could do that based on memory address accesses. E.g. if we see FFFE and FFFF and then 8000 then it's an OS entry, even if it wasn't actually an interrupt, and the code at 8000 needs to be robust against manipulation. I didn't think it through but was sure there would be some sequence length after which we could be certain that at the very least executing is going to continue in OS code. But someone commented on the page that in fact interrupt response is the only time the CPU ever executes three write cycles in a row, and that would be a cleaner way to detect this.

Getting out of supervisor mode was also tricky. I think it relied on the user code having a specific entry point containing some stub code like an RTI instruction. So the kernel would restore the page register and then the memory map would change and the CPU would hit the users RTI instruction to reload the continuation address and flags from their own stack.

There were definitely some complications that I didn't resolve. I think NMI reentrancy was a potential issue that I didn't fully solve, so if the NMI occurred during the context switch at a particular time it would fail. And due to my stinginess with extra components, getting the OS to access user memory pages was not trivial. A PLD would have made all the difference! But my interest was specifically trying to do this in a low tech way while still being 100% secure against malicious user code.

once you dive into the world of MMUs and extended Memory it's very hard to come back!
they can be as simple as a 65c22 hooked up to some RAM/ROM, or complex enough to fill a small FPGA.

originally i wanted to make a version 3 of my 65c02 using a basic MMU designed to fit into an ATF1504 and direct access a 512kB SRAM IC.
the MMU worked like this:
all of RAM (so excluding ROM and IO) is split into 8x 8kB Banks, and the MMU has 8 internal Registers each 6-bits wide.
when the CPU accesses some RAM Address the MMU would take the upper 3 bits of the Address Bus and use them to select which "Bank Register" should have it's contents directed through a Multiplexer to the output.
that output is then combined with the lower 12 bits of the CPU's Address bus to form a 19-bit Address that goes to the SRAM IC.
This effectively gives you a total of 64 Banks to swap in and out whenever you want.

it barely fits into a ATF1504, but i was still able to fit the basic OE and WE signal generation using RWB and PHI2.

i never got to use that MMU, so i don't know if it would actually work like i imagined, but it is insanely basic so i think it would.
I'll attatch it in case anyone wants to look at my horrible attempt at creating a 6-bit wide Multiplexer in WinCUPL. (the verilog generated .jed file is more likely to work as i handwrote the CUPL version and i'm not confident in my CUPL abilities)

I have always considered that to be an unfortunate design decision, unnecessarily restricting use of the precious zero page.

If you can live with the banking control register being write-only, a better way is to decode them somewhere in the ROM address space.

That's a valid remark, but it's only valid in certain contexts. Circumstances and priorities make a big difference.

Many 6502 fans began their journey using computers with an existing BIOS/OS that claimed most of zero page for itself, leaving only a small portion uncommitted. In that circumstance it does make sense to be miserly about those few precious, remaining bytes.

I'm not sure what tokafondo's circumstances are, but things change drastically if legacy zero page usage is absent and one has the luxury of starting with a clean sheet of paper. That's because the routines you create for yourself are likely to consume far less of the precious resource... especially if you create a data stack, allowing z-pg variables to disappear when not in use.

(This isn't just idle talk. My 65xx-based workbench computers have oodles of free z-pg, despite mapping their VIAs there. It's not the right solution for everyone, but in my own particular circumstances it's a tradeoff that justifies very well indeed. It matters little that I'm unable to run resource-hungry code written by others; for me that isn't a priority.)

I'm not advocating that everyone adopt the same approach as mine. On contrary, the point is to match one's approach to one's priorities and circumstances. And that means being ready in some situations to loosen up the purse strings, so to speak, and spend some of the precious resource.

-- Jeff

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

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