Emulate an EPROM - How Hard Could it Be? -- Episode 517

That's great. Except, I can't rely on polling the "OUTPUT ENABLE" signal if the microcontroller is going to do anything else (like interface to a keyboard.)

I need an interrupt. The AVR datasheet says:

The interrupt execution response for all the enabled AVR interrupts is five clock cycles minimum.
After five clock cycles the program vector address for the actual interrupt handling routine is executed.
During these five clock cycle period, the Program Counter is pushed onto the Stack. The
vector is normally a jump to the interrupt routine, and this jump takes three clock cycles. If an
interrupt occurs during execution of a multi-cycle instruction, this instruction is completed before
the interrupt is served.

There is a minimum of 5 clocks (312 nanoseconds) and up to 8 clocks (500 nanoseconds) as a MINIMUM latency. That's assuming the processor can even start servicing the interrupt on the next clock. So at a MINIMUM, it will take longer to get into an ISR than I have to service it. And even if I could get into the ISR within the 5 clocks, I only have 3 single-cycle instructions left (at best) to do something.

Yes, I could get into the ISR faster without the Arduino library. (Which then means I have to write *everything* from scratch. Wow.) And even if I did that, it still IS NOT FAST ENOUGH.

So, none of your math on how fast you can toggle a pin matters.

See MY point?

interrupts create latency, required for multitasking.
500ns requires 2MHz
https://www.unitjuggler.com/convert-frequency-from-ns(p)-to-Hz.html?val=500

AVR has 16MHz XO standard,
most AVR instructions have 2 clocks per cicle... some 3, some 4,
but can be overclocked to 20MHz "most people do, in complex projects."

...
AVR has a 8 clocks available "heardroom" at 16Mhz and 500ns,
see my point? very confusing...

No, it has nothing to do with the Arduino library (it isn't a language) nor how fast you can directly read/write the GPIO pins.

The fundamental problem is that it takes a minimum of 1.5 microseconds for an AVR to respond to an interrupt. In the case of the Apple IIe's keyboard access, we have less than 500 nanoseconds to respond and output a value. (And then less than 10ns to get back off the bus.)

The best case for an AVR is 1.5 microseconds. The Arduino library adds about another microsecond of overhead.

i don't understand your projects, too over-simplified for a begginer ...

I'm sorry you feel that way. But the point of this video was not to explain the entire project. The point was to show the steps I went through to solve one specific problem of a much larger project.

Arduino is a High Level Lenguaje,
but AVR allows to write directly to pins at MHz / 2 speeds "ultra fast".

it seems very strange when you say AVR is Not fast enoigh...
if you only want to create a Keyboard translator with LUT.
also AVR has EPROM, RAM, and Flash Memory,even more confusing..

There are many projects usign HW card readers to automatically type passwords on a keybaord, and stuff...

i don't understand your projects, too over-simplified for a begginer...
your audience has developed Telepathy.

Finally had the chance to watch this. Very cool. Love how you incorporated your live reaction to it working also. It's a very relatable feeling after you've worked so hard at something for it to finally work.

I think so. There are a couple of microcontrollers with a similar feature or capability. Each vendor calls it something else.

The unique combination here was the support in CircuitPython. Being able to write a string and hit ctrl-s was what swayed me in this direction. In the final project, I am programming the RP2040 with C instead of CircuitPython.

But what a great way to quickly prototype a concept.

Good episode.

When I worked with the early micro-processors, I always spent a lot of time doing timing analysis, especially when connecting other components to them.

I did wonder if you could have used a PSOC to do the same task.

DAB

We need a separate gauge for fun. I considered it easy because I really enjoyed writing the assembly code.

There are only 9 instructions, but they are very powerful. So it was like solving a jigsaw puzzle with massive pieces.

you call that easy???

Thats alot of work with some tight thinking here, I'm sure it would be a lot harder for me.

Now I need to get into how to use these PIOs of the RP2040....

Related Live Streams

Check out these live streams for even more details on how I figured out the EPROM stuff. These are all part of an ongoing live stream series where I am designing a mini Apple IIe using the MEGA-II chip from an Apple IIgs. (No FPGAs!)

Part 11

Apple IIe Keyboard Emulators

This stream is KiCad heavy. You can see how I designed the interposer PCB. This PCB is how I probed the EPROM while in a real Apple IIe AND how I injected the signals with the Pi Pico.

Part 12

First Attempt with Mega 2560

For this stream, I tried using an interrupt on a Mega 2560. However, you can see the measurements I did which showed the ISR took WAY too long to respond to the Output Enable signal.

Part 13

Deep dive on Pi Pico PIO programming

Most of the stream was spent learning how to program the programmable IO modules (PIO) on the RP2040. If you want to see how the assembly language works, check out this one. Also, there are lots of fun oscilloscope shots here.

Part 14

Qualified Success!

Off-line, I re-wrote the assembly code to better emulate the EPROM behavior. So in this stream, we plugged the Pico into the EPROM socket with fly wires and got it to "Type" on the Apple IIe. I didn't have emulation of the control signals to the IO controller emulated yet, so I had to still type on the "real" keyboard. However, the Pi was what provided the data to the IIe's data bus! So, SUCCESS!