Yea, it is most irritating.



Yea, I was going to use the second quad AND gate as an inverter but, well, I had a senior moment and forgot that of course an AND gate can't invert... The NAND works better anyway, less prop delay and we get two inverters out of it instead of just one.

So, the final count is a 74x138, a 74x139, a 74x10 and a 74x1G00.


I don't use WDC's notation for the PHI pins as I find it unecessarily confusing. I call their PHI2 as PHI0 and their PHI2O as PHI2.



Its not the software side of the '816 that concerns me; I'm fully aware that you need only use as much of its extra features as you want to. Its the hardware that concerns me, particularly that multiplexed data bus.

_________________
Want to design a PCB for your project? I strongly recommend KiCad. Its free, its multiplatform, and its easy to learn!
Also, I maintain KiCad libraries of Retro Computing and Arduino components you might find useful.

From the data sheet:

Pretty simple.

_________________
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?

The W65C265S exposes all 24 bits of the address bus.

Probably a bit overkill to save the wiring and two chips in order to decode the bank register (there's a suggested circuit in the '816 data sheet to decode the bank/data bus), but it's there. Also need to jump through a couple hoops to just use it as a raw CPU (notably disabling ports and what not). It's also slower (8Mhz v 14Mhz) and more expensive (~$24 vs ~$9).

You can also look at the schematic of the W65C816SXB to see it in action. BD's POC v1 schematic I'm sure has that logic laid out as well.

My understanding was that you needed to use VPA/VDA as well to qualify otherwise you get accesses to garbage addresses?

_________________
Want to design a PCB for your project? I strongly recommend KiCad. Its free, its multiplatform, and its easy to learn!
Also, I maintain KiCad libraries of Retro Computing and Arduino components you might find useful.

It's a good idea to use those particularly for non-65-family ICs that mess up if you access them two clocks in a row, like BDD experienced with the NXP UARTs. VDA and VPA are an added functionality that you don't have on the '02. If you have a scheme that would work on the '02, it will also work on the '816 without using VDA and VPA. It was the NMOS '02 that did reads from invalid (but predictable) addresses in some situations. That was fixed in the CMOS '02. VDA and VPA were added to the '816 design for use with cache and DMA, things I don't think you're interested in implementing. Am I forgetting anything?

_________________
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?

And now I discover that the screen has a minimum cycle time of 1.2ms; given I intend to dangle it off the CPU bus and my target CPU speed is 4MHz/250ns.... yea, I'm going to have to put in wait-states for that. Lovely .

Though having said that, I'm not 100% certain that it really does require such a cycle time. I'll get the relevant datasheet and discuss my thoughts on the matter tomorrow.

_________________
Want to design a PCB for your project? I strongly recommend KiCad. Its free, its multiplatform, and its easy to learn!
Also, I maintain KiCad libraries of Retro Computing and Arduino components you might find useful.

An idea might be to put in a pulse-stretcher and a latch.
By which I mean, put latches between the bus and the screen, and have a timer, triggered by the inactive edge of the enable signal, that holds all the signals in a valid state for long enough that the screen can respond. Then when the timer runs out, it deasserts the enable signal that the LCD sees.
The only problems I see with this are that that's a fair amount of hardware, and you'd have to wait between accesses.

I suspect that's how long it takes to handle an entire screen update or something like that. Or maybe it takes 1.2µs (a thousand times as fast as 1.2ms)? The common character LCDs however are not fast enough to put directly on the bus if you're running at 4MHz, which is why my workbench computer (at 5MHz) handles the LCD (plus five other things) through the first VIA. If you'll still write to it faster than it can process the data or instructions, the next thing is to check its busy bit before writing to it again. If putting it in a thumb-twiddling wait loop is not acceptable, you can set up a VIA timer to interrupt when it should be done, so the computer can do other useful things while waiting for the display to be ready for more data or instructions.

_________________
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?

Yes, a good idea, and "those" typically means just VDA (not VPA). Simply fix things so your I/O devices (or at least the sensitive I/O devices) can't get a chip-select unless VDA is high. No similar requirement applies to VPA (ie: I/O needn't become enabled when VPA is high) unless you plan to fetch code from the I/O device. That's utterly unusual except regarding EEPROM memories, some of which are in effect also I/O devices if in-system programming is used.

The 6522/65C22 VIA is a device that's potentialy sensitive to unexpected access, but protecting it using VDA often requires no extra gates. If the active-high chip-select is unused you can simply connect that to VDA.

Yes. In both cases there's potential for

• a double access to I/O when it should be a single access, or
• appearance of an invalid address that creates an I/O access when there should be none

... but evidently not all the necessary circumstances apply. Ie, if you got away with it on (NMOS) '02 then you'll also get away with it on '816 without VDA.

Yes. Then with the '816 they removed some or all of the 'C02 fix (thus re-introducing invalid addresses) and gave us VDA as a means of protection instead. Two different solutions to the same potential issue. (The 'C02 substitutes an extra read at PC for accesses which would, on an '02, read from an invalid but predictable address.

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

Yes, 1.2µs. Sorry it's given in ns in the datasheet and I got my SI-prefixes mixed up on converting.


I only have one VIA and there isn't enough pins left on it to drive the LCD screen. I would very much rather not add a second VIA to the system if I can avoid it as VIAs are not cheap components, and they take up a lot of space (relatively speaking compared to a couple of logic gates). Also this is as much a learning experience for me as it is an attempt to make an efficient system. I've never done wait states before (more on that below), so its an opportunity to learn.


I know about the busy bit, but it won't help for this issue. With the LCD directly on the CPU bus at 4MHz, the read/write timing specification is violated so I won't even be able to read the busy bit, let alone read or write anything else.

---

Link to LCD Screen Datasheet
Link to LCD Controller Datasheet

If you look at the timing diagram on page 30 of the controller datasheet and the AC Characteristics table on page 32, one can see that the two critical timings for this purpose are Tc and Tpw. Tc is the total time between rising edges of E, minimum 1200ns; Tpw is the minimum width between the rising edge and the falling edge, minimum 480ns.

Overall I don't think that Tc is an issue because (with the possible exception of RMW instructions) I don't think its possible for the 65C02 to access the same memory I/O device quicker than once every four cycles... e.g. STA $C002 takes four cycles to execute, only the last one of which is an actual write to the I/O device. So, for the purposes of Tc, one could argue that the access rate has dropped from a potential 4MHz to a potential 1MHz. Yes, technically 1MHz is still too fast for Tc, but it certainly a lot better.

Tpw is a bigger problem though. E would be high for only 125ns on a 4MHz system (ignoring prop delays) and there really is no way around that. Not to mention Tdsw requiring a data setup time of 80ns before E's falling edge, so with prop times it'd be cutting it close. So, I think that for accesses to the screen I would need to stretch the access over three cycles. 125ns + 2*250ns = 625ns > 480ns. This has the additional bonus of increasing the total length of the cycle for the purposes of Tc and should therefore keep that in spec too, taking into account the stuff I've already stated.

Two options for stretching the screen accesses: 1. stop / disconnect PHI0 for a specified period. 2. Use RDY. I prefer the latter option, gating the clock seems like a bad idea. That brings me to André Fachat's RDY Generator Mini Project, which looks like it will do what I want, but I'll be honest, despite staring at it for hours I have no idea how it works, and I am uncomfortable using glue logic that I don't understand. Also there might be a simpler way to implement wait states that you lot have hidden up your sleeves; this one appears to require a minimum of three extra chips.

I'm going to do some thinking and experimenting in the mean time, but I shall await your collective wisdom with anticipation.

_________________
Want to design a PCB for your project? I strongly recommend KiCad. Its free, its multiplatform, and its easy to learn!
Also, I maintain KiCad libraries of Retro Computing and Arduino components you might find useful.

Was your original mapping with a single 128K RAM chip something like the diagram below, and now you're simply adding an additional 32K RAM chip and mapping it into address space at $0000-$7FFF unconditionally for each map?

Mike

Yes Michael, that is an exact representation of the original map. I'm pretty happy with the new map though, it significantly simplifies the glue logic and gives me an extra 32K to boot.

_________________
Want to design a PCB for your project? I strongly recommend KiCad. Its free, its multiplatform, and its easy to learn!
Also, I maintain KiCad libraries of Retro Computing and Arduino components you might find useful.

So, here's my attempt at adapting André Fachat's Circuit to my immediate needs, the new parts being the '164 in the middle and the logic connected to it. I have also attached a timing diagram showing how I believe this circuit will work with respect to the relevant signals for the wait stating. In particular the E Period between cycles 1.5 and 3.5 should be roughly 500ns, which would meet the Tpw requirements of the LCD. Provided my timing diagram is an accurate representation of what will occur, I believe that this would allow it to work in a 4MHz system.

_________________
Want to design a PCB for your project? I strongly recommend KiCad. Its free, its multiplatform, and its easy to learn!
Also, I maintain KiCad libraries of Retro Computing and Arduino components you might find useful.

(You might already have this covered but note that the LCD can be driven either as an 8 bit or a 4 bit peripheral. That means you can use fewer pins and perhaps squeeze it into the VIAs ports. You may be able to share some pins if you keep a careful eye on device selects.)

Thanks Ed, yes I was aware that it can be used in 4-bit mode. I still wouldn't have enough pins on the VIA without multiplexing at least one pin and, probably, sacrificing all my remaining GPIO. I would rather avoid needing to split commands into nybbles, multiplexing pins and sacrificing what little GPIO I have left. I had always planned on attaching the screen direct to the bus, I just didn't realise how slow the LCD screen's interface is....

_________________
Want to design a PCB for your project? I strongly recommend KiCad. Its free, its multiplatform, and its easy to learn!
Also, I maintain KiCad libraries of Retro Computing and Arduino components you might find useful.