Hello members of the 6502 forum! I'm designing my first SBC computer, and I opted for the 65c816 over the 6502 despite the quirks for numerous reasons, one being RAM. It's quite an ambitious project, but I'm certain it will turn out great in the end. It will primarily be a gaming machine.

However, I've ran into an issue with address decoding since the 65c816 starts in emulation mode on boot and requires a reset vector within the 64K of RAM since that's all the 6502 can map.
I've come up with a memory map that I think would work well for my project, any advice on how to implement it (or a similar, simpler one) would be very welcome. Here it is:

$0000-$BFFF: RAM [48K]
$C000-$CFFF: I/O [4K]
$D000-$FFFF: ROM [12K]

$10000-$2FFFF: HiROM [approx. 128K]
$30000-$17FFFF: HiRAM [approx. 1.37MiB]
$180000-$FFFFFF: Misc. external devices [approx. 15.2MiB]

Attached below is a chart of all the address line bits for the above memory map. I know it is possible to use CPLDs, GALs, PLDs, etc, to make address decoding easier. However, since I'd like to keep the cost down (since I've already opted to use an FPGA for the video generation), a solution with logic gates (or ICs) would be appreciated. If it isn't possible without too much trouble, then I'll opt for an easier solution.

Thanks in advance everyone!

Welcome! If your aim is to keep address decoding simple, then two things will help a lot. One is to keep an eye on the powers of two - the round numbers. And the other is to allow yourself certain forms of inefficiency - you will need to make tradeoffs. So for example, not fully decoding addresses will allow you to use less logic. That means some devices or areas of memory might appear in multiple places in the map.

So, instead of 48k RAM, which is not a round number, consider 32k. You're going to have heaps of high RAM in any case. And 32k is already a lot. And if this means you don't get to use all of the RAM chip, that's just one of your tradeoffs.

Instead of a 12k area for ROM, consider 16.

And then you have 16k for I/O. As you plan to put some I/O devices into high memory, where you have lots of bits of address available, you might minimise the amount of I/O in this 16k area. It would not be wrong to have two or three devices fill up the 16k, by incomplete decoding. In fact, if you use individual address lines as device enables, one device might take up 8k, the next 4k, the next one 2k, and the remainder of the 16k area would be forbidden territory, because multiple devices will appear at the same addresses.

If none of this makes much sense, get to reading Garth's primer!
http://wilsonminesco.com/6502primer/

Hey! Thanks for all the advice and all. I appreciate it. As a matter of fact, I have read Garth's "primer" site, and I found it useful in partially understanding address decoding. However, I'm still unsure of how to map anything above 64K as certain addresses could interfere with the logic for the address decoding within the first 64K and accidentally enable another device.

It really helps me out when I have a working schematic to look at, but there's barely any information for the 65c816 when it comes to this. I've searched for hours and hours and made no progress whatsoever. It might be asking for too much to get a working schematic and an explanation of how it works, so I'm not expecting it. Thank you for the advice anyhow! Preferably, I would like to avoid having mirrored addresses. My aim is for the design to be easy to understand, but I also want the programming for it to be logical. Mirrored addresses is quite an inelegant solution in my opinion, so I'd like to avoid it. I would rather use a GAL if I need more address decoding logic.

Perhaps the missing piece is this: if you're using higher banks as well as bank 0, then all your decoding for bank 0 will need to(*) detect the high bits and ensure it is bank 0.

That is, the 816 memory map is up to 256 banks of 64k each: it's not 64k and then a lot of banks above that. The bottom 64k is bank 0.

(*) There are probably at least a couple of ways you do this differently - there always are! For example, if you allowed every bank to have 32k of RAM, plus an image of the top 32k of bank 0. But generally I'd expect most systems would have 64k of RAM in each bank.

That's true, I would like to have 64K in each bank. I see what you mean about detecting the high bits. Would you possibly be able to draw up a quick schematic of one of such solutions? If that's not possible, then maybe you could point me in the right direction with some ICs to use (or GAL logic, whatever works) and the logic behind it? Thank you for the help so far! I'd prefer to not waste any address space, even if there's plenty on the 65c816.

Welcome!


Please see attached for an example of how to do it with discrete gates. The target system is 512KB with a bank $00 memory map the same as what you want. Adding more extended RAM wouldn't be too difficult, but mapping in ROM above $00FFFF would be a challenge with conventional logic (though not impossible).

Please carefully study the attached and then ask questions.

BTW, you may need to consider a wait-stating mechanism to deal with relatively slow ROM accesses, but that's getting ahead of the program, so to speak.

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

In that case I would seriously consider doing two designs, the first which wastes address space and, once that's working, the second of which doesn't. Avoiding "wasting" address space can be tricky and requires experience.

Remember Thompson's rule for first-time telescope makers: "It is faster to make a four inch mirror then a six inch mirror than to make a six inch mirror."

_________________
Curt J. Sampson - github.com/0cjs

Ha ha - my favourite rule!

Better perhaps not to think of waste but spend. You spend some of your address space in the interest of simplifying your system - in this case, the stated aim is to simplify the decode logic.

There are many tradeoffs in an 816 system, because the 816 has various oddities. It does not offer a flat 24 bit address space: Bank 0 will contain the vectors, the stack(s) and the direct page(s). Commonly, I would expect Bank 0 to contain all of the ROM, and also the I/O, although it needn't. There is of course an interplay between your hardware design and your software design.

Yes, I do agree that it'd be more complicated to not waste address space, hence why I'm open to using GALs.

I will be making a simple version in iterations on a breadboard to make sure my design is working slowly, and once I'm happy, I will order a professional PCB. Perhaps this would be enough? Thanks for all the help everyone, and thanks to BigDumbDinosaur for the helpful schematic. It's really helped me understand how to use a different memory map in the 64K than the rest of the address space.

It worked for me.

I used one GAL in my 65C02 board which started on breadboard, then stipboard then PCB. for my '816 board I went directly to PCB and use 2 GALs.

Bit of a long-winded descrition here: https://projects.drogon.net/6502-ruby/

That's just the 6502 version, however the '816 is very close. I use one page - $FE00 for IO in both systems.

Some thoughts: Do you need IO in high RAM? do yo even need ROM there? Might it not be easier to just use a big slab of RAM up there and copy code/data into it from something running in bank 0?

Good luck - great to see another '816 project.

-Gordon

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

You'd likely need multiple GALs to generate all the needed chip selects, which circuit may end up with obdurate timing issues. Even then, the logic density in a GAL is significantly limited compared to even a small CPLD and you may find yourself wishing for more resources.

In any case, virtually all 6502-based systems end up "wasting" address space simply because to do otherwise can result in extremely complex glue logic, with little gain achieved.


You're welcome.

Note that by replacing U6b with a 74ACT11030 and inverting the latter's output, you will have the capability to distinguish between bank $00 and the remaining 255 banks. However, the logic required to select individual SRAMs in excess of 512 KB becomes convoluted. Realistically, it is not practical in discrete logic if performance at all matters, which is why I limited that design to 512KB, which is available in a single SRAM.

If you are going to go with more than 512KB it's time to get a CPLD involved. Not only will you need room for the chip select logic, you will need many more output pins to select SRAMs (one chip select per 512KB of RAM).


What Ed is saying is in a practical system code has to exist at the upper end of bank $00 so the '816 has somewhere to go at reset. Your decision to make 12KB available at $00D000 takes care of that requirement. However, consider that ROM is quite a bit slower than SRAM, so you might want to consider running your operating system out of write-protected RAM so you can avoid wait-states.

Also as noted by Ed, I/O could be anywhere, but if not in bank $00, it will be interrupting what would otherwise be contiguous RAM above $00FFFF. That's not necessarily an impediment if your operating system kernel is running in the same bank, as it would be able to access I/O with conventional 16-bit addresses, which is faster than 24-bit addressing. For example, you could place I/O and all of the kernel except the front end of the interrupt service routines (ISR) in bank $01. In bank $00, your ISRs could do a long jump into the kernel in bank $01, at an expense of four Ø2 cycles.

Don't forget that bank $00 is the only bank in which direct page and stack accesses can occur. Also, the JMP (<addr>) instruction looks in bank $00 for <addr> (on the other hand, JMP (<addr>,X) and JSR (<addr>,X) look for <addr> in whatever bank is in PB).

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

Hi, let me explain a bit more about why I decided on the memory map that I posted.
As I said, the aim is for it to primarily be a gaming machine, but not just that. The plan is to add an SD card reader for easy loading of programs/ROMs onto the computer, and those programs would have access to the rest of the address space, hence "Misc. devices". What I'm saying is: the program would be run from the SD card and would occupy the rest of the address space.

I'm actually only using 1 SRAM chip and 1 EEPROM chip. The former is 1MB, the latter is 128K.

The reason why I want ROM in the high area is because I want to make sure I can utilize all of the available space of the chip, and I feel like 128K is a good size.
Maybe it's too much, maybe it isn't. But that's the space I feel comfortable having. If I need to involve a CPLD to get what I want, then that's what I'm going to have to do despite the cost situation. I've never used them however, so some pointers on how to implement what I want would be appreciated.

It might be worth noting that once you have solid state storage, you only need a minimal amount of ROM to load your OS. It's then also a great deal easier to iterate on the OS, because you're not reprogramming, just rebooting.

OS and applications in ROM is a good idea when you don't have convenient mass storage.

In a situation like that, where I'm not utilizing the full capacity of the EEPROM chip and it's only in the first 64K, how would you suggest I split up the memory map after the 64K between the HiRAM and the mass storage? Would it basically be the same as my idea was? 1MB of RAM at $010000, and then the rest is devoted to mass storage? Hmm.

Even as little as 2k ROM would be enough to load a bootstrap: 16k would be enough for quite a sophisticated loader.

So, indeed, banks 1 and up are all RAM.

I don't quite understand your 'devoted to mass storage' - you are perhaps thinking of memory mapped storage? I'm thinking of SD card block storage: your ROM routines read a block, place it in RAM.

If you have a large EEPROM mapped into high memory... well, you have non-volatile memory. That reduces boot time, I suppose. But it means there's a distinction between booting and upgrading.

Do you have a clear idea why you want large amounts of non-volatile storage? Is it perhaps because you hadn't originally got the SD card in mind?