Jump to content


  • Content Count

  • Joined

  • Last visited

Posts posted by mozzwald

  1. 10 minutes ago, mytek said:

    Any possibility of having this work more like a standard SIO device, thus not requiring the cassette motor control line to enable it?


    Should be possible in software. Really, all we need is the command line and read the command. If it's not for the modem, ignore it. Could probably make it work exactly/similarly to an 850. I think motor ctrl is a good temporary solution, not needed ultimately. New R: handler is probably the best route as Thom suggests

    • Like 1

  2. 17 minutes ago, Dropcheck said:

    Okay here's two versions:


    Mozzwald if you could check the schematic and see if I missed something.  The NodeMCU sits in the female sockets with the usb towards the bottom.





    And SMT



    NodeMCU2SIOTH.pdf 39.82 kB · 3 downloads NodeMCU2SIOSMT.pdf 25.3 kB · 2 downloads

    Looked at the thru hole schematic and I think you have the mtr ctrl and cmd lines swapped like in my first wiring diagram. I'll hafta verify again with my actual hardware again when I get home.


    30 minutes ago, manterola said:

    I might be wrong but what I see from the schematics is that Atari control esp8266 tranmission and reception. But As I mentioned in my late post, the idea of MtrCtrl dictating when the TX and RX esp8266 lines are connected to the SIO bus won't allow us to make this SIO-Wifi device to answer (at least) Type 0 polls.

    The device itself (the esp8266) should be able to "lift" TX and RX from the sio bus, not the Atari.

    just my 2 cents

    As long as the esp8266 can see what is happening on the motor control and command lines, it can decide when to write or read the datain/dataout pins. So, if the esp8266 is supposed to be D1 and it reads a command for D2, it can ignore it. Likewise, it can respond to a D1 command. It's just a matter of making the code do that. Atarigeezer's hardware version which uses motor control to physically disconnect the tx/rx lines will not work like this.

  3. 7 minutes ago, Dropcheck said:

    I would like to make a carrier adapter for the level shifter board.  Can you tell me the over all dimensions and the width between the two rows of holes.  I'm assuming the hole spacing is 2.54mm(.1")

    The 8 channel one I have is 14mmx28mm, 2.54mm spacing. Rows are roughly 10.25mm spacing (uses up 5 rows on a breadboard)

  4. 10 hours ago, mozzwald said:

    I'm currently experimenting with the gpio's on the nodemcu (esp12e/f) to include connection with the proceed and interrupt SIO lines. I think those are what someone was going to use for a new Rhandler. 


    It's a bit tricky picking the gpios to use as some are used for bootloader / flashing.

    Here is my fixed and updated wiring diagram. I tried shifting some of the SIO lines to different GPIO's but had problems with the Nodemcu booting. This setup boots every time. Note, you must disconnect it from SIO to use the USB for programming (with interrupt/proceed connected). I could not get it to boot into programming mode when connected to SIO (Atari on or off). Some of the flash chip pins are shared with GPIO's and are likely being pulled down preventing programming mode. I don't really know if the Interrupt or Proceed lines work without pull up/down resistors, they are currently always high. Is there a way to toggle those from BASIC for testing?


    Is this a good plan: use the Nodemcu board as-is and create a carrier board with the level shifting and SIO connections? Basically have a plug in SIO Modem dongle.

  5. 38 minutes ago, Dropcheck said:

    How did you get the Arduino IDE to recognize this board?


    I've got one in my parts bin and a four channel level shifter, but I don't see the board listed in the Arduino IDE v1.8 to choose from.

    I can't check for sure til later when I get home. If you have the esp8266 board defs installed, its one of them. Iirc, it does have nodemcu in the name, likely the latest version number.

  6. 55 minutes ago, tschak909 said:

    I also have been talking with @mozzwald to get one of his rigs, as well.


    @mozzwald Hopefully with this, I can help cross-pollinate and make the firmware better, and we can come up with something that will work REALLY well for Atari users.



    I'm currently experimenting with the gpio's on the nodemcu (esp12e/f) to include connection with the proceed and interrupt SIO lines. I think those are what someone was going to use for a new Rhandler. 


    It's a bit tricky picking the gpios to use as some are used for bootloader / flashing.

  7. 5 hours ago, AtariGeezer said:

    Hmmm,  this new code implements CMD and MTR_CTRL as a Flow Control Option,  which means RTS / CTS can not be used with this new scheme...

    True, and I did think about this after the fact. It should be possible to move the command/motor control code out of the flow control options.

  8. 7 hours ago, a8isa1 said:

    In your ESP8266 sketch you have COMMAND connected to GPIO12 and Motor Control to 16.  In your schematic these are reversed.


    After switching my wires around to match the sketch I was able to communicate.   


    I'm not using a level converter.  I think everything is working. At least when I switched from MyDOS to SpartaDOS X all seems fine.


    Here is what else I've done.


    I restored DSR and DTR to the original GPIOs.  As you documented this should not matter.  Atari doesn't use these.  However, my v0.90 NodeMCU dev boards have N/C for GPIOs 9 and 10. 


    I also un-swapped your swapped RX and TX.  My wiring was already configured for GPIOs 1 & 3.


    Thanks for this, mozzwald!


    I'll let you know if I discover anything.  



    Oops, yeah, I have the CMD and MTR lines wrong the wiring diagram, sorry about that.


    You should probably use a level shifter, but to each his own. You may burn out the esp.


    The swap for TX/RX is to prevent the esp boot msgs from being sent to the Atari at power up. I thought it could interfere with boot. Keep this in mind if you have any issues booting with it connected.


    If you could try doing a file transfer and report your results it would be much appreciated. I can do small files ~15k or less but anything larger never starts and just times out using Bob Term.


    And yesterday I tested it with Platoterm at 1200 baud which worked great.

  9. 2 hours ago, mozzwald said:

    The problem is that when connected to a bbs, any SIO activity causes the connection to die and the modem is put back in AT command mode. There is a noticeable delay when the system tries to read from floppy. Then, I assume the connection is lost and the system reads from the disk just fine.


    In AT command mode, SIO activity is working fine.

    I found the problem. DTR code was causing the connection to break during disk activity. Removing that seems to be working. I sent and received a small txt file with xmodem. I will clean up the code and push changes to github tomorrow.

  10. 1 hour ago, Dropcheck said:

    I would ask for elevated bbs privilege to access the files area first.  Then try to dl from the actual bbs.  


    Try an unmodified version of zimodem with your server as a quality control.  If you also have the same issues, then it's not your modifications.  It's more likely settings. 

    The problem is that when connected to a bbs, any SIO activity causes the connection to die and the modem is put back in AT command mode. There is a noticeable delay when the system tries to read from floppy. Then, I assume the connection is lost and the system reads from the disk just fine.


    In AT command mode, SIO activity is working fine.

  11. 4 hours ago, Dropcheck said:

    I was able to dl with this bbs,

    I don't have access to the files area so I installed mystic bbs on a linux box at home. I am unable to send or receive files. When connected to a server, the disk access causes the connection to be dropped and the modem is put back in command mode. Looks like more work to be done in Zimodem code 🥴

  12. Just a few more notes about the setup...


    You can flash the nodemcu with the usb port as normal. When Zimodem starts up, it switches the TX & RX lines from the default GPIO 1 & 3 to GPIO 15 & 13. This prevents the bootloader messages from being spewed out to the atari at powerup. This also means, you will not see anything on a serial terminal on the computer when connected with the usb port (also the command & motor lines would need to be pulled low for transmission to occur). The 1k resistor on GPIO 15 is required to prevent the nodemcu bootloader from trying to boot from SD card at powerup.


    The pull down on Atari side Motor Control was needed as the level shifter wasn't pulled down enough to register a low reading.


    Can anyone recommend a bbs that has files available for download with Xmodem? I want to see if it will work with bobterm.

  13. 22 minutes ago, Dropcheck said:

    So it sounds like you might be using I2C on the NODEMCU.  Adafruit indicates that an alternative option for 4 channel Bi-directional level shifter is i2C friendly and that board is FET based.  Or maybe the 74LVC245 chip which has supposedly a stronger output drive

    Definitely not using i2c on the nodemcu. Not really sure what was causing the problem. I got garbage on both the atari and pc when testing with a usb to uart adapter. Also tried 2 different boards to make sure it wasn't a bad one.

  14. I've been fiddling around with my nodemcu (esp8266) board, Zimodem firmware and the atari and have been successful with using the modem while allowing the atari to still use the sio bus with minimal parts. I have a simple fet based level shifter (wiring diagram below, amazon part) that adds the motor control and command lines to nodemcu inputs. When either line is asserted, the Zimodem firmware allows other devices to communicate on the bus and ignores the transmission. 


    The modified firmware adds a new Flow Control type (FCT_AMTRCTL) which must be enabled for it to work. If you wish to flash the firmware to a previously used zimodem/esp board you should format the SPIFFS before flashing so that the new flow control will be selected by default, otherwise you will have issues with it not communicating as it will be set for some other flow control scheme (this issue bit me a couple times during testing). 


    The modified Zimodem (v3.5) firmware is in my github (atari branch) at https://github.com/mozzwald/Zimodem/tree/atari


    • Like 1

  15. Nice work. Do you have a URL for the $50 custom printed keycap set?



    Starglider aka Perifractic http://youtube.com/perifractic



    I *think* it can be done with the ANSI 87 Key Layout (6.50x Spacebar and Top Printed Keys) but I haven't completely verified it yet. Depending on available extra keys, might need to use the 104 layout.

    still would love a color matched bezel around the keys making them look integrated into the 400.

    Yes, I had that idea also and should be possible to 3d print something. Can add some screw holes to the keyboard pcb for attachment of the bezel

    • Like 1

  16. I've been looking into making a new keyboard for the 400 and picked up some sample switches and keys for experimentation. Regular cherry keys are quite tall but the low profile kailh brand keys are a bit shorter. To use the Kailh switches with Cherry keycaps you need an adapter which I 3D printed.



    Cherry keycaps are 18mm square and are meant to be on 19.05mm centers which does not allow the original 400 layout to be used. I came up with this layout. Any recommendations are welcome.


    The keycap samples I got are from MaxKeyboard. They seem a bit thin but I think they would be alright to use. It looks like you can get a complete set of custom printed keycaps for less than $50. This would allow for custom legends on the keycaps. I had one key printed as a sample and it looks good. The brown, orange and yellow keys don't match the original 400 colors but I think would look alright.


    I also made this 3D printed chicklet style key that fits the Kaihl switches. It's only 16mm square and I think would be possible to get the original A400 layout. Problem is making the legends on the keys. I had the idea to make an indent on the top of the keycap and have custom cut stickers with the legend to put in them. Then perhaps clear coat it for protection. This path seems like the most work and I'm not really sure how the sticker idea would hold up over time. But, this is probably the only way to keep the original layout (other than having expensive custom injection molded ones made).


    • Like 5

  17. I remember one of the after market keyboards, I think it was the B-key one, pictured in the very first post, came with extra keys of a different color so if you wanted you could have all the keys the same color, or some, like function keys, etc. in a different color. I've been kinda looking off and on the last few years for a 400 to pop -up on ebay, at the same time I have extra cash, with an after market keyboard.


    I really like the look and style of the 400 with the membrane keyboard, but I also know that my warm-fuzzy feeling for the original look of the 400 would wear thin after a while, and I'd want an after market keyboard like ones shown in this thread. But I'd rather have one like the B-key that has the lower profile and retains some of the 400's sleekness too. The ones that are raised all look terrible to me.


    I like the different colored keys of the 'B-key' and it's low profile, but I think the keyboard #2 in the first post looks the best out of all of them, nice and neat rows and no keys sticking out like the 'B-key.' BUT, I think it's probably a little too cramped, the 'B-key' keyboard looks like they got it closer to full-stroke size. The 'B-key' keyboard is the one I've been looking for on a 400.

    These low profile Cherry MX keys might be an option for a new replacement keyboard:




    Not sure if keycaps are available for them specifically.


    Edit: Just found these (different brand) keys and keycaps:



    • Like 1
  • Create New...