mozzwald

I just gave it a quick run through of the examples and this is looks quite awesome When I saw this program and what it is able to do, I immediately thought of a stripped down web browser for Atari with a server handling HTML to ADF conversion and feeding the data with FujiNet. I did some playing around with FrogFind and converting HTML to Markdown to ATASCII. I think converting to ADF would be much more amazing with the use of graphics. So, if you can make compiler that runs on linux, do share Input form would be useful for web browser I envision a portal page like the FrogFind search engine and send the form results back to the server using the N: device.

The only thing we use Bluetooth for is SIO2BT functionality (BT Classic serial port protocol). We do not use it for wifi bootstrapping.

One of the big problems with memory usage is Bluetooth functionality which uses a HUGE amount. The newer esp-idf toolchains won't even build the current firmware due to the ram use. We have been discussing removing bluetooth support for the time being. I had an idea that may or may not work by disabling BT at boot but you can turn on BT mode which would force a reboot into BT only mode. Another reset would return FujiNet to normal/wifi mode with disabled BT. This is the function that disables the BT stack: https://docs.espressif.com/projects/esp-idf/en/latest/esp32/api-reference/bluetooth/controller_vhci.html#_CPPv229esp_bt_controller_mem_release13esp_bt_mode_t

* Longer receptacle pins for better fit * Run MOTOR line thru buffer * SD Card detect pin to a GPIO * Fixed SIO voltage calculation

Support for both IO12 and IO15 as card detect is already in the firmware. The nuc boards in the wild will be supported. I recommend you change to IO15 in all future boards that get made. I got bit by this problem with the WROVER-IE boards which I was not expecting.

I got 2 sets of v1.6 boards in on Friday and built one of each. The difference b/w the two is that one has the same push/pull SD socket and the other has a push/push socket. I was hoping the push/push would work out, but unfortunately it's much more difficult to get the card out. The socket is as far out to the edge of the PCB as possible and when the card is fully inserted does not protrude from the case so that you can give it a push to eject. Was worth a try. Maybe down the road with a complete redesign of the board and a different socket. The receptacle pins are new and fit much better on the 3 different types of SIO cables I have to test with. SD Card detect is added but I have had to bodge a wire on these boards to use a different gpio pin (IO15 instead of IO12). This will be changed before I release the gerbers. Black PCB with push/push socket on front, blue with current push/pull socket on back push/push socket with card inserted, card invisible New beefy pins

#4 1/2 inch

Best place to start is with the wiki https://github.com/fujiNetWIFI/fujinet-platformio/wiki There are some videos on youtube also https://www.youtube.com/results?search_query=fujinet

So, there's a slight issue with using IO12 for the card detect pin. IO12 is used as a bootmode pin and if pulled high or low at boot changes how the hardware configures itself. Somehow I missed that even though my spreadsheet of gpio pins clearly states "boot fail if pulled high." IO12 is used to set VDD_SDIO voltage for the internal flash storage chip at 1v8 or 3v3. The latest WROVER-E modules just so happen to use 1v8 which means a pull up on IO12 is ok. However, if you use a WROVER-B module which requires a pull down for 3v3 VDD-SDIO, then the FujiNet will not boot UNLESS you have an SD card in the socket when you turn it on. @Mr Robot ran into this while building his latest NUC FujiNet boards with WROVER-B modules. Now, I could just leave the schematic as-is since I'm not sure you can even buy B modules anymore, but you never know. Someone may have a bunch in stock somewhere and they work fine for FujiNet. I've decided to move card detect to IO15 which is not a bootmode pin and this will be v1.6.1 I already have v1.6 boards incoming and I will leave them as-is with IO12 for card detection. There are also a good handful of NUC FujiNet's already in the wild using IO12 and WROVER-E modules. What I have done is modified the firmware to detect which pin is being used for SD card detection and adjust itself accordingly. I've tested this myself with both the E and B modules and it worked fine. I've asked @Mr Robot to bodge and test his FujiNUC board when he has time. Sorry for the inconvenience/stupid mistake

This will always put the FujiNet into flashing mode and you can do it if needed. It's interesting that you have to do this with one v1.5 and not the other. Are you using the same USB cable & computer to flash both FujiNets? Makes me think there's a (minor) hardware issue, but it if you can flash by force, then it should be ok. Case makes no difference on the guts. All the differences between versions have been and still are on the Wiki in addition to the README files for each version in the fujinet-hardware repo.

A new firmware update is available at https://fujinet.online/download FujiNet Version: 0.5.bbbb9f96 Version Date/Time: 2021-07-17 23:14:15 Build Date/Time: Sat Jul 17 23:40:30 UTC 2021 A big THANKS to those submitting new code/features to FujiNet! Keep it coming! * Add error handling to prevent crash when saving config to SPIFFS or SD Card * Improved joystick support in fnCONFIG from @greblus * New APETIME commands from @billkendrick (for use with APOD or your own program) - New SETTZ call for APETIME (0x99), which allows you to send a string from the Atari to FujiNet, specifying the timezone you wish to receive times for rather than the timezone set on the FujiNet (e.g., via web interface) - The standard GETTIME call (0x93) is unaffected. A new call, GETTZTIME (0x9A) fetches the time in the timezone specified when SETTZ was called * New web ui configuration option from @ninex to disable SIO STATUS wait which fixes issue with SpartaDOS X ejecting config disk on boot Please do not respond to this thread. If you have an issue, start a new post in the FujiNet subforum, open an issue on the github tracker or ask for assistance in Discord chat.

The first batch of FujiNet hardware shipped before CAS support was added and lack the required pulldown resistor on the MOTOR line for automatic playback. The B button option is for that first batch of hardware so they can start the tape playback by pressing B.

I only run Linux also. I rarely use emulation, but Altirra does run perfectly for me under Wine. Last I saw, atari800 doesn't have complete SIO support so adding N: is not likely to happen soon.

A new firmware update is available at https://fujinet.online/download FujiNet Version: 0.5.194250a3 Version Date/Time: 2021-06-09 19:15:24 Build Date/Time: Mon Jul 5 20:09:41 UTC 2021 New Things: * Adding fnconfig_on_spifs=0 to the General section of fnconfig.ini on your SD Card will disable the use of fnconfig.ini on the FujiNet's internal SPIFFS as long as and SD Card is present. This reduces writes to the flash storage to prolong it's life. FujiNet without SD Card will still use/save config to SPIFFS. Thank you @ninex for the code submission! * Default advertised Bluetooth name is now SIO2BTFujiNet to maintain compatibility with the SIO2BT Android app. Please do not respond to this thread. If you have an issue, start a new post in the FujiNet subforum, open an issue on the github tracker or ask for assistance in Discord chat.

Did you enable the correct algo?

Maybe better idea to cache ATR to SD Card (if available). It could also save some tiny fractions of bandwith for public tnfs servers in some cases When user mounts a disk image in fujinet config, they decide if read only or write. If read only, then we can cache the ATR. Issue is open for comments on fujinet github https://github.com/FujiNetWIFI/fujinet-platformio/issues/455

Failed loading from tnfs server seems very random. First test froze in 15 minutes. I let the second test run overnight and it stopped around 4.5 hours. Both times Atari is requesting the same data (a retry error I presume?) which forces Fujinet to reload it's small cache of the disk image which it sends over and then no more command frames are sent by Atari. Fujinet debug output does not show any other duplicate command frame requests, although I only skimmed it over and did not go through all 4 hours of log. Of note is that it takes Fujinet longer to reply with data when it must read and cache from the tnfs server (100-200ms), but why this particular frame failed/froze/crashed is a mystery to me. Here is output from FujiNet: and from the tnfs server log: 123.456.789.0 s=4567 c=21 q=5b | REQUEST cmd=0x21 TNFS_READ 123.456.789.0 s=4567 c=25 q=5c | REQUEST cmd=0x25 TNFS_SEEK lseek: offset=151440 (24f90) whence=0 tnfs_whence=0 lseek: New location=151440 (24f90) 123.456.789.0 s=4567 c=21 q=5d | REQUEST cmd=0x21 TNFS_READ 123.456.789.0 s=4567 c=21 q=5e | REQUEST cmd=0x21 TNFS_READ 123.456.789.0 s=4567 c=25 q=5f | REQUEST cmd=0x25 TNFS_SEEK lseek: offset=151552 (25000) whence=0 tnfs_whence=0 lseek: New location=151552 (25000) 123.456.789.0 s=4567 c=21 q=60 | REQUEST cmd=0x21 TNFS_READ 123.456.789.0 s=4567 c=21 q=61 | REQUEST cmd=0x21 TNFS_READ

I think it has been mentioned before. It could get difficult to implement if you want to write to disks. Would be easier if it only applies to read only disks. I'll do you one better and put it up at fujinet.online tnfs in the games dir. We'll see how long this runs...

I've been running PoP_DD_20210619_bugfix.atr for over 1.5 hours with no issue yet. Will let it ride until bedtime unless you have another test to try instead. This is what I'm using: 800XL 512k No HSIO FujiNet hardware v1.5, latest firmware ATR on SD card

Yes, as @tschak909pointed out previously, the 1050 will always try to be D1 (if jumpers on it are set for D1) regardless if you have a disk in it or not. Therefore, Fujinet cannot boot CONFIG or whatever you have configured for Fujinet D1 if the 1050 is ON. There is no way around this. You can also configure Fujinet from a web browser http://fujinet or http://<ip address of fujinet>. This allows you to mount and eject disks from a web browser instead of constantly hitting reset

Yes, Fujinet implements COMMAND according to Atari specs but always a possibility of a bug. The web gui option to change is only available on fujinet-pc for the different USB to serial converters. True Fujinet hardware uses a gpio pin.

iirc, @jamm ported the XEX code to Fujinet from SDrive or at least used it as a guide. I have no useful input on how it works but I can test it and see if I have the same issues. I'll also check if there's anymore debug info we can get from Fujinet.

I've never used a SDrive Max before so I'm shooting in the dark here. Remember that anytime Fujinet is reset or power cycled it will automatically become D1 (to boot CONFIG) which would conflict with any other device that wants to be D1. AFTER you "MOUNT and BOOT" from CONFIG, the Fujinet will not attempt to be D1 anymore, UNLESS you have a disk mounted in D1. So, you should boot Fujinet CONFIG, remove any disk from D1, MOUNT and BOOT, then you can use your SDrive Max. If you do not have the Fujinet powered externally via MicroUSB then anytime you turn off the Atari the Fujinet is reset and will be ready to boot CONFIG at next power up.

It is supposed to work with other devices. Does your SDrive have the proper circuitry to be compatible with other devices on the SIO bus?

Most of the suggestions you have here are non-options for the current design. Top and higher on the side is impossible (buttons, LEDs, antenna, screws). More protruding card is not possible. A recess on the front side of the case is possible to allow more finger access. I spent a little time adding a push/push micro socket to the front side of the board (impossible to fit on the backside with current layout). Not sure how well this is going to work. It seems like it would be really close to the Atari and possibly more difficult to remove with Fujinet connected to Atari. I've probably got tunnel vision on this so any more ideas are welcome. Here's what the new socket looks like in the old case: PCB Front: PCB Back: