6502.org

In my memory map, $0000-$7FFF is mapped to RAM (A15=0), and I want to implement banking of a segment in range $1000-$7FFF.

Since I'm using AS6C4008 SRAM, I can have 16x 32-KB banks. (I can throw in more SRAMs for more banks though!)
I want to do this with discrete components only: it would be trivial to do this with 6522, but I don't want to waste entire port of 6522 just for this job.

My kernel uses first 4K of RAM ($0000-$0FFF) for its own purposes (zeropage, stack, video memory, etc), so I want to switch banks only for $1000-$7FFF (when A14 | A13 | A12 == 1) - this is where loadable programs will live, and each of them will get its own bank. And yes, I'll be wasting first 4KB of each bank just to make addressing easier.

Here's what I came up with so far:
The plan is:
- $0000-$0FFF is always in the same bank (A15-A18 pulled high).
- $1000-$7FFF is banked with the help of A15-A18 that's latched by '574.
- $8000-$FFFF does not activate RAM at all (A15=1), so I don't care about the value of A15 that comes from CPU.

Here's how I expect it to work:
- Bank selection is initiated when CPU writes to a memory location where the '574 is mapped (/EN is asserted). I think of putting this in my IO segment and activating it with one of '138-s outputs.
- The data line is then latched by '574 at the end of the cycle (once Ф2 goes low).
- '574 stays transparent (A15-A18 pulled high) for all writes to $0000-$0FFF.
- Once CPU attempts to write to $1000-$7FFF, '574 is activated (/ACCESS is asserted), and so the specific bank is activated.

I'd like some feedback on this approach, and also several questions:
- Is it OK to have A15-A18 pulled high? I need this for non-banked RAM segment to work ($0000-$0FFF). Should I use small resistor ratings for higher throughput? (I heard high-rating resistors increase capacitance and thus slow down maximum switching speed. I want to run this thing @ 8 MHz.)
- My concept is write-only. However, it would be nice to be able to READ current bank number as well! The only solution I can think of is to have another transparent latch in reverse direction which would be activated when R/W is high, so that I can "read" the byte from the '574.
- Are there any potential caveats with my approach?

Thanks in advance! Any thoughts are welcome.

I don't know if it's OK, but I do it on my 65C02 and 65C816 boards.

I have [A8:15] pulled high via 10K resistors. The boards run at 16Mhz. I don't have the test kit to tell me it shouldn't work or why it's just fine, but it's been very reliable since the days it was running on stripboard. (Years now).

The reason I do it is so I can implement a mutually exclusive shared memory region ($FFxx) between the 65xx and the board host MCU (ATmega) with 8 address lines from the ATmega to A[0:7]. That way when I stall the 65xx and pull BE low on the 65xx I can read/write that top 256 bytes of RAM.

(In the '816 version, A16:20 are driven low when BE is low so the ATmega still sees 256 bytes at $00.FFxx)

-Gordon

Thanks Gordon, that sounds great! So now I have proof that even 10K resistors are OK for pull-ups.

I'm been looking more and more at '816... It feels so much more friendly to relocatable code. But I'll reserve it for future times in case I get bored with 6502. So far I really like how 6502 constantly requires me to think out of the box to work around various limitations in interesting ways. In x86 all of this is made trivial with CS/DS/SS registers, but to me 6502 memory banking is more fun.

I've currently implemented a simple `system()` function that reads a program from uSD card and runs it, but I'm limited to 1 loaded program. Banking will allow programs to spawn their own child programs, and there will be no need for relocatable code at all, plus each program will have its own software stack while having shared zeropage, hardware stack, and kernel memory.
Eventually I hope to implement some POSIX stuff like fork()/exec(), real file descriptors (for stdin/stdout pipes between programs), and timer-driven context switching.

You two might not be doing things the same way.  See below.


Keep in mind that the '816 can initially be used as a 6502 with just more instructions and addressing modes available, even in '02-emulation mode, and you can dip your toes into the water slowly as you're ready for each new thing.  This way, it doesn't have to be overwhelming or intimidating.  I have an article about that at http://wilsonminesco.com/816myths/ .


The higher resistances do not increase the capacitance, but will make it take longer to charge up whatever capacitance there is on the line.  The time constant is the amount of time it will take to charge it to 1-1/e of the final voltage excursion, about 63%; so if you really started from 0V, and the resistors pull up to 5V, that's 3.16V, more than high enough to be considered a valid '1' in TTL levels, but not high enough to be a solid '1' for a CMOS device that wants 70% of VDD.  The time constant is the capacitance times the resistance.  The concept is illustrated in Figure 2 of my 6502 interrupts primer.  The link gets you to the right section of the page; then scroll down to the first diagram below the cartoon of the drug-store photo counter.  Suppose you had 15pF on the line, which includes the input capacitance of the SRAM's address line, the capacitance of the 574's output when it's turned off, the traces, and maybe sockets; then suppose you have 10K pull-ups. 15pF x 10K = 150ns, probably too long.  3.3K, and if you can get down to even 10pF, gives you 33ns.

If you need to drive the address lines, rather than using pull ups, you could add a 74xx157.

If you feed A15-A18 to both input banks of the with select pin tied off high or low. With *access feeding the enable pin, the 157 will output all lows when the enable is high and the fixed 4k is in use, and will pass the address lines from your bank register the rest of the time.

If it's important to have the A15-A18 drive high rather than just fixing on one bank, then he a similar result can be achieved with enable tied low, and A15-A18 to the I0 bank and the I1 bank tied high. *access connected to the select input will then switch between all high and the bank register.

Also, how about using a 3 input NOR instead of the chain of 2 input devices to produce your *access signal. That would give you a 1 for the fixed 4k area and a 0 elsewhere with only one gate delay instead of 3.

You mention to keep stack and zeropage for the system and bank in loadable programs above $1000.

Did you consider that your programs also need stack and zeropage? How are you going to share this area?

André

The BBC Micro had banked ROM (latterly RAM) when it launched in 1981. Linear access wasn't the intention but providing separate ROMs for languages (BASIC, Forth, Word Processor, Spreadsheet, etc.) , utilities, disk and network was the aim.

The memory map was simple: $0000-$7FFF was RAM, the upper portion (variable from 1K to 20K used for video). $8000-$BFFF was the paged ROM - for which they coined the phrase "Sideways ROM", then $C000 through $FFFF was the operating system with a small window for hardware IO.

The operating system could switch in one of 16 different Sideways ROMs and as long as you obeyed the rules, code in one ROM could call code in another ROM without even knowing it was doing it. The operating system had a bunch of fixed-point calls for all the functions envisaged, so to read in a file, you created the parameter block in RAM, called the OSFILE routine, then the OS would work out what the ROM number of the current filing system was, activate that ROM, make the call, then return to the original ROM - which may have been a language ROM such as BASIC or BCPL, Forth, Spreadsheet, etc.

It all worked (still works) remarkably well. There is overhead, but the flexibility if offers more than compensates. It also took away various functions from language ROMs so the BASIC didn't need to do pixel poking for the screen or know how to scan the keyboard and so on - the OS did all that for you.

Later models (The BBC Master) introduced another bank of RAM to "shadow" the 20K of video RAM so without change, programs now had much more data space even when using the high resolution/colour video mode that required 20KB. This "just worked" because it was effectively designed into the operating system from day 1.

-Gordon

You're right: a PIA port is such a useful thing that losing one would be unfortunate. In fact, it's so useful it might be good to have an extra one!

So, this is going to sound crazy, and maybe it's never been done before, but how about adding a second PIA to the system? Since you've already got a VIA with timers and all that, the second one could be just a 6821/6520 PIA, giving you a port for your memory mapping and another spare port for more stuff. And it now lets you read your current bank configuration.

(Actually, come to think of it, perhaps there was some company out there who regularly used two 652x PIA-style chips in their computers, but I can't think off-hand who it might be. :-))

A thing to bear in mind with the 574 is that if you want to be able to set bits independently, you either need to maintain a RAM copy of the current state to OR/AND against, or you need to arrange a way to read the current output.

If you're just writing a byte then there's no issue, of course.

(There's a nice approach in some STM32s (though not all, and it can bit you if you're not careful) where there is a control register which sets matching bits; another which clears matching bits, and a third which both sets and clears. Handy.)

Neil

I agree this will, as you say, give a readable port for memory mapping and also a spare port for other stuff. But rather than a 6520 I'd be inclined to put in a 6522, despite the extra capabilities that (presently) simply seem like overkill.
On an existing Z80 SBC of mine, I managed to retrofit the readback capability! But if I had the whole thing to do over again it would probably have been better to eschew the ad hoc creativity and simply include a read/writeable peripheral IC.

-- Jeff

Thanks for all the replies!
This explains a lot! Clearly, I had wrong understanding of how this works.
Today I learned! Every time I have a challenge, there's always a 74' chip that I've missed which solves the problem in an elegant fashion.
Hey - I read a lot of your articles @ 6502.org, so I'd like to say huge THANKS for your work! My entire banking & context switching thing was inspired by your work.

Actually, I was planning to use only software stack in my loadable programs (since almost all of them are written in C), so entire zeropage would be used by kernel only.
However, now that you've asked this, I think there's a big flaw in my design... Namely, sp/tmp*/ptr*/regbank stuff that's used by software stack resides in zeropage, so there will be conflicts between stacks of different programs...
I might need to re-think my entire design.
That's a good idea. I actually thought of this, however I had several issues with this:
- 6522 is still rather bulky
- It felt too simple and I was feeling like doing a bit of over-engineering.
- I'm trying to reserve my VIA for I/O only to make things simpler, since even with simple bit-banging & a shift register things get hairy real fast!
The downside is that my entire VIA can only handle 4004 LCD, uSD card (SPI mode), PS/2 keyboard, and an I2C bus, with only 2 free pins to spare. However, the coding is much easier, since all devices are directly connected to VIA without intermediate glue logic.

Anyway - I need to seriously re-think my design, since I'll probably need to bank a part of zeropage (26 bytes of CC65 variables) as well.

Another tricky thing is that during syscalls, I might need to switch to kernel's bank, since part of my kernel is also written in C...

/Andrew

I decided to return to this idea and try implementing simple preemptive multitasking by having paged RAM.

It would be very easy to do with a VIA (and I'm still planning to use VIA's timer for context switching), but I want to have a separate 8-bit "register" to hold active bank, and also to be able to read its value. I'm going to use AS6C4008, so I'll get 16x 32KB banks.

Here's what I came up with as a "cheap" read-write register:
I couldn't think of a way to do this with less than 2 chips (+ logic gates), but I may be wrong. Maybe there is a better way. Finally, I'm not sure if the above contraption is going to work (although it seems to when simulated). Any thoughts are welcome.

EDIT: Okay, turns out all chip selects can be handled by a single NAND. So now I'm down to 3 chips total - '273, '244, and '00.
EDIT 2: André - as you mentioned about zeropage etc, I gave it some thought and my new plan is to bank entire visible RAM and make first bank a "kernel" page (zerobank, if you will), and banks 1 to 15 will be for individual "processes".
So each process (as well as the kernel itself) will have their own zeropage, stack, and RAM.
When a system call is performed (basically, any call of kernel's public routines), kernel will then decide whether it needs to bank to its own bank or stay in program bank.
E. g. for `open`, kernel will use program's bank to read file name, but then use its own bank to store file descriptor information.
For `exec`, it will use program's bank to read file name and then use a new bank to store cmdline, initialize stack, etc.
For `memcpy`, it can stay inside program's bank.
Basically, I'm treating bank register as something like CS register in x86.

Finally, system calls will use a lot of sei/cli instructions to ensure that context switching does not happen during critical kernel operation. And most importantly, all system calls that switch from program bank to kernel bank will reactivate program bank before return to ensure that we're returning to the right PC in stack.

Another benefit is that with banking I won't need to write relocatable code.

Of course, it's all just a theory for now. And my `rom.cfg` is probably going to look like a mess with lots of overlapping segments. I'll be happy to hear your thoughts, especially considering your impressive work on GeckOS!

EDIT 3: I think the biggest bottleneck in my case is that I'll need to waste some cycles or even an entire register to keep track of "previous" bank number in cases when a syscall needs to, say, copy some data between banks and not get lost in multiple stacks. I'm starting to think that it might be worth sharing a small segment of RAM (say, 256 bytes at the end of RAM region - $7F00-$7FFF), i. e. making this little page non-bankable. Or I could make it 1K or more and call it a "shared memory" so that it can be used for more powerful primitives like pipes or mutexes.
(My dream is to use all of this to build a POSIX-like shell for 6502 with job control, piping, and subshells.)