If you locate the magic 'WDC' string at one of the locations the boot ROM checks, either in an external ROM or boot loaded RAM, you can take control and disable the internal ROM completely. I seem to remember that the i/o page can be disabled too.

_________________
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

The problem is that the chip is over 20 years old, and the space has moved dramatically since then. (Now I don't know the actual chip history, but the monitor listing for the peripherals on the chip is copyrighted '94 and '95, so that's where I get "20 years" from.)

The ROM is not a problem. You can get around it two different ways. One through hardware (using the BE and RDY lines), and one through software using the WDC out at $00:8000 and $00:0800. Using the BE/RDY lines, the busses are all exposed including the RESET vectors, like a normal CPU. At which point you have full control and can configure it however you want as if the ROM is not there.

The XB board is a 5 chip system including the USB -> Serial chip, 32K RAM chip, Flash ROM (as a socket, writable by the MCU), MCU, and a NAND gate. You can bump the 32K up to "a lot" (a 1MB chip, a 512K chip) and get more memory. Dump the USB and it's 4 chips.

You still have several UARTs, a couple of Parallel ports, and a bunch of timers and other stuff with that.

Something I never noticed before, particularly concerning the other threads going on right now about variable clocks and wait states.

The '265S use 2 clocks: the 32K slow clock and the system (XXMhz) Fast Clock. But, internally, it has the ability to drop the Fast Clock to 25% (Fast Clock/4). You can set that system wide by toggling a bit, but you can also qualify the CS lines so that when the MCU fires a particular CS line, it'll drop it just for that, transparently, and automatically. So, you can readily map ROM and/or I/O to a slower clock. Didn't realize it had that, and that's pretty neat.

Which brings up with all of the other decoding and stuff they've done on this thing, the idea that you need to still qualify WEB and PHI2 (which is what the NAND gate is for) kind of boggles the mind. I guess they ran out of pins on the 84 pin package.

I was looking at the PIB, their Parallel Interface Bus, considering the stuff I've been thinking on recently. And discovered that it has ready interrupts built in to the PIB ports. Basically, when you write a value, the chip will trigger automatically handshake with the co-processor. Similarly for when it receives a byte. An interrupt will fire.

The PIB is badly documented, but seems to be an interesting facility.

The 134XB has a serial token network protocol built in to it (but not SIP or I2C).

Which goes back to it would be nice for them update this chip. It's seems very CISC like in its capabilities. For those place where it fits it can be a really good fit, but it's not very orthogonal. If it doesn't fit, then back to the drawing board with the '816. But still seems like a pretty usable chip.

Revisit the core, add a couple modern accouterments. Imagine a smaller version with several channels of SIP, driven by a tunable clock (ideally faster than the CPU rate), since many SIP devices can SIP at several MHz. If you want Parallel ports, use a plethora of SIP devices to expand them out, you can SIP faster than the CPU. If the SIP clock is 8x the CPU clock, then a "single cycle" write is (almost) as fast as parallel anyway.

On the other hand, the 265s may well just be an example WDC uses showing what you can do with an '816 core. The 265s is not a replacement for the '816, minimally it has a boatload more interrupt vectors, and the common system ones (RESET, IRQ, etc.) are not in the same places as they are on the '816. But you can see WDC holding the chip up as a showcase to designers "see what you can do with our core, you can make things like this".