Lastic Posted November 15, 2019 Share Posted November 15, 2019 12 minutes ago, tschak909 said: power via the USB. Also be sure to get the latest version of the code, as I made a change for a8isa and his NodeMCU 0.9 board. -Thom It is the latest code, I just double-checked. Powered via USB whilst connected to SIO , nothing happens. The only output I get on TNFSD is that line I posted when I connect the NodeMCU via USB to my laptop. I'll reset my NodeMCU tomorrow to factory settings to be sure that nothing is lingering on it. Since the serial monitor is also spitting out gibberish in the Arduino IDE, that might be the quickest solution to start troubleshooting again. Link to comment Share on other sites More sharing options...
tschak909 Posted November 15, 2019 Author Share Posted November 15, 2019 @mozzwald may want to weigh in on this. but, I'm guessing your serial pins are not swapped like they are on our current board. you'll probably need to remove Serial.swap(); from the setup() function, and try again. -Thom Link to comment Share on other sites More sharing options...
mozzwald Posted November 16, 2019 Share Posted November 16, 2019 2 hours ago, Lastic said: It is the latest code, I just double-checked. Powered via USB whilst connected to SIO , nothing happens. The only output I get on TNFSD is that line I posted when I connect the NodeMCU via USB to my laptop. I'll reset my NodeMCU tomorrow to factory settings to be sure that nothing is lingering on it. Since the serial monitor is also spitting out gibberish in the Arduino IDE, that might be the quickest solution to start troubleshooting again. 2 hours ago, tschak909 said: @mozzwald may want to weigh in on this. but, I'm guessing your serial pins are not swapped like they are on our current board. you'll probably need to remove Serial.swap(); from the setup() function, and try again. -Thom 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. 1 Link to comment Share on other sites More sharing options...
tschak909 Posted November 16, 2019 Author Share Posted November 16, 2019 I commissioned this laptop from Ben Heckendorn in 2006. I asked him to provide an SIO port. Luckily, this means that I can Attach the #AtariWiFi board to it, and boot Jumpman off the Internet! The USB connector is providing power. 6 Link to comment Share on other sites More sharing options...
a8isa1 Posted November 16, 2019 Share Posted November 16, 2019 (edited) I have a new problem. Yesterday, I watched tschak909's latest video and realized my transfers are much slower, perhaps only 1/3 the speed. Trying to troubleshoot my earlier problem I enabled the debugging. When it occured to that I have no way to read data from GPIO 2. I tried to connect the USB cable. I didn't think I'd be able to see anything legible but I wanted to see if anything was happening. As you already know I did find something and it led to a solution. Back to my slow disk reads... I had forgotten to disable debugging. That's why it's running slow. However, I did finally disable it the disk loading doesn't work at all. Just Atari *raspberries*. Same results with two separate dev boards. When I re-enable debugging it starts working again. Any Suggestions? -SteveS Edited November 16, 2019 by a8isa1 Link to comment Share on other sites More sharing options...
tschak909 Posted November 16, 2019 Author Share Posted November 16, 2019 You will probably want to mess with timing. Find the delayMicroseconds() commands and start fiddling with them a bit. btw, debugging is typically disabled by default, and only available by #defining DEBUG_S, did you do this at first? -Thom Link to comment Share on other sites More sharing options...
Faicuai Posted November 16, 2019 Share Posted November 16, 2019 14 hours ago, tschak909 said: I commissioned this laptop from Ben Heckendorn in 2006. I asked him to provide an SIO port. Luckily, this means that I can Attach the #AtariWiFi board to it, and boot Jumpman off the Internet! The USB connector is providing power. Very, VERY nice... Wow... quite a privilege to witness how on old dream seems to be finally coming true... one SIO-port at a time! ? It would be really good if the SIO connection can be driven at divisor 5 or lower.... like <=2... or being able to sustain an effective >= 8 KBytes/sec throughput. A LOT of stuff will run / boot just nicely at that speed! Bring it on! Link to comment Share on other sites More sharing options...
tschak909 Posted November 16, 2019 Author Share Posted November 16, 2019 @Faicuai it's very early at the moment, we're still trying to get those of us testing up and running on dev hardware. For those who want to know how things will proceed, please read carefully: I am currently trying to write test programs to implement each tiny piece of functionality individually. You'll see lots of little increments of things coming online, followed by a long pause while all of these little tests are studied, and a production firmware is written from the ground up using what has been collected from all of these tests. -Thom 1 Link to comment Share on other sites More sharing options...
tschak909 Posted November 16, 2019 Author Share Posted November 16, 2019 FOR ANYONE WHO WANTS TO HELP: I need somebody who is decent enough at writing test programs, either in BASIC or Assembler to do SIOV calls to test functionality. For reference, here is an example bit of functionality in BASIC to get network info using the netInfo test program: 10 REM DISPLAY NETWORK INFORMATION 11 INFO$=" " 20 DCB=768 30 POKE DCB,112:REM $70 (NETWORK) 40 POKE DCB+1,1:REM UNIT 1 50 POKE DCB+2,33:REM GET INFO 60 POKE DCB+3,64:REM READ FROM ADAPTR 70 ADDR=ADR(INFO$) 80 ADDRH=INT(ADDR/256) 90 ADDRL=ADDR-(ADDRH*256) 100 POKE DCB+4,ADDRL:REM BUFFER LO 110 POKE DCB+5,ADDRH:REM BUFFER HI 120 POKE DCB+6,15:REM TIMEOUT 130 POKE DCB+8,64:REM 64 BYTES 140 POKE DCB+9,0 150 POKE DCB+10,0:REM AUX1=0 160 POKE DCB+11,0:REM AUX2=0 170 X=USR(ADR("h Yd`")) 200 PRINT CHR$(125) 210 PRINT "ATARIWIFI TEST PROGRAM #8: BA SIC VER." 220 PRINT 230 PRINT "SSID: ";INFO$(1,32) 240 END -Thom 1 Link to comment Share on other sites More sharing options...
Jinks Posted November 16, 2019 Share Posted November 16, 2019 I prefer the sio 2 bt was super cheap and easy to use 1 Link to comment Share on other sites More sharing options...
tschak909 Posted November 16, 2019 Author Share Posted November 16, 2019 6 minutes ago, Jinks said: I prefer the sio 2 bt was super cheap and easy to use Good for you. This does a lot more than the SIO2BT ever could, and infinitely more reliable. -Thom Link to comment Share on other sites More sharing options...
Jinks Posted November 16, 2019 Share Posted November 16, 2019 3 minutes ago, tschak909 said: Good for you. This does a lot more than the SIO2BT ever could, and infinitely more reliable. -Thom Wifi probably has no limits to file sizes etc. Link to comment Share on other sites More sharing options...
tschak909 Posted November 16, 2019 Author Share Posted November 16, 2019 Just now, Jinks said: Wifi probably has no limits to file sizes etc. It's much more than disk emulation. How are you not understanding this? This device is providing three main device types: "D:" emulation for a good out of the box use: using disk images over a network "R:" to provide a WiFi-Modem emulation for modem programs "N:" to provide a new Network device for handling TCP and UDP traffic to do real network card type things. -Thom 1 Link to comment Share on other sites More sharing options...
Faicuai Posted November 16, 2019 Share Posted November 16, 2019 (edited) 2 minutes ago, tschak909 said: It's much more than disk emulation. How are you not understanding this? This device is providing three main device types: "D:" emulation for a good out of the box use: using disk images over a network "R:" to provide a WiFi-Modem emulation for modem programs "N:" to provide a new Network device for handling TCP and UDP traffic to do real network card type things. -Thom Don't sweat it, Thom. Stay focused. This baby is HOT (!)... Bring it on! Edited November 16, 2019 by Faicuai Link to comment Share on other sites More sharing options...
Jinks Posted November 16, 2019 Share Posted November 16, 2019 (edited) Dont worry about me please. If you don't know me maybe I am coming off as a real douche. But I dont know much about anything when it comes to computers etc. Looks interesting what your creating. Best of luck. I will read ALL of this topic. Edited November 16, 2019 by Jinks Link to comment Share on other sites More sharing options...
tschak909 Posted November 16, 2019 Author Share Posted November 16, 2019 This #AtariWiFi test deals with testing the transfer of data from the Atari computer back to the peripheral over SIO. The setting of network configuration data seemed appropriately simple enough. To drive home the flexibility of working with the adapter, this test was coded in BASIC. Code, as always, is here: http://github.com/tschak909/atariwifi in the tests/config folder. 1 Link to comment Share on other sites More sharing options...
tschak909 Posted November 16, 2019 Author Share Posted November 16, 2019 The BASIC source code for this config test is: 100 REM CONFIG TEST 110 DIM CONFIG$(512),INFO$(64),SSID$(32) ,KEY$(64),S$(4) 111 ? CHR$(125) 120 PRINT "INITIALIZING CONFIG BUFFER... " 130 FOR X=1 TO 512:CONFIG$(X,X)="?":NEXT X 140 PRINT "INITIALIZING NETINFO BUFFER.. ." 150 FOR X=1 TO 64:CONFIG$(X,X)="?":NEXT X 151 FOR X=1 TO 4:S$(X,X)="?":NEXT X 160 ? 170 DCB=768:REM $0300 200 PRINT "SSID";:INPUT SSID$ 210 PRINT "PASSWORD";:INPUT KEY$ 220 ? 230 PRINT "WRITING NEW CONFIGURATION..." 231 FOR X=1 TO LEN(SSID$):CONFIG$(X+4,X+ 4)=SSID$(X,X):NEXT X 232 FOR X=1 TO LEN(KEY$):CONFIG$(X+36,X+ 36)=KEY$(X,X):NEXT X 240 POKE DCB,112:REM DEVICE $70 250 POKE DCB+1,1:REM UNIT 1 260 POKE DCB+2,34:REM SET CONFIG 261 POKE DCB+3,128:REM DO A WRITE 270 ADDR=ADR(CONFIG$) 280 ADDRH=INT(ADDR/256) 290 ADDRL=ADDR-(ADDRH*256) 300 POKE DCB+4,ADDRL:REM BUFLO 310 POKE DCB+5,ADDRH:REM BUFHI 320 POKE DCB+6,15:REM 15SEC TIMEOUT 330 POKE DCB+8,0:REM DBYTLO 340 POKE DCB+9,2:REM DBYTHI (512) 350 POKE DCB+10,0:REM AUX1=0 360 POKE DCB+11,0:REM AUX2=0 370 X=USR(ADR("h Yd`")):REM PLA, JSR SIO V, RTS, CALL SIOV 380 IF PEEK(DCB+3)=138 THEN ? "TIMEOUT." :GOTO 500 390 IF PEEK(DCB+3)=139 THEN ? "NAK.":GOT O 500 400 IF PEEK(DCB+3)=1 THEN ? "SUCCESSFUL. ":GOTO 500 500 ? "WAITING FOR NETWORK..." 510 POKE DCB+2,83:REM GET STATUS 520 POKE DCB+3,64:REM DO A READ 530 ADDR=ADR(S$) 540 ADDRH=INT(ADDR/256) 550 ADDRL=ADDR-(ADDRH*256) 560 POKE DCB+4,ADDRL:REM BUFLO 570 POKE DCB+5,ADDRH:REM BUFHI 580 POKE DCB+6,15:REM 15SEC TIMEOUT 590 POKE DCB+8,4:REM DBYTLO (4 BYTES) 600 POKE DCB+9,0:REM DBYTHI 610 POKE DCB+10,0:REM AUX1=0 620 POKE DCB+11,0:REM AUX2=0 630 X=USR(ADR("h Yd`")):REM PLA, JSR SIO V, RTS, CALL SIOV 640 IF PEEK(DCB+3)=138 THEN ? "TIMEOUT.. .":GOTO 760 650 IF PEEK(DCB+3)=139 THEN ? "NAK.":GOT O 760 660 IF PEEK(DCB+3)=1 THEN GOTO 700 700 IF S$(1,1)="?" THEN GOTO 750 710 GOTO 510:REM RETRY STATUS 750 PRINT "CONNECTED." 760 END Link to comment Share on other sites More sharing options...
tschak909 Posted November 17, 2019 Author Share Posted November 17, 2019 An actual reaction to somebody booting Boulderdash from a TNFS server on the Internet on their Atari 8-bit with #AtariWiFi. 3 Link to comment Share on other sites More sharing options...
Faicuai Posted November 17, 2019 Share Posted November 17, 2019 6 hours ago, tschak909 said: FOR ANYONE WHO WANTS TO HELP: I need somebody who is decent enough at writing test programs, either in BASIC or Assembler to do SIOV calls to test functionality. For reference, here is an example bit of functionality in BASIC to get network info using the netInfo test program: 10 REM DISPLAY NETWORK INFORMATION 11 INFO$=" " 20 DCB=768 30 POKE DCB,112:REM $70 (NETWORK) 40 POKE DCB+1,1:REM UNIT 1 50 POKE DCB+2,33:REM GET INFO 60 POKE DCB+3,64:REM READ FROM ADAPTR 70 ADDR=ADR(INFO$) 80 ADDRH=INT(ADDR/256) 90 ADDRL=ADDR-(ADDRH*256) 100 POKE DCB+4,ADDRL:REM BUFFER LO 110 POKE DCB+5,ADDRH:REM BUFFER HI 120 POKE DCB+6,15:REM TIMEOUT 130 POKE DCB+8,64:REM 64 BYTES 140 POKE DCB+9,0 150 POKE DCB+10,0:REM AUX1=0 160 POKE DCB+11,0:REM AUX2=0 170 X=USR(ADR("h Yd`")) 200 PRINT CHR$(125) 210 PRINT "ATARIWIFI TEST PROGRAM #8: BA SIC VER." 220 PRINT 230 PRINT "SSID: ";INFO$(1,32) 240 END -Thom Ok, I've been quite busy completing and testing an enhanced control-layer for my Ultimate/SD cart in assembler (Which is now complete and fully operational, as it will address some nagging issues with this cart). But since this is really special, I will happily put time into this, but it would be great to get an idea of what exactly is required in the short-term. For expediency purpose, we can start in basic and then move to Assembly. Definitely at SIO-level. PM if necessary. Link to comment Share on other sites More sharing options...
tschak909 Posted November 17, 2019 Author Share Posted November 17, 2019 @Faicuai if you take a look at the source tree, you'll see that we're basically trying to implement the SIO commands that are needed. tnfsBoot is a read-only ? emulation, and tnfsWrite (which i am working on right now) is a read/write emulation. Oddly enough, the write goes through, but I do not see the changes on the TNFS filesystem. -Thom Link to comment Share on other sites More sharing options...
Lastic Posted November 17, 2019 Share Posted November 17, 2019 On 11/16/2019 at 1:00 AM, mozzwald said: 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. One thing I found that enables me to read the boot message is setting both the serial monitor speed to 74880 and using this command in the sketch Serial.begin(74880); I've enabled the serial debug on GPIO2 but still no avail , no messages in TNFSD nor on on the serial debug. I tried an 130XE instead of an 800XE thinking it might be machine related, no chance. Booting with OPTION pressed, just gives me the self-test screen. Only way I see something in TNFSD is when hooking up the NodeMCU to my laptop using it's USB port. I thought I missed a step so I double-checked the manual and initialized the SPIFFS file system , but no luck neither. At this point I feel like that I should stop bothering you guys and just let you continue with your amazing work, clearly Arduino/ESP is not meant to be my cup of tea. Link to comment Share on other sites More sharing options...
mozzwald Posted November 17, 2019 Share Posted November 17, 2019 34 minutes ago, Lastic said: One thing I found that enables me to read the boot message is setting both the serial monitor speed to 74880 and using this command in the sketch Serial.begin(74880); I've enabled the serial debug on GPIO2 but still no avail , no messages in TNFSD nor on on the serial debug. I tried an 130XE instead of an 800XE thinking it might be machine related, no chance. Booting with OPTION pressed, just gives me the self-test screen. Only way I see something in TNFSD is when hooking up the NodeMCU to my laptop using it's USB port. I thought I missed a step so I double-checked the manual and initialized the SPIFFS file system , but no luck neither. At this point I feel like that I should stop bothering you guys and just let you continue with your amazing work, clearly Arduino/ESP is not meant to be my cup of tea. 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. Link to comment Share on other sites More sharing options...
Lastic Posted November 17, 2019 Share Posted November 17, 2019 @mozzwald well thanks once again for your time, at least I got a bit further. I changed the Serial.begin() to 19200 as you suggested. And connecting GPIO2 (TX) to RX on the USB Serial adapter did the trick in regards to serial debugging. NodeMCU is the only SIO device connected to the Atari. With the Atari powered UP , same result nothing happens, no serial debug, no TNFSD logging. There is no pulldown resistor or anything between my NodeMCU connections and the SIO port, everything is directly connected With the Atari powered OFF , and powering the NodeMCU via MicroUSB whilst using another USB/Serial for the debugging I get TNFSD logging and the following serial debug output addicted@biggie:~$ picocom --b 19200 /dev/tty.usbserial-AL02YC1Y picocom v1.8 port is : /dev/tty.usbserial-AL02YC1Y flowcontrol : none baudrate is : 19200 parity is : none databits are : 8 escape is : C-a local echo is : no noinit is : no noreset is : no nolock is : no send_cmd is : sz -vv receive_cmd is : rz -vv imap is : omap is : emap is : crcrlf,delbs, Terminal ready ?bCbZ???nK??!bB'??b??Rkb*?!?[^??? #AtariWifi Test Program #7 started Mounting / from 192.168.1.132 Req Packet: 0 0 0 0 1 0 2F 0 0 0 Resp Packet: A74100001E83 Successful, Session ID: A741 Opening /autorun.atr... Req packet: A7 41 1 29 1 0 0 0 2F 61 75 74 6F 72 75 6E 2E 61 74 72 0 0 0 Resp packet: A7 41 1 29 0 0 Successful, file descriptor: #0 Link to comment Share on other sites More sharing options...
mozzwald Posted November 17, 2019 Share Posted November 17, 2019 32 minutes ago, Lastic said: @mozzwald well thanks once again for your time, at least I got a bit further. I changed the Serial.begin() to 19200 as you suggested. And connecting GPIO2 (TX) to RX on the USB Serial adapter did the trick in regards to serial debugging. NodeMCU is the only SIO device connected to the Atari. With the Atari powered UP , same result nothing happens, no serial debug, no TNFSD logging. There is no pulldown resistor or anything between my NodeMCU connections and the SIO port, everything is directly connected With the Atari powered OFF , and powering the NodeMCU via MicroUSB whilst using another USB/Serial for the debugging I get TNFSD logging and the following serial debug output 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. Link to comment Share on other sites More sharing options...
Lastic Posted November 17, 2019 Share Posted November 17, 2019 43 minutes ago, mozzwald said: 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. YEEESSS I thought I had tried this with Vin disconnected, powered via USB but I guess my timing was off. Although this is still on internal LAN and with the debugging still on , slow WOW. Thanks a gazillion times for guiding me thru this and your patience. For thrills I copied REHARDEN.ATR (92K) Reharden Demo by HARD to TNFS and it took whopping 3 minutes 9 seconds to load with debugging on I should take a selfie of the smile on my face seeing a demo boot copied over the network , we're almost TFTPBOOT/PXEBOOTing . Turned off debugging, ran the same test, REHARDEN.ATR (92K) , booted at 1 minute 2 seconds. Now on to the next step ,connect NodeMCU to iPhone tethering , run a TNFSD on my server here at home and connect to it via Internet aka WAN. Then dissect the code. 4 Link to comment Share on other sites More sharing options...
Recommended Posts