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!
c is fast . depending on how you use it. its much like a assembly libraries collection. it has lots of prewritten assembly codes embeded inside. the reason its slow in lots of cases is because of programmers lazyness and control codes used thats necessary for uninformed programmers probable errors going to happen. you can skip the slow libraries/codes used with your own ones whenewer you want. c is technically collection of code. actually today gcc has them all. and you can access the some features from allmost any language. and it simply links to relative ones from whichewer language you use :P atleast most of the times it seems .
C is ok for slow logic stuff if used right. You will not have feeling of "loosing control" if that's calling C from asm and not reverse. arduino is kinda opposite of how it should be.
@@ahmetmutlu348 You are most likely right. But there's a limit to the number of systems I can learn and still be proficient at them. I don't code every day so I"m "good enough". C seems to be really good if you want to be able to move programs from system to system. State machines beat everything if speed is essential . 74s02 can make a decision in as little as 1.5ns.
Most of the rest of your comment is fine, and I love the low level development. Doing a bit of assembly here and there, C and C++ is what I work with most. But "Designing state machines is mostly a lost art" isnt entirely true. working with assembly for whole projects probably is getting a art style (some still use it, for the art factor). but state machines are still everywhere. Even in modern video-games, people use state-machines for various tasks or objects to be in. That awesome multi capable object that moves across networks? it might be in a certain state and the programmer dint fully understand object orientated programming at all. Anyway, its a great video and somehow I feel a but dirty thinking I can only use modern MCU for debugging older hardware... there must be a way to use a older z80 sbc for this... probably with state machines, ttl logic and assembler XD. inline assembly
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'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 really want to play with these now but how many pins can they do? Teensy barely has enough pins for a 28 pin eeprom..while I have gotten it going fast enough I haven't succeeded in merging the address and data pins on the teensy side
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.
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.
Not even sure it is an Arduino problem. GCC does unnecessary register pushes in ISRs, unless they are declared "naked" and you do the housekeeping yourself.
Yes, AVRs can run really fast if you use C to manipulate registers directly, and it gets even faster using Assembly. But, if i understood everything correctly, the atmega2560 runs at 16MHz. One clock cycle therefore lasts 62.5 ns. And the datasheet says (page 18): "The interrupt execution response for all the enabled AVR interrupts is five clock cycles minimum". The resulting 312.5 ns for 5 clock cycles would still be too long if even the 180 ns of the Teensy were to long (3:55). (A second pair of eyes to check this information is very welcome :) )
The teensy can emulate a 70ns eeprom fine. I've done it. Took me like 2 weeks with a scope to get the ISR response quick enough. Basically got it down to 20ns to flip a pin. And I had to overclock a bit.
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).
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?
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. 🙏
I want to start a Tech Hangout. Working only with what God provides through his beautiful people. Re-purposed E-Waste. Equipment, Hobbyist Things. Anything to give the young ones another option besides drugs and trouble. Unfortunately we see less and less fun and more trouble in my little community. I keep an open mind and teach from my mistakes. Sounds simple but we all know it’s very complex at the same time. Love and light. God Bless.
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!
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.
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.
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.
Indeed. That way the Arduino could run in "loop over input buffer: set outputs, trigger key-pressed signal, wait for enable pin to toggle, repeat" with no speed issues.
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 ?
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
the pico or a similar microcontroller can in fact emulate the Apple2 perfectly. The ESP32 is able to generate video, read a PS2 keyboard , read emails, and emulate the Apple2 at the same time !
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.
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.
I was thinking the exact same thing. The only thing that needs to be fast is the tri-state enable, so stick that in hardware instead of trying to emulate it in software. That said, it is interesting to see that the Pi Pico can be quick enough to do the job in software, which is kinda cool.
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.
FPGA would be overkill for this application. Maybe a CPLD but in general an MCU will be cheaper and easier to program even though it is inherently far more complex than a CPLD. A low end 8 bit MCU is perfectly capable of handling this level of latency requirement if programmed efficiently in assembly
@@listerdave1240 Micros are generally much cheaper of course, and are generally easier to program, but if you looked at the jitter of your assembler routine in terms of input vs output, and plotted that as a histogram, you would see that the CPLD/FPGA will be much tighter. For this application, there are lots of alternatives. For others, the extra jitter is a ghost in the machine that may show up occasionally. I program both microcontrollers and FPGAs.. Both have their place. I have a lot of experience with pulse generators and sequencers and precision timing. Cheap FPGAs give me sub-nanosecond resolution. All the same , microcontrollers keep on getting better and cheaper for what you get.
@@2jpu524 Sure and in fact I do use FPGAs where I need that sort of resolution. My point is that the particular application presented in this video is nowhere near needing anything of that sort and can very easily be done with a very cheap MCU and a few lines of assembly code or even C. Jitter would only be an issue if the MCU is doing other stuff apart from the simple task presented here, which in the case of Arduino would be going on even if you didn't ask it to - even something as simple as updating the millis() counter could interfere. With the PIC IDE there are no such things going on unless you specifically include them so in general even with C I manage to achieve timing accuracy and latency with low end 8 bit PICs much better than I can with Arduino, regardless of how powerful a chip I use in the Arduino environment. That would probably change if I were to go to the trouble of learning assembly for the MCUs I currently use with Arduino and figure out how to exclude the various processes and things going on in the background.
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.
@@MRooodddvvv Quite possibly. I've never tried programming AVR in assembly. I got into the world of microcontrollers with assembly on PIC and later moved to C and C++ for anyhting that didn't need very precise timing. Never got into AVR assembly but I can understand that it is probably just as good as PIC. In more extreme cases I use FPGA but it is fascinating how much can be done even with the 8 bit PICs and even more so with the DMA equipped PIC32s. The application described in this video would be dead easy to do in assembly on an 8 bit pic even clocked by its internal RC oscillator/PLL. I think even in C it would cope enough as I have done some things quite similar in the past.
@@listerdave1240 i got into avr first and then look at pic it seems horrible overcomplicated and difficult with all memory pages, limitations of what registers can be used where and so on. avr is waaaay more straightforward
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.
FPGAs for quite some time have block-ram as part of the fabric. What does "decent size" mean to you? You also have the possibility of using a DMA engine to write directly to DDR3/4 memory. There are even faster memory solutions as well. At one point in my career, I continuously captured data from a gigasample-per-second ADC, from one sub-hundred dollar FPGA to a Zynq SoC, that used scatter-gather DMA to write directly to DDR3 memory.. I think it's worthy to review the architecture to see if an FPGA can work for you. You can accomplish a lot with popcorn small FPGAs. If you detail the problem you're trying to solve, we may be able to figure something out. There are other very fast memory solutions as well that I have not looked into that FPGAs support.
@@2jpu524 thanks for your reply. Very interesting! I have to revise my statement. I'm an electronics novice, trying to do some fun projects using readily available (in my context) hardware like ESP32 and such. The stuff that you are doing is far beyond my capabilities and I currently don't have the time to invest in my education. "Decent size" in my case would be emulating an 8 MB ROM with no a priori knowledge of where the next read will occur.
@@nkronert Actually see the PiStorm project. The RaspPi emulates an entire 68000 CPU, RAM and ROM while running Linux plugged into a real Commodore Amiga. I think they added hard drive emulation on the Amiga as well now. But indeed, one would think proper EPROM emulation would be easier -- but that access time is a problem...
An idea that may interest you - The MisterFPGA project uses an Altera DE10-Nano board with an external 128MB SRAM module that is dedicated to the FPGA fabric. You could load in your EEPROM data from an SD card, etc, and load it into SRAM memory. What kind of latency are you looking for. One intesting aspect of this project is that it'c cycle accurate in hardware-emulating vintage computers and their associated peripherals.
That would be too easy except the usb host interface and you would need voltage level converters as almost all FPGAs and CPLDs are 3.2 volt or lower devices. if you went down that path why would you bother at all with the rest of the hardware.
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
@@element14presents Didn't you directly connect it to the Apple II here, and thus feed 5V TTL over the GPIO? You just used a Pico w/o any level shifters added, correct?
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.
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.
All the same. overkill is useful.. The price of the new fancy stuff is often cheaper than the alternatives. Once you get familiar with the toolset, it can become your swiss army knife. FPGA are awesome for this sort of task and are really easy to program and verify, and very consistent with nanosecond timing..
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 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.
The why was covered in the first 20 seconds of the video right after the intro. Working towards a single board computer that takes a USB keyboard rather than the original
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 .
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.
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.
These are pretty stupid suggestions, to be honest. For the Wifi, these modules include an ESP32, and the main processor is an ARM from Nordic, plus a bunch of other, completely unnecessary components to implement a ROM emulation. Thus the obvious choice would be to just use any fast ARM Cortex MCU that also runs Arduino, like one from the STM lineup.
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
Will have to play with the rpi2040 now. But you shouldn't have given up on the teensy so quick. Like I said, I got it flipping an output on interrupt in like 20ns or so and have it emulating an eeprom in a 70ns system perfectly.
I regret not making a video now as this stuff hasn't really been done before (emulating an eeprom with a microcontroller).. congrats on being #2 to do it.
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? 😉
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.
It is missing the other side. Python does not matter if the hardware secretly does everything. In this model the Python is top level configuration/noncritical event processing logic. They left that out cause it does not really exist. It can sort of exist in some SoC platforms. Lot of work for a top level polish no one will ever use, I guess. However the goal is to make user level interface. Just never happened and probably is not going to either.
Неу! 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.
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!
c is fast . depending on how you use it. its much like a assembly libraries collection. it has lots of prewritten assembly codes embeded inside. the reason its slow in lots of cases is because of programmers lazyness and control codes used thats necessary for uninformed programmers probable errors going to happen. you can skip the slow libraries/codes used with your own ones whenewer you want. c is technically collection of code. actually today gcc has them all. and you can access the some features from allmost any language. and it simply links to relative ones from whichewer language you use :P
atleast most of the times it seems .
C is ok for slow logic stuff if used right. You will not have feeling of "loosing control" if that's calling C from asm and not reverse. arduino is kinda opposite of how it should be.
@@ahmetmutlu348 You are most likely right. But there's a limit to the number of systems I can learn and still be proficient at them. I don't code every day so I"m "good enough". C seems to be really good if you want to be able to move programs from system to system. State machines beat everything if speed is essential . 74s02 can make a decision in as little as 1.5ns.
Most of the rest of your comment is fine, and I love the low level development. Doing a bit of assembly here and there, C and C++ is what I work with most.
But "Designing state machines is mostly a lost art" isnt entirely true. working with assembly for whole projects probably is getting a art style (some still use it, for the art factor). but state machines are still everywhere.
Even in modern video-games, people use state-machines for various tasks or objects to be in. That awesome multi capable object that moves across networks? it might be in a certain state and the programmer dint fully understand object orientated programming at all. Anyway, its a great video and somehow I feel a but dirty thinking I can only use modern MCU for debugging older hardware... there must be a way to use a older z80 sbc for this... probably with state machines, ttl logic and assembler XD.
inline assembly
Interrupt latency is the bane of my existence. Great video!
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'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 really want to play with these now but how many pins can they do? Teensy barely has enough pins for a 28 pin eeprom..while I have gotten it going fast enough I haven't succeeded in merging the address and data pins on the teensy side
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.
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.
Not even sure it is an Arduino problem. GCC does unnecessary register pushes in ISRs, unless they are declared "naked" and you do the housekeeping yourself.
Yes, AVRs can run really fast if you use C to manipulate registers directly, and it gets even faster using Assembly. But, if i understood everything correctly, the atmega2560 runs at 16MHz. One clock cycle therefore lasts 62.5 ns. And the datasheet says (page 18): "The interrupt execution response for all the enabled AVR interrupts is five clock cycles minimum". The resulting 312.5 ns for 5 clock cycles would still be too long if even the 180 ns of the Teensy were to long (3:55).
(A second pair of eyes to check this information is very welcome :) )
The teensy can emulate a 70ns eeprom fine. I've done it. Took me like 2 weeks with a scope to get the ISR response quick enough. Basically got it down to 20ns to flip a pin. And I had to overclock a bit.
@@graealex not so sure about that..if that was the case I wouldn't have got down to 20ns.
@@jahrkh3518 yeah a 2560 won't do it. A teensy can, I've done it, without even really resorting to asm
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).
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?
I think in this case on the APPLE CPU side of things is only READING from the eprom. The problem would be if the APPLE wanted to WRITE to the Pico.
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.
🙏
I want to start a Tech Hangout. Working only with what God provides through his beautiful people. Re-purposed E-Waste. Equipment, Hobbyist Things. Anything to give the young ones another option besides drugs and trouble.
Unfortunately we see less and less fun and more trouble in my little community. I keep an open mind and teach from my mistakes. Sounds simple but we all know it’s very complex at the same time.
Love and light.
God Bless.
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!
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.
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
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.
Indeed. That way the Arduino could run in "loop over input buffer: set outputs, trigger key-pressed signal, wait for enable pin to toggle, repeat" with no speed issues.
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 ?
Sweet shirt!!😉 Fun video!!! 🤓
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
the pico or a similar microcontroller can in fact emulate the Apple2 perfectly. The ESP32 is able to generate video, read a PS2 keyboard , read emails, and emulate the Apple2 at the same time !
How hard could it be to do this with 555 timers instead?
@Lassi Kinnunen 81 You can make a SR latch with a 555. So I guess 1 bit?
@@chnhakk So at this rate we'll reinvent a forth transputer in say another 30 years? 🤔
What about a spin loop in the main code and avoid the ISR overhead?
he probably wants to do some other stuff in the background to communicate with a keyboard over serial interface or something else.
Couldn't you achieve similar result with the Arduino by writing the code in super-loop? The AVR interrupts are rather slow...
How does the power consumption compare to the Apple 2 circuit?
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.
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.
I was thinking the exact same thing. The only thing that needs to be fast is the tri-state enable, so stick that in hardware instead of trying to emulate it in software.
That said, it is interesting to see that the Pi Pico can be quick enough to do the job in software, which is kinda cool.
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.
Could just write isr in assembly and ditch arduino bloat and should be fine
FPGA would be overkill for this application. Maybe a CPLD but in general an MCU will be cheaper and easier to program even though it is inherently far more complex than a CPLD. A low end 8 bit MCU is perfectly capable of handling this level of latency requirement if programmed efficiently in assembly
@@listerdave1240 Micros are generally much cheaper of course, and are generally easier to program, but if you looked at the jitter of your assembler routine in terms of input vs output, and plotted that as a histogram, you would see that the CPLD/FPGA will be much tighter. For this application, there are lots of alternatives. For others, the extra jitter is a ghost in the machine that may show up occasionally. I program both microcontrollers and FPGAs.. Both have their place. I have a lot of experience with pulse generators and sequencers and precision timing. Cheap FPGAs give me sub-nanosecond resolution. All the same , microcontrollers keep on getting better and cheaper for what you get.
@@2jpu524 Sure and in fact I do use FPGAs where I need that sort of resolution. My point is that the particular application presented in this video is nowhere near needing anything of that sort and can very easily be done with a very cheap MCU and a few lines of assembly code or even C.
Jitter would only be an issue if the MCU is doing other stuff apart from the simple task presented here, which in the case of Arduino would be going on even if you didn't ask it to - even something as simple as updating the millis() counter could interfere.
With the PIC IDE there are no such things going on unless you specifically include them so in general even with C I manage to achieve timing accuracy and latency with low end 8 bit PICs much better than I can with Arduino, regardless of how powerful a chip I use in the Arduino environment. That would probably change if I were to go to the trouble of learning assembly for the MCUs I currently use with Arduino and figure out how to exclude the various processes and things going on in the background.
That is a great "evil genius" laugh.
is it possible to clone commodore sound ic. chip?
read and copy content and burn a new programmable ic
See the ARMSID -- a recreation using the ARM MCU
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.
Avr got precise quick timing if it is not ruined by arduino bloat
@@MRooodddvvv Quite possibly. I've never tried programming AVR in assembly. I got into the world of microcontrollers with assembly on PIC and later moved to C and C++ for anyhting that didn't need very precise timing. Never got into AVR assembly but I can understand that it is probably just as good as PIC.
In more extreme cases I use FPGA but it is fascinating how much can be done even with the 8 bit PICs and even more so with the DMA equipped PIC32s.
The application described in this video would be dead easy to do in assembly on an 8 bit pic even clocked by its internal RC oscillator/PLL. I think even in C it would cope enough as I have done some things quite similar in the past.
@@listerdave1240 i got into avr first and then look at pic it seems horrible overcomplicated and difficult with all memory pages, limitations of what registers can be used where and so on. avr is waaaay more straightforward
cool @Baldengineer :)
That is pretty cool.
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.
FPGAs for quite some time have block-ram as part of the fabric. What does "decent size" mean to you? You also have the possibility of using a DMA engine to write directly to DDR3/4 memory. There are even faster memory solutions as well. At one point in my career, I continuously captured data from a gigasample-per-second ADC, from one sub-hundred dollar FPGA to a Zynq SoC, that used scatter-gather DMA to write directly to DDR3 memory.. I think it's worthy to review the architecture to see if an FPGA can work for you. You can accomplish a lot with popcorn small FPGAs. If you detail the problem you're trying to solve, we may be able to figure something out. There are other very fast memory solutions as well that I have not looked into that FPGAs support.
@@2jpu524 thanks for your reply. Very interesting! I have to revise my statement. I'm an electronics novice, trying to do some fun projects using readily available (in my context) hardware like ESP32 and such. The stuff that you are doing is far beyond my capabilities and I currently don't have the time to invest in my education. "Decent size" in my case would be emulating an 8 MB ROM with no a priori knowledge of where the next read will occur.
@@nkronert Actually see the PiStorm project. The RaspPi emulates an entire 68000 CPU, RAM and ROM while running Linux plugged into a real Commodore Amiga. I think they added hard drive emulation on the Amiga as well now.
But indeed, one would think proper EPROM emulation would be easier -- but that access time is a problem...
An idea that may interest you - The MisterFPGA project uses an Altera DE10-Nano board with an external 128MB SRAM module that is dedicated to the FPGA fabric. You could load in your EEPROM data from an SD card, etc, and load it into SRAM memory. What kind of latency are you looking for. One intesting aspect of this project is that it'c cycle accurate in hardware-emulating vintage computers and their associated peripherals.
Congratulation …. So cool.
How about a cheap cpld or fpga? Would be great to see a follow up
That would be too easy except the usb host interface and you would need voltage level converters as almost all FPGAs and CPLDs are 3.2 volt or lower devices. if you went down that path why would you bother at all with the rest of the hardware.
Could you have kept the Arduino and just stretched the ISR pulse using an R-C circuit?
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
There are PIC micros with a "parallel slave port" which are designed to connect straight to another MPU's bus.
Is RPi Pico 5V tolerant?
No.
@@element14presents Didn't you directly connect it to the Apple II here, and thus feed 5V TTL over the GPIO? You just used a Pico w/o any level shifters added, correct?
yup defo more needed on PIO assembly on the Pico
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.
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.
All the same. overkill is useful.. The price of the new fancy stuff is often cheaper than the alternatives. Once you get familiar with the toolset, it can become your swiss army knife. FPGA are awesome for this sort of task and are really easy to program and verify, and very consistent with nanosecond timing..
Answer: 8:01
Of course he goes with the pi pico.The thing is a beast !
Love it,but please make a tutorial on impedance
Since when PiPico has 5V tolerant GPIOs?
Would the arduino not faster if used assembler code?
how hard could it be to interface a 8bit ISA OPL2 soundcard from a arduino please
Why not just use a microcontroller + a tristate latch, instead of forcing the microcontroller to keep up with the bus?
Teensy 4 can clock up to 1ghz with cooling, 800mhz without so may bring the response times down somewhat
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 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.
The why was covered in the first 20 seconds of the video right after the intro. Working towards a single board computer that takes a USB keyboard rather than the original
@@DoctorWhom I don't get why he didn't just convert the USB keys into key matrix presses as the standard keyboard does.
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 .
if you emulate KB3600 can use arduino uno easily.
Neat
How Hard Could it Be?
That's what she said.
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.
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.
These are pretty stupid suggestions, to be honest. For the Wifi, these modules include an ESP32, and the main processor is an ARM from Nordic, plus a bunch of other, completely unnecessary components to implement a ROM emulation. Thus the obvious choice would be to just use any fast ARM Cortex MCU that also runs Arduino, like one from the STM lineup.
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
But without keyboard how could you get there
Does anyone use Atmels anymore for anything? They're horribly slow pushing and popping all those registers on every interrupt (when programmed in C).
I did this a few months ago with a teensy.
And it was *tough* to get the interrupt response down to under 100ns.
Teensy can respond to ISR in under 20ns with the right code.
PIO is a neat solution though.
Will have to play with the rpi2040 now. But you shouldn't have given up on the teensy so quick. Like I said, I got it flipping an output on interrupt in like 20ns or so and have it emulating an eeprom in a 70ns system perfectly.
I regret not making a video now as this stuff hasn't really been done before (emulating an eeprom with a microcontroller).. congrats on being #2 to do it.
Try an FPGA or CPLD
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? 😉
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.
It is missing the other side. Python does not matter if the hardware secretly does everything. In this model the Python is top level configuration/noncritical event processing logic. They left that out cause it does not really exist. It can sort of exist in some SoC platforms. Lot of work for a top level polish no one will ever use, I guess. However the goal is to make user level interface. Just never happened and probably is not going to either.
Your definition of easy is obviously not the same as mine...
You look like rick from pawn stars
Неу! 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 think a bluepill will handle that no problem
I'm not surprised. Arduino is such bloat. Just ditch all arduino crap, write in normal assembly and you should be ok.