|
Post by dshadoff on Dec 1, 2019 23:05:28 GMT
This project is just starting, but could be interesting for various developer types.
Chris Covell's PCEmon implements a serial port through the PC Engine's joypad connector, and establishes communication with a light monitor program on the PCE side, which has some functionality to read and write memory, access BRAM, VRAM, and do some other nifty tricks.
The aim of this project is to overcome various limitations which exist in the current setup, and make it a more useful and lush environment by implementing an intermediate processor to make things easier for the user.
Drawback #1: Since PCEmon communicates through the joypad port, switching cables between joypads and PCEmon is a bit tedious.
Solution: The PCEmon accelerator board has a 74HC157 switch, controlled by the on-board processor, so the joypad can always be plugged in, and activated with a keystroke.
Drawback #2: Downloading data into a PC file is tedious with Teraterm, requiring some switching of echo settings, and so on.
Planned Solution: The PCEmon accelerator is planned to implement Zmodem protocol, to make this easier. It will also have a SDCard as an interim solution to store files.
Improvements which can be added: - The microcontroller can drive a session to edit memory directly, can chain commands in sequence, and can add additional help text - A disassembler/assembler could be added, if this were thought to be useful (a symbol table could be placed on the SDCard to make the disassembly a little easier to read) - PCEmon's stub program could be reduced in size, removing conversational text if its size were considered an issue - user interface improvements such as: color-coding of output, prompting for subcommands and parameters, full-screen (character-based) editing, etc.
...I'm sure that if you're reading this, you probably also have a few ideas of your own.
I've just sent the boards off to be made, and will create a GitHub as soon as I am comfortable that the boards are working. It seems that all the surface-mount parts I have chosen are available for JLCPCB's SMT assembly service, so if the design is good, I can make more as needed (Adafruit M0 Adalogger board and mini-DIN sockets would be an additional step, but a straightforward one).
The code will be Arduino-based and open source, so that new functionality is easily added, and forks of the code can be made. I will update here with news as it happens.
|
|
|
Post by dshadoff on Dec 2, 2019 18:59:54 GMT
So it turns out that somebody has already put Zmodem on an Arduino-based microcontroller and made it public: github.com/ecm-bitflipper/Arduino_ZModemIt seems to be a bit resource-hungry (Flash and RAM), but manageable. On the other hand, zmodem has the appearance of requiring a full file to exist, rather than just a stream... The MCU I am using has an SDCard on it, so that’s fine - but it means an additional delay as the data would now require two steps. Probably not a deal-breaker, and maybe not even noticeable for fetches of 4KB or less. In future, a souped-up MCU could be used so the data can all fit in memory, if this is a hardship.
|
|
|
Post by dshadoff on Dec 10, 2019 3:42:13 GMT
I got the first revision of the boards back today, and it worked first time, better than I expected ! I need to put some pull-up resistors on the joypad inputs, and current-limiting resistors on the flow back to the PCE, (maybe want to dim the status LEDs a bit too...), but other than that, it worked like a charm ! Here's a pic, with controller for scale:
|
|
|
Post by dshadoff on Dec 11, 2019 13:12:32 GMT
I put the adjustments into the design last night, and submitted it as a “SMT assembly” order. I should have 10 boards back in a week or so (minus connectors and the MCU, but those are easy to hand-solder).
Wow, things like this became inexpensive... the board, the SMT parts, and assembly is actually cheaper than the board and stencil I ordered last week. (But I passed on the ENIG treatment this time, so we’ll see if their manufacturing can compensate for that).
|
|
|
Post by dshadoff on Dec 14, 2019 20:51:48 GMT
I created a GitHub repository for the PCEmon_PLUS project. Currently, only rev.A boards and a trivial Arduino sketch are in there, but take a look if you'd like to see what it's about. More updates this week, as rev.B boards come back from the factory. github.com/dshadoff/PCEmon_PLUS
|
|
|
Post by elmer on Dec 16, 2019 6:14:12 GMT
This is all super-cool Dave, and I'm happy to see that little atmel board in there, I've been fantasizing about using one of those for years!
|
|
|
Post by dshadoff on Dec 17, 2019 2:41:40 GMT
It's a great little board (especially because of the SDCard socket), and the Arduino environment makes it simple to code for boards like this. If the code ever outgrows this particular board, the "Feather" standard footprint would make it trivial to transition to another board - for example, this one is a pretty big upgrade (but overkill at the moment): www.adafruit.com/product/4382By the way, I've just put another (semi-trivial) commit into the GitHub: - synchronize echo at startup - implement 1-key BRAM download to SDCard - using 'PCE' as an alias for 'Serial1' for ease-of-reading I should get the assembled rev.B boards tomorrow or the next day, and I'll try to get a few of these into the hands of other developers, to help with the development (assuming the boards are working OK).
|
|
|
Post by dshadoff on Dec 20, 2019 2:31:58 GMT
OK, I have received the rev.B boards now, and they work as expected. And I committed the rev.B updates into the GitHub repository.
By the way - I have extra boards in case anybody is interested. They are already assembled except for the mini-DIN sockets and the microcontroller board.
I'd be happy to mail them out for free to people who are likely to use them, with the following limitations:
1) You will need to obtain your own (a) Adafruit M0 Adalogger microcontroller, (b) male-to-male mini-DIN-8 cable, and (c) micro-USB cable for computer-to-microcontroller communication 2) I'll include the mini-DIN sockets, but you'll need to solder them in (as well as the Adafruit board, for which you will probably want to use a socket) 3) The software is under development, but you're welcome to participate in its development !
If interested, PM me... (first come, first serve - I have 4 available)
Dave
|
|
|
Post by ccovell on Dec 20, 2019 7:57:39 GMT
That's a pretty cool board, Dave! I look forward to seeing how this develops.
|
|
|
Post by dshadoff on Dec 20, 2019 13:34:19 GMT
A couple of notes about the rev.B updates - they are basically just about power paths: The 74HC157 which selects between inputs is powered by the PCE joypad port, whereas the microcontroller is powered by USB. This wasn’t a problem, except when one side was powered and the other wasn’t: enough power was bleeding from one side to the other that normal power-up was affected on the side which hadn’t yet powered up. (I also forgot the pullup resistors on the joypad in case it’s not plugged in.)
This power leakage issue was solved with current-limiting resistors; also, the joypad will be in passthru mode when USB power is not applied (but I wouldn’t recommend using it in this configuration for extended periods.)
Also, as it’s not in an enclosure, take care against static electricity and liquid spills... but you should already know those.
For anybody I am sending these to, please provide feedback if you see any odd behaviors of this type.
|
|
|
Post by dshadoff on Dec 21, 2019 14:11:14 GMT
So it turns out that somebody has already put Zmodem on an Arduino-based microcontroller and made it public: github.com/ecm-bitflipper/Arduino_ZModemIt seems to be a bit resource-hungry (Flash and RAM), but manageable. On the other hand, zmodem has the appearance of requiring a full file to exist, rather than just a stream... The MCU I am using has an SDCard on it, so that’s fine - but it means an additional delay as the data would now require two steps. Probably not a deal-breaker, and maybe not even noticeable for fetches of 4KB or less. In future, a souped-up MCU could be used so the data can all fit in memory, if this is a hardship. This morning I was able to verify that this code works - at least on Teraterm. Very little modification was necessary to their code to make it work as it did in their example (just a couple of definitions and comment out a header file). I was able to get transfer speeds of 16KB/s from MCU to PC, which is a bit slower than I had expected - especially given that the data must already exist on the SDCard by this point. Maybe there's opportunity for tuning later. The good news is that ZModem transfer works both ways. But I will still need to take this code and somehow integrate it into the sketch I am writing... it's just good to see proof-of-concept working. There was one little hiccup which gave me more trouble than it should have:
For Teraterm, I needed to edit the default teraterm.ini file in order to enable automatic Zmodem transfers: EDIT: Transfer speed in the direction from PC -> MCU is better, around 65KB/s
|
|
|
Post by ccovell on Dec 22, 2019 0:59:51 GMT
So, the arduino module acts as a man-in-the-middle between the PC and PCE? Do all systems run at the same baud rate?
TeraTerm has a pretty simple & useful scripting facility too, so it might be possible to make a script run from an assembler / notepad++ etc. that uploads a PCE ROM project as soon as it's assembled through TeraTerm (via ZMODEM?)
|
|
|
Post by dshadoff on Dec 22, 2019 2:31:29 GMT
Exactly ! Man-in-the-middle. As if the FTDI module was on steroids. The systems don't have to run at the same baud rate - I'm running microcontroller-to-PCE at 19200, and the microcontroller-to-PC is running much faster (up to 12Mb/s). I know I could run 57600 to the PCE, but I fear that chained commands might overrun the buffer - this is fine-tuning for later (millisecond-granularity delays can easily be added within critical sections when needed). The PC side is limited mostly by the microcontroller's processing power and transmit buffer sizes. Yes, I see where you're going - and that sounds like a great idea ! At first, I'm just trying to get a framework together without breaking anything - so it will have dual personalities: 1) pass-thru, retaining all existing functionality with the added benefit of switching inputs, and switching modes to the 'alternate' 2) 'alternate' mode which I am currently inspired to give it a layout like "bug monitors" of old - this "ZBUG" article might give some ideas (I have fond memories of this): archive.org/details/80-microcomputing-magazine-1981-01/page/n129(There might also be a few cool functions in that old utility which could come in handy...) I'm also thinking that the SDCard will need to be a waypoint along the way from PC to PCE... we'll need to explore what works best/feels best.
|
|
|
Post by dshadoff on Dec 25, 2019 19:50:33 GMT
First steps... got it loading and a crude display. I'll try to add a rudimentary command or two before I check it in.
|
|
|
Post by dshadoff on Dec 31, 2019 16:31:57 GMT
Update: I have checked in more updates, and it's starting to take shape. You can scroll around in CPU-mapped memory with sub-second response time, but lots of commands still need to be added. At a certain point, I might need to make some additions/changes to the PCEmon side, for example access to non-mapped banks is currently only by downloading/displaying/uploading the full bank (but a chained command can perhaps work around this for the time being, temporarily mapping it in and back out as necessary). It looks like this now, although it seems brighter on the terminal screen than the snapshot. (easy to change the theme colours if these don't appeal): Another thing I wanted to do, was to put all the developer code out of reach of commercial software; somewhere like bank $90, so that developers wouldn't have to worry about memory conflicts during debugging and so on. This explains my interest in the CD Stupid Card; I was looking to implement RAM across the full addressing space (minus bus-conflict cut-outs), with a boot ROM holding whatever (i.e. PCEmon, or CD System Card with PCEmon additions); the "normal" RAM would hold all software except SFII (which needs mapping), and any "abnormal" RAM (i.e. banks $88-$F6) would hold developer code or work area, including a PCEmon stub. (The CD Stupid Card currently does not work this way though.) ...But maybe I'm getting ahead of myself.
|
|