6502.org

How much trouble would it be to place an array of photodiodes on a PCB to be set down over a piece of paper that you could change out or modify as necessary?

Ooo! Nice idea, Mike! In particular, I like how "photodiode" begins with 'p,' thus conforming with the whimsical PPROM acronym!

Your idea would indeed be well suited to an application where the values must frequently be changed out or modified as necessary. Sadly -- because the photodiodes would be lotsa lolz to implement! -- the values turned out not to need much alteration other than for the initial setup.

At one point it did occur to me that the project could use a microprocessor, and could manage the 12-bit counting in software (along with the sequencing of machine operations). But, at the time, electrical noise in the industrial environment was a scary subject for me, and this concern undermined my confidence and swayed my decision making. RCA's 1802 -- a CMOS microprocessor -- was available back then, and would've been a step in the right direction, but that still left the problem of field alterable, non-volatile storage. The switch/diode ROM solved that problem; and so, for better or for worse, I ended up doing the 12-bit counting in hardware. Definitely a streak of the ridiculous, I'd say, but at least I got the project out the door. The thing saw years of service (and now the logic box adorns my living room).

-- Jeff

Hollerith and Jacquard high five while off to the side Babbage sulks.

Looking at a hypothetical SPI-in-glue-logic board -- with separate PISO and POSI shift registers, based on what is still available in DIP, with a counter to generate the SPI clock while stretching the CPU clock -- an SPI serial Flash "pseudo-ROM" loader could fit into a 4x8x8bit diode board.

The hypothetical board is set for two I/O pages at $0200-$03FF, so this basically places the bootloader code as far down in general RAM as possible, to allow for soft-ROM images of 8KB, 16KB or 32KB at the top of memory.
While I hadn't sketched it in yet, my idea was to have eight jumpers read in the I/O space with two jumpers selecting 4K, 8K, 16K and 32K second stage bootload and the next six jumpers selecting the address on 4K boundaries, with special handling of base address 0 to finish loading from the first 4K bank at $0400 for a menu based pseudo-ROM loader.

However, going down previous ROMless bootloader threads, as pretty as the Diode board it, I would actually be more inclined to set the board up to have a PIC16F57 stuff the 1st stage bootloader routine into RAM and then pulse /BUS_RESET to start the ball rolling, where in non-bootloader mode the PIC would bit bang the MOSI data out while a single 8bit SIPO would collect the MISO. I am thinking that putting a bus transceiver between the PIC data lines and the bus data lines simplifies things considerably in the "pre-boot" stage when feeding "LDA #code : STA $FFnn" instructions to the 6502, since the PIC would only output in the bootloader stage in single step mode, with the bus transceiver avoiding contention while writes would proceed without halting. The PIC16F57 doesn't have EEPROM storage, but hopefully 31 bytes doesn't use up too much program storage.

I had a further look at implementing an SPI interface for a 65xx bus system with 74' logic, and I suspect a circuit can be built around a 74x169 4 bit U/D binary counter, a 74x4094 parallel loadable octal SR for the MOSI byte out, and a 74x597 tri-state readable octal SR for the MISO byte in.

My thinking was to run the state machine with two /S /R latches built from each side of a quad 2-input NAND gate, labelled functionally below as SR0 and SR1, with SR0 generating a RDY hold and SR1 generating the load state for the counter and the MOSI shift register. The MISO shift register is a promiscuous serial input that will reflect the previous 8 bits of MISO data at the upward shift of the SPI serial CLK generated by the QA output of the 4bit counter: (1.1) /SR1_SET, /SR_MOSI_LD=/COUNT_LD=0=/SR1_Q
(1.2) /SR0_SET, CPU_RDY=0, /COUNT_ENT=/COUNT_ENP=1=SR0_Q
(2.1a) COUNT A..D=%0000 loaded
(2.1b) /QA rises, SR_MOSI loaded
(2.2) /SR1_RESET, /POSI_LD=/COUNT_LD=1
(3.1) QA rises, SOPI shifts MISO in
(4.1) /QA rises, POSI shifts Q6_n-1->Q7_n=>MOSI
(...) repeat 3.1 and 4.1 6 times
(17.1a) QA rises, SOPI shifts MISO in
(17.1b) /SR0_Reset = /CNT pulses, RDY=1
(17.1c) /COUNT_ENT=/COUNT_ENP=0=SR0_Q, Counter holds QA=1
(17.2) RDY=0 CPU state lasts until first PHI2 drop.
(18.1) Following instruction executes

I believe I may have sorted out a scheme that supports the following 1st stage bootloader, where the reading of the jumpers at the end of the code also toggles out the /RD signal going to the /DIODE board and toggles on the /RD going to the SRAM & I/O, so that the 2nd stage bootloader code loaded to $FF04-$FFFF needs to have a BRK address of $FF04 and a BRK or JMP opcode in the byte before the BRK/IRQ vector ... the BRK and BRK vector shown in the code is a pantomine, as the DIODE would no longer be providing the program source at that point:
One advantage of a circuit made of 74' IC's and some odds and ends is the ability to set things up on a breadboard with switches, LEDs and a visibly slow clock circuit to see if if it's working as hoped. If I can get the SPI circuit up and running on a breadboard this fall, I'll see about getting some open source circuit simulator tools on my mini-PC at that site so I can post the circuit properly.

It's getting silly... now it goes to 128 bytes, and it's selectable as to whether it's the upper or lower half of a page. Double sided board, components on both sides - potentially 1024 diodes though that would be a bit silly.

I don't see this as a production part; it's a 'get me started with no external hardware' block. Perhaps an LED and keypad SBC with an EEPROM which can be written to and a mechanism to block the top page (for the reset) and perhaps the zero page too (to avoid as many 3-byte instructions as possible).

It occurs to me that a _very_ simple manual code loader could just fit in 128 bytes, with a bit of luck... I'll think about that. Something that presents a default address ($0200 would be handy) and accepts keypresses to load a hex value; an enter key to store the value and a go key to start at the default address. If the code thus written can write to the eeprom, we're laughing; if not, keep this bootstrap rom in place and try again.

Here's a render (the other side is almost identical but covers the lower addresses): We have discussed various boot proposals many time but I don't know if we have a definitive list anywhere. I think this is the only one that requires no external hardware (other than a soldering iron and a pile of diodes!).

Neil

p.s. one of my BBC colleagues may have access to the details of a diode-rom caption generator - punch tape to video output, all in TTL.
p.p.s. Paleolithic: definitely old stone age here.

I think this diode matrix has an application in Z80-RC2014 world as a 50mmX100mm bootstrap board with 32 bytes of program to boot a CF disk. Arguably CF disk is a programmable device, but in RC2014 world it is well known and there are various PC tools to program it. I can see people having a RC2014 system including a CF disk but want to reprogram its EPROM. A diode matrix RC2014 board can provide an alternative to EPROM programmer. It will be fun to build, too. When I have more time in a month or two, I’ll see if I can design such a board.
Bill

Yes ... and when the basic circuit is confirmed working, replace that with a very slow RC / Schmitt-Trigger clock that flashes an LED at a human visible pace, and a debounced "/Reset" contact switch to trigger the SPI cycle.

Since storing to an SPI serial flash is just a series of SPI bytes, add eight non-debounced toggle switches or push buttons and that's a manual serial SPI flash programmer to boostrap a micro-monitor as the boostrap 2nd stage bootloader.

The micro-monitor can then be used to write a fuller fledged monitor on the board using whatever its normal terminal I/O happens to be.

The micro-monitor I/O might be a UART to a terminal ... if it can be fit in ... it might be an SPI 32x4 text display and a 20 key keypad of hex characters plus keys that can act as return, space, '-' (ie, rubout) & ".":

<aaaa><CR>
* display the eight bytes starting at the given address on current line, begin next line with <aaaa+8>
<aaaa> 00 00 00 00 00 00 00 00 <CR>
* write up to eight bytes starting at the given address, begin next line with <aaaa+8>.
-<CR>
* blank the current line.
<aaaa>.
* jump to the given address and, on return (if returning), display 0000 & the first eight bytes in zero page.

... and the micro-monitor takes its four actions based on the last byte of the line when <CR> is hit being <space>, '-', '.', or something else.

In Tiny68K I used a state machine to load AT24C256 serial EEPROM into low 32K of memory and released 68000 to run. The state machine is in CPLD and is fairly simple, I recall. It has been 8 years, so I need to refresh my memory, but the state machine may be simple enough to implement in 74xx.
Bill

Yes, but even if I succeed in putting some simple hardware together, I'll still be a software hand at heart, and so having a 65xx CPU as part of the state machine by executing 65xx code on the Diode board is a satisfying approach to me.

To make it mostly circuit board and glue logic, the board I've been sketching around the SPI circuit is built around a triple 3-input OR and hex inverter, to get to the SRAM0 high, IO low logic in a two deep logic ladder:

6NOT:
1A <= BUS_PHI2
1Y => !PHI2
2A <= BUS_A11
2Y => !A11

3OR:
1A <= BUS_A15
1B <= BUS_A14
1C <= BUS_A13
1Y => 2A

2A <= 1Y
2B <= BUS_A12
2B <= NOT_2Y = !A11
2Y => SRAM0_CE1/IO

And a 64KB UM61512A pull with a CE1 and /CE2 to qualify to phase 2 with the !PHI2 signal.

So the memory map would be:
$0000 ZP
$0100 Stack Page
$0200-$03FF Golden RAM
$0400-$07FF 1KB Buffer
$0800-$09FF /IO1, 3 CE1 /CE2 devices with up to 64 registers on bits 9, 8 or else 7 high, and a %00000100.00xxxxxx latch enable line for up to six latches / jumpers (more than one each requires another 74' quad AND).
$0A00-$0BFF /SPI, with MOSI written on $0A00{*}, MISO read with any read in the /SPI space, and the SPI latch with 7 selects and a Mode0_Reset bit written with any /SPI address with bit0=1.
. {* Or indeed, any address inside /SPI with bit0=0}
$0C00-$0FFF reserved for a second SRAM1 for a RAMdisk.
$1000-$FFFF RAM, with a soft-ROM variably at $8000-$FFFF, $C000-$FFFF or $E000-$FFFF.

After the Hex inverter and triple 3-OR logic, the idiosyncratic partially-decoded, partially-undecoded, partially address-as-data I/O is driven in part by what logic gates were left free after the SPI circuit, SRAM0/IO select, /BUS_RESET debouncing and DIODE/MAIN toggle of the /SRAM_RD and /DIODE_RD lines. I'd be skeptical it could be made to run much faster than 8MHz unless all of the logic other than the Schmitt-Trigger NAND is 74ACT family logic.

But, OTOH, I'm not a hardware hand, so if it could run at 4MHz, I would still be well pleased.

The SPI latch Address-as-data is specifically to get the 1st stage bootloader to fit inside 32 bytes, including actual /RESET vector and under-written /BRK vector. The magical appeal of hardware circuitry to a software hand is trying to work out something to make the code more clock cycle efficient and space efficient at the same time.

For instance, the MOSI read -- and driving the actual SPI transaction -- on SPI_address+%x.xxxxxxx0, SPI /SS latch loaded from address lines by any /SPI access, read or write, on SPI_address+%s.ssssssr1, and MISO Read on any read within /SPI, allows SPI devices that rely on selecting the device, putting in a 16bit word and retrieving a byte response in the 2nd byte, and de-selecting the device, to be served efficiently with:
... which doesn't work for /SS0, which is address $0AFF, but /SS0 is intended to be the SPI serial flash, which does not tend to work with two byte packets, so that's not a binding constraint.

With a longer piece of paper you could move it over a handful of diodes to import larger data.

(I should try this again now that I'm a bit more seasoned, rather than building a paper tape reader as my first ever mechatronics project)

Welp, that was fun... I discovered that I'd used the wrong footprint for 1024 diodes; the right footprint (SOD123) is somewhat fatter and necessitated a complete board respin

But at least this one is easier to solder... Neil

Sadly, it turns out that using leaded components and plated through holes, there's only room for sixty-four bytes. And even then, I had to upset every rule the PCB program had, and alternate the alignment of the diodes (they all point south). It has a certain elegance, though...

Neil