So, all the talk on the new board, and it's in built limits, made my eye wander over to the W65C265SXB.

This is essentially the same thing, with a better header, 32K of RAM and a 128K Flash PLCC socket. It's also distinct in that I guess you can plug in a raw USB cable and talk to it serially, whereas with the smaller board, it just exposes the raw serial signals, and you'd need an FTDI empowered cable to talk to it.

Looking around a bit, and I found this family of flash chips:

http://ww1.microchip.com/downloads/en/D ... 05022C.pdf

Do you think it would be possible to program that on the board? That is, plug in the chip, load some code from the monitor, and be able to program it in place?

I ask because I saw some other chips, and they seemed to require 12v to program, but it doesn't look like that's the case with this one. But I'm not sure if the CE, OE, and WE signals would be correct, as those are driven by the CPU. The same signals go to the RAM. Is that just a normal write operation, nothing special? To write a byte you write several bytes to the chip, to certain addresses in a certain order, and then the address and byte you want to store, and then wait for it to happen.

Is programming it in place a smart idea? I might be worried about "bricking" it by writing a bad program to the flash -- just enough to convince the CPU that there's something there (in the sense that it sees WDC at $00:8000 and jump to $00:8003), but buggy to the point where I never get control back (without yanking the Flash out). So, as long as it's in the socket, the board can't reprogram it. I don't think there's a away to make the board ignore the ROM if its in place.

In that case, it seems straightforward enough to be able to craft a simple programmer with little more than a socket and a bread board, map it in to another section of the memory space, and use that.

Any of this make sense?

Yes, these are a common type of flash devices. I've used them several times. As long as you have all the read/write/select signals attached, it's a matter of writing the appropriate code sequences to write a byte or erase a sector.

The flash is divided into 4kB sectors, so what you could do to minimize the chance of bricking is put a secondary bootloader in the first sector, and never overwrite it. The secondary bootloader would then a) verify that main program in second sector is in good shape, and b) checks I/O line for override signal. If the override signal is set, it would not jump into the main program, but enter a monitor mode where you'll be able to fix the flash.

Another trick I've used to unbrick a flash like that is to short circuit a few data pins with a small screwdriver while booting up so that the signature bytes don't match. Most devices can handle a brief short like that.

Hehe - tricky

In case of the W65C265SXB there are P43 and P44 attached to A15 and A16 of the Flash. Both select lines have a test pad on board (located between the MCU and U5). Grounding one of them briefly during reset should work as well.

Sadly WDC has made no provisions to access pins 1 and 30 of the Flash. This prevents using F020 or F040 devices

My SXB hacker program allows you to program the flash in place on this board. The source code is on git hub.
https://github.com/andrew-jacobs/w65c265sxb-hacker

_________________
Andrew Jacobs
6502 & PIC Stuff - http://www.obelisk.me.uk/
Cross-Platform 6502/65C02/65816 Macro Assembler - http://www.obelisk.me.uk/dev65/
Open Source Projects - https://github.com/andrew-jacobs

Ok, yea, that makes sense. Maintain a trusted bootloader, stage the boot, and then add a jumper that can be last resort checked to abort the flash startup. That's a good idea.