6502.org

A segment of a spreadsheet that converts assembly code into diode patterns (diodes required where zeros are wanted). To my surprise, it needs 592 diodes, probably because of all the zero page addressing references.

(The code starts at $90).

Neil

You could save some soldering by using ZP addresses with lots of ones for: For example, I think there are nine references to memptr / memptr+1. Just moving that from 08/09 to FE/FF would save soldering 54 diodes.

This is a very different slant on code optimization. Minimizing the number of zeros rather than minimizing the number of bytes.

Dave

Excellent point!

Zero page addressing doesn't intrinsically use more 0's unless treating kernel code like application code and starting its allocation from $0000.

I had leds at $FA and memptr at $F8 ... and then realized that for patching to be able to use all eight leds, leds ought to occupy eight bytes even if only six are used ... but yes, since memptr is used more, memptr at $fe and leds at $f6 is %11111110 and %11110110, which helps reduces the zeros. The temp is at $f5, %11110101.

So putting memptr at $FE rather than at $02 saves 6 diodes per use (7 versus 1), and putting memptr+1 at $FF rather than at $03 also saves 6 diodes per use (6 versus 0). If "leds" appears three times, putting leds at $f6 rather than at $08 saves 5 diodes per use, or 15 total.

I put the segment table at the end of the DROM code, right before the RESET vector, for greater ease in later patching when copying into EEPROM, but $ffec is %11111111 %11101100, which increases the ones in reading the segments table, and then "to_leds", which is called three times, can be at FFD3, which is %11111111 %11010011. So those are two words used I think five times total with only three zeroes per word.

Leaving the segment table at the original $FF80 makes it %11111111 %10000000, for 7 0's for a word that I believe appears twice, costing 8 more diodes than my location for the segment table.

So even setting aside the patching issue, it optimizes the hardware to put the segment table right below the RESET vector.

Well, I could save even more simply by using inverting buffers on the DROM: that would require diodes where a one is required, so I'd need 1024 - 592 = 432, an immediate saving of 160, but I've already got the parts order running and I'm not starting another

As pointed out above, the issue isn't zero page per se, it's references to constant locations with lots of zeros in them...

Neil

So, the following changes

• move LED_PATTERNS to $ffec
• move temp, leds, and mem_ptr to start at $f5
• move keys to $97ff (incomplete memory decoding!)
• move led_addr to $9ff8 (again)

gets the diode count down to 463!

I think I can live with that

Neil

Rats, I laid an egg...

The EEPROM requires specific writes to (its memory space) $5555 and $2AAA in order to enable and disable its software write protection. Unfortunately, only the first half of it is visible in the processor space, mapped to $C000-$FFFF... which means a locked part can't be unlocked by software on Mesolithic. The A14 pin is tied to ground.

Not an issue with a new part; they're delivered unlocked and one would simply not be able to lock them. But the parts from the bay... they seem to be used, locked, pulls from scrap boards, and they would be no use.

The software chip erase process uses the same addresses, _and_ leaves the software lock unchanged, so that's no help!

Hmmm.

Neil

Are there still four unused /IO selects in $Axxx?

One strategy would seem to be to change /romsel so that a write into one of the free $Axxx /IO ... specifically the one that includes $AAAA ... also triggers /romselect, so that A14 will be low while ROM is selected when writing into that specific range.

Another would be to use an /S /R latch for one of the EEPROM address lines that is put into /Reset state by /Reset and one of the free $Axxx /IO selects and put into /Set state by another one of the free $Axxx /IO selects, putting /Q into EEPROM A14.

That's my thought; as the boards are on the way I don't want to respin them again; ideally something that can be bodge wired...

AND the existing ~romsel and ~a000-a7ff (well, nand and invert) to provide a new shiny ~romsel.
Invert ~a000-a7ff and use that to drive A14 on the eeprom.

That uses the last three remaining gates on the board, so could be bodged - if I got the logic right. It doesn't need to read from those addresses, just write.

So the mapping would be:
2AAA (in the eeprom) would live at EAAA
5555 (in the eeprom) would live at A555

Neil

Would it work to tie the A14 input to the A12 input?

I don't think so; it needs to be able to read the whole of the bottom half of the eeprom (i.e. A14 low) at $c000 (i.e. A14 and A15 both high)... oh, wait, you're thinking to view it in four non-contiguous chunks? That's sneaky... thinking.

Neil

Tying two address inputs together does halve the capacity, but it allows for easy lock/unlock. Maybe a tradeoff.

That looks as if it might work... it would map the internal addresses
0000 to C000
5000 to D000
2000 to E000
7000 to F000
Which would allow access to the magic addresses at EAAA (for 2AAA) and D555 (for 5555).

It might make it interesting to program the eeprom externally, mind, but the process might be to lift the leg of A14 (pin 1) and attach it to A12 (pin 2) to allow erase, lock, and unlock, and to attach it to GND to use as normal. That would allow normal external programming with no special requirements (except to offset the code to live at $C000) and yet still allow the special functions with just a stroke of the soldering iron.

I don't think it halves the capacity, particularly if it's a one-off change and then back to normal. We're already only using half the capacity by tying A14 low.

Thanks, Ed. Please accept a virtual (and virtuous) cookie for the suggestion!

Neil

If it's intended as a trainer, then could that special mode to erase / lock / unlock be done with a jumper in future board design?

I don't see why not. The reason I'm concerned about is not when it's made with new eeproms - they're delivered unlocked - but to avoid surprises when someone gets a locked second hand part.

A three-pin header would do the job.

Neil

Indeed, given the time investment to get an EEPROM populated by punching code in (as opposed to the USB to serial cable from a computer approach), some might like to lock one or more of their EEPROM's to avoid erasing the wrong one.