088
20.11.2020, 05:27 Uhr
avrkris
|
Hello Everyone!
This is Kris aka mygeekyhobby.com 
I've been chatting to some of you individually, and finally, Klaus pointed me to this forum. I'll write in English with the hope Google will do a good job translating it for you.
First of all, I would like to say thank you to Rene (aka Creep) for spreading the news about the project here and organizing the group purchase. The "donation" you all made as part of the PCB purchase was not expected but is much appreciated! Thank you all very much!
I can see some of you have already managed to build the emulator, but if anyone still gets stuck feel free to reach out to me (I will also monitor this forum and try to answer if I can).
There is also an official support channel for the emulator: https://groups.io/g/eprom-emu-ng
There were a few questions about some of the technical aspects of the emulator, let me try to briefly answer here:
In #39 Ralf is asking about the HC vs HCT. I had many discussions with people who are much more experienced than me about this topic. HCT would normally be a better choice due to the TTL compatibility - I agree, but there are two reasons I'm sticking to HC, One: with the voltage drop on the polyfuse and the Schottky diode, if your target system supply is anything below 4.9V you end up with 4.3V on the 541 buffers - officially this is below the specification for HCT series. Two: once I used HCT, my ZX Spectrum would not boot... So unless there is some other reason we should be using HCT, I'll be sticking to HC for now.
in #43 and #44 the was a discussion about the limitation of 128bytes for the SPI EEPROM write. The reason it took so long to fix, was that I had to re-write the entire firmware/software and move the file processing from the firmware into the software. Additionally, although SPI EEPROM allows you to write a single byte, in the background when you issue a single byte write, the SPI EEPROM will read a block of 128 bytes, modify a singe byte and write the entire block into the EEPROM - so if you address single byte in the SPI EEPROM, you are affecting entire block of 128. This is just how Flash works, it is better for the long term usage of the SPI EEPROM to write to it in blocks of 128. This is what I implemented in 2.0rc1.
in #60 Matthias is asking about gating A11-A15. The original article on my website describes that section of the diagram but in #61 Ralf explained correctly why we need those buffers.
in #77 there is a discussion about the Q1 and Q2 transistors... At some point, Klaus emailed me pictures of his assembled device I noticed he put the transistors "the wrong way around" I asked him about it and he responded this was because he used different types of transistors. When I looked up the transistor it still didn't make sense to me. In the end, I realized there is a mistake on the PCB. The footprint on the PCB is for BC547 and BC557, but at some point, I started using 2N4401 and 2N4403 (I somehow missed that those transistors are using different pinouts). It was strange, as all the emulators that I shipped to people worked fine (I have a test setup here at home that I test each emulator before I ship). Turns out, a standard transistor can work fine with E and C swapped around (it's called "reverse active" mode). The "beta" of the transistor running in reverse active mode is much smaller, but in our circuit, the transistor is just serving the purpose of "buffer" so it should be fine even if it's installed incorrectly. I published an Errata document to GitHub in case someone wants to fix their emulator (if you have one of the pre-assembled devices from me, or used 2N440x and assembled as per silkscreen on the PCB).
#86 New PCB is out, the main motivation was a few minor fixes and a bit of cost-cutting (for me at least). Only the "required" pull-ups are now on single RN2 (/OE, /CS, and A11-A15), the rest is on "optional" RN1, RN3. Saves me time soldering, and the cost of 2x RN and 2x precision socket (my margins on the emulator are really small considering how much time it takes to build, package and ship it out). Q3 is as Ralf pointed an attempt to lower the loss between E_VCC and VCC, I would be using a FET instead of D5 (end skipping even the polyfuse)... but it may never happen, the power distribution is rather complicated, as we have to deal with the fact that there is also supply from the Arduino Nano... I will need to do more testing, the footprint for Q3 on PCB1.8/1.8b should be skipped/left unpopulated.
#87, Sorry Rene, I didn't realize you are buying more PCBs. It took me a bit of time to figure out the Q1 and Q2 issues. I only changed and published the PCB 1.8b yesterday. I haven't used the 1.8b yet, I still have a stock of over 20 PCBs version 1.8 with the wrong silkscreen for Q1 and Q2... the other changes to the layout in 1.8/1.8b are minor, like the addition of RN on A0-A7 and the experimental Q3, so you are not losing anything going with the older design.
Once again, thank you all for your support and kind words about the project. As you know, those days feedback is really important and to see you all building the emulator and trusting my project is very rewarding! If you would like to further "support" my activities, simply "star" the project on GitHub(https://github.com/Kris-Sekula/EPROM-EMU-NG), "like/comment" on my website (https://mygeekyhobby.com/2020/07/05/eprom-emulator/) or "like/comment/subscribe" to my YouTube channel (https://www.youtube.com/channel/UCit6NSQC8YubzeR6NZB2kRg/) and I will be working on more "retro" computing-related projects, all of them will be open-source.
Also, please share with me pictures of your emulator "in action", I'll be featuring those in my upcoming article about "supported targets".
Greetings to you all.
Kris
P.S> I needed a simple Z80 based "target" to use with my emulator with, so I came up with this: https://github.com/Kris-Sekula/mgh80 |
Jetzt ist das wieder vom Tisch, und ich mache mit i8080 und dem EPROM Emulator weiter.
