Disabling the system while flashing

[speculatrix]

Michael wrote:

I'm sure you could make that work if the uC is fast enough.

My current candidate is the STM32H523CE, which can rattle along at 250MHz, has plenty of flash storage to hold the ROM image and enough GPIOs to handle both buses and the control signals with some left over. It’s also small enough that I reckon I can fit it within the footprint of an AT28C256 EEPROM. That’s even with headers in place to reflash it in circuit.

[DavidL]

speculatrix wrote:

Michael wrote:

I'm sure you could make that work if the uC is fast enough.

My current candidate is the STM32H523CE, which can rattle along at 250MHz, has plenty of flash storage to hold the ROM image and enough GPIOs to handle both buses and the control signals with some left over. It’s also small enough that I reckon I can fit it within the footprint of an AT28C256 EEPROM. That’s even with headers in place to reflash it in circuit.

Maybe, but only maybe. The ARM cores are heavily dependent on their caches for their performance and the cores are pipelined. Both of those contribute to a general lack of determinism so the "handle both buses and the control signals" might end up being quite a challenge. Definitely let us know how it goes!

[BigEd]

The Raspberry Pi Pico is a deterministic ARM and can certainly keep up with a bus running at 2MHz, probably rather faster, with careful low-level programming.
https://github.com/dp111/PicoTube

Likewise the Teensy has a deterministic ARM on it.

By deterministic I mean a simple enough machine that you can cycle count, and you don't have cache misses to worry about.

[speculatrix]

Instruction and data caches can be turned off on the STM32. And there might not be much of it going on. The program is going to be extremely simple:

* Check if /OE is low.
* If it is, get the address from the address port pins
* Put the relevant byte on the data pins
* Wait for /OE to go high
* Rinse and repeat.

There's no interacting with external devices, like SPI, I2C, UART or whatever. It's all GPIO based.

[speculatrix]

Oh, and I've just learned that STM does a middleware package called X-Cube-EEPROM that looks like it does exactly what I want, although this learning curve is rapidly getting steeper!

[barnacle]

It's tempting to use interrupts to recognise the ~we signal going low, but it's often a bad idea; the interrupt latency on STM ARM parts can be horribly long. At least looping while waiting has a reasonably constant response time. For the faster STM32 running at 250MHz that might not be an issue...

Neil

[barnacle]

Hmm... looking at the application note, it seems the access time is very slow. I've not yet read it all, but in parallel mode it appears that reads are on the order of 6 to 600us, while parallel eeprom is easily in the 70ns range (and parallel flash at five or six times faster). That might be a show stopper...

I wonder if we're approaching using ram as fast eeprom emulation, and just blowing an eeprom once reasonably certain things are working? (I still want an affordable eeprom with both serial and parallel interface!)

Neil

[barnacle]

Thinking further about this, many of the STM parts have enough pins to represent an actual eeprom part; with an adequately fast part with sufficient RAM - many are 20kB or better - one might use the RAM for emulation and write to that ram via an external link (e.g. a nucleo board provides in circuit programming over USB) though you'd need to write some code for the STM. And possibly a PC.

Similarly, the PI micro (whatever it's called) has fast access to a data bus, though I'm not certain yet how to do it.

Neil

[gfoot]

I used a Teensy (3.5 I think - as the newer ones were not 5V-tolerant) as a bus analyser a few years ago, from memory it had over 30 pins with through-hole mounts and maybe 10-20 additional pads you could also connect if you had the patience to solder wires onto them. I think it worked well for sampling the 6502 bus at 2MHz, maybe 4MHz, but not faster than that. It was quite pleasant to set up and use - the GPIO was very logical and I think you could easily set/read large chunks of pins with single instructions - which sounds obvious, but I've always found that annoyingly awkward on Arduinos.

It is old now though so probably not a good choice any more, and with the newer ones not being 5V-tolerant they'd probably only be practical in 3.3V systems.

[BigDumbDinosaur]

barnacle wrote:

Hmm... looking at the application note, it seems the access time is very slow.  I've not yet read it all, but in parallel mode it appears that reads are on the order of 6 to 600us, while parallel eeprom is easily in the 70ns range (and parallel flash at five or six times faster).  That might be a show stopper...

As I opined a few posts back... 

An in-circuit ROM emulator fashioned from a µcontroller that can be plugged into the ROM’s socket for use as a development tool makes sense to me—it beats wearing out the socket.    However, given that 55ns flash ROM is readily available, it seems it would take a mighty fast µcontroller to act as a ROM and keep up with a 65xx system running at double-digit clock rates.

Jus’ sayin... 

39sf0x0_flash_microchip.pdf

39SF0X0 55- & 70 Nsec Flash

(3.11 MiB) Downloaded 45 times

[speculatrix]

barnacle wrote:

Thinking further about this, many of the STM parts have enough pins to represent an actual eeprom part; with an adequately fast part with sufficient RAM - many are 20kB or better - one might use the RAM for emulation and write to that ram via an external link (e.g. a nucleo board provides in circuit programming over USB) though you'd need to write some code for the STM. And possibly a PC.

The STM32 I'm looking at has 272K of RAM, and it's possible to configure it so that everything runs from RAM (which avoids flash fetch delays and cache issues). The contents get copied to RAM on boot-up.

[plasmo]

If you want to run 6502 double digit fast, you may want to consider small ROM in fast programmable logic that contains enough code to load larger program into RAM from a serial port then page itself out of the memory map. A 22V10 can do that.
Bill

[Michael]

Cool idea. Is there enough space in a 22V10 for code to support reading a serial EEPROM?

[plasmo]

You can put roughly 50 bytes of instructions in a 22V10. It is highly dependent on the patterns of instructions, however. A small instruction change can reduce or increase the total number of instructions, so the best test is just try it.
Bill