Jump to content


  • Content Count

  • Joined

  • Last visited

Everything posted by mozzwald

  1. I actually have that board but the one with onboard antenna. Moar LED's are always nice and those multi color ones are handy. WS2812 LED's might be an option too. The board I've designed actually uses the ESP32 module and not a nodemcu type developer board. To keep it as small as possible I made a completely custom board with all necessary components (CP2102 USB/Serial, 3V3 regulator, etc). I'll be using the ESP32-WROOM-32D (onboard antenna & dual core) with the first few boards. If there are signal issues (I expect there not to be, but you never know), I can always swap it with the external antenna module (ESP32-WROOM-32U). Could make a "long range" version with external antenna adapter if there's a need
  2. I ordered PCB's for a prototype ESP32-WROOM-32 based board with SIO Plug and Receptacle. I hope to get them by the end of next week if all goes well. The pinout used is at https://docs.google.com/spreadsheets/d/1qEPPM3-gqzfHsogJYuVXqhbvSSsgxdQMb_KGfpoV9KI/edit?usp=sharing on the ESP32 sheet. @jeffpiep is using a Nodemcu ESP32 for testing already with a reduced version of that pinout. ESP32 has many benefits over the ESP8266 for not much more money. Notably, more GPIO allows MicroSD Card socket, optional Bluetooth, 2 UARTS with no need for pin swapping, faster cpu and optional Dual Core ESP32 chip.
  3. The code is at https://github.com/mozzwald/FujiNet-MIDIMaze but I have not been able to try over the internet. I can test with someone who has the CLKIN line wired to GPIO14 on the Nodemcu. Just need to share IP addresses and open/forward a port on the router.
  4. Finally got all the pieces to test out MIDI Maze with FujiNet and it works with UDP for 2 player games. Code is updated at https://github.com/mozzwald/FujiNet-MIDIMaze and for your viewing pleasure:
  5. Not really sure if there would be a benefit. FujiNet boots before the Atari does, unlike the Raspberry Pi which takes a long time. Wifi connection can take longer (a couple seconds or less) to get going, no where near the time it takes a Raspberry Pi to boot. We can boot from internal SPIFFS first, then load ATR over network by selecting it from the Atari (diskulator example). It's certainly possible to add the supercap, I just don't know if it's worth it. Maybe someone else has an idea or use case for it. You can also power the FujiNet from microusb.
  6. I've been experimenting with MIDI Maze and FujiNet to get networked game play working. My first test will be to pass the raw MIDI bytes back and forth between two machines. The FujiNet is using PWM to generate 31.250khz on the CLOCKIN pin. At this time I can trick the game into thinking it's the master by sending it a 0 and I can see a few bytes of MIDI notes sent before the game errors/times out. When I get another MIDI Maze cart I will test with 2 FujiNet/Atari systems. If this first test works, the next test would be to create a networked MIDI ring by having a MIDI-IN and MIDI-OUT TCP socket on each FujiNet for more than 2 players. Further down the road, I would like to have some kind of server that could tell each FujiNet which IP's to use so you could setup a game from a webpage. Thanks to @Fletch we have some data dumps of MIDI Maze startup and game play. I'm putting them here so they are available if anyone else needs them. MIDIMaze-data-capture.zip
  7. SIO thru doesn't really matter at this point. It's just a bonus hardware feature (if it works; no one has tested it yet since pcbs are not made). If you can build the posted schematic on breadboard or perfboard or deadbug (if you like 🙂 you will be good to go for testing.
  8. It's just spewing out bootloader messages on TX. If the Atari is off, nothing is there to read it so they go into the black hole of nothingness no buffering
  9. I managed to pull the SIO command functions from Thom's tests into my ZIModem Atari Fork and have successfully booted Bobterm from SPIFFS while still allowing the modem to work. The repo is updated here: https://github.com/mozzwald/Zimodem/tree/atari
  10. The only issue with using GPIO 1 & 3 for TX/RX is the esp8266 bootloader messages at startup. If you power up the FujiNet externally before turning on the Atari, it should not be a problem.
  11. I'm working on getting MIDI Maze to talk with the FujiNet so that we can play over the network. So far I have been able to trick MIDI Maze into thinking it's the master by sending it's MIDI data back to it. Does anyone know what commands and data are passed over MIDI for the game to work? Does it use standard midi commands like noteon and data is the position in the map or something different? Anyone have a dump of data passed during a game?
  12. Off the top of my head I dunno. I picked that one based on price and specs. You should be able to find something similar using a parametric search for thru hole. The important specs would be low forward voltage (schottky), capable of 1A or greater, 10V or greater. Same with the NPN's, probably any would work. @jeffpiep used 2N2222 and I only had 2N3904 (lower current limit) available in my parts bin. The signal lines aren't pushing much current. My smd board will use a different NPN.
  13. Thanks to @jeffpiep for figuring out a way to let the nodemcu boot while powered from SIO AND allowing other devices on the chain to work along side it (without a diode) using 2 NPN transistors and 2 resistors. It’s now buffered with an RTL inverter and Open collector inverter to make a buffer. CLOCKIN has been added to GPIO14 in hopes that we can get MIDI over WiFi working at some point (multiplayer MIDI MAZE over the internet anyone? ). CLOCKOUT was added by request. In my schematic there is a solder jumper (SJ1) that can connect CLOCKOUT to GPIO2. GPIO2 is used for debug serial output so the jumper is optional if you want to use CLOCKOUT and not have serial debug. Below is the updated schematic:
  14. Not required, just there as a current limiter. Are you still having problems? I thought you got it working
  15. Getting closer Since you have no pulldown on GPIO15 the nodemcu *must* be powered on before turning on the Atari, otherwise the nodemcu will not boot. Your serial debug log shows that it is booting with the Atari off. Powering up the Atari should show the command frame data. If you have SIO 5V connected to Vin on the nodemcu without a diode, remove it. You will need to power the nodemcu with the microusb cable.
  16. If you are getting output from TNFSD when disconnected from the Atari, it tells me that the nodemcu is probably not booting when connected to the Atari. This is likely an issue with DATAIN/GPIO15. Do you have the 2k pulldown on this line? Try it with the AtariWiFi as the only device on the SIO chain. Try to power the AtariWiFi up with MicroUSB before turning on the Atari. Just to clarify, to see serial debug messages when you have #define DEBUG_S uncommented in the code you need another separate USB to Serial adapter connected to GPIO2 and GND (GPIO2 is TX, connected to RX on the USB serial adapter). Then, in a serial terminal on the PC make sure you open the correct serial port for the second adapter at 19200 baud. The only thing you will see from the nodemcu MicroUSB port serial is the bootloader messages, then *nothing ever again* after it's booted. Make sure you set the Serial.begin() baud rate back to 19200 or the Atari can't talk to the nodemcu. Don't stop bothering me The feedback is helpful in making this better.
  17. If you've followed the schematic I posted in this thread, then there's no need to remove the Serial.swap(). TNFSD only shows that line which means the nodemcu mounted the TNFS directory. The nodemcu tries to open "autorun.atr" so make sure you have an ATR with that name in the path you define when running TNFSD (tnfsd /path/to/myatrdir). The serial monitor will not give you anything worth reading, only some bootloader msgs when powered on (garbage :). You can enable debug output in the sketch (near the top the note about uncomment for debug output) but the debug output is on GPIO2 and you'll need another usb/serial adapter connected to it and GND to get msgs. Also, debug serial printing slows it down considerably.
  18. You can use GPIO 1 & 3 for TX/RX but, make sure the nodemcu is powered up before turning on the atari and you will need to comment out/remove the Serial.swap() line from the sketch.
  19. The diode only prevents SIO from getting 5V USB power. The Nodemcu board already has a voltage regulator to step down the the input voltage from 5V to 3.3V (from both Vin and USB).
  20. Any SPDT on/off switch will work. It's just a commonly used on/off mini slide switch in small devices, and I have some.
  21. Your table is correct. Any single GND on the Nodemcu can go to either GND on SIO. Vin can go directly to 5V on SIO, but make sure you do not connect the Nodemcu Microusb to anything while it's plugged into the Atari or you will be pushing power back into it. If you add diode D2 (Schottky, ie 1N5819) then this is not an issue: D2 Vin-----|<-----SIO5V
  22. The biggest change to hardware is the fact that we no longer need the level shifter as the esp8266 is 5V *LOGIC* tolerant. The GPIO pins can handle voltages up to 5V, but the device must be powered with 3.3V still. This has actually been confirmed by the CEO of Espressif (on facebook of all places, see the comments in this link https://www.facebook.com/groups/1499045113679103/permalink/1731855033731442/?hc_location=ufi). The current schematic is below. The switch allows the device to be powered from the SIO 5V or from the MicroUSB port on the nodemcu, the diode prevents USB power from entering the SIO bus. The current topic of debate is with GPIO15 which if pulled HIGH when the esp8266 is powered on prevents it from booting normally. The 2k pull down resistor allows the esp8266 to boot, but pulls down DATAIN on the SIO bus to around 3.5V, iirc. This may or may not cause an issue with other devices on the chain. I tried and failed to get a NPN/Resistor/Capacitor pulldown to work. At any rate, the above schematic is tested working with 3 boards I have made.
  23. In the gist I left the sio_cmd_change function modified to do a digital read of the pin state. Not sure if that will be fast enough to use with the CHANGE interrupt mode.
  24. Messed around with what you posted a bit. We really need to know when the cmd pin is falling as that's when the cmd frame is starting. Your original code would freeze my nodemcu due to the debugI inside the interrupt handler function. The interrupt handler function should be as small as possible to not block the main loop (or so I've read). I still have sync problems at the start. Also, if Atari is powered off and back on without a reset of the Nodemcu, the sync gets worse. https://gist.github.com/mozzwald/f84692d942111a29a6764c2f45a35152
  25. I've designed a custom carrier board for the nodemcu with a new take on the SIO connector. OSHPark boards have shipped and should arrive this week. The new SIO connector uses round DSUB pins that solder directly to the PCB which slides part way into a 3D printed connector. This should make it smaller and easier to build (no need to cut, strip, crimp wires for SIO). Here's a test I did with an old SIO23V3 pcb: In the mean time I've been working on a case to put it all in: Below you can see how the pins sit on the carrier board: Lots of empty space in the bottom since the nodemcu sits on top and carrier board is dead center. Clips hold the two halves together, buttons for reset and flash, cut out for microusb: In the earlier stages of the case design I had posted some pictures on twitter. Someone had asked about making it a pass through device with SIO in and out. I think this could be done using the same technique but using male DSUB pins. The issue with adding it to this board would be placement of the nodemcu and having the microusb port accessible. If you rotate the nodemcu 90 degrees it would interfere with a neighboring SIO port if plugged into a device (like a disk drive). Or, it could have two ports with pins and you just use a cable to connect it.
  • Create New...