Jump to content
Have You Played Atari Today?
2600|5200|7800|Lynx|Jaguar|Forums|Store  

jokker

Members
 View Profile  See their activity

  • Content Count

    33

  • Joined

  • Last visited

Posts posted by jokker

  2. Posted

    9 hours ago, mozzwald said:

    The diode is needed if you want to have other SIO devices on the same bus. It emulates an open collector pin.

    Ok cool, I'm the only device on the bus so then it's good for now.

     

    I'll order up some diodes I guess and for the future now that I know. Always happy to learn a little bit more about anything. Admittedly when the final product is available I'll certainly order one to support its existence, but for now I like having something new to tinker with. Who knows maybe I'll even be useful in some way with contributing something. :D

     

    Thanks again for the help and guidance!

    • Like 5

  3. Posted

    21 minutes ago, jamm said:

    Well, I'm glad you've found where the issue is!  I can't speak much about the hardware, unfortunately.  Maybe @mozzwald can jump in later with an answer to your questions.

     

    Indeed I can get interaction between the fuji/atari/tnfsd albeit with regular UART timeouts and also issues with timeouts getting directories from tnfsd as well. They are at least talking now so I'm happy with that.

     

    The UART timeouts seemed to go away when I enabled HSIO on my U1MB but having them disabled caused regular timeouts in the SIO communication. (No idea if that's expected or not)

     

    regarding tnfsd interaction

    TNFS >> TX cmd: READDIR, len: 1
            [4567 05 11] 01
    Timeout after 6000 milliseconds. Retrying
    TNFS >> TX cmd: READDIR, len: 1
            [4567 06 11] 01
    TNFS << RX cmd: READDIR, len: 3, response (0): Success
            [4567 06 11] 00 2e 00
    TNFS >> TX cmd: READDIR, len: 1
            [4567 07 11] 01
    Timeout after 6000 milliseconds. Retrying
    TNFS >> TX cmd: READDIR, len: 1
            [4567 08 11] 01
    Timeout after 6000 milliseconds. Retrying
    TNFS >> TX cmd: READDIR, len: 1
            [4567 09 11] 01

     

     

    It does seem to work sporadically though....so hey I'll take the partial win :D

  4. Posted

    21 minutes ago, jamm said:

    You're right - that exactly what it looks like.  The obvious thing is to double-check the DATAIN going to the Atari.  That's GPIO17 on the WOOVER ESP32 and GPIO21 on the WOVER.  Have you checked to see if your Atari can talk to other SIO devices?  Do you have anything else plugged in the the daisy chain simultaneously?

    Well I think I figured it out...it's my diode choices...I didn't have a schottky so I just used an IN4004 and tried a IN4007...so with that none work but if I pull it out then things are starting to work now.

     

    How important is that diode for DATAIN? is there back-current on that line? Again forgive me for my hardware insolence as like I said I'm "real" rusty on it. I am trying to read up again but it'll take some time. :D

     

     

  5. Posted

    On 5/22/2020 at 1:02 AM, jamm said:

    There's a chance this got fixed in a patch I uploaded recently.  Can you download and build the latest firmware, making sure to "Erase Flash" before updating the device and trying again?

    Gave it a go and no such luck yet...so I guess I'll have to keep digging it to figure out what's going wrong.

     

    I really seems like although the Fuji gets data from the Atari, the Atari isn't getting anything back from the Fuji. Perhaps i've wired something up incorrectly or something else.

     

     

  6. Posted

    3 hours ago, jamm said:

    Nothing unusual there. All I can think to do is to add more debugging information to the output so we can get a better idea of what's being sent to the Atari over SIO.  I'm pretty busy at work right now, so it may take me a couple of days to get back to you, though.  I'll check back in soon.

    No worries, thanks for having the glance. It at least tells me I'm on the right track. Heck if I ever want to contribute in any meaningful way it's a good idea I understand how it all works.

    • Like 2

  9. Posted

    Hi all,

     

    So I grabbed a copy of NodeMCU ESP32 boards and I've got things hooked up right it seems as I can see the SIO traffic flying around but the config tool never seems to find the MAC address. I don't see any errors in the debugging log and I've tried both booting up and trying for the automatic load as well as using the U1MB+SIDE2 loader and loading the autorun.atr directly. Application loads up fine but never finds anything and the MAC is all zeroes.

     

    Here's some output from the log and if I can provide anything else let me know or give me some suggestions about debugging the issues. Thanks in advance

     

    FujiNet PlatformIO Started @ 41
    Starting heap: 235500
    [E][sd_diskio.cpp:739] sdcard_mount(): f_mount failed 0x(3)
    SD Card Mount Failed
    SD Card Type: NONE
    fnConfig::load
    fnConfig deleting configuration file and skipping SD check
    disk MOUNT
    mounting ATR to Disk: /autorun.atr
    num_para: 5760
    sectorSize: 128
    num_sectors: 720
    mounted.
    NETWORK DEVICE 0x00 ADDED!
    NETWORK DEVICE 0x01 ADDED!
    NETWORK DEVICE 0x02 ADDED!
    NETWORK DEVICE 0x03 ADDED!
    NETWORK DEVICE 0x04 ADDED!
    NETWORK DEVICE 0x05 ADDED!
    NETWORK DEVICE 0x06 ADDED!
    NETWORK DEVICE 0x07 ADDED!
    MODEM ADDED!
    using SPIFFS for printer storage
    Printer output file (re)opened
    ~filePrinter
    ~printer_emu
    Printer output file (re)opened
    21 devices registered
    SIO SETUP
    SIO Voltage: 4733
    Available heap: 177084
    Setup complete @ 550 (509ms)
    Starting web server on port 80
    O_KEY: LONG PRESS
    Index request handler
    Opening file for parsing: '/www/index.html'
    File_in_query request handler '/file?style.css'
    File_in_query request handler '/file?selectedprinter.js'
    File_in_query request handler '/file?logo.png'
    File_in_query request handler '/file?printer.svg'

    00:18.580 CF: 70 fe 00 00 6f
    sioFuji::sio_process() called
    ACK!
    Fuji cmd: GET SSID
    COMPLETE!

    00:18.667 CF: 70 fe 00 00 6f
    sioFuji::sio_process() called
    ACK!
    Fuji cmd: GET SSID
    COMPLETE!

    00:18.734 CF: 70 fe 00 00 6f
    sioFuji::sio_process() called
    ACK!
    Fuji cmd: GET SSID
    COMPLETE!

    00:18.800 CF: 70 fe 00 00 6f
    sioFuji::sio_process() called
    ACK!
    Fuji cmd: GET SSID
    COMPLETE!

    00:18.867 CF: 70 fe 00 00 6f
    sioFuji::sio_process() called
    ACK!
    Fuji cmd: GET SSID
    COMPLETE!

    00:18.934 CF: 70 fe 00 00 6f
    sioFuji::sio_process() called
    ACK!
    Fuji cmd: GET SSID
    COMPLETE!

    00:19.001 CF: 70 fe 00 00 6f
    sioFuji::sio_process() called
    ACK!
    Fuji cmd: GET SSID
    COMPLETE!

    00:19.067 CF: 70 fe 00 00 6f
    sioFuji::sio_process() called
    ACK!
    Fuji cmd: GET SSID
    COMPLETE!

    00:19.134 CF: 70 fe 00 00 6f
    sioFuji::sio_process() called
    ACK!
    Fuji cmd: GET SSID
    COMPLETE!

    00:19.201 CF: 70 fe 00 00 6f
    sioFuji::sio_process() called
    ACK!
    Fuji cmd: GET SSID
    COMPLETE!

    00:19.268 CF: 70 fe 00 00 6f
    sioFuji::sio_process() called
    ACK!
    Fuji cmd: GET SSID
    COMPLETE!

    00:19.334 CF: 70 fe 00 00 6f
    sioFuji::sio_process() called
    ACK!
    Fuji cmd: GET SSID
    COMPLETE!

    00:19.401 CF: 70 fe 00 00 6f
    sioFuji::sio_process() called
    ACK!
    Fuji cmd: GET SSID
    COMPLETE!

    00:19.468 CF: 70 fe 00 00 6f
    sioFuji::sio_process() called
    ACK!
    Fuji cmd: GET SSID
    COMPLETE!

    00:19.532 CF: 70 e8 00 00 59
    sioFuji::sio_process() called
    ACK!
    Fuji cmd: GET ADAPTER CONFIG
    COMPLETE!

    00:19.635 CF: 70 e8 00 00 59
    sioFuji::sio_process() called
    ACK!
    Fuji cmd: GET ADAPTER CONFIG
    COMPLETE!

    00:19.735 CF: 70 e8 00 00 59
    sioFuji::sio_process() called
    ACK!
    Fuji cmd: GET ADAPTER CONFIG
    COMPLETE!

    00:19.835 CF: 70 e8 00 00 59
    sioFuji::sio_process() called
    ACK!
    Fuji cmd: GET ADAPTER CONFIG
    COMPLETE!

    00:19.935 CF: 70 e8 00 00 59
    sioFuji::sio_process() called
    ACK!
    Fuji cmd: GET ADAPTER CONFIG
    COMPLETE!

    00:20.035 CF: 70 e8 00 00 59
    sioFuji::sio_process() called
    ACK!
    Fuji cmd: GET ADAPTER CONFIG
    COMPLETE!

    00:20.135 CF: 70 e8 00 00 59
    sioFuji::sio_process() called
    ACK!
    Fuji cmd: GET ADAPTER CONFIG
    COMPLETE!

    00:20.235 CF: 70 e8 00 00 59
    sioFuji::sio_process() called
    ACK!
    Fuji cmd: GET ADAPTER CONFIG
    COMPLETE!

    00:20.336 CF: 70 e8 00 00 59
    sioFuji::sio_process() called
    ACK!
    Fuji cmd: GET ADAPTER CONFIG
    COMPLETE!

    00:20.436 CF: 70 e8 00 00 59
    sioFuji::sio_process() called
    ACK!
    Fuji cmd: GET ADAPTER CONFIG
    COMPLETE!

    00:20.519 CF: 70 fd 00 00 6e
    sioFuji::sio_process() called
    ACK!
    Fuji cmd: SCAN NETWORKS
    scanNetworks returned 1
    COMPLETE!

    00:26.139 CF: 70 fe 00 00 6f
    sioFuji::sio_process() called
    ACK!
    Fuji cmd: GET SSID
    COMPLETE!

    00:26.227 CF: 70 fe 00 00 6f
    sioFuji::sio_process() called
    ACK!
    Fuji cmd: GET SSID
    COMPLETE!

    00:26.294 CF: 70 fe 00 00 6f
    sioFuji::sio_process() called
    ACK!
    Fuji cmd: GET SSID
    COMPLETE!

    00:26.360 CF: 70 fe 00 00 6f
    sioFuji::sio_process() called
    ACK!
    Fuji cmd: GET SSID
    COMPLETE!

    00:26.427 CF: 70 fe 00 00 6f
    sioFuji::sio_process() called
    ACK!
    Fuji cmd: GET SSID
    COMPLETE!

    00:26.494 CF: 70 fe 00 00 6f
    sioFuji::sio_process() called
    ACK!
    Fuji cmd: GET SSID
    COMPLETE!

    00:26.561 CF: 70 fe 00 00 6f
    sioFuji::sio_process() called
    ACK!
    Fuji cmd: GET SSID
    COMPLETE!

    00:26.627 CF: 70 fe 00 00 6f
    sioFuji::sio_process() called
    ACK!
    Fuji cmd: GET SSID
    COMPLETE!

    00:26.694 CF: 70 fe 00 00 6f
    sioFuji::sio_process() called
    ACK!
    Fuji cmd: GET SSID
    COMPLETE!

    00:26.761 CF: 70 fe 00 00 6f
    sioFuji::sio_process() called
    ACK!
    Fuji cmd: GET SSID
    COMPLETE!

    00:26.828 CF: 70 fe 00 00 6f
    sioFuji::sio_process() called
    ACK!
    Fuji cmd: GET SSID
    COMPLETE!

    00:26.894 CF: 70 fe 00 00 6f
    sioFuji::sio_process() called
    ACK!
    Fuji cmd: GET SSID
    COMPLETE!

    00:26.961 CF: 70 fe 00 00 6f
    sioFuji::sio_process() called
    ACK!
    Fuji cmd: GET SSID
    COMPLETE!

    00:27.028 CF: 70 fe 00 00 6f
    sioFuji::sio_process() called
    ACK!
    Fuji cmd: GET SSID
    COMPLETE!

    00:27.092 CF: 70 e8 00 00 59
    sioFuji::sio_process() called
    ACK!
    Fuji cmd: GET ADAPTER CONFIG
    COMPLETE!

    00:27.195 CF: 70 e8 00 00 59
    sioFuji::sio_process() called
    ACK!
    Fuji cmd: GET ADAPTER CONFIG
    COMPLETE!

    00:27.295 CF: 70 e8 00 00 59
    sioFuji::sio_process() called
    ACK!
    Fuji cmd: GET ADAPTER CONFIG
    COMPLETE!

    00:27.395 CF: 70 e8 00 00 59
    sioFuji::sio_process() called
    ACK!
    Fuji cmd: GET ADAPTER CONFIG
    COMPLETE!

    00:27.495 CF: 70 e8 00 00 59
    sioFuji::sio_process() called
    ACK!
    Fuji cmd: GET ADAPTER CONFIG
    COMPLETE!

    00:27.595 CF: 70 e8 00 00 59
    sioFuji::sio_process() called
    ACK!
    Fuji cmd: GET ADAPTER CONFIG
    COMPLETE!

    00:27.695 CF: 70 e8 00 00 59
    sioFuji::sio_process() called
    ACK!
    Fuji cmd: GET ADAPTER CONFIG
    COMPLETE!

    00:27.795 CF: 70 e8 00 00 59
    sioFuji::sio_process() called
    ACK!
    Fuji cmd: GET ADAPTER CONFIG
    COMPLETE!

    00:27.896 CF: 70 e8 00 00 59
    sioFuji::sio_process() called
    ACK!
    Fuji cmd: GET ADAPTER CONFIG
    COMPLETE!

    00:27.996 CF: 70 e8 00 00 59
    sioFuji::sio_process() called
    ACK!
    Fuji cmd: GET ADAPTER CONFIG
    COMPLETE!

    00:28.079 CF: 70 fd 00 00 6e
    sioFuji::sio_process() called
    ACK!
    Fuji cmd: SCAN NETWORKS
    scanNetworks returned 2
    COMPLETE!

    • Sad 1

  11. Posted

    Yeah so I also messed with this and I set my disconnmode to 80 and now my wimodem232 works in raw mode. Syncterm works as well when raw mode is selected. NetRunner still didn't work at all.

     

    I don't think you can have both or a setting that does both unfortunately. I think everything still works just fine from a non-downloading point of view though. I guess you can advertise RAW mode for downloads or something?

     

    I was looking at the telnet RFC's to understand the terminal types and while you could set it to ANSI which has the binary mode (which I think it's the equivalent to RAW is it not?) then theoretically you can have "both" I would think. Although I wasn't able to get downloads to work with telnet modem and my terminal was set to ANSI which supports BINARY mode even when I had telnet translation enabled on my wimodem232. Maybe the UDS doesn't support it? Perhaps I'll play around with my other UDS and see if I can make it talk about it's supported options. Maybe there is a common ground or something.

     

    I guess you can clearly indicate what mode you are using when people go into your download section?

    I don't know what the prevailing method is on the net for things like NetFossil, Synchronet, or UDS.

     

    Just for the record my BBS UDS-10 is configured like this:

    *** Channel 1
    Baudrate 38400, I/F Mode 4C, Flow 02
    Port 04000
    Connect Mode : 56
    Auto increment source port disabled
    Remote IP Adr: --- none ---, Port 00000
    Disconn Mode : 80  Disconn Time: 05:00
    Flush   Mode : 44

     

    I should really up the baudrate though it can go a lot faster since it's on a PC with real 16550 UART's

     

    _Troy

  12. Posted

    So I gave it a try with a few things with strangely mixed results...

     

    With a WiModem232 on a Mega STE using FZDT (Modem 1 port)

    raw mode - failed

    telnet mode - failed

    Also various speeds, with/without RTS/CTS, with HSMODEM and without, different protocols, all failed

     

    With NetRunner Beta 18 (Win32) - also failed?! This surprised me...

    Syncterm (Win32) - worked! Although I can't remember if it was raw or telnet, so I might try them again to see if one worked over the other

     

    Having different results with the Windows apps is odd to me but again it could be one mode over the other.

     

    I'm not 100% on the reasoning but raw vs telnet is just that certain telnet byte sequences have to be handled properly were as raw is just pure 8-bit data across the connection. I think the documentation for tcpser explains it much clearer.

  14. Posted

    Actually another group that might be interested are people who own VIDIOT board based arcade/pinball hybrids such Granny & The Gators and Baby Pacman. These use the 9928 as the arcade portion display. I am one of these people and I think I might have to pick one of these up to test it out as an alternative option for those boards!

     

    Thanks for bringing this to life all those involved in making it happen!

  16. Posted

    I remember Captain Blood being one of those obscure games that only worked with TOS 1.0. I was never able to play that game on my 520STFM with TOS 1.2. This was a long time ago, but I remember being disappointed because it was one of the few games that only worked on old hardware. I'm not sure how accurate these memories are, being so long ago. Copy protection and memory issues could have been the problem.

     

    I would love to be able to play the game after all this time. I haven't thought about Captain Blood in 15 years. Thanks for the links!

     

    It should be alright with at least 1.02 as I played that game constantly on a Mega ST2 back in the day. That was the game that got me into Jean Michel Jarre with that intro song being a edited down version of Ethnicolour.

  19. Posted

    Hey thanks for the reply,

     

    So I re-seated the POKEY - no change

    Tried another known working POKEY from an 800XL - no change

    Checked the POKEY socket - socket is fine

    Checked the keyboard connector - connector is fine

    Tried 400 POKEY in the 800XL - works just fine

     

     

    So I guess the POKEY is a ok it seems. Perhaps something else has shorted somewhere on the board. Visual inspection hasn't provided me any clues as of yet sadly. I gave all the socketed chips on the board a firm push to make sure there was a good fitting.

     

    Any other thoughts?

     

    Thank you again!

     

    Have you cleaned both the male & female keyboard connectors with rubbing alcohol? Have you re-seated the POKEY?

     

    As a side note, if you Armor-All the old broken 400 Keyboard, and put it in a black frame, behind glass, it makes a really cool office decoration.

  20. Posted

    Hey all,

     

    Hoping I can find some help with this odd keyboard issue on an Atari 400. It's a brand new keyboard to replace an older one that's basically rotted and fallen apart. I remember it still working with the non-destroyed keys until I put it away for a bit until I got a better keyboard. So I pulled it apart and plugged in the new keyboard and well no keys work except for Reset, Option, Select, Start and break. No other keys seem to respond at all. I plugged in the old keyboard and it exhibits the same issue.

     

    I put in some disks and checked that the 400 itself seems to be ok. I loaded up SpartaDos, Jumpman from disk and Basic and Assembler cartridges. I didn't encounter any problems at all except for the lack of keyboard functionality.

     

    Could this be a sign of the POKEY giving up the ghost or is there another something else I can look at. I'm pretty new to the 8bit Atari line as I'm more of an ST guy. Still it's always nice to play around with another platform. :)

     

    Thanks very much in advance for any help!

  21. Posted

    Another important thing to know about the Mega series is that there is no FM modulator present. You have to have an Atari monitor to use it for the colour resolutions (ST Low & ST Medium). You can get an adapter that will let you connect a VGA monitor to it but it will only work in monochrome high resolution mode.

  22. Posted

    Hi all,

     

    So I managed to get my hands on an Mega ST2 and I would really like to get it working again if possible. I have a 520ST and a 1040ST available for parts if necessary (prefer to not part out the 1040 if I have to because it already works great). The 520 is the variety requiring an external brick power supply of which I don't have so I'm happy to use it up.

     

    So anyways, it's a stock Mega ST2 NTSC so nothing out of the ordinary there. It's only able to boot to a pure white screen using an SC1224 (that works fine as I use it with the 1040 for now). I've tested the TOS roms in my 1040 and they work fine so I know it's not a ROM issue. Are the GLUE, DMA, Shifter, etc chips compatible with the ones from the 520?

     

    I'll post a link to the motherboard picture for convenience, as it's quite large to allow for lots of detail.

    Motherboard of Mega ST2

     

    I'm no stranger to using a soldering iron and I have a decent multimeter as far as tools go.

     

    So thank you again for any and all help and if you need further pictures or information, I'll make sure to get it asap.

     

    (I also posted this on Atari Forum if anyone notices a similarity)

  23. Posted

    Hey AX, sorry to bother since I know you've got enough going on. Any chance you've managed to follow up on this? It's still not here so I'm figuring it's lost to the ages. :(

     

     

    So has everyone got theirs yet? Still awaiting mine sadly...

     

     

    Yep, they were sent quite some time ago, and this is the only that doesn't appear to have made it's destination. I'm not able to get at my customers DCN forms at the minute because of the move, but can confirm it was sent. This was international, but even by those standards is looking very slow.

     

    AX

AtariAge
Forums
Store
General
Follow AtariAge

Copyright ©1998-2021 AtariAge

×
×
  • Create New...