Hello everyone!

I've been fiddling with my next SBC revision's logic, and I found a way to set aside 4KB of unused memory in the $B000-$BFFF area. I've been thinking of all the things I could do with it, expansion boards and whatnot. Things like an additional 6522 VIA, or perhaps a way to set up banked RAM there.

Here is the discussion:

1) Do you intentionally leave some of the memory map unused for later expansions like this? How much? Where?

2) What type of expansions have you planned or used on your SBC's? Do you have ways of reaching those expansions without unused memory locations?

Would like to hear what y'all do and what you find useful. Thank you!

Chad

I absolutely leave some addresses reserved, especially on hardware where I know I'll want to expand, but don't know what the expansion will be. You need to have high addresses for the interrupt and reset vectors, and you need to have low ram for zero page and the stack, so it probably makes sense to place the unused addresses in the middle between RAM and ROM (assuming you have ROM). Other popular choices include just above the stack area (might start at $200 or might start at $1000 for easier decoding) or a bit below the interrupt/reset vectors (again, might do something like up to $FE00 or even $F000 for easier decoding).

I have a 32K RAM + 32K ROM system, so I have to "steal" address space from one of those. I chose to steal it from RAM so I reserved a block of 256 addresses from $7F00-7FFF. I decoded select lines for 4 peripherals (3 on my board and one external) giving 64 bytes to each peripheral (most use 16 or less). If you wanted to add external RAM (eg. a video card or memory mapped flash storage device), then you will need to reserve a larger block of addresses. I used a PLD for the address decoding, and here is the relevant section from my PLD file (available at https://github.com/SamCoVT/SBC/blob/master/ADDECODE.PLD). I never changed the code here so it still references a PIT, but I currently use that select line for my compact flash interface.


I had originally expected to interface an external 8254 (Intel Programmable Interval Timer, or PIT) as I was familiar with that device and had one on hand. Because it's an Intel device, it needed the separate RD* and WR* so I had those decoded as well. I ended up adding a 6522 to my single board computer design instead, which had a timer I could use, so I didn't end up adding the 8254 at all. The decoded area was still available, however, and I ended up adding an external compact flash slot, which also needed the separate RD* and WR* lines so it was good I brought those out.

I also have I2C and SPI connected devices (for EEPROM and SD Card), and those were interfaced through the parallel ports of the 6522. You need some addresses reserved for the 6522, but then can connect a whole slew of things to those and bit bang the serial interfaces. You can also connect parallel devices by using one port for the data and the other port for whatever control signals you need. It will be slower than having that device directly on the 6502 bus, but it does work and is generally fine for playing around and exploring.

I will recommend the use of a PLD or similar device for address decoding because you can easily remap your memory layout if, for example, you realize later that you want to reserve 2K instead of only 64 bytes for a particular expansion. I used a 22V10 device.

Thanks SamCoVT, good reply. So with only 64 bytes per peripheral, you are not planning on putting in any type of banked memory I am guessing. It is a hard tradeoff though, because if you wanted to put in some type of RAM/ROM expansion, you should provide a large enough area to access it without trouble. But then if you were to use it for peripherals like you are saying, it would be a huge waste!

Is there a middle ground? Anyone else use a configuration they are particularly happy with?

Thank you.

Chad

64 bytes per peripheral is enough for many of the chips I interface with - most use 16 or less, including the compact flash card in 8-bit True-IDE mode.

The reason I recommend a PLD for address decoding, like the GAL22V10, is because it's very easy to change the memory map by just updating your PLD file and then reprogramming the chip. I've been considering trying to play with the compact flash card in memory-mapped mode, whereby the buffer used for reading/writing is inside the CF card and you memory map the whole buffer. This saves the time/hassle of copying the bytes in or out of the CF card and into system RAM. It does mean that the card will need to be enabled for a much larger range of RAM addresses and I can easily just update my GAL22V10 to do that (using the existing lines on my board, so no PCB changes needed).

This may not help, but might add another thought to the process...

I've been building systems for a purpose for a long time now - and not just 65xx based systems, so sort of along the "do one thing well" lines.

Which sort if irritates me at times as I was "brought up" on the Apple II with it's expansion slots and so on, then an S100 bus system with room for more expansion, then the BBC Micro - with it's own type of expansion ports...

So building a thing for a thing is easy - as long as the thing you're building it for is fairly well defined in the first place...

This tends to extend to software too, although I have written several "domain specific" little interpreters for things like hardware diagnosis and so on.

Latterly my 65xx systems have been very specific - no real "bus" expansion (as in no access to the address+data buses) I have, however created an expansion bus aimed at a slightly higher level using a VIA to interface to peripherals like a sort of cut-down SCSI bus. my 65xx systems have an IO hole at $00.FE00 through $00.FEFF because it's easy to decode and all I have there is a single VIA. They are otherwise RAM all the way (64KB for the 65C02 and 512KB for the 65816. KISS principle.

The idea of having the IO hole up high sort of comes from the BBC Micro - with a bit of a nod towards the Apple II. If I were building a new, more general purpose 65xx system - I suspect it would still look remarkably like a BBC Micro (which didn't waste much in the way of decoded IO space), so 32KB RAM from 0, space to a 16KB "ROM" at $8000, then more ROM from $C000 for the OS with a small hole for IO somewhere up there. Ruby is more or less like that, but it's RAM all the way.

Cheers,

-Gordon

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

Acorn used a page of I/O for mass storage, in effect, with three bytes of I/O to act as a block index, IIRC. So one could address a RAM disk up to 2^32 bytes (unrealistic!)

For me, a RAM disk is quite a good use of cheap RAM on 8 bit micros.

A 4k window is an interesting amount: it's not a great deal, but it's more than a little! It could be used as a window into a larger memory, or more flexibly as several windows. We used a 16k window set for the large Life on a Beeb second processor.

4k isn't perhaps big enough for an option ROM, although that depends on what you'd put in the ROM. Examples that spring to mind are: floating point library, graphics library, filesystem, machine monitor. It's big enough for a bootstrap: something which loads and then runs a block or a few blocks from mass storage.

4K is perfect size for direct-mapped text video display; 1K for font table and 3K for video RAM. For large pixel graphic display, 4K is a nice size window into the graphic RAM. I set my 4K window from $C000-$CFFF because monitor is from $B000-BFFF; DOS/65 is from D000 and up; IO and ROM are at top of memory.
Bill

The Hitachi HD63450, a CMOS version of the Motorola 68450 DMA controller, is still readily available through Quest Components, though depending upon package and speed prices may vary from less than $20 to over $100. If you're willing to settle for NMOS, the Motorola MC68440 and MC68450 are still available, too, from at least Quest and Electronics Surplus, and generally cheaper.

Earlier DMA controllers from Motorola and Intel typically have a 16-bit address range, though this can be worked around. The later (five digit) Hitachi and Motorola products have a 24-bit address range, and while designed for a 16 bit data bus can be made to work with an 8 bit bus, especially because they wanted compatibility with the early 6800-family peripheral chips.

I intend to leave a tiny bit of room in my memory map and address decoding for future expansion, but not too much - but I'm looking at a 65816-based system and SPI for much of my peripheral interfacing.

Just brainstorming on some things it could be used for:
* Dual-port memory shared with another 8-bit bus processor - another 65C02, 63C09, Z80, 68008. 8088, etc.
* Microcode store and register space for a microcoded second processor or coprocessor
* Traditional RAM banking
* Additional SPI controller
* LCD display for status, or as monitor output for debugging if there's also a keyboard
* A VIA or PIA for a keyboard and status lights
* Use some for MMU control registers and mapping table
* RTC + NVRAM
* Audio