kris-sekula / eprom-emu-ng Goto Github PK

EpromEmu_2_2d_BoM_DigiKey_v1.xlsx list the following

Index	Quantity	Part Number	    Manufacturer Part Number	Description	                Customer Reference
5	2	        4610X-1-103LF-ND    4610X-101-103LF             RES ARRAY 9 RES 10K OHM 10SIP	RN2
31	1	        A786AR-ND           10-0518-10	                CONN SOCKET SIP 10POS GOLD	RN2

but the assembly documents says you need RN2 and RN3

So these are in error.

Index 5 the customer reference should be RN2, RN3
Index 31 the quantity should be 2 and the customer reference should be RN2, RN3

Kris,

I got the new FDP-624-T 24 pin and 28 pin from DIGIkey. I remade a new board and put the header into row 2/3 of Ver 2.2d board. If I run it on pc I can program and then read the emulator in TL866Pro, but as soon as I put either the 28Pin into a Amstrad CPC (27256), or the 24 pin into a TEC one-a (2716), the U6 starts to heat up and it does not work.

The 28 Pin worked in the previous board i made with the same Amstrad but with with the TLY probe and Header connector in Position 1/2

When i buzz the pins from the FDP out, they appear correct according to the Schematic. I have tried with the RN2 installed and removed, same issue.

Any ideas?

I recently bought a batch of Nano modules based on the newer ATMEGA328PB microcontroller without even realizing it. Although the microcontroller is practically backward compatible with the ATMEGA328P, I experienced issues when using the EPROM Emulator with those modules, for example, the upload of the binary image was failing randomly, this would look like a successful upload is happening, the red LED would be lit up for a short moment and then would go off. When monitoring with a logic analyzer I was seeing that the microcontroller gets reset at the end of the upload when the python script disconnects. This was "unexplained". As per this repo: https://github.com/watterott/ATmega328PB-Testing the reset level for the PB version is: 1.6V @ Vcc=5 and 2.1V @ Vcc=5V for the P version... this leads me to believe that the reset control is the problem. To confirm I removed the 100nF capacitor between the DTR line on the CH340 and the ATMEGA328PB Reset line. This fixed the issue. See the picture of the modified board:

Not sure how to deal with this further, my workaround for the batch of Nano modules will be to remove the 100nF capacitor and ask users to press the "reset" button during firmware upload (not a big deal as this is not often required).

Removing the 100nF capacitor also means that when the python program connects to the emulator it doesn't automatically reset the emulator - this is a good thing, but this also exposed a small bug in the original firmware where the address bus was not fully set before data was re-uploaded via the serial connection. This bug is now fixed and updated firmware has been added to the repository.

hey do you have the kicad sources for 2.2d? the 2.2.c ones are there, just wondering on the 2.2d

thanks!

G'day,
I made this version, and ordered 10x 28 pin TLY-3100 -28P. I assemble the unit, but cannot get the Probe to work. I installed the 40 Pin header in position 1 and 2 as per silk screen, but the signals are all over the place. When I probed them, they are not in the correct order for the TLY plug. Also, the IC numbers are different on the top and bottom of the silk screen, so which is actually correct.
Thanks
Paul

There is a difference in values of RN1, RN2 and RN3. In the schematic and on the board it is 10K, in the BOM it is 47K.

Hi Kris,

in setup() you starting the emulator with EN_RST = LOW, with means, the target is not in reset.

pinMode( EN_RST, OUTPUT ); digitalWrite( EN_RST, LOW ); // disable outputs to start with AD0-15 from outside

What is the reason for this setting?
After the emulator is powered on, the content of the SRAM is not defined, it is random.
That is, the target system's CPU starts executing random code.
Maybe that's not a problem in an Atari or something similar.

In my use case I want to emulate the firmware ROM of an industrial system.
This stores important data in a battery-backed CMOS RAM.
The execution of unknown code after the start could overwrite data or cause unwanted signal combinations at external I/O connections.

I would prefer the emulator to start with holding the target system in reset (EN_RST = HIGH) until the SRAM contains defined content and EN_A11 to EN_A15 are set appropriately. The target system should only be released after autoload from the SPI, upload from the PC or manual load from the SPI using the push button.

Thanks
Ralf

24 pin devices like the 2716 and 2732 are supported by keeping the top 4 pins of the 28pin emulator probe unplugged. The power must be provided by the USB cable.

I didn't see any assembled devices or bare boards anywhere so I had some boards made, and bought parts to assemble them

I have some if anyone needs.. I can get you bare board, or fully assembled/programmed ready to go units>>https://store.interbiznw.com/

There is a fatal bug in firmware 2.0rc9 and rc10 (Files EPROM_EMU_NG_FW_2.0rc9.ino and EPROM_EMU_NG_FWrc10.ino).

The (E)Eprom type with the highest ID is the 28C64 (mem_cfg=8).

If you set this type permanently (:iniE64), the next time you start the emulator in setup () the deafult type 27512 (mem_cfg=6) is set again because the following program section is faulty:

//
// get "last used EPROM" config from SPI_EEPROM
//
if ((EEPROM.read(mem_cfg) > 7) || (EEPROM.read(mem_cfg) < 1)) {
EEPROM.write(mem_cfg,6); // set default to 27512
Serial.println(F("Setting default EPROM Memory to 27512"));
}
else {
lastEPROM = EEPROM.read(mem_cfg) ;
Serial.println(String("Config: Last EPROM used is ") + memTable[lastEPROM]);
}

The if statement must be like this:

if ((EEPROM.read(mem_cfg) > 8) || (EEPROM.read(mem_cfg) < 1)) {

If this error is corrected, access to memTable[] will fail because there is no index 8 there:

const char* memTable[8] = {"27xx","2716","2732","2764","27128","27256","27512","28256"}; // lookup table for memory type

The table must contain an element for index 8:

const char* memTable[8] = {"27xx","2716","2732","2764","27128","27256","27512","28256","28C64)}; // lookup table for memory type

Greetings
Ralf aka Hubert

So I'm a fairly green electronics hobbyist, and I was wondering if it would be easy to make this work on the IBM 5140's dual socket interface, probably with some form of daughter/adapter board.

I found references to the original roms here, and they're listed as 27c256

http://www.minuszerodegrees.net/rom/rom.htm

I haven't confirmed that, but I assume since there's a dumped rom file there, it's probably accurate.

Any thoughts?

with the changes made to pysimplegui licensing. have you though about switching to FreeSimpleGUI as an alternative?

I may have spoken too soon on #8 - it stopped working in 28256 mode in my BE6502 when using -spi n (y works).

Also, the transfer time almost triples when using -spi n:

• -spi n: Time taken to transfer: 15.22s, fails to boot.
• -spi y: Time taken to transfer: 5.27s, boots fine.

Firmware version: 2.0rc8.

Uploader version: 2.0rc8.

macOS 11.2.3

Python 3.9.2

High Kris,

I had previously done tests with higher serial data rates and discussed them on groups.io.
I had successfully tested the FW/SW (rc3/rc3) with 115200 (default), 250000, 500000 and 1000000bit/s.
Higher speeds lead to shorter transmission times.
This no longer works in the current rc11 firmware/rc9 software.
When transferring with the old method (spi=yes => :SBN) it works as before.
With SRAM only mode (spi=no => :DIR), the transmission time is shortened when increasing from 115200 to 250000bit/s as expected.
At 500000 and 1000000bit/s it now takes 64s.

I haven't investigated the problem yet.
I suspect it is due to the serial receiving algorithm in the firmware (buffer problem?).
At first glance, the send routine in the Python script is identical except for the start command (:SBN vs. :DIR)

Thus, even with "SRAM only" (spi=no), a higher transmission rate would have a better effect than different algorithms for spi=no and spi=yes.

Ralf

The KiCad source files are missing from the 2.2c folder.

I only see them in 2.2 and earlier.

m24c64wp.pdf

Hello,
Is it possible to read which address the target device is accessing?

Thanks

Thank you for providing the firmware EPROM_EMU_NG_FW_2.0rc3.ino for testing.
The firmware works flawlessly in my environment.

I would prefer to switch off the red LED during the long press together with EN_RST=HIGH.
I.e. when the reset signal is activated, the LED goes out and when the button is released it lights up again.

I tried out a few small code changes.
Here is the summary.

// - remove unused variable 'page_ctn'
// - move variable 'spi_address' from global scope to function load_SPIEEPROM()
// The variable is only used in this function.
// The positive side effect: Saves 20ms more in loading SRAM
// - simplify filling shift registers in writeMemoryLocation(), two variables are omitted.
// No effect on speed.
// - in long press button move the turn LED off few lines up, so the 150ms is included in LED off time
// This makes it easier to recognize the triggering of the reset and release the button at the right time

In addition, some comment lines are incorrect in the rxframe evaluation:
:iniAuto0
:iniSPI0

The diff file is attached.

In the Python script EPROM_NG_v2.0rc3.py, reference is still made to the old function (turm autoLoad off) for Long Press Button. That can be omitted.

Greetings
Ralf

v20rc3update1.diff.txt

I'm trying to find dhe component to build the probe, but I can't find anywhere the dip28 header. the link to digikey you posted on your website not work anymore. Can you help me to find the header?

Hi Kris,

When uploading a binary ROM image, the 64k limit is not checked.
The script crashes when the file exceeds this limit.

Use case:
128kB image file for a target with 2 * 64kB EPROM (2 * 27512).
It is not a problem to burn the image in two EPROMs with an EPROM burner, as I can specify the start address in the file and the length in the burning software for each burn process.

The emulator is in the socket of the lower ROM.
During the upload, an attempt is made to load the complete file into the buffer, which leads to an overflow.

D:\<path>\>EPROM_EMU_NG_SW_Python_v2.1.2.py -mem 27512 -spi n -map y d:\<filepath>\file128k.bin com9
-------------------------
EPROM EMULATOR NG Script version 2.1.2 started - mygeekyhobby.com
Option 'use cache' is set to: disabled
Reading data from: d:\<filepath>\file128k.bin
Traceback (most recent call last):
  File "D:\<path>\EPROM_EMU_NG_SW_Python_v2.1.2.py", line 565, in <module>
    main()
  File "D:\<path>\EPROM_EMU_NG_SW_Python_v2.1.2.py", line 338, in main
    current_data = load_to_buffer(file)
  File "D:\<path>\EPROM_EMU_NG_SW_Python_v2.1.2.py", line 304, in load_to_buffer
    data_64k[x+startaddr] = binfile[x]
IndexError: list assignment index out of range

The buffer in the Python script is declared as 64kB.
A test as to whether the loading address (option -start ) + file length is> 64kB should be implemented.
A warning should be issued for files that exceed the 64k limit and the upload should stop automatically when the 64k limit is reached.

On the other hand, it is not possible to plug the (or a second) emulator into the socket of the top ROM and load the top half of the file into the emulator. File offset = 0x10000, Loading address = 0x0000.
For this one would have to be able to specify an offset for the start in the file.

Of course, you can split the image file beforehand using suitable tools. But during a development process this would be an additional step that would have to be repeated after each ASM / compiler run.

Ralf

Please consider this a draft note-to-self, since I don't have time tonight to write a pull request.

The pinout between an AT27C256 and a 28256 differs in that the EEPROM's A14 is on pin 1, with /WE on pin 27, while the 28256 EPROM has Vdd on pin 1 and A14 on pin 27.

So, since in the EPROM-EMU-NG, pin 1 is A15, and A14 will be held high ("write enable" not asserted), we can write a little Python script to convert a 32K binary file into a 64K file padded with junk in addresses 0000:3FFF and 8000:c000:

#!/usr/bin/env python3

import sys

if __name__ == "__main__":
    with open(sys.argv[1], "rb") as infile:
        data = infile.read()
        assert len(data) == 0x8000, f"len must be {0x8000}; was {len(data)}"
    with open(sys.argv[2], "wb") as outfile:
        outfile.write(b'\xff' * 0x4000) # junk
        outfile.write(data[0:0x4000])
        outfile.write(b'\xff' * 0x4000)  # junk
        outfile.write(data[0x4000:0x8000])

then write it out like usual:

% python3 EPROM_NG_v2.0rc3.py -mem 27512 -spi y -auto y ./a512.out /dev/tty.usbserial-1410 -start 0 -map y

I used a TL866 II+ with minipro to confirm that this reads correctly as a 27C256:

% minipro -p AT28C256 -r a.test

And, I attached it in place of the EEPROM of my Ben Eater 6502, and it boots up correctly!

It would make things easier for larger roms (like bios for old PC's made from new(ish) parts (EMM 8088, etc). And you could replace the two RAM chips with a single 512kx8 ram. If I ever have time, I may fork this and attempt it, but I have lots on my plate already...

Hi MyGeeky

I rewrote your EPROM_EMU_NG_FW_2.0rc3.ino
So that it uses eprom structs instead.
EPROM_EMU_NG_FW_2.0rc3.ino.zip

I wonder if you would be willing to sell a bare PCB ?

I was wondering if you would consider adding 23xx support, the difference is only in pinout. This would make it handy to use in things like ZX81/TS1000 without an adapter.

do you think is it possible to implement trace feature in your fw without lose to much performance?
with trace I mean see in real time which address/data is access from the circuit where the emulator is mounted.

Currently, the -start argument is only taken into account when processing non-HEX input files.

hey I got some questions around the project and methods used for use on another project, would you mind to chat a bit via email?

my email is [email protected]

thanks in advance!