Jump to content
IGNORED

#AtariWiFi - an Atari Network Adapter


tschak909

Recommended Posts

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

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.

  • Thanks 1
Link to comment
Share on other sites

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 by a8isa1
Link to comment
Share on other sites

14 hours ago, tschak909 said:

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

@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

 

  • Like 1
Link to comment
Share on other sites

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

  • Like 1
Link to comment
Share on other sites

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

  • Like 1
Link to comment
Share on other sites

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 by Faicuai
Link to comment
Share on other sites

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 by Jinks
Link to comment
Share on other sites

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.

 

 

  • Like 1
Link to comment
Share on other sites

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

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

@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

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

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


@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

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

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

 

IMG_5100.thumb.JPG.462393547b67f9dd70639b304624107f.JPGIMG_5101.thumb.JPG.65c4093254549240f3447c7e3f26d71b.JPG

 

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 :D 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 :D

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.

 

IMG_5102.thumb.JPG.c40e6763067b2bcf898ab887e8cd91c8.JPG

 

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. 

  • Like 4
Link to comment
Share on other sites

Guest
This topic is now closed to further replies.
  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...