6502.org
http://forum.6502.org/

Using CPLD for very fine-grained memory mapping...
http://forum.6502.org/viewtopic.php?f=10&t=5753		 Page 1 of 2
Author:  cbmeeks [ Mon Sep 16, 2019 7:54 pm ]
Post subject:  Using CPLD for very fine-grained memory mapping...
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.
Author:  BigEd [ Mon Sep 16, 2019 8:16 pm ]
Post subject:  Re: Using CPLD for very fine-grained memory mapping...
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))
Author:  cbmeeks [ Mon Sep 16, 2019 8:29 pm ]
Post subject:  Re: Using CPLD for very fine-grained memory mapping...
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
Author:  BigEd [ Mon Sep 16, 2019 8:37 pm ]
Post subject:  Re: Using CPLD for very fine-grained memory mapping...
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!
Author:  cbmeeks [ Mon Sep 16, 2019 8:41 pm ]
Post subject:  Re: Using CPLD for very fine-grained memory mapping...
BigEd wrote:
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.
Author:  BigEd [ Mon Sep 16, 2019 9:00 pm ]
Post subject:  Re: Using CPLD for very fine-grained memory mapping...
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.)
Author:  BigEd [ Mon Sep 16, 2019 9:35 pm ]
Post subject:  Re: Using CPLD for very fine-grained memory mapping...
(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!)
Author:  Chromatix [ Mon Sep 16, 2019 10:59 pm ]
Post subject:  Re: Using CPLD for very fine-grained memory mapping...
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.
Author:  floobydust [ Tue Sep 17, 2019 4:31 am ]
Post subject:  Re: Using CPLD for very fine-grained memory mapping...
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.
Author:  drogon [ Tue Sep 17, 2019 8:45 am ]
Post subject:  Re: Using CPLD for very fine-grained memory mapping...
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
Author:  BillO [ Tue Sep 17, 2019 2:39 pm ]
Post subject:  Re: Using CPLD for very fine-grained memory mapping...
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.
Author:  barrym95838 [ Wed Sep 18, 2019 11:16 pm ]
Post subject:  Re: Using CPLD for very fine-grained memory mapping...
drogon wrote:
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 ...

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!! :mrgreen:
Author:  Chromatix [ Thu Sep 19, 2019 12:19 pm ]
Post subject:  Re: Using CPLD for very fine-grained memory mapping...
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.
Author:  Dr Jefyll [ Thu Sep 19, 2019 3:41 pm ]
Post subject:  Re: Using CPLD for very fine-grained memory mapping...
barrym95838 wrote:
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!! :mrgreen:
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.
Quote:
why would you want to devote some of that precious space to a data stack when it's already in short supply? As it turns out, it's a pretty good investment. It's like variables that only exist when they're needed, and afterwards, the space is released for something else to use it.
Quote:
If you need a variable long-term, fine—leave it as a variable. Other variables however may be needed only intermittently, and their contents will be irrelevant between uses.


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
Author:  kakemoms [ Thu Sep 19, 2019 10:09 pm ]
Post subject:  Re: Using CPLD for very fine-grained memory mapping...
You can put ALL registers into one address. :shock: Its less efficient as you need to read a sequence of data (going into the same address), but a CPLD can handle that easily... :roll:
Page 1 of 2 All times are UTC
Powered by phpBB® Forum Software © phpBB Group
http://www.phpbb.com/