.
As a rule, vintage 6502 computers don't map their I/O devices into zero page. It's almost a tradition that the decode hardware will put I/O at some higher address instead. But should new 65xx designs follow the rule, too? I started this thread to talk about how much faster I/O in zero-page can be, and how the pros clearly outweigh the cons for some new designs.

I have edited this post in light of subsequent discussions. Here are the main points to consider:

• benefits of I/O in z-pg: speed
• benefits of I/O in z-pg: smaller code size
• possible impediment: users' unfamiliarity with the idea
• possible impediment: consumption of zero-page addresses (balanced against fast I/O as a priority)
• possible impediment: decode hardware has less freedom to ignore address lines -- you need full decoding (or close to it).

Code Size and Speed
The chart below shows various instructions commonly used for I/O, listing the size and speed. In the cases (shown in color) where a given mode or instruction is not available, a roughly-equivalent "next best" code sequence is evaluated. For BBS/BBR and their equivalents, the usual optional extra cycles apply (for branch-taken and branch-taken with a page crossing).
The 33% speedup for byte-oriented I/O (eg LDA STA) is noteworthy. Even greater are the gains for BBS/BBR (about 55%) and SMB/RMB (100% ) -- bit-oriented instructions which, unfortunately, are available only on the 'C02. However, even the SMB/RMB-equivalent code (used by '816 and NMOS '02) shows a 20% speedup if the I/O is in zero-page.

IMO, these gains could in some cases make or break the viability of a heavily I/O bound application. Example: SPI or a software UART.

If I were being more rigorous, the equivalent routines should begin with PHA and end with PLA. But that'll often be unnecessary, as Garth mentions below.

On the '816, "Zero Page" is known as Direct Page, and is relocatable via the Direct Page register. It's worth remembering that, during I/O, this register must be set to zero (or whatever page is decoded for I/O). This is usually a non-issue but may be a nuisance if you're using D's esoteric capabilities elsewhere in your code.


Possible Impediments

In the thread that leads up to this one, Garth remarked that I/O mapped in Zero-pg is not normal for our applications. Certainly I/O in Zero-pg is uncommon -- and the pros & cons are worth reviewing! The rarity of I/O in Z-pg is partly explained by the high premium placed on Zero-page itself:

• with I/O in Z-pg, it's more important to fully decode the I/O address since it's undesirable to have many images of each device.
• in vintage microcomputers, free addresses in Z-pg are unobtainium. That's a regrettable reality.
• Unfortunately, yesterday's reality engenders a mindset that some modern-day builders seem to accept without question -- namely, that nothing merits the sacrifice of Z-pg. But in the context of a new design, the tradeoff might be attractive -- or even compelling.

Later in this topic I have some schematics to, uh, address (!) the challenge of decoding. Without proper attention, decoding is an issue that could limit clock speed in a system designed for absolute maximum performance.

Finally, I think I/O in Z-pg is rare simply because it's not talked about enough. IOW, its potential gets overlooked -- and that's a shame. But it wouldn't happen if we examine the matter on a case-by-case basis. My own experience has been 100% positive, and even WDC maps the I/O of its W65C134S into Zero-page. As I say, this approach needs to be mentioned more often.

-- Jeff

An incidental point (also from the other thread):

GARTHWILSON wrote:

I guess they [BBRn, BBSn, RMBn and SMBn instructions] were in ZP because a few microcontrollers had I/O there and they had so little ROM that it was important to save one byte each time one of these instructions was encountered

Absolute (as opposed to Zero-pg) versions of BBS/BBR might be impossible -- or at least in conflict with existing limitations on the sequencing logic. With branch-taken and a page crossing, Absolute BBS and BBR would be eight-cycle instructions! But I agree that saving code bytes in ROM may have been a consideration. Another factor is throughput, since the Zero-pg versions are about 20% faster than the Absolute versions would've been.

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

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

It's easy to imagine that, as time went on, new features got added piecemeal -- and the list of z-pg requirements just grew and grew. A unified organization such as a stack might've largely avoided that. IOW a new design needn't include the horrible congestion seen in old designs.

As I said, each case needs to be examined individually. To decode z-pg, what you need is a big, wide OR (or NOR) gate. Some systems have programmable logic, and a big, wide OR/NOR is no problem. Other systems -- those using slower memory, peripherals and clock -- have less demanding timing margins, and it's OK to replace that big gate with some SSI equivalent circuit. You'll still benefit from the reduced cycle count of I/O in z-pg. But I admit programmable logic may be the only answer if you're pushing for maximum clock rates.

One very tidy decoding solution is the 74ALS679 -- a configurable 13-input gate which has no trouble in plunking the 16 registers of a VIA, for instance, into z-pg for you. It can easily be configured as big, wide NOR (but it won't achieve 8.5ns max prop delay). Another way to get a wide NOR (14-input) is with both sections of a 74F260 feeding into an 'ACT138 (only one output would be used). Or a 74FCT521 might serve as part of the scheme.

Well, nothing says all the I/O has to be mapped to z-pg. You could map some of the less critical devices elsewhere -- and, if the "elsewhere" location is judiciously chosen, there'll be zero added complexity in the decode circuitry. A 50:50 split between Page 0 and Page 2 works nicely, for example. The circuit is virtually identical to that required for putting it all in pg 0.

FWIW, my own experience is with my workbench computer -- the Kimklone. It has a Rockwell 'C02 running at 5 MHz, and the I/O decoding uses a 74HC679. There are three VIA's (48 bytes total) mapped into z-pg, and I have oodles of space left over since the only other thing in z-pg is the Forth data stack.

I agree that if we're careful then we need "less of that." I had mixed feelings about including PHA & PLA in my code examples. Still, your SPI code snippet can run a lot faster if the bits being banged are mapped to z-page. (Edit: also expect further improvements in the posts to follow.)
The speedup we see here is from shorter instructions, from not having to push/pop A, and from not having a bit mask held in A. I hope I'm correct in assuming CLK_HI_PULSE assembles an INC abs followed by DEC abs (or vice versa).

FWIW, it's possible to optimize away use of Y as a loop counter, but that's not pertinent to I/O in z-pg so I'll leave it alone. BTW I sure do like the structured macros!

cheers
Jeff

[Edit for clarity, and better understanding of the CLK_DN macro. Tweak code comments and emphasize the split-I/O-area option.]

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

The absolute versions would be four bytes long, wouldn't they? Is that a major issue with regard to the design of the internal state machine?


Excellent point. The hardware complexity vs. software complexity balance can be tilted either way, depending on the design requirements, and your code comparison definitely caught my attention.



Another excellent point. It wouldn't have been hard to profile zp use while running the monitor, DOS and BASIC interpreter, and I'm sure that doing so would have exposed some inefficient usage ... in my opinion, the firmware gobbled up far more than necessary, and could have benefited significantly from a liberal dose of data-stack mentality.

Mike

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

I'm no authority on vintage 6502ery, but certainly that's my hunch as well.
Yes I guess BBS/BBR absolute would be four bytes, but that's incidental. As Garth says, it's the cycle count that's of concern. Somewhere we have a link to a 1970's magazine article that touches on this, although I can't find it just now.

During early development, the 6502 design underwent some drastic surgery to meet die area (ie, cost) objectives. IIRC, one of the things that got chopped was automatic pushing of the accumulator upon interrupt. Nice feature, but it would've demanded that the sequencing logic support eight-cycle events. Evidently that would've required that the entire PLA be a little longer. (Or wider?) Anyway, saving A is something that can also be done in software. The feature was dropped and the die area objectives were achieved.

Edit - here's that reference: This is the press clipping, and BigEd's lead post in this thread includes some details. Chuck Peddle is quoted as saying the 6502 team "tried an 8-state machine which would dump the accumulator as well as the program counter and status but since it added another 10 mils to the chip, we discarded it."

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

Unfortunately, there are other disappointments. AFAIK the '679 was never produced in any process faster than HC or ALS. The HC version seems to have disappeared. And nowadays Digikey and Mouser are asking more than $20 for an 'ALS679!

Ummm... If you really wanna max out the speed of that SPI routine, the final tweak might demand some of that spaghetti we were hoping to avoid. I'm referring to the IF ELSE ENDIF that's in the body of the loop. I suspect the ELSE translates to an unconditional branch, and in this case it's pure overhead -- the unconditional branch does no "work." Instead the fastest code will use a conditional branch (as part of an extra copy of the loop bottom).

But as for eliminating Y as a loop counter, there's no spaghetti required. Instead of Y, I'd use the actual data in the "shift register." That's the accumulator... and the carry flag -- nine bits! IOW, just SEC before entering the loop. At the bottom of the loop (after each shift), loop if Not Zero. The accumulator is guaranteed non-zero until all 8 actual data bits have been shifted.

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

How about optimising the use of zp I/O by stacking similar devices at the same address? Controling access to each similar device with a zp control byte, which would actually drive the chip select through, for example a latch. latching /CS1 while normal zp I/O logic asserts CS0 on the device. It seems to me you'd get enhanced zp I/O and reduced zp overhead for a 'marginal' increase in s/w complexity.

_________________
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, that was what I was thinking. The latch would have its own zp address - to refine it further, when you read the latch address, you get the interupt status of the devices in the bank. Thinking a little more, All your zero page I/O could go in the foot print of the largest device - for example 16 bytes for a 65c22. The zp overhead would then be sixteen bytes plus one for the control/interrupt register. Up to eight devices, VIA, ACIA etc in the one 17 byte zp footprint, of course the trade off would be added code complexity.

Edit:



Which might be a worthwhile price for ~33% acceleration.

Alright, I'll apply my "no-loop-counter" speedup first -- and then the "I/O in zero-page" speedup after that optimization, not before. That'll make the percentage of speedup for I/O in zero-page seem more dramatic! (Joking aside, we know that a program that doesn't spend most of its time actually doing I/O won't accelerate as much, percentage-wise, as one that's heavily I/O bound.)

As the initial reference, let's begin with Garth's version. I have expanded the macros so all instructions are explicitly listed. Later I'll compare this with alternative versions. In all cases,

• average execution time is calculated based on a 50:50 proportion of ones and zeros in each byte
• branches are presumed not to involve page crossings
• the RTS is not included in the timing. Presumably any speed-obsessed coder would in-line the SEND_BYT routine (at least when it's contained in a loop).
• those versions (like Garth's) that trash X, Y and A have PHY and PLY added. This helps to level the playing field, as other versions inherently preserve one or more register(s).

My pencil'n'paper tally says the average execution time for Garth's version is 299 cycles per byte:

The next version averages 272.5~/byte -- a 9.7% speedup compared to the original. Y is not used, and the "bottom" of the loop is duplicated -- ie, there are two instances of BNE Looptop and the preceding instructions.

The "I/O in zero-page" version averages 189.5 ~/byte. This is 44% faster than the already-optimized version. And X and Y are both preserved.


Corrections are welcome if there's a typo or other boo-boo anywhere. Further speed increases are possible, up to twice as fast as the original -- or more. I can share that code if anyone's interested. With that version, I/O in zero-page is definitely helpful, but the speedup is mostly due to a table-based approach. Each nibble of data generates a 16-way branch, and each branch destination outputs 4 bits without pausing to take a breath! There's also an assumption that all bits of VIA3 PortB -- including the six bits not used for SPI -- may be read, held in a register, then written back later. That's problematic if an interrupt might modify any of those six bits, as the changes would be lost. But if interrupts don't touch those bits, or if the bits are used as inputs, then you're good to go!

cheers
Jeff
ps- the lead post has been revised somewhat -- for clarity, and for an '816 and NMOS '02 perspective on I/O in zero-page.

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

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

If you're pushing for maximum CPU clock speed and can't use programmable logic for decoding, that makes sense. As I've said all along, each design needs to be be considered individually -- which seems an obvious thing to underscore, but I/O in zero-page oughtn't to be overlooked merely because it happens to be uncommon! There are some who seem to flatly dismiss the idea as a non-starter. My own experience and WDC's use of I/O in zero-page (W65C134S) refute this.

Sure, I understand. But applications that seriously need the bit-banged SPI to be as fast as possible can gain a few percent by having a dedicated copy of the routine in-line where the "hot spot" occurs. Out of the many, many places in an application that you need to transmit a byte, probably only one is critical -- and it's a block move. (If the SPI is talking to a temperature sensor, you won't encounter this. But talking to an SD card or EEPROM you probably will.)

In the context of a max-performance block move, SEND_BYT would typically be embedded in a loop, with LDA (SrcBuffer),Y preceding it and INY / BNE following it -- all of that together would be the hot spot. The bracketing code adds about 10.5 cycles, which tends to "dilute" the 44% speedup I was crowing about. But, even so, the speedup is still 41%. IMO, speeding up a program's hot spot by 41% amply supports my assertion that this can make or break the viability of an application. (And it's not all about SPI. For another example, consider a bit-banged software UART that fails to achieve the requisite baud rate.)

Keep the idea in your bag of tricks. Someday you might surprise yourself and use it!

-- Jeff

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

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

No, not 5 -- each of us is including different stuff in the calculation. I think eliminating Y as the loop counter saves 9 cycles. We lose 8 DEY's (and save 16~) in the loop, but there are 9 shift operations, not 8, so the saving is diminished by 7~. (It'd only diminish 2~ if A weren't tied up and we could do the shifts there.)
Putting it that way isn't wrong, but seems to miss the point that I/O in zero-page is as beneficial as all the other tactics combined (except the fast but bloated 16-way-JMP version I mentioned).

However, I will admit wishing I'd chosen a slightly less sensational title for this topic. A speedup like 41% is "significant," or even "major," but not exactly "huge"!

Hmmm... could your SPI input routine benefit from special hardware, too? How does your machine presently read in MISO? Is it on VIA3PB?

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