First post after my 'introduction', so please be nice.

Encouraged by two successful builds of Andrew Jacobs' "3-chip 6502" boards (6502 and 65C02), I decided to check out another project of his, "em-retro" – see links below. This squeezes 8 different 8-bit CPU emulations onto a PIC24 chip. The Z80 & 6809 emulations are said to be incomplete, but let's not quibble, this is pretty impressive.

I've burned and verified Andrew's Github code onto the PIC24, but I'm having no joy in getting any real connectivity with it. As recommended, I am using a USB-to-TTL converter board to connect to the PIC24, with Putty terminal emulation on my PC.

I've confirmed that the USB-TTL converter works OK (tested with Andrew Jacobs' own "3-chip 6502" mentioned above). I've also ensured that it's switched to 3.3 volts. The PIC24 has its own power provision, via a 3.3v regulator. The only links between the converter and the PIC24 are Gnd, RX (to TX), and TX (to RX).

When I connect, I get no response from my PC key presses, but I *do* get something displayed on my Putty window – a single '?' character, which, interestingly, appears to repeat every 2 minutes or so. Well, it's something! At least it's not dead. (I've tried reversing the RX & TX lines, but that gives nothing at all.)

What about Putty settings? The code does make a couple of references to 57600, so I'm using that baud rate. As for the rest, I've got 8, N, 1, Xon/Xoff. That's what I've used when successfully connecting to other SBCs, including those "3-chip 6502"s.

I've searched the code for any possible references to a "?" character, or 3F in hex, to see if one is output under any specific conditions, but no joy as yet. I dare say I'm missing something obvious.

Can anyone shed any light on this at all? Has anyone out there perhaps built this project? TIA.

Em-retro (earlier & later versions): viewtopic.php?f=8&t=1936
Andrew Jacobs GitHub project page: https://github.com/andrew-jacobs/em-retro

I've always found it a struggle, and then a great relief, to get serial connections working. Of course one would hope it would be simple.

Which USB to serial adaptor do you have, exactly? There are two popular chips used in these.

Personally, I'd want to try to get a hex display of what the PC is receiving. Those '?' may not be the byte you think they are, and there might be a clue there. See
https://superuser.com/questions/150202/ ... for-serial

The USB to serial adapters I use all have the CH340 chip. They all work fine for connecting to Arduino Pro Mini boards, and to the SBCs that I've built.

Good idea about getting a hex display of the transmitted character, and thanks for the link. I'll do a bit more digging and see what I can find.

A quick update, which may help any others who want to try out this project.

I read the GitHub code for em-retro into MPLAB X, v5.30. When I built the project, I got a few warnings, which suggested that 'config…' at the start of a few lines should be '#pragma config…'. I made the changes and then got a 'clean' build, with no warnings or errors. Unfortunately, the resultant hex file, when uploaded to the PIC, gave the virtually non-existent serial connectivity I mentioned originally.

However, I have now discovered that if I ignore the warnings issued by the build, the hex file created is very slightly different, having some 18 additional records at the end. You can see what's coming: when I upload this latter hex file to the PIC, I get an 'EM-Retro' banner displayed on my Putty terminal window, and drop, by default, into a 6502 emulator, able to type in and run BBC Basic programs. Hurray!

So I need to be more careful, and remember that warnings are not the same as errors. And, whilst it's probably best not to ignore them, sometime it actually pays to do just that.

I still have loads of questions about how to use all of the project's facilities, but at least I now have a working platform on which to operate, and hope to get some answers from a good look at the code. I'm still very happy to hear if any other users have done anything with this project.

Good result - thanks for the update.

Repeated bits may indicate that the transmitter is too slow (or the receiver is too fast). The start bit is bleeding into the data bits and the data bits are duplicated.



I've had similar with DNS, SMTP and printer/scanner protocols. A common factor to all of them is that there is very little gap between "it does nothing" and "it just works". Meanwhile, people invent new ways for them to fail. That makes it difficult to publish a troubleshooting table or diagnostic flowchart. For example, it would have to include checks such as "Has your fake FTDI serial device been bricked by a Windows driver?", "Does your PPP interface filter out rude words?" or "Does your Ethernet payload force your network connection to 10Mb/s and drop the link?"

Most pertinently, my first suggestion would be to check that the clock speed is a reliable, known quality at the processor *and* the UART. (I've had this fun running a 20MHz idle loop on a 16Mhz microcontroller.) The next suggestion would to check that clock division is correct.

Apparently, an absence of clock configuration was the root cause in this case. I wouldn't have diagnosed that.

_________________
Modules | Processors | Boards | Boxes | Beep, Beep! I'm a sheep!