Not too complicated but "Period appropriate" RAM/ROM banking

[Paganini]

For my next project I'll be using a SST39SF010A - 128k flash ROM and W24512AK-15 - 64k SRAM. The simplest option here is to just map them into the 6502's 64k address space and leave large chunks of them unused. There are still advantages to using these devices, for example their low cost, and the simplification to decode logic provided by the W24512AK's multiple chip-selects.

However, this wastefulness rankles a bit. I have no interest in turning the 6502 into a 16-bit machine in disguise (I have an A500 upstairs under the bed). On the other hand, some kind of banking is often to be found in the 8-bit micros of the 1975-1985 home computer market. For example, my CoCo2 (stored next to the A500) can bank out its ROM and run from 64k of RAM.

I'd like to explore possible banking schemes that would not be too complicated to implement but would still offer the potential of some kind of useful access to all available memory and also be of - let's say - historical interest. Not necessarily duplicating any existing historical system, but being more "in the spirit of the age."

My first thought is to simply have the ROM be switch/jumper configurable before power on. The 128k would be divided up into 32k (or 16k, or whatever size) partitions. This would be like switching out ROM cartridges, except without having to physically swap them. If I want to boot into XINU, I select ROM bank 0, if I want to boot into my threaded interpreted language, I select ROM bank 1, etc. The RAM would be set up just like the CoCo; if you want to, you can copy ROM to RAM and then bank out the ROM to run from a full 64k RAM space.

I'd like to hear everyone's thoughts about that configuration. What alternatives are there that might be interesting?

[gfoot]

My favourite low-overhead approach is just to wire some VIA pins to form a bank register - if you have the VIA already then it's very easy to do. I use the same pins that are multiplexed for accessing the LCD and other things in Garth Wilson's design, accepting that I need to reset the bank after any LCD output etc. I've mostly used it for video RAM banking but the same scheme would work for this sort of thing too.

It is also quite easy to do this using a 74HC273 with a few logic gates for address decoding for writes to the bank register, I've done it that way in the past too.

[cjs]

Yes, just putting a jumper block on the top couple of address pins to give you four user-selectable banks of ROM for the top 16K or 32K is a pretty common and standard thing to do, at least on homebrew systems.

If you want to get more sophisticated, and you're using an EEPROM, you might consider a system that would let you map in all or part of one of the unselected banks into lower address space so that you can do in-system programming of the unselected banks. Then you can reprogram, power off, change the jumper, and boot into the new version of your system.

[Paganini]

This is Peanutbutter-1's address decoding, more or less:

I am thinking that an easy way to do what I want is to gate the ROM_SEL\ signal by OR-ing it with a RAM/ROM\ bank select signal. When RAM/ROM\ is low, access to the upper 32k of address space will go to ROM. when RAM/ROM\ is high, access to the upper 32k of address space will go to RAM.

My next question is, how to ensure that RAM/ROM\ is low after power-on? Is there a way to do this with a 6522, or will I need to add a hardware register driven by RESET\?

[Proxy]

IIRC all 65c22 IO pins have a default state after reset.
Though I don't remember if it was as input or as output driving logic low.
Either case you should be able to simply use a pull down resistor.

[fachat]

65xx IO typically defaults to input after reset

[A0CBM]

If you are interested in putting RAM under your ROM, like on the C64, you're in luck. I've built such a circuit using discrete logic, although it fits nicely on a Xilinx XC9536, not an XL. It goes nicely with my 8K internal RAM board. Just let me know if you're interested, I can post drawings if you want. I posted it a long time ago, but I don't remember seeing the drawings with it. It's not complicated and allows writes to RAM under the ROM without switching in the ROM. This circuit also allows 2 * 4K RAM under the character ROM, opening up all kinds of options for bitmaps and screen buffers. I've used these on both the small board and the CR NTSC boards. How is your point to point wiring skills?

[Paganini]

A0CBM wrote:

Just let me know if you're interested, I can post drawings if you want.

Yeah, I'd like to see it, thanks! Especially the discrete logic version. I use perf board with a "wire-wrap on top" construction method (kind of like wire-wrap on breadboard), so point-to-point wiring isn't much of a problem. I only get the soldering iron out for IC sockets and power connections.

[A0CBM]

VIC_Down_Under.pdf

(102.13 KiB) Downloaded 120 times

This will add a 4-bit register @ $9200, by breaking up the IO @ $9000 with new locations @ $9000 (don't use), $9100 for selecting existing VIAs, $9200 (new write only register), leaving an extra IO starting @ $9300. I tried to make the labels intuitive. The circuit for the character RAM requires an internal 8k board that I build off the character ROM socket. UC4 can be removed as well as any 2114's (memory), except the 2114 for color ram. It may also be good to add pull-up resistors to the inputs of the 74LS133 that used to connect to UC4. All connections on my VIC can be made at pass-throughs. I think the same is true with the small board also.

I first designed and built it using discrete logic in 1993. CPLD's makes it fit nicely inside the case.

[A0CBM]

This is a basic hookup of the internal 8K ram to the character rom. VICBNK0 would drive the first 8K SRAM. Add another 8K to this board and you can use the RAM under the character ROM.

[Paganini]

Cool. Thank you!

[Michael]

Paganini wrote:

I'd like to hear everyone's thoughts about that configuration. What alternatives are there that might be interesting?

I think your decoding/banking method is clever and elegant.

One alternative, if I may? My current SBC project reduces a normally large external microcontroller-based ROM Emulator / Programmer board to its functional essence in the form of a $2.50 Arduino Nano clone installed directly onto the SBC. The SBC is similar in function to the "whole basic computer" in Garth Wilson's "The Primer" and includes a CPU, a VIA, a 64K RAM, a 128K Flash ROM (divided into 64K 'A' and 'B' sections), and a 74HC139 for the 'glue' logic. The ROM Emulator / Programmer (Nano clone) copies the 64K 'A' or 'B' ROM into RAM during power-up or reset at a leisurely sub 1-MHz rate to support the use of slow ROMs and the SBC runs entirely from the 64K RAM with a 1, 2, 4, or 8 MHz CPU clock (supplied by the Nano). You can also load hex files from a Terminal Program on a PC through the ROM Emulator directly into RAM for iterative code testing and a 'long press' on the <SYS> push button will take the 6502 out of 'run' mode, invoke the ROM Emulator / Programmer, and program the selected 64K 'A' or 'B' ROM with the current 64K RAM image (takes about 9 seconds).

To install Nick Gammon's G-Pascal system into the 'A' ROM on my prototype I simply loaded the G-Pascal hex file into RAM and performed a 'long press' of the <SYS> push button to program the ROM with the contents of RAM.

I'm expecting the first production boards this week (see below) and I'm hoping this might be an economical entry-level 6502 SBC for newcomers. I've also attached notes for a future SBC with the '688 decoder chip like the one you're using.

Good luck on your project. Cheerful regards...

[Paganini]

Michael wrote:

I think your decoding/banking method is clever and elegant.

Thank you, Michael! I first learned the "relocatable I/O window" concept from your posts in this thread: Address decoding upgrade with 74HC139. I really enjoy your schematics. Not only do they always have cool ideas, but they're really fun to look at.

Quote:

I'm expecting the first production boards this week (see below) and I've also attached notes for a future SBC with the '688 decoder chip like the one you're using.

Are you planning to sell these boards? I'd buy one, even though I'm a bit of an Arduinophobe.

[Michael]

Paganini wrote:

... I'm a bit of an Arduinophobe.

I understand. Some of our most esteemed members dis Arduinos while admitting they've never used one. I'm guessing many newcomers and electronic enthusiasts may come here looking for more economical alternatives to Ben Eater's $200+ kit package and may be less biased and perhaps already familiar with or using Arduinos (or other microcontrollers).

As I said, your method is simple, clever, and elegant and a variation might use half of the 74HC139 to provide clock qualified read and write strobes instead of RAM and ROM selects and the other half of the '139 might be used to provide I/O strobes.

Good luck and have fun...

[Paganini]

Michael wrote:

Some of our most esteemed members dis Arduinos while admitting they've never used one. I'm guessing many newcomers and electronic enthusiasts may come here looking for more economical alternatives to Ben Eater's $200+ kit package and may be less biased and perhaps already familiar with or using Arduinos (or other microcontrollers).

Well, maybe "phobe" was an overstatement on my part. I don't have a particular beef with Arduinos; in fact, I have a cheap one that came with my first electronics kit, and I've used it to run Ben Eater's 6502 bus monitor. It just seems like an approach to hobby electronics that is somewhat removed from the sort of "period practice" retrocomputing that's captured my attention.

Quote:

...a variation might use half of the 74HC139 to provide clock qualified read and write strobes instead of clock qualified RAM and ROM selects and the other half of the '139 might be used to provide I/O strobes.

That is slickety-doo-dah. I love it!