fujinet #FujiNet - a WIP SIO Network Adapter for the Atari 8-bit

[mozzwald]

1 hour ago, sideburn said:

Has anyone else noticed that the Fujinet won’t boot if there’s an SDrive Max on the SIO bus if it is turned off? I have to power up the SDrive Max and the. Set D1: to “empty” for the Fujinet to boot up. If the SDrive Max is powered down then Fujinet freezes. My physical 1050 can remain on the SIO bus powered down without issue. 

Can you capture the FujiNet serial debug output with your setup like this? It will show the boot process and may give a clue as to what's happeneing. 

 

https://github.com/FujiNetWIFI/fujinet-platformio/wiki/FujiNet-Flasher#capturing-serial-debug-output

[sideburn]

Agreed and LOL my original question was simply asking if anyone has seen the same Fujinet failure I am where it won’t boot if an SDrive Max is in the chain and powered off. 
 

Instead of an answer I got a “why do you have an SDrive Max dummy?!” 😂 😜 

[sideburn]

5 minutes ago, mozzwald said:

Can you capture the FujiNet serial debug output with your setup like this? It will show the boot process and may give a clue as to what's happeneing. 

 

https://github.com/FujiNetWIFI/fujinet-platformio/wiki/FujiNet-Flasher#capturing-serial-debug-output

Thanks! Yeah good idea, I can give that a try. 

[+mytek]

27 minutes ago, sideburn said:

Agreed and LOL my original question was simply asking if anyone has seen the same Fujinet failure I am where it won’t boot if an SDrive Max is in the chain and powered off.

I also saw a similar problem, but no longer have the hardware to to pursue it farther. I changed direction in my development because of it, and the new hardware now works fine, albeit no longer being expected to share the SIO bus in the same way that revealed the original problem.

 

I also remember seeing somewhere (???) a list of known issues that needed to be addressed for the Fujinet, and the SDrive-Max was on that list.

 

27 minutes ago, sideburn said:

Instead of an answer I got a “why do you have an SDrive Max dummy?!” 😂 😜 

Yeah I kinda got told the same thing in the same manner when I was first developing my new daughter board and just wanted to share what I was doing. This isn't the first time or the only person to respond in this way on AtariAge. Seems like at times people around here are incapable of answering an OP's question or provide help without revealing their personal bias instead.

[sideburn]

38 minutes ago, mozzwald said:

Can you capture the FujiNet serial debug output with your setup like this? It will show the boot process and may give a clue as to what's happeneing. 

 

https://github.com/FujiNetWIFI/fujinet-platformio/wiki/FujiNet-Flasher#capturing-serial-debug-output

Mines the Fujinet Pro with a single usb-c jack on the back. I wonder if that’s the same port for optional  power and debugging / flashing. 

[mozzwald]

6 minutes ago, sideburn said:

Mines the Fujinet Pro with a single usb-c jack on the back. I wonder if that’s the same port for optional  power and debugging / flashing. 

yep, same port for flashing and power

[sideburn]

2 hours ago, mozzwald said:

Can you capture the FujiNet serial debug output with your setup like this? It will show the boot process and may give a clue as to what's happeneing. 

 

https://github.com/FujiNetWIFI/fujinet-platformio/wiki/FujiNet-Flasher#capturing-serial-debug-output

Nothing that looks very useful from the logs:

Here's what I got WITH the SDrive Mac plugged intact he SIO chain and powered down:

 

... continuing from previous log output ...

 

[13:46:02] WiFiManager::start() complete
[13:46:02] WIFI_EVENT_STA_START
[13:46:10] 
[13:46:10] CF: 31 53 00 00 84
... end of loggging fujinet frozen ...

 

 

And here's what I get with the SDrive Max removed from the SIO chain:

 

... continuing from previous log output ...

 

[13:49:29] WiFiManager::start() complete
[13:49:29] WIFI_EVENT_STA_START
[13:49:33] 
[13:49:33] CF: 00 31 53 00 00
[13:49:33] CHECKSUM_ERROR
[13:49:33] 
[13:49:33] CF: 31 53 00 00 84
[13:49:33] FujiNet CONFIG boot
[13:49:33] disk sio_process(), baud: 19200
[13:49:33] ignoring status command
[13:49:33] 
[13:49:33] CF: 31 53 00 00 84
[13:49:33] FujiNet CONFIG boot
[13:49:33] disk sio_process(), baud: 19200
... more output follows ...

 

 

[mozzwald]

1 hour ago, sideburn said:

Here's what I got WITH the SDrive Mac plugged intact he SIO chain and powered down:

yeah, that doesn't help much. Fujinet gets the first command frame and nothing else. do other sio devices work when sdrive is plugged in but turned off?

 

did you build the sdrive max yourself or buy it? At minimum you need the fix listed under "Fixing the SDrive-MAX SIO issue" from this page https://atari8bit.net/tutorials/de-re-sdrive-max/ and the diagram here looks like a better way to isolate all the pins

 

[sideburn]

33 minutes ago, mozzwald said:

yeah, that doesn't help much. Fujinet gets the first command frame and nothing else. do other sio devices work when sdrive is plugged in but turned off?

 

did you build the sdrive max yourself or buy it? At minimum you need the fix listed under "Fixing the SDrive-MAX SIO issue" from this page https://atari8bit.net/tutorials/de-re-sdrive-max/ and the diagram here looks like a better way to isolate all the pins

 

Yeah the 1050 drive can remain plugged connected and powered off without issue. 
 

I bought it. It’s the Fujinet Pro from Lotharek. I put the latest firmware on it while I was setting up the debug a few hours ago… Didn’t help. 
 

it’s a minor issue. Was just curious if it’s isolated to my setup prints known. 

[mozzwald]

11 minutes ago, sideburn said:

Yeah the 1050 drive can remain plugged connected and powered off without issue.

I'm curious if the 1050 works with the Atari when sdrive is on the bus and not turned on. Not sure if that is what you meant above.

 

12 minutes ago, sideburn said:

bought it. It’s the Fujinet Pro from Lotharek

I was asking if you bought or built the sdrive, not fujinet.

 

I suspect the issue is related to the sdrives microcontroller being connected to the bus when turned off. Fujinet 1.0 had similar issues and we added buffer chips to fix that in newer hardware.

[+mytek]

3 hours ago, mozzwald said:

I suspect the issue is related to the sdrives microcontroller being connected to the bus when turned off. Fujinet 1.0 had similar issues and we added buffer chips to fix that in newer hardware.

That very well could be the problem since not all chips behave nicely when VCC is not connected but there is power at one or more of the I/O pins. I know BITD CMOS was highly susceptible to getting fried under these conditions. TTL (LS) and some other modern day chips are usually ok with this, but not all, and some may end up causing line load issues as well by trying to extract power from the signals (checkout this LINK).

[sideburn]

Ahh that makes sense. 

[sideburn]

* and sorry for posting off topic in here. I literally just now noticed this thread was specific to the Network Adapter after watching tschak909’d YouTube about it. I saw Fujinet and SIO and thought I was good 😆 🤦‍♂️ 

 

FujinetN00b 

[+mytek]

11 hours ago, sideburn said:

* and sorry for posting off topic in here. I literally just now noticed this thread was specific to the Network Adapter after watching tschak909’d YouTube about it. I saw Fujinet and SIO and thought I was good 😆 🤦‍♂️ 

You know with probably something like 450+ topics already created under the FujiNet flag, I think you can be excused for any notion of posting in the wrong one

[+mytek]

just to add a bit more info about SDrive-Max compatibility with FujiNet...

 

When I was developing my project that had both devices co-existing, I never powered down the SDrive to remove it from the equation. Instead I held the ATMEGA328 reset line low which puts all the I/O into an input mode, thus removing its influence on the SIO bus. When it was in this state, there was absolutely no interference with FujiNet or anything else on the SIO bus.

 

However when I tried leaving both the SDrive and the FujiNet 'active', if the SDrive ID was set to Drive 1 there would be noticeable interference with the FujiNet, even when FujiNet had nothing in Drive Slot 1. If I moved the SDrive ID to Drive 2, then there was no conflict. Because I had assumed when having nothing assigned to Drive Slot 1 in FujiNet this would allow unimpeded access to this drive by SDrive, I was rather surprised to see the conflict. Since this was not acceptable behavior, I changed directions and decided to keep each device in its own little sandbox, with no interaction between them.

[sideburn]

yeah if i leave it on and make drive 1 empty on the SDrive Max then its fine.

[desiv]

Just feeling lazy and thought I'd post my "I'm really lazy" feature request that totally isn't needed, but I'd use.

 

I wouldn't mind if, on the screen when you are selecting the file, if there was a quick way to select it, assign it to drive 1 and boot, all with one keypress.

 

Something like, instead of Enter to select it, hit Q and it automatically assigns it to drive 1 (read-only?) and boots the Atari... (quickly, hence the Q! )

 

I know, totally silly and just shows how super lazy I am...  
 

But just a thought... 

 

[tschak909]

The Adam config has this as quick boot, so this should be doable(tm).

 

-Thom

 

[Mr Robot]

It would be really nice if .nfo or .txt files could be read rather than mounted when selected from a file list. Handy for loading or usage instructions.

 

.nfo files... nice and retro too! 

 

.ata (for atascii text files) maybe?

 

EDIT: maybe incorporate Recoil and ASAP into the Fujinet code so gfx and sound can be loaded and opened by the Fujinet? 

Edit Edit: maybe if someone tried to mount a .bas file it could be inserted into a blank dos2.5 disk image and mounted so it can actually be loaded into the Atari?

Edited February 2 by Mr Robot

[tschak909]

1 hour ago, Mr Robot said:

It would be really nice if .nfo or .txt files could be read rather than mounted when selected from a file list. Handy for loading or usage instructions.

 

.nfo files... nice and retro too! 

 

.ata (for atascii text files) maybe?

 

EDIT: maybe incorporate Recoil and ASAP into the Fujinet code so gfx and sound can be loaded and opened by the Fujinet? 

Edit Edit: maybe if someone tried to mount a .bas file it could be inserted into a blank dos2.5 disk image and mounted so it can actually be loaded into the Atari?

txt files, yes. we can do that.

 

edit... if a way can be found to do it?

 

edit edit...would basically be a new media type DiskTypeBAS on the firmware side.

 

-Thom

[Mr Robot]

7 hours ago, tschak909 said:

txt files, yes. we can do that.

 

edit... if a way can be found to do it?

 

edit edit...would basically be a new media type DiskTypeBAS on the firmware side.

 

-Thom

It was way too early in the morning for me to edit or edit edit my reply. I should know better! The text file thing was the thing I thought was a good idea, I've no idea how the other two would ever work!