If your little block of ROM at the top of bank 0 was 1k instead of 256 bytes, would that remove two terms from the calculations?

Yes indeed, thanks! I didn't think of that. Using instead of uses 16 product terms for RAM_CS and fits in the PLD.

That's probably a good compromise to get over the problem of RAM being selected during writes to ROM to get the 256 byte version to work. And it gives me more ROM in bank 0 should the need arise.

If you have spare output pins, you can also use them as intermediates to let you effectively use more product terms for an output you do care about. I don't think WinCUPL can do it for you though.

In your case you'd just have to give RAM and/or EXRAM pin assignments to make that happen. You'd still require them individually to fit within the product term limits of the device.

Also note that the product term limits per pin vary a bit, and sometimes you may get better results by not assigning pin numbers manually and letting WinCUPL do it for you. You need to pay attention though when you revise the code, as if it changes them around later then you'll need to update your circuit. Next time you run out it might be worth letting it pick the pins and seeing if that helps, then baking the arrangement it uses explicitly into your code to stop it varying later on.

Edit - another thought - this is very challenging:

But given IO already exists, I think it's equivalent to:

Similarly, these are equivalent I think:

Unfortunately I've used all inputs and outputs for this PLD. Any change means adding a chip to my design, which I want to avoid (silly goal yes, but I want this to fit on a 100x100 mm PCB). Good to know this option though. I had heard it mentioned elsewhere but haven't seen any concrete examples.


Thanks, I didn't know WINCUPL could do that. I did rearrange my pin assignments and wiring to accommodate getting RAM_CS on a pin with the maximum number of product terms but it's good to know that WINCUPL will do that too. Probably best for a first cut though, for the reasons you mention as well as PCB layout and routing.

Edit:
This does compile and the resulting ROM_CS looks correct

Interestingly, RAM_CS is down to 3 product terms! I'm going to test it on hardware, but think you won the challenge.

If I remember correctly, all you do is remove the pin numbers - still declare them as pins, but without specific numbers. Then use the diagram it outputs to tell you which ended up where!

More advanced PLDs have internal macrocells just for this purpose, not connected to physical pins at all. For those you write "PinNode" I think instead of "Pin". I'm not sure, but this syntax might also work for the 22V10, just allocating a real pin instead. If it works then it'd make it clearer in the code that it's not intended as an actual output.


The only thing to be a little wary of is there's potentially an extra propagation delay now. But hopefully the chip is fast enough that that doesn't matter for your case.

Ah. That's how that works. I'll give it a try. I'm definitely not using all of this PLD's capability on most pins. Perhaps they're available elsewhere if not used.


Maybe that's the problem, becuase the code you suggested compiles but doesn't work on hardware. On the scope though it looks more fundamental than that. There are periods of several clock cycles where no device, RAM, or ROM have been selected. I think that's impossible with my memory map and very inconsistent with what I was observing yesterday in which something was always selected regardless of my PLD coding choice.

Edit:
I was hoping to use the logic info from WINCUPL's DOC file to do a sort of before and after comparison to see what was going on, but the logic your consolidated addressing isn't at all similar to that from my other tries, both working versions and ones that won't fit in the PLD, but with very plain addressing. I suppose, as indicated by my scope, something is missing.

Could you post the updated code? And does it work in the simulator?

Here is the updated code. Perhaps I didn't properly translate your intent.

I didn't prepare a simulation file for the expanded memory map. But I suppose that would show me where this is going wrong. Oh the corners I cut when things appear to work.

Ah I missed that !ROM_CS also involved RW so now writes to ROM addresses will actually activate the RAM. But it doesn't really sound like the bug you described.

Oh, the problem is with the inverting. ROM_CS and IO_CS are active low. So you should remove the '!' from the RAM and EXRAM lines. I usually put the inversion in the pin description like BDD suggested, for signals that are active low - I get what you mean though, that it might not make sense in your head with it done that way. But if you consistently follow the rule is that all variables are active high, it can get easier to intuitively understand the expressions.

Yes, I noticed that after a while. This does work on my build, but,

and now, drumroll ...

I can chalk this all up to user error, or if we're being kind, user inexperience at the minimum. Researching your PinNode reference I came across a CUPL Language tutorial. It wasn't much help with PinNodes but when I searched it for "product term" it took me right to the page on logic minimizations. I'd been using Quick, a recommendation I'd read about when I first downloaded WINCUPL. Turns out that Quine McCluskey works with my desired memory map.

RAM_CS uses 13 product terms, ROM_CS just 2. Some intermediate terms use a lot more. EXRAM for example uses 56, the same as before, but obviously WINCUPL is minimizing this away with the Quine McCluskey setting. Interestingly, the tutorial says to
Still, this was a good experience and I learned a lot.

Thanks to everyone for there help!

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

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

Thanks. I'd like to say I wish I had these earlier, but I already had the user manual, but didn't think to look at it. The reference I linked to though covered the area I needed better. I don't think the user manual would have gotten me to the same point.


It seems the 22V10 still has a ways to go, at least with respect to my design, once I learned how to use the software properly. The following code compiles (and works) just fine with Quine McCluskey minimization. It's what I was originally trying to do but wouldn't compile with the Quick minimization setting I'd been using.

_________________
http://WilsonMinesCo.com/ lots of 6502 resources
The "second front page" is http://wilsonminesco.com/links.html .
What's an additional VIA among friends, anyhow?

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