6502.org

My prototype is running happily, and I’m having plans on a more permanent version.
What I’m not happy about is the memory map I’ve worked out so far.

I would like to use 512k of SRAM at $0000-$7FFF switchable at 16 x 32k.
The first 1k or 2k would always be bank 0 while the rest is bankable.
I/O is planned from $8000-$BFFF in 16 x 1k chunks. (with two 138’s)
As ROM I’d like a 29F010 128k FLASH at $C000-$FFFF switchable at 8 x 16k. RAM 628512 SRAM
ROM 29F010 FLASH

A latch of 8 bits could take care of banking and write protect.
CBBBAAAA
A = 16 x RAM bank select.
B = 8 x ROM bank select.
C = ROM write enable.

What I don’t like about it is 1. the vast I/O map at $8000-$BFFF and 2. the ROM not that easy to alter. I would have to erase 16k at once and reprogram the whole sector, and of course write a program to do that.

1. I’d like a more convenient location for I/O, near zeropage and stack.
What would be a good location and how big should the I/O blocks have to be to fit most needs? 64 bytes?
Of course $8000-$BFFF becomes available and could be added to the RAM or the ROM. Any thoughts about if it should be ROM or RAM?


2. I’d like rather use RAM with battery and write protect instead of ROM.
How do I get the firmware in “ROM” the first time or when ram gets corrupted or erased? This is my biggest issue.

A possible memory map could look like this:
RAM 628512 SRAM
ROM 628512 SRAM (battery backed and write protected)


Or perhaps: RAM 628512 SRAM
ROM 628128 SRAM (battery backed and write protected)

Any perspective would be helpful.

edit: changed title

I started to think about the banking decades ago, but it just wasn't worth doing when the 65816 is available, designed for that already and much more practical. You get

• 16MB of address space
• 256 banks of 64K each
• you can have the data bank and address bank be different even if they're both in the same RAM IC
• long jumps and branches and subroutine calls and interrupts don't require any fancy moves in the program to switch banks without crashing
• data accesses with long (3-byte) addressing don't require any bank switching
• the stack pointer is 16-bit
• 16-bit operations are many times as efficient, and it's actually easier to program than the 6502
• you can move zero page (now called "direct page") anywhere in bank 0, so each task can have its own zero page
• it has a lot more instructions and addressing modes, some making it more suitable for multitasking and multithreading and relocatable code

and I'm sure I'm forgetting more important attractions. My '816 Forth runs two to three times as fast as my '02 Forth at a given clock speed.
Don't forget the '154 which might be better than a pair of 138's. How many I/O ICs do you want though? I can't imagine more than 8. That's a ton, and I thought I was the I/O freak around here.
I'd probably want the ROM WE to be controlled by a manual switch, so a software bug cannot accidentally ruin something. You might want it so the software can write-protect it, but cannot get it out of write-protect mode if the manual switch does not allow it. IOW, either one can protect it, but they have to agree on write enabling to write.
Dallas has SRAM modules that act like SRAM but you can pull them out of the socket and they hold their data like ROM. They have the lithium battery inside, plus the circuitry to protect the RAM when the power goes down, and often have a RTC built in. The problems with them is that they're slow, expensive, and their 10-year battery cannot be replaced.

In another topic, we were discussing getting a tiny bootloader loaded into RAM by way of manual switches, just enough to have something that works to load the rest from a serial port or mass-storage device. If you almost never have to do it, it might be well worth it.

If you put enough logic together, you can get any scheme you want; but realize that with lots of levels of logic, the delays accumulate to possibly prohibitive levels unless you use programmable logic.

Let's not get sidetracked into the '816 every time banking comes up! It's perfectly reasonable to put banked memory into a 6502 system.
I would guess 16 bytes per I/O device is easily enough: even if you decoded more finely you could always give two adjacent blocks to one greedy device.
If your peripherals will include a way to load code from a storage device or a PC, then you only need enough ROM to hold your bootstrap and enough of the OS to support it. 48k RAM, 8k ROM might be a good mix.
There seems no ideal place to put the I/O: right up in FE00 or the lower half of FF00 is the tidiest. Page 2 was a recent novel idea, and well be a good plan, because pages 0 and 1 are both fixed and special, and then you can have the maximum span of RAM from 0300 upwards.
Cheers
Ed

On the 65C02 you could use all of page $FF as the processor will assert VPB when accessing the fixed vectors and this could be used to direct the access to a ROM rather than an I/O chip.

@GARTHWILSON Oh dear, that looks like a whole other league! You have to consider that I’m only familiar with the NMOS 6502 / 6510. Not that I don’t want to expand my knowledge, but I think it wouldn’t be wrong to set some boundaries for my first homebrew computer. I probably would stick to the NMOS 6502 at 1,8432MHz. I don’t want to get lost in a too complex first try. Programming wise I want to stay close to the VIC-20 and C64. Or am I restricting myself too much by using regular NMOS instead of the WDC chips?
Yes that would be a better one!
I’m not sure either, I just want to be on the safe side I was thinking of VGA, keyboard, joystick, ACIA, 65SPI, VIA’s, SID’s.
I actually had that in mind with a jumper, but a switch is more convenient.
I wasn’t aware of them.
Unfortunately I can’t find it, do you have a link? Is it this topic? viewtopic.php?f=12&t=2705

What about having a 16k EPROM and RAM occupying the same space, and during a cold boot the EPROM is active and copies itself to RAM. But that has been certainly been thought of.

@BigEd
I would put a charset or a startup bitmap in one of the ROM banks. So it’s more like for data storage then the need of programming space.
that’s a good idea, the SID needs 29 bytes I believe.
I noticed that Daryl’s OS and Lee’s EhBASIC make use of those lower regions, so that in consideration, I would come up with:
RAM 628512 SRAM
ROM 628128 SRAM (battery backed and write protected)
ok, I have to resign and read that datasheet of the 65C02

Don't forget that the 65C816 was designed to replace and emulate the 65C02. Just run the 816 in emulation mode (it actually powers up in that mode) and the 816 24 bit long address accessing will still work, as a matter of fact most 816 features still work in that mode. You don't have to use any of the 816 features unless you want to use them.

edit: 24 bit long address

If you want to use the bank address feature of the 65C816 at some point in time, you still need to implement the bank address latch from the start.

Now, an interesting question: can we design a simple bank address latch that works with the '816, but can also be operated from a 6502 ?

When I think about what it takes to switch banks on the '02, it was more complicated than just using an '816. The '816 does require the '573 latch if you want to use A16-A23, but that's pretty simple.

For the 6502, think about how to jump to part of a program in a different bank. You have to store the bank and address of where you want to go into either the processor registers, RAM variables, or onto the stack, then go to a routine in non-banked memory which will then store the new bank number to the bank latch and then complete the jump into banked memory. Otherwise you first switch the bank, and before you have a chance to do the actual jump, the next instruction will be read from the wrong place, and the most likely end in a crash. Another way might be to add more hardware so the bank latch doesn't take on the new value until the third byte after the JMP or JSR instruction. The '816 does this stuff rather seamlessly, without the complications. You can do it with the '02 if you want to, but I think you're more likely to meet with success (which is what we all like to see ) with the '816.

But, like clockpulse said, the '816 powers up usable just like a 6502. You don't have to learn anything new up front until you're ready for more.
The keyboard, joystick, beeper, RTC, I²C, and maybe other stuff too can all go on one VIA. (I also put the printer port and LCD on VIA1, but I don't have a joystick, and my keypad is smaller. If I wanted a bigger keypad, I might have to have it go through the I²C.) I've been bit-banging SPI on a VIA, but Daryl's 65SPI IC is definitely nice. I have six I/O ICs, three being VIAs and three ACIAs, but I'm only using one ACIA now, and I wouldn't mind having another VIA. I get sound through a D/A converter on one of the VIAs (and input through a fast A/D also on a VIA).
Yes, that looks like it.
That's one of the things ElEctric_EyE started with, then he kicked the clock rate up after the copying. The EPROM was too slow to handle the final clock rate. Another way to do it is to use a microcontroller to pre-load RAM before letting the processor out of reset. Then the reset routine can be in an 8-pin serial EEPROM.
If you do not try to have program material in multiple banks, the difficulty I mentioned further up goes away. My own attraction to large memories is for data.
Very good idea! (The WDC 65c02 has VP\ output on pin 1.)

As was noted, the 65C816 starts in emulation mode and essentially appears to the system to be a 65C02. There are some hardware detail differences related to memory accesses that are readily handled. Aside from that, you can use it as a 65C02 until you are ready to switch to native mode and enter the world of 16 bit programming and all that. I ran my POC unit in emulation mode for the better part of a year while I fiddled around with hardware and such. Also, my POC unit doesn't use the A16-A23 part of the address emitted by the '816 and it works just fine. There's no reason to avoid the '816.

As for devising a system with more than 64KB to run with a 6502 (which device I don't recommend you use), Garth is right. The acrobatics required to use banked RAM with the 6502 are considerable. You need only to look at the Commodore 128 to see what I mean. The C-128's kernel had to jump through all sorts of hoops to prevent a memory map from being selected that would result in no ISR code being available when an interrupt hit (if that happened the machine crashed). BASIC was constantly switching the memory map around to access program text (located in RAM bank 0) and variables (located in RAM bank 1), since the 8502, of course, couldn't access more than 64K at a time. Predictably, performance took a hit, and BASIC 7.0 was perceptibly slower on a C-128 running at 2 MHz than BASIC 2.0 was on a C-64 running at 1 MHz.

If you are really intent on building a machine that will use more than 64KB the '816 is a better choice and will require less glue logic.

Getting back to my comment about not using a 6502, I would not use NMOS hardware on any new design. If you want to stay with the 6502 you should use the more technically advanced W65C02S (not the Rockwell pulls that are floating around on eBay or at Jameco). WDC's CMOS processors are efficient low power, high performance devices that are superior in every respect to the NMOS equivalents. The PDIP-40 version of the 65C02 is a drop-in replacement for the 6502 (with one caveat). Errata in the NMOS parts have been corrected (e.g., the infamous JMP ($xxFF) bug) and new instructions (some very useful, such as PHX and PLY) have been added. Also, the NMOS part has some odd hardware behavior that can cause false chip accesses at inopportune moments if the circuit isn't carefully designed.

Regarding the '154 decoder, you should know that it is relatively slow device. Unless you truly need more than eight I/O slots in your design you should consider using the faster (and physically smaller) '138. Naturally, your glue logic should be 74AC or 74HC, not 74LS.

This reminds me I never did answer your earlier question about what year my NSC CMOS logic data book was from. The answer is '88, and it has the '154 at about the same speed as the '138, both kind of slow-- but it may not matter much if he's going to run the circuit slowly enough for the SID. The '154 in CMOS is in a .300"-wide skinny DIP, unlike the TTL and LSTTL ones which were wide, so the CMOS one takes about as much room as one and a half 138's.

I'd be tempted to make that address range bankable too. Then it might be possible to run multiple programs which use the area.

I placed all my I/O high up in memory at the range $FFDxxxxx for my system (32 bits).

Has anybody ever used a register file like the 74HC670 as an address translator for partial bank switching? The idea is to translate any two address bits to a 4 bit address segment of RAM or ROM (8 bit address segment if you use two). It is of course slower (49 ns max, 21 ns typical from read register address select to output) than the typical decoders and I wonder if it is doable. It would certainly add more flexibility to bank switching.

Haven't used it, but I've made the suggestion: viewtopic.php?f=4&t=2533

So how did you overcome the issue with the bank for the reset vector not pointing to the propper reset vector ROM after power up? The 670 doesn't have a reset and its content is unknown at power up.

The same problem would apply to a 573 switching the topmost bank with the reset vector.

The outputs of a tristate buffer could hold the '670 outputs low until it was initialized. See 2nd post I made in that thread.
I assume you mean a 74LS573? Use a '273 or other latch that has a Clear input.

The way the Commodore 128 handled IRQ, NMI and RESET was during initialization the hardware vectors were copied to the same addresses in all ram banks. Also copied to the same addresses in all ram banks were short target routines in rom to save A,X,Y and the current memory configuration on the stack, then switch in ROM where the appropriate handler would execute. Upon completion a routine in rom and the same address in all ram banks would restore the cpu registers and the saved configuration and execution would continue in whichever bank the interruption occurred in.

I could post a disassembly when I track down one online.