Emulate an EPROM - How Hard Could it Be? 

Interrupt latency is the bane of my existence. Great video!

Designing state machines is mostly a lost art. I've designed dozens of them but that's because I'm older than dirt. I never got around to learning C because it was too slow and It didn't give me the control of the processor that I needed. That said, I really enjoyed vicariously experiencing your path of discovery. I remember the excitement I had when my TRS80 made my ASR33 print from the keyboard. Good job man!

Really liked every single moment in this video. Thank you for taking us on your journey of discovery. Super relevant to people's experiences, and (as you already know) way better than just jumping to the final solution.

I thought this was going to end up being sort of the inverse of using an EPROM as a programmable logic device, but then I realized you were wanting to type via the microcontroller rather than operate strictly as the character ROM. EPROMs as PLDs is a fun thing to experiment with because you have many inputs (address pins) and either 8 or 16 outputs (data).

I've played with the Pico PIOs and they're amazing. You can calculate the exact number of clock cycles for your code and get perfect timing. I'd love to see a PIO on the RPI5

I have seen a few projects where a similar thing was done as part of a larger project but with no details of how they did it. Thanks for all the info. I am just getting started in micro-controller communications and it really helps to see actual implementations. Wow do I have a lot to learn, just the jargon and acronyms make my head spin some times. Great video.

A Cortex M7 with its MSP (main stack pointer) pointing to DTCM, and the interrupt vector table and code in ITCM should be able to enter the interrupt handler within 12 cycles, but the M7 based MCUs are often lack single cycle GPIO access because of the bridges between AXI, AHB and APB matrices e.g. on the dual core STM32H7xx parts the slower M4 cores directly connected to the AHB matrices have lower GPIO access latency and can respond to interrupts in 12 cycles as well. Still the RP2040 is a great fit for your project and the PIO can should be able to perform address decoding for you like this. Wait for a valid address, shift it into the FIFO, have a DMA channel read from the FIFO into an other DMA channel configuration register and trigger that channel. This way the M0+ cores remain available and the Python overhead won't hurt your timing. To further improve latency you can make use of the two priority levels supported by the RP2040 bus matrix. That should be enough to emulate a ROM without jitter (as long as the ROM fits into SRAM). The PIO FIFO could also be polled from one of the ARM cores or raise a interrupt line on either ARM core to procedurally generate ROM content.

7:07 These small captures of time. Seeing your reaction made me emulate it. Gold. Literal Gold. This maybe the first video I’ve seen of yours. It’s these little moments, combined with your teaching capabilities that make me hit the like button. 👍 Key timing too. You just told me about your Jesus. 🙏

Thank you for figuring this out! I recently attempted to use my old commercial versions (Flexrom and EE08) and found they needed parallel ports and not PCI based ones, old school PIO based ones. So aside from digging out a 486 and setting up DOS I figured there was some product out there that now did this....and I was disappointed. The best I could find was a MCU based project that overcame your problem by loading some latches up (74374 or something) to hold the address (hi/lo) and data. I was kind of figuring that that access time (back in those days measured in hundreds of Nano seconds you be too fast for a modern high level language based MCU device? You saved me a pile of work! subbed and thumbs up!

Sweet shirt!!😉 Fun video!!! 🤓

Just before you started attempts I thought "this sounds like a perfect fit for the Pi Pico!"

The Pico PIOs look very, very interesting and promising to me since I've been trying to accomplish something very similar to what's being attempted in this video. I too ran into problems while trying to emulate EPROM for my Z80 project with an Arduino nano and then later with a RPi Pico. At first it seemed to me obvious to use interrupts to control the logic of my program (toggle the WAIT control signal, sample the address bus, check the control signals to determine whether an input or output operation was being executed, read or write data to the data bus and then continue). I managed to get some meaningful output results from the arduino and so decided to use something way faster like a RPi Pico. At the beginning I thought that a 125 MHz MCU could easily outpace a Z80 that was running at a ridiculously low speed of ~370 KHz. I was wrong. I ended up using external digital circuitry to make the Z80 wait in order to allow the Pico determine what to do.

You got another subscriber just by being very happy and almost red when laughing, I like when people celebrate little conquests and move on. ;D

What if you used native C of even Assembly in the Teensy? I found that’s the arduino abstraction is hellishly inefficient. Pi Pico is a graceful solution.

Nice Discovery 2 board! I had to buy the original Discovery 1 for classes and I still use mine (for scoping, supplying, and analyzing). While it isn't as good as something like a Keysight scope, I was still able to find an issue with an nRF dev board communicating with an ESP board by probing the serial lines.

That is pretty cool.

The RP2040 on the Pi Pico runs at 3.3V and has an absolute maximum I/O pin rating of VDD + 0.5V (so 3.8V here), but you seem to connect directly to the Apple bus running on 5V. Does the Pico pull down the bus high voltage, or have the ESD diodes in the RP2040 pins failed open?

Congratulation …. So cool.

cool @Baldengineer :)

That is a great "evil genius" laugh.

How hard could it be to do this with 555 timers instead?

Neat

I don't understand the level conversion in your project the pico is 3.3 volts and the apple is 5 volts. Why does the pico not blowup with the input signals from the apple ?

How does the power consumption compare to the Apple 2 circuit?

Could you have used an arduino and a 8 bit wide 3 state HC logic chip like a HC573 or HC4094? The apple is looking up a conversion table in the rom to go from keyboard matrix to ascii. Cant you just load a 573 with the value you wanted anyway for any keypress? It's the grabbing that needs to be short on time, not the loading. A 4094 would let you do it using only 3 i/o from the arduino.

Seems like a perfect use case for a psoc. You could make a fifo to store pressed keys in the programmable logic, and connect the fifo clkout to the read-enable.

Couldn't you achieve similar result with the Arduino by writing the code in super-loop? The AVR interrupts are rather slow...

yup defo more needed on PIO assembly on the Pico

Now, in all fairness, you're not really emulating an EPROM. You're emulating a keyboard decoder that happens to use an EPROM as a lookup table. I was somewhat surprised that after decades of huge improvement in hardware, it is still virtually impossible to emulate any form of random access memory of any decent size using programmable logic. We now have gigabytes on a micro SD card, but it all comes at a cost in the form of latency that one cannot afford when the requested data is required within tens of nanoseconds.

Why aren't you just using a 74HC541 buffer or something comparable? It has three-state outputs, so you could just wire whatever slow signal you want to set on the bus into its inputs, and let its output-enable pin react incredibly fast on the "bus enable" request.

What about a spin loop in the main code and avoid the ISR overhead?

Love it,but please make a tutorial on impedance

nice concept - but doesnt the pi pico have more processing power than the appleii anyway? seems a bit overkill using such a powerful processor to just run the keyboard

Of course he goes with the pi pico.The thing is a beast !

Not using the Arduino code libraries but programming the native MCU registers will speed things up. After that: assembly, which is basically what you ended up doing. Another favorite of mine is the PSoC5: an ARM core with programmable hardware and a cool IDE (windows). My usual take on emulating a ROM is replacing it by a RAM and get bus access to load it.

is it possible to clone commodore sound ic. chip? read and copy content and burn a new programmable ic

it would be interesting if you could, do this with every EPROM's and ROM's, e.g. using a Apple motherboard, but with all and every but with every EPROM's and ROM's emulated or simulated, maybe doing it as one chip at a time to the point there is no original apple parts left, except the motherborad and case? 😃

It still seems more straightforward to use a CPLD or FPGA. Will this work all the time (like not miss a character after days of typing for example)? Your project is impressive though.

When it comes to applications requiring quick and precise sub microsecond timing I tend to go for PIC microcontrollers. Even the DIP packaged 8 bit ones can give a very good response time to interrupts. It is best to use assembly language and access registers and stuff directly rather than a high level language though as the latter often has many overheads and also introduce many unknowns.

How about a cheap cpld or fpga? Would be great to see a follow up

if you emulate KB3600 can use arduino uno easily.

Is RPi Pico 5V tolerant?

Nice job but it seems like massive overkill. I have a handful of Apple II's and have wanted to do this and also map in some RAM with special functions. I will have to try. I thought an Arduino Nano at 20MHz might make it. I would never use interrupts for this. Just a branch. In fact I would unroll a loop as far as I can given memory available and branch back. Basically unroll in a loop. If that was not enough, an STM32F407 or a Blue Pill is next. I like ARM instruction sets and I would use MicroPython with its ability to inline assembly code. ESP32 is possible as well. Teensy 2 is worth a try.

Since when PiPico has 5V tolerant GPIOs?

how hard could it be to interface a 8bit ISA OPL2 soundcard from a arduino please

Nice! Although resorting to 600Mhz or 120Mhz+PIO chips to emulate a 37 years old 1Mhz Apple IIe chip seems kind of overkill. Almost kind of a fail, in a way… :-p Sure, the

Teensy 4 can clock up to 1ghz with cooling, 800mhz without so may bring the response times down somewhat

todays software is too fast for reverse engineering by hand with standard devices. it seems most of devices needs specific tools to decode or reverse engineer or track/debug they charatheristics syncronously. in old devices some mechanisms code can be seen even with barely looking at their workings. when i first saw arduinos . i tought they are ready to go reverse engineerint debugging system control tools for modern era devices but after lots of trys i realised their speed is not enough for debugging alive working systems ... atleast not online. but can be done by recording and analysing data offline. atleast in lots of cases .

It is not clear why you want to tinker with the "ROM" to insert other character than the one typed in, that could be done with software and it has been done with software, remember a baby behind the computer, typing random letters and ciphers and the outcome is a real text (that has been selected before). Then it looks like the child is very clever.

Could you have kept the Arduino and just stretched the ISR pulse using an R-C circuit?

Why not just use a microcontroller + a tristate latch, instead of forcing the microcontroller to keep up with the bus?

Anything that needs quick turn around will cause issues for this type of software. The best you can do is what he did, move from slow to fast. Then move from indirect to direct. Once multicore drives down area cost this will likely be the next area of concern. Note this assumes a high level of determinism. Teensy uses Cortex-M7 so there goes ISA improvement and moving to 1+ GHZ would likely have marginal gain. Another example of this that is challenging would be SPI EEPROM. The issue here is processing the command, address and data lookup quick enough for the next clock cycle. The gain moving from 16 to 600 is 37.5 (could be 150 is you consider ISA difference at 4 times), which is very good. However we will need more and there is a limit in practice to how high we can make this gain. So indirect solution has its limits for IO. Direct on the other hand has next to no limit. It could process this very quickly. However this is not very useful in all cases. Enter the problem that RP2040 has only scratched the surface of. How do we abstract or simplify direct solutions. This has been discussed since the 90s. Never really been economically possible. Not sure the RP2040 can process SPI EEPROM, but can resort replaying known data if access is predictable. Other than that you are left with redesigning the protocol. Software systems are basically memory, state machines, etc. just like hardware. Only difference is the delay, latency, efficiency, coefficient, etc. FPGA existing in between. This is a rabbit hole by itself.

Would the arduino not faster if used assembler code?

1 craft for you Make Cotten tinner fevicol 1st dry full, Cotton tinner White fabric color dry full. See that paper is getting wet or not All the best Then 1 broom 10 mud sag to grow potatoes or seed Earn Fidger and hair blower fan for water. Enjoy

Answer: 8:01

I did this a few months ago with a teensy.

How Hard Could it Be? That's what she said.

Try an FPGA or CPLD

But without keyboard how could you get there

A 2650 has a clock speed of 16Mhz which is not great for this application. Personally I would have used a 120Mhz Particle Photon or Argon MCU which is as easy to program (most Arduino code runs with few or no modifications) and almost 10x as fast - not a lot of price difference either and it has Wifi if you need it.

Your definition of easy is obviously not the same as mine...

Does anyone use Atmels anymore for anything? They're horribly slow pushing and popping all those registers on every interrupt (when programmed in C).

You look like rick from pawn stars

1234H is one two three four hex - it most certainly would not be one thousand two hundred and thirty four hex! One thousand two hundred and thirty four is a decimal! How hard can it be to correctly say a hexadecimal number? 😉

I think a bluepill will handle that no problem

Can't believe people are still using Python for microcontrollers. Such a slow, high-level language barely has any place on desktop, let alone tiny microcontrollers.

Неу! That is the crazy way to make your product "compatible" - when it is no need to do it, and it didn't make anything no easy or cheaper. It was great work... for nothing. Nothing at ALL. Use microcomputers to emulate keyboard chip for ultra OLD computer. Pi can emulate work of 200 such computers, 200 in same time.

I'm not surprised. Arduino is such bloat. Just ditch all arduino crap, write in normal assembly and you should be ok.