After I get settled into my new house, I'm considering starting another 8-bit computer that uses a CPLD for very detailed memory mapping.

Especially for the I/O.

For example, if I have the following:

VIA-A
VIA-B
DUART
Video
Audio

That could be 96 bytes or so of I/O addresses. I know, typically, memory decoders will block off I/O in pages or maybe a single 256 page for all I/O to share. Or even 1-2 KiB of I/O space in order to save money.

Does anyone see any issues with reserving the exact number of bytes for my I/O? It would be an even number and probably in multiples of 8 bytes since my video will be proprietary.

I figure if I'm using a CPLD it should be a piece of cake. Even if I do some banking. I could always change the mapping if I added or removed additional I/O devices and the CPLD should have enough pins for all 16 address lines.

Thanks.


**EDIT**

In case you're wondering why I'm asking this, I was thinking of doing something like the following:

32K Main "system" RAM. This would be $0000 - $7FFF.
16K Banked RAM ($8000 - $BFFF).
16K Banked ROM ($C000 - $FFFF).

The I/O area (96 bytes or so) would come off the top of the main system RAM. Leaving slightly less than 32 KiB of fixed RAM.

_________________
Cat; the other white meat.

If it doesn't cost anything, it feels more tidy to avoid multiple images of, say, a VIA's registers.

But personally I wouldn't think it worthwhile to set aside less than 256 bytes for I/O - unless, perhaps, page FF can contain both the I/O and the OS API (as it necessarily contains the vectors.) At best you gain a page, but at the cost of squeezing things.

It does feel worthwhile to leave a bit of room for more devices: another ACIA, another VIA, a Tube port, a second video adapter...

More important, I would think, is to allow for lots of contiguous RAM, and a sensible possibility for paging. So, putting I/O just below C000, for example, would seem to me an odd choice.

(Might be worth noting that Acorn allowed 3 pages for I/O in the BBC Micro: one page for the various individual devices in-system, one for external devices on the 1MHz bus expansion, and one for external paged RAM (up to 32 bit addressing I think))

Hmm.

That's a good point. Having a full page of I/O is probably a more sensible choice.
I was thinking of using a port from a VIA to control the ROM/RAM paging locations. 4 bits each. So I could use a single 512 KiB chip for 256 KiB of RAM and ROM with the CPLD disabling writes in the ROM area. That's why I was thinking of pulling a little off the top of fixed RAM for I/O.


BTW, this is really all pie-n-the-sky brainstorming anyway. I will probably talk myself out of it. I like the idea of multiple ROM banks. I like the idea of having many built-in languages and utilities in ROM that you can quickly switch to. But, I also believe these tricks of getting huge amounts of memory in a 6502 is a little silly.

So, I may stick with bankable ROM but drop the idea of bankable RAM and just leave a page of I/O just under the ROM.

All of my equipment is boxed up for our move so I'm going nuts trying to stay occupied and these ideas somehow end up on this forum....lol

_________________
Cat; the other white meat.

It does feel attractive to use some kind of paging to allow for lots of RAM (or write-protected RAM) but it's not attractive to swap out the whole 64k space at once: you really need a safe place to stand before applying your large lever. At one extreme, almost all the 64k stays unmapped and you access through a single byte. At another extreme, you keep a page or so unmapped and change everything else. But if you need to block-copy data from one part of the large RAM to another, you might want a couple of mappable windows, rather than just a single window. There are lots of ways to slice up a memory map!

That's a good point too! I never thought of that. Having one window of moveable RAM would be difficult if you needed to copy RAM from one bank to another. You would have to use your fixed RAM location.

The more I think about it, the more I like simple. So I will probably just focus on some bankable ROM. Maybe reserve the top most 4 KiB for a minimal monitor/OS and 12 KiB that can be banked in. I imagine you can get some Forth, BASIC, etc. in 12 KiB.

_________________
Cat; the other white meat.

Now that we have solid state storage, personally I'd keep the ROM-ish stuff pretty minimal. If I need to load a 12k Forth, I might load at D000. If I needed to load a 24k BCPL, I might load at A000 - in both cases keeping the max amount of free RAM in low memory.

(Might be worth remarking that we went for 8k-sized mappings into 8k slots for the extended 6502 second processor, for lots of flexibility. That cost us 8 bytes of I/O and was very simple. We could address 2 MByte of RAM, I think. Maybe too simple to be a good fit for, say, Fuzix, but good enough to run huge Life patterns.)

(Sorry I don't mean to project all my own thoughts onto your project!) (Edit: they are not even all my own... hoglet did all the memory-banking work. And Acorn's ideas were Acorns!)

If you look in the right places, I believe you can still get 4x4b register chips in the 74HC series (at least, TI still claim to make them). I think they also have separate address lines for read and write ops. Put two of those together to make 8b width, tie the write address to A0/1 and the read address to A13/14, and provide appropriate control signals. Voila - you can now run 8KB pages mapped onto a 2MB address space. Repeat to do the same for ROM. If you can't find the register chips, you can emulate them using 8-bit latches and a decoder, which also gives you more flexibility in choosing how many pages of which size you want.

One of the things this would be useful for is multitasking - you can give each task its own private ZP and stack, greatly simplifying context switches. You can also provide ROM only for boot, immediately copy it into a RAM page, and then map that RAM page to high memory and switch out the ROM. Useful if your ROM is slow enough to require wait-states while your RAM doesn't.

Using a CPLD for glue logic does make a lot of sense, as you get a lot of flexibility which is easy to change, even after your initial design is completed.

I used a single logic chip for my recent 65C02 board, an Atmel ATF22V10BQL. It provided chip selects for RAM and ROM (32KB each), 5- I/O addresses that are 32-bytes wide and qualified memory read and write signals. All of the I/O takes 160 bytes (5x32) starting at $FE00. It's a small amount of ROM to lose for a decent amount of I/O space, or you could always reconfigure it to take from RAM.

Depending on your I/O devices, you might even look at wider I/O ranges (48 or 64 bytes), which would be easy to implement with a CPLD. Good luck moving forward.

_________________
Regards, KM
https://github.com/floobydust

I used a GAL for address decoding (and other glue) in my 65C02 system - 2 GALs in my '816 system, so using a CPLD with all 16 address lines (plus clock and r/w) is just the same but more, so go for it ...

If it were me, I'd be tempted to leave the RAM intact and put the IO 'hole' in the top 256 bytes - ish, so $FF00 -> $FFDF for IO and $FFE0 -> $FFFF for the hardware vectors. Leave space for the '816 vectors from $FFE0 too for when you swap out the 6502 for a 65816 ... (or just start with the '816 - I wish I had!)

With your banked ROM idea, keeping that top page fixed while banking the rest of the 16K ought to be possible, or maybe even keep the top 2 pages fixed, so you could use $FE00 through $FEFF for vectors to have fixed entry points into your monitor/OS ...

-Gordon

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

My last 4 designs also used a GAL for address decoding. A GAL can handle more than just address decoding too. Like providing an inverter or other logic function without having to add another underutilized package. It's the only way to go in my opinion. Inexpensive, fast, flexible and efficient. I buy up all the 7ns GALs I can find.

_________________
Bill

That's an attractive idea, IMO. Another would be to steal $0000 -> $007f for I/O, allowing for faster and shorter access. Of course, you're left with only 128 bytes of ZP RAM, but that ought to be enough for anybody!!

_________________
Got a kilobyte lying fallow in your 65xx's memory map? Sprinkle some VTL02C on it and see how it grows on you!

Mike B. (about me) (learning how to github)

One potential advantage of using the top page for I/O is that you can also intercept vector pulls there, and remap them to individual ISRs for each IRQ source. That's a lot more natural to pull off if you're already decoding that area for another reason.

OK, you're joking, Mike -- and the jest is amusing in the context of legacy systems whose Z-pg is stuffed full of a hodge podge of "essential" items. But let's remember the situation can be drastically different when you're creating your own system from scratch. For example, one of my systems easily affords a generous, 64 byte I/O space in Z-pg. This makes the I/O code smaller and -- more importantly -- faster. See my thread major speedup with 65C02 I/O mapped into zero-page.

In this section of his Stacks Treatise, Garth explains how a coordinated strategy can magically relieve crowding in Z-page.

And... just thinking out loud... Since the topic is fine-grained decoding, here's an aspect incidental to the matter Chromatix mentioned (above).

With fine-grained decoding, some or all of the three vectors in Page $FF could activate the same physical page of RAM which also hosts the ZP area. What this buys you is the ability to remap the individual ISRs more quickly. (Only in very specific circumstances will this matter. But I believe in stirring the pot and exploring ideas.)

Here's an example. Maybe a timer interrupt needs to get redirected so that (say) four different routines will be serviced, each being serviced once per four interrupt intervals. So, the CPU fetches the vector using the address in page $FF, of course. But the code which then updates the vector would address those same bytes according to their Z-pg aliases, shaving cycles off of the performance-sensitive ISR.

-- Jeff

_________________
In 1988 my 65C02 got six new registers and 44 new full-speed instructions!
https://laughtonelectronics.com/Arcana/ ... mmary.html

You can put ALL registers into one address. Its less efficient as you need to read a sequence of data (going into the same address), but a CPLD can handle that easily...