EPROM-EMU-NG VS Marlin

I actually used one of these things[0] during development of the DX9/7 firmware mod. I like your Mirage tools by the way! I've actually got a very battered Ensoniq Mirage I picked up for free that's badly in need of some maintenance. If I can get that running I'd love to give your firmware a try!

[0] https://mygeekyhobby.com/2020/07/05/eprom-emulator/

Well, the static RAM that the EPROM emulator uses has an access time of 55 nanoseconds. Here's a better description of the hardware.

To use an arduino you'd need to design debug and code something like this specifically to emulate the expected EPROM in the poly-800. An arduino isn't pin-compatible, you can't just shove one in there. Guessing based on the size of the dump file, it's 8k x 8bit, or 64kbit, so probably either 24 or 28 pins? Kind of boils down to how valuable you consider your own time and how much you want to spend to build something for what is basically a one-off, because nobody really needs that.

I’ve recently started using the EPROM-EMU-NG to replace the EEPROM with a second SRAM chip, along with an Arduino Nano and some shift registers to be able to program the SRAM from your development station. It holds RST low on the 6502 while it’s doing its work, and can be powered by either USB or the EEPROM power rails.

There is _a lot_ wrong with Marlin. It is a complex codebase, full with ancient artefacts, litterred with preprocessor ifdefs every 2-3 lines of code, dynamic includes in the middle of CPP files, etc[1]. It's about as unreadable as C++ code gets--well, I guess it's not template metaprogramming.

Klipper by contrast is a breeze to read through[2].

I am very grateful for Marlin, for all of reprap, and everyone who has contributed to it. But saying there is nothing wrong with it is straight up misguided.

[1]: https://github.com/MarlinFirmware/Marlin/blob/bugfix-2.1.x/M...

[2]: https://github.com/Klipper3d/klipper/blob/master/src/lcd_hd4...

I think you are mistaken. I can't speak for implementations preceding the Ender 3 V2, so what you're saying may have been true at some point for other machines. However, here you can see Marlin developers confirm that there is an EEPROM on the stock E2V2 board using diagrams from Creality and photographic confirmation. Here is the datasheet for the EEPROM. Here is a thread discussing this Marlin release, and also the then-recent release of official Creality firmware which resolved the same issue. Since the stock firmware is based on Marlin, and at the time Marlin did not support this type of EEPROM, the EEPROM was not usable at launch. Any mainstream firmware (official or third-party) from the last three years will be using the onboard EEPROM unless the user intentionally specified otherwise.

pull latest Marlin from github: https://github.com/MarlinFirmware/Marlin

Also, checked the following discussion but seems like I need to update the firmware to be able to comment that like right? Temperature variance monitor tweaks by zeleps · Pull Request #23571 · MarlinFirmware/Marlin · GitHub

i spent some time and successfully rebased Kobra 2.8.2 OG firmware from an unknown Marlin ~2.0.8 frankenstein to a clean latest (as of now) release (not bugfix) 2.1.x -- v2.1.2.1 + 1 commit

As an example, check the macropocalypse in Marlin - but the actual trigger for me to start was Reprap firmware doing a floating point divide in interrupt context while targeting AVR8 core…

Any change of thermistor or to a PT100/PT1000 will require recompiling the firmware, because every type has different characteristics. Marlin uses an internal table to calculate the temperature for whatever reading it gets from the CPU's analogue-to-digital converter. It has many tables for different thermistors, but only one is ever incorporated at compile time. So you have to specify which type you're using. You can see the commonly-used types in the list in Marlin's Configuration.h file, in the section headed // @section temperature. The tables themselves are in Marlin/src/module/thermistor.