I'm trying to code the following memory map for the PLD address decoder for my 65816:

It wouldn't fit within my PLD with the following logic:

But the following logic does work:

Are the two expressions for RAM_CS equivalent? The second one does work in my build so far, but my operating system is still a bit basic.

Edit (5/17/2022):
For those finding this in the future, the straightforward:

will compile in WINCUPL with the Quine-McCluskey minimization option enabled. Read further in this post for background and details.

Hey! Fun problem to work through, hope this helps.

From the first logic we get, using DeMorgan's law:

RAM_CS = !(RAM & !ROM) & !(EXRAM & !IO)

We can apply the law to each group as well, which gives:

RAM_CS = (!RAM # ROM) & (!EXRAM # IO)

Or, because distributivity works in boolean logic,

RAM_CS = !RAM&!EXRAM # ROM&!EXRAM # !RAM&IO # ROM&IO

From your memory map

!RAM&!EXRAM is equal to a subset of ROM [10000..1FFFF]
ROM&!EXRAM is equal to ROM
!RAM&IO is equal to IO
ROM&IO is always false

so RAM_CS = [10000..1FFFF] # ROM # IO # 0 = ROM # IO (we can ignore the subset of ROM ORed with ROM)

From your second logic

!RAM_CS = ROM_CS & IO_CS gives you RAM_CS = !ROM_CS # !IO_CS = (ROM & RW) # IO

So they're not strictly equivalent. The second one also activates the RAM when you're writing to ROM space, which you might not want because your RAM doesn't occupy the whole ROM space.

_________________
BB816 Computer YouTube series

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

Thanks Adrien. Very interesting analysis. I always struggle getting my head around those equivalencies.

I'm not sure I understand your last point. Physically my RAM does occupy the entire ROM space as I'm using 256k ROM and 512k RAM, both directly wired to the address bus. Thus, as you point out, a write to ROM would also write to RAM, but from a system perspective would be nonconsequential since nothing is expected in the overlapping region.

Better still, in my system, writes to ROM would be an error. I hope I don't have any of those.

I'm using an ATF22V10C.


My complete code in the second case is:

I'm using WINCUPL and the TL866II+ programmer.


Some of my I/O is interrupt driven. My ISR is in ROM located in the page $FF00. I placed I/O in bank 2 because that's where I'm currently placing RW data. Thus, by setting the data bank register to 2 I can address both my data and I/O with 16-bit absolute address. I figured I'd use another address mode for banks above that, but I'll admit I haven't given it much thought. At this point even three banks of memory seems like a luxury. Honestly, I have on my to do list some of your posts on the subject, so I have a lot more learning to do.


Yes, this is a work in progress. I'm not wedded to a particular scheme yet. So far I've just converted my hardware related code from the 6502. As I convert my Forth related code I'm sure I'll come across things that require more consideration.

I was looking at this specifically:


RAM is overlapping ROM between FF00 and FFFF. Which I didn't think through fully to realize you were overlaying them on top of each other in the chip select definitions below.

For clarity/safety you might want to write RAM = Address:[0000..FEFF]. Even though it works in this file, since you're doing RAM & !ROM for RAM_CS, you're one mistake away (forgetting to &!ROM) from enabling both chip selects at the same time. Same thing for EXRAM = Address:[20100..7FFFF]. Then you can also do !RAM_CS = RAM # EXRAM which is easier to read

_________________
BB816 Computer YouTube series

Also agree that putting I/O in bank 0 is the way to go; I use the end of the core RAM space for this in my design.



EDIT: Although, with changing the data bank register that might work. Sorry it is late I missed that part of your message.
So if data is in bank 2, what are you putting in bank 0 besides the direct page? Stack?

_________________
BB816 Computer YouTube series

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

The problem is this requires more product term than the PLD pin provides. That's why I've used the overlapping range with logic to exclude the ROM range from RAM.

Direct page, return stack and Forth data stack and likely multiple instances of them. But this is just a thought at this point. Much like the 6502 zero page, it seems a waste to use the 65816 bank 0 for normal data and code.

Hmm, several new posts. I'm falling behind! But...

... can either of you clarify this preference for I/O being in Bank $00? I do see why I might choose Bank $00 for I/O because of hardware issues. For example, maybe I intend to use an 8-input NOR gate to decode the bank address, in which case banks other than $00 don't go with the flow -- $00 is very clearly preferred because it agrees with how I want the hardware arranged.

But I don't see much value in choosing Bank $00 for I/O because of software issues, even in the context of an ISR.


It's true that long accesses incur a penalty, and of course we'd prefer to avoid that. But I'm doubtful that having I/O appear in Bank $00 is of much use for avoiding that penalty.

The Program Bank Register PBR gets pushed to stack when an interrupt is recognized, and also a new value (ie, $00) written to it. This is crucial. The Data Bank Register DBR does not get pushed to stack (booboo edited as per your correction, tmr4 -- thx), and -- more to the point -- neither is a new value written to it -- DBR remains unchanged from the value it had prior to the interrupt.

So, if the ISR explicitly updates DBR then the penalty can be avoided. Or, the DBR update becomes unnecessary if we make a rule that the foreground code must disable interrupts anytime it wants to use a DBR value other than $00, but this is an unappealing compromise. That's why I say having I/O appear in Bank $00 isn't a very useful shortcut for avoiding the penalty

I'm drawing a blank on your suggestion to "split your ISR between bank $00 and the I/O bank and JML to the rest of the ISR." Like an interrupt, JML fails to update DBR. And can you supply a reference for your statement that long accesses using R-M-W instructions will incur multiple clock cycle penalties per instruction? Long address modes do mean the instruction will include a three-byte address, and certainly it costs an extra cycle to fetch that additional byte. But AFAIK the penalty only applies once, even in the case of a R-M-W

-- Jeff

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

Thanks for the review and comments. I still have a lot to consider. In answer to your questions:


It provides the inverted clock signal needed by the bank address latch and data bus buffer. Using the PLD for this saves a chip in my build. I've attached an image of the breadboard version (btw - I got the 64k, 12 ns RAM version of this up to 10 MHz before I started seeing stability issues). Ultimately I plan on a small handheld unit.


I've tried a number of ways to express the logic but the second method was the only one I got to work for a single page of ROM at the end of bank 0. I could get the wider ROM range of $F000-$FFFF to work with RAM of $0000-$EFFF, but I don't need that much ROM in bank 0. I'll see if some of Adrien's other suggestions work though. I'm definitely a novice on WINCUPL.


Looks like I picked up some bad coding practices on the web. I guess it's easy to do. There are so few examples of concise coding for address decoders. Lots of bad stuff though, like where they do all of WINCUPL work on a spreadsheet and then import it.


I'm using the 65C51 and the transmitter can't be interrupt driven.


My reset front end is in bank 1. I long jump to it from page $FF00. As I've seen you advise, my ISR is short.


Thanks. I'll keep this in mind. Right now I'm very far from fully using much of either bank 1 or 2. My 6502 hardware and Forth primitives use less than 9k of ROM and my Forth code and dictionary probably use an equal amount of RAM. I expect that to go down with the 65816.


Yes, I still have a lot to think about along those lines.


I think I was hoping to rely on one of the busted myths form your 65816 Facts and Myths post, that the 65816 banks could be addressed as a whole. I haven't considered it much beyond that, so it's currently just an idea (hope?) that I'm hanging onto right now.

I'm really new to the game here, but I thought only the program bank register was pushed to the stack on an interrupt.

Doh -- sorry, you're right; DBR doesn't get pushed. My mistake; comes with typing in a hurry. However, I did and still do mean to say that, unlike PBR, DBR does not get a new value placed in it when an interrupt occurs. This is central to my post.

-- Jeff

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

Yes and that's what my current system relies on. DBR is set to bank 2 on start up and with I/O in bank 2 I don't need to change it again, either in the ISR or in my other code.

Still to be considered though is what I do when I exceed bank 2 for data. Still thinking about that.