mozzwald
-
Posts
1,041 -
Joined
-
Last visited
Content Type
Profiles
Forums
Blogs
Gallery
Events
Store
Posts posted by mozzwald
-
-
A new firmware update is available at https://fujinet.online/download
"version": "0.5.7ecd3623", "version_date": "2022-05-19 01:06:18", "build_date": "2022-05-19 01:06:18", "git_commit": "7ecd3623",* JSON Parser is BACK!
* WiFi can be disabled by adding/editing enabled=0 to the [WiFi] section of fnconfig.ini on the SD Card. CONFIG will skip checking/scanning for WiFi
* SSID length fixed
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.
-
5
-
-
17 minutes ago, ol.sc said:
That's the reason why I re-posted after two years in this thread to check if someone who's into hardware is interested in building it.
Is the hardware working/done? All I see on the first page is a fancy render and I have not skimmed thru the whole thread. If it's not done, I think you have a hard road ahead. If it is 99.9% done then maybe someone will step up and finish. If it's 100% done, send the gerbers and BOM to China and make them already
or find someone like @Gavin1968 to make them.
Get those eagle files and post them here before something bad happens and they are lost forever. Make it easy for someone to roll with it.
-
2
-
-
20 minutes ago, ol.sc said:
that this is something pretty different to an open platform like a Linux SBC.
An esp32 and a Linux SBC are not the same hardware, but both are open platforms. A Linux SBC is likely MUCH faster and with more capabilities than the esp32, absolutely. I can see the utility of having a Linux SBC hooked up to an Atari.
23 minutes ago, ol.sc said:However, the team produces the tools, the users consume the tools.
We create tools and release source code, anyone can add their own tools. You can take the hardware and write your own tools in Micropython if you like, or whatever language can be compiled for the esp32.
30 minutes ago, ol.sc said:In a rather closed environment, the few programmers can come up with any type of custom multiplexing scheme.
31 minutes ago, ol.sc said:2. A midweight, rather intelligent device like the ESP32. It allows for extending its functionality to a rather small group for persons coordinating their work well.
If you are referring to the FujiNet project as a closed environment, you are mistaken. Everything is open. Anyone can extend, add, remove, replace if they wish. Some folks have already taken it upon themselves to change and extend FujiNet code and submit changes back to the master repo.
35 minutes ago, ol.sc said:3. A heavyweight, very intelligent device like the RPi. It allows for extending its functionality to all its users.
As I said before, FujiNet also "allows for extending its functionality to all its users."
I realize I'm just arguing to argue so I'm sorry and done. FujiNet and Dragoncart are not the same. They both offer connectivity to the outside world in different ways and the end user can figure out which works best for them. The more choices, the better IMO.
-
1
-
-
21 minutes ago, ol.sc said:
With serial you only have one port. If you listen to it with your hack, then nothing else works anymore. With TCP you have built-in multiplexing with TCP ports. Your hack listening to port 1234 doesn't keep all the existing stuff on their ports from working.
Since Fujinet conforms to the Atari OS SIO calls you can open multiple channels/ports over the "serial port". FujiNet buffers the incoming information and provides it to the Atari when requested. With the Fujinet N: device driver you can, for example, copy a file from a FTP server to a TNFS server. You could read from an HTTP(S) server and write to a UDP port.
https://github.com/FujiNetWIFI/fujinet-platformio/wiki/Using-the-N%3A-Device
27 minutes ago, ol.sc said:However, as far as I understand it's still consuming what is provided by the FujiNet team. Adding something to FujiNet is still implementing it in C/C++, using the ESP32 SDK to create a new firmware and uploading the firmware to the ESP32. I see that doing way less individuals than I see logging into a RPi and writing some Python script.
We have added helpers to the firmware to facilitate easier ways to access certain things on the internet, the JSON parser for example. If you want to write your own Atari side program to parse pure JSON, you can. Just open your JSON file using the protocol of your choice and parse the data. You can access HTTP using TCP instead of our provided HTTP(S) protocol adapter, then you would need to deal with the HTTP headers in your program. You can open a raw TCP or UDP port and do what you will on the Atari with the information stream.
-
1 hour ago, Atari8guy said:
I get this in the debugger:
[11:21:44]SD Card Inserted
[11:21:44]E (18914) spi: spi_bus_initialize(628): SPI bus already initialized.
[11:21:44]E (18934) vfs_fat_sdmmc: sdmmc_card_init failed (0x107).
[11:21:44]SD mount failed with code #263, "ESP_ERR_TIMEOUT"
[11:21:44]SD Card detect ignored (debounce)I'm assuming this is the "insert card when powered up" test which shows it's still not reading the card. If you've tried older firmware to confirm it's not a software issue, then my guess is a problem with the sd card socket. If you got it from me (fujinet.online) then PM me and we'll figure it out
-
9 hours ago, _The Doctor__ said:
actually, most of the washington post stuff is completely garbage articles so it's hard to determine what 'filter' would be best... maybe just filter anything from the WAPO out completely as you did with yahoo... it's not like you won't find the same or much better elsewhere.
Haha, I'm not filtering based on validity or quality of the content. I'm filtering out unnecessary generic text or sites with pay walls. You get to weed out the 'fake news' on your own.
9 hours ago, _The Doctor__ said:Is this being handled by a middleman server, or is the code able to be loaded as internal fujinet processor use and then fed to the Atari client (both local).
The server code is php and is running on fujinet.online. Source code is available in a previous post if you want to run your own.
-
2
-
-
For anyone using the news reader, if you happen to see any completely garbage articles or stuff that could be removed from the articles, please let me know so I can add filters to the server. I'll need to know the source name and part of the article title (hit TAB when viewing an article to get this) and data/time if you can.
For example, all articles from Washington Post start with "Placeholder while article actions load" which I have added a filter to remove. Also, articles from yahoo.com were total junk and contained a bunch of javascript so all articles from there are ignored.
Thanks
-
You can load the app from fujinet.online tnfs server at ATARI/networking/fujinews.xex or fujinet.pl tnfs server at networking/fujinews.pl
Server source code is at https://github.com/FujiNetWIFI/fujinet-apps/tree/master/news/server
Client source code is at https://gitlab.com/bocianu/fujinews and https://github.com/FujiNetWIFI/fujinews
Thanks @bocianu for making the Atari client app, it's awesome!
-
2
-
-
On 5/1/2022 at 5:40 PM, Atari8guy said:
E (1454) vfs_fat_sdmmc: sdmmc_card_init failed (0x107).
This indicates the card is not being detected at all. If the card works in another fujinet and you've tried another card in this fujinet, it could be a hardware issue. Try inserting the card after you've powered up the fujinet and capture debug output to see if it mounts or not. you could also try installing an older firmware to see if for some reason it's a firmware problem.
-
1
-
-
20 minutes ago, Schadret said:
I personally think that the image name itself is more important to see than part of the path and/or truncated image name
This makes sense to me, image filename is more important than the path
-
1
-
-
On 4/29/2022 at 2:12 PM, Atari8guy said:
Did this ever get solved? I'm now suddenly having issues with the SD card reader in my 1.6. As it won't read the card any longer (nothing changed, didn't pull it out since last use, didn't disconnect the fujinet, just stopped working). The card works fine in my 1.0 fujinet.
Can you get some debug output of fujinet booting up and trying to access the SD?
https://github.com/FujiNetWIFI/fujinet-platformio/wiki/FujiNet-Flasher#capturing-serial-debug-output
-
9 hours ago, mytek said:
I'm not a GitHub guy, so perhaps someone that's already signed up and likes any of these ideas, can open a request.
https://github.com/FujiNetWIFI/fujinet-platformio/issues/493
https://github.com/FujiNetWIFI/fujinet-platformio/issues/492
-
1
-
2
-
-
8 hours ago, mytek said:
Kinda along these same lines. Would it be possible to have an option to allow one to enable/disable network connectivity and not have to constantly skip the search each and every time FujiNet is powered on with no WiFi. This selection should be non-volatile, so as to be restored when powered back up.
This could be done by adding a new webui config option to enable/disable wifi. Then atari side config could check this value before scanning for networks and skip automatically if set to disabled.
8 hours ago, mytek said:And to add to this... what about having FujiNet remember maybe up to 10 previous WiFi portals and associated passwords, so that if it sees one of these when doing the power-up search it can automatically log-in. This would make it work just like your phone or tablet, and save the headache of having to re-enter this information every time you switch location.
This is more difficult. The esp32 only stores the last known network so this would require adding "slots" for wifi networks and corresponding passphrases. These would be saved in the INI file and if the default network is not available, call that list and iterate through them. Doable, but not as easy as the first feature request. Are there really that many people with portable Atari's that need this feature? I can see the utility of it, but I think most users have their FujiNet/Atari in one place and wouldn't be bothered to enter a new password if they take it to a show or friends house for the day.
You can open an issue for these two feature requests on Github
-
Source code for the app and server side script are available on Github
https://github.com/FujiNetWIFI/fujinet-apps/tree/master/wiki
-
3
-
-
1 hour ago, DjayBee said:
Can this be watched on YouTube?
Presentations will be streamed, but @jeffpiep just has an exhibit table and not sure if they go around to visit those live.
https://vcfed.org/events/vintage-computer-festival-east/
11 hours ago, Stephen said:Do you know if anyone will be at VCFMW?
I'm planning to go, not 100% yet tho
-
2
-
-
I received the new boards, assembled and tested a small batch of them. Everything is working great. The completed units are available at https://fujinet.online/shop and I will be making more as time permits. I also have PCBs for sale with the option to have the MicroSD socket pre-soldered since it is the only SMD part on the board and not everyone is up to that task
The complete design files have been release under the CERN OHL License and are available in our Github Repo.
-
1
-
-
I've been looking into what it might take to get internet gameplay working with Comlynx, possibly using #FujiNet. FujiNet code/hardware is probably overkill as I'm only considering Comlynx and not game loading. The esp8266 is probably suitable in this case and would be a very low cost add on.
The basic idea is to use the esp8266 as a wifi bridge, taking the serial data from Lynx and piping it over the network back and forth. Down the road I imagine a server somewhere handling the initial connection, but to start just direct 1 to 1 by ip/hostname.
In my forum searches here it appears the Lynx uses non standard bauds (62500) which is not a problem for the esp8266 or esp32. My understanding from what I've read, though, is that games pick their own serial settings so this could vary. Am I correct in this? If so, we could have a database/list of games and serial settings to choose from when starting the connection.
I'm hoping some lynx experts can chime in with any info and whether or not it seems doable. I have not had a lynx since the 90's so I would need to buy one to do any actual experimenting which is a costly endeavor with the current prices. If it looks promising enough, I can get one, but want to know more before I take the plunge. Is there any Comlynx documentation out there I can read up on?
Thanks,
mozzwald
-
17 minutes ago, Mr Robot said:
Could someone please test that my TNFS server is working OK? I got a new ISP at the weekend and had to reconfigure everything. It shows as 'up' to my scripts but I've had no visitors for a few days.
Fujinet.atari8bit.net or tnfs.atari8bit.net should both work.
both are working here
-
1
-
-
Some folks have privately asked questions about the new ADAM FujiNet hardware. Other folks may have the same questions so feel free to ask here for everyone's benefit.
I have begun working on a quick start guide that hopefully answers some common questions:
https://github.com/FujiNetWIFI/fujinet-platformio/wiki/ADAM-FujiNet-Quickstart-Guide
-
1 hour ago, mytek said:
It would still be nice to at least release the schematic for the NUC/FujiNet/Cart board, although I don't see that as a must.
@mozzwald if you feel that something is missing, please post your thoughts here
My opinion is that the entire design was released under a license that requires any modifications be released by the licensee. If the licensee read the schematic and created a new FujiNet partly based on that, then licensee should release any and all files related to the new product that licensee has designed and is selling. I'm not a lawyer so maybe I'm wrong, but that's how it reads to me and that is why I chose this license. There's at least one person interested in gerbers for the pcb so someone wants to build their own and I think that's fair to at least allow someone that option if they so choose. The first FujiNet for NUC had a gerber release so I see no reason why this newer version shouldn't have a gerber release as well.
That said, I don't want/am not trying to cause a stink or threaten anyone, just wanted to give nudge for a release of the complete designs in the near future.
-
On 3/31/2022 at 9:15 AM, mytek said:
The FujiNet/Cart is currently a proprietary device as far as I'm aware. So gerbers have not been released to the public.
I've been "triggered" by your use of the word proprietary in the same sentence with FujiNet
FujiNet is a completely open project, hardware and software. The license states that modifying the source and releasing a product requires releasing your modified source. Judging by the fact that the FujiNet name is being used and FujiNet compiled code is running on the device I would venture to guess this is a derivative of the original.
I'm not the FujiNet police nor do I want to be, just want to make the intentions of the project clear. I understand the time, effort and money it takes to make a device like this. I can only hope that the files will be released after @MacRorie has recouped the costs of development. As always, pull requests are welcome
-
8 hours ago, jblenkle said:
Will you be making these available on a regular basis? Not sure how soon I can get one.
I plan to make them for a while as long as there is demand and I have time.
This board was made with through hole components in the hopes that people would build their own when the design files are released, but I understand that not everyone is capable of doing that. I have also been thinking about offering the board with MicroSD socket already soldered as that is the only surface mount part.
-
1
-
-
I have 8 of the fixed ADAM FujiNet's available to those interested:
https://fujinet.online/shop/hardware/fujinet-v1-0-for-coleco-adam/
When I get the corrected PCB's I will have some more available and at the same time release the design files in our github repo
-
1
-
-
5 minutes ago, NIAD said:
Seems then that most are powering on their Proto FujiNet devices at all times or if not, know of the ADAMnet issue and unplug the cable from the device or Memory Console.
Of those testers I've been in contact with, only the one unit has the problem and they have confirmed by testing. I think it could be a hit or miss thing based on variations of the parts used. Right (or wrong) resistance tolerances, etc. @rietveld had the bad one and I replaced it with another unit from the same build run which did not have the issue.
10 minutes ago, NIAD said:Seeing as you have developed a fix for the issue, I can only assume that the next HOT mod to do will be to apply this diode fix to ADAM Disk Drives!!!
I'd have to look at the drive schematics to see if it's possible. On FujiNet, the switch cuts off ADAMNet 5V power from the ESP32. I had connected the ADAMNet 5V directly to the transistors used for translating RX/TX to ADAMNet Data. The transistors were being biased and the ESP32 being off was causing ADAMNet Data to stay high and freeze the bus. I cut the ADAMNet 5V trace to the transistors and ran a diode from the switched ESP32 5V to the transistors. The diode prevents partial back powering of the ESP32 when FujiNet is off.
or find someone like 
Like us on Facebook
Follow us on Twitter
AtariAge on Instagram
Watch us on YouTube
Chat on Discord
FujiNet without the "Net"
in #FujiNet SIO Network Adapter
Posted
https://github.com/FujiNetWIFI/fujinet-platformio/issues/492
I've got the basics done for this in the latest firmware update. It requires one to edit the fnconfig.ini on the SD card and set enabled=0 in the [WiFi] section.
I went this route since:
It would take more work to add the option in Atari side CONFIG and require another new command for the Fuji device. If what I've done isn't enough, you can reopen the issue and request more changes, otherwise it's a done deal.
The other issue https://github.com/FujiNetWIFI/fujinet-platformio/issues/493 seems like a doosie and probably out of my skill range. Probably take me every waking hour in a year to code that up