Alright, here's my followup to the "illegal instruction" VGA plan. But firstly some background... Earlier I mentioned the
Ultra-fast output port using 65C02 illegal instructions, and I have edited that post to include a new option, one which also plays a role in the VGA idea. As shown below, the new arrangement provides 8 one-bit ports, each of which can be individually written using a 1-byte, 1-cycle NOP from Column 3.
- 74_259 approach allows 8 individually writable bits
- Ultra-fast_65c02_output_port using a '259 .png (5.9 KiB) Viewed 82839 times
Adding to that, the circuit below also responds to opcodes in Column 1. (These are
not illegal.)
The opcodes in Column 1 are all either (z-pg,X) mode or (z-pg),Y mode, and it's the latter that appear in Bill's little ditty:
Code: Select all
LDA (z-pg),y
INY ;the 2-inst'n sequence repeats 80 times to generate one line of 640 pixels
The LDA (zp),y opcode -- or any other (zp),y or (zp,X) opcode -- will cause the /COL_1 signal to go low at the end of the cycle during which the opcode is fetched. This gets inverted, and a one-cycle high subsequently makes its way through a delay line that's formed by 5 sections of a 74_174 hex D flipflop.
Referring to the cycle description included at the bottom of the diagram, we see that only cycles 5 and 6 will vary according to presence of a page crossing.
- With a page crossing, cycle 5 is a CPU "internal operation." Cycle 6 is when the data access occurs and cycle 6 is when the Video Shift Register loads.
- Without a page crossing, cycle 5 is when the data access occurs. Bus capacitance preserves this data for an extra cycle because on cycle 6 the data bus floats. Cycle 6 is when the Video Shift Register loads. The CPU is trying to fetch the next opcode during cycle 6, and that's why SYNC goes high... floating the bus and pulling RDY low for a single cycle.
There are some incidental details to attend to. The altered behavior of (z-pg),Y instructions exactly suits our needs for video, but we need a way to turn off the new behavior when
not dealing with video. I've connected Q0 of the '259 so that a 1-byte, 1-cycle NOP can enable or inhibit the special response to Column_1 opcodes.
Q1 and Q2 of the '259 are shown as VSYNC and HSYNC outputs, and all the other bits remain available for whatever. They could be used to select colors, for example. Or... by adding another gate or two they could cause various other
entire 64K regions to be activated during cycles 5 and 6!
Because it decodes instructions, this "video" scheme provides a potential means to let you read and write data of any kind from several, perhaps dozens, of other 64K banks at will.
I'll develop this idea further in a separate post, perhaps. But for now let me point out a highly pertinent point, and it is this:
instruction decoding lets us know when the special memory access will occur. That's a crucial contrast with ordinary banking schemes, which rely on
address decoding to tell us "when."
If the "when" question ceases to rely on address decoding then you eliminate the regrettable need for the "window" -- a peephole within the 64K space -- that'd be necessary to trigger the address decoder. Instead of accessing the beyond-64K region as a series of peephole-sized chunks, you can access it in units which are each a full 64K. Peepholes suffice for some applications, but if you care at all about treating the new memory as a linear space (containing very large arrays, for example) then 64K units (similar to what the the 65816 uses, BTW) will perform a lot faster and give you fewer gray hairs than working through a peephole, IMO.
-- Jeff
