Jump to content
IGNORED

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


tschak909

Recommended Posts

1 hour ago, StickJock said:

So, you are saying that you really had to "Jump" on this deal! ??

Now we just need some lessons on how to use it, at least someone will wnd up "Hot for Teacher"

 

(Okay, that one is probably a bit of a stretch, but I have been Running with the Devil)?

Link to comment
Share on other sites

2 hours ago, leech said:

Now we just need some lessons on how to use it, at least someone will wnd up "Hot for Teacher"

 

(Okay, that one is probably a bit of a stretch, but I have been Running with the Devil)?

Sounds like you need to reach down between your legs and ease the seat back....

 

  • Haha 2
Link to comment
Share on other sites

Oscar Fowler @jamm has been hard at work refactoring the #FujiNet firmware, removing the calls to the Arduino library, and replacing them with calls to the ESP-IDF framework. This will ultimately mean faster boot-up times and more efficient use of resources on the ESP32.

 

Why are we doing this?

 

Initially when we started this project, every single feature was written as a completely autonomous Arduino sketch, one sketch for each feature that we wanted to test. This ultimately allowed us to quickly test if what we were doing was actually going to be feasible. We quickly racked up almost fourty test sketches over a period of two months. Arduino allowed us to concentrate on implementing enough logic to be any number of SIO peripherals, and provided a wealth of classes and functions that we didn’t have to implement.

 

Meanwhile, Jeff Piepmeier @jeffpiep had made the case that PLATFORM.IO should be used to build the production firmware. This case was made on a few very solid grounds, namely that it was much easier to fan out the various bits of code into separate libraries and utilize them from within the main code. It also provided a very nice editor in the form of VS.CODE, which is really a nice improvement over the Arduino editor in both usability and scalability terms. Jeff was able to do his initial work on the printer emulation in PLATFORM.IO. He also started working on taking the work that had started to come together under the Multilator sketch, and breaking it into nice C++ classes spread across a few libraries, as well as implement the virtual SIO bus that we needed inside the main code to tie all of these different virtual devices together. By the end of January, all work on Multilator had slid into a soft landing, and we had moved entirely to the PLATFORM.IO codebase.

 

It was wonderful seeing the ? R: and P: devices working together under one roof. Because of all of the hard work of everyone involved, it all came together and worked almost completely the first time, with the bugs worked out over the next couple of weeks, and by February, I had started working on the first pieces of what would become the N: device.

 

Jeff also found time to sneak in a nice bit of a surprise in the SAM speech synthesizer. I had found a port of SAM to C quite some time ago, and had remembered it, passed it to Jeff, and over a weekend in March #FujiNet started to speak.

 

Meanwhile, in March we had gotten much needed help from Rick Lopez aka 8bitandmore, who built a FujiNet from schematics and started to improve and tweak the R: device, to make it work even better, fixing bugs.

 

And we got a special surprise from Marcin Sochacki @TheMontezuma, who also built an ESP32 on a breadboard and contributed SIO2BT support!

 

As March rolled on, I slowly started fleshing out more of the N: device, in the form of the TCP and UDP protocol adapters. As I implemented the firmware for this part of the system, a series of test programs that talked to the #FujiNet over SIO were written to verify the low level operation of various parts of the code that the N: handler would eventually use. This minimized the number of points of debugging to one, rather than two, and the network functions started falling into place.

 

Meanwhile, in April, we started seeing help and contributions from Oscar Fowler @jamm, who started sifting through the code and slowly refactoring it, making it better.

 

We started May with a new hardware revision that fixed some issues that I will expound upon, below, and I started working on extending N: to handle file level network file systems.

 

As we fleshed out all this functionality, we started running into problems:

 

* The printing emulation was sucking RAM. The 320K on the ESP32, which we had moved to because we were running out of the 80K of available ram on the ESP8266, was also being exhausted, causing crashes and stability problems. It takes a LOT of RAM to construct a PDF! This was solved by a further hardware revision that increased the RAM to the maximum available for ESP32 (8 megabytes of PSRAM)

 

* The Bluetooth emulation was also taking up not only valuable RAM, but flash space. The fix was not only to increase the RAM, as we did above, but also to increase the amount of flash memory to the maximum available (16 megabytes).

 

* As we were tying everything together, it was becoming evident that start-up times were vastly increasing due to the large amount of initialization required. This was exacerbated by the amount of time taken to test the PSRAM. While all the initialization was happening, the FujiNet could not respond to anything from the Atari during this time, and more importantly, could not boot. It became clear that we needed to have finer grained control over the initialization process to not only shorten the initialization time, but also to finely prioritize and defer aspects of initialization, to bring up just enough of the device, that it could at least respond to booting the CONFIG program, while the rest of the device could initialize in the background.

 

* The serial I/O routines that ultimately send and receive the SIO traffic, are not as efficient as they could be. Timing on SIO is absolutely critical, with response times expected in microseconds for such things as acknowledgment (ACK), and the buffered nature of the UARTs meant that we had to flush the UART to ensure that things like the acknowledgment (ACK) packets were sent on time, it meant that further transmission of data would be delayed by a few milliseconds, and while this isn’t detrimental, it does mean that it can be made faster, but only if we control the hardware directly.

In addition to the Arduino framework (and frameworks like Pumbaa and Simbaa that allow other languages like Python and Lua to be used to write code), PLATFORM.IO offers the ability to build and manage projects written for the ESP-IDF framework, which is the vendor framework provided by Espressif for C and C++ software development on ESP32 projects. Much of the Arduino classes are actually implemented as wrappers around ESP-IDF and this unneeded wrapper can be removed.

 

In addition, many of the flexible options available in ESP-IDF (such as specifying a larger number of allowable TCP connections, setting buffer sizes, changing how start-up and initialization is performed, etc.), are simply not available under the Arduino API, we need to get at these features directly. To say nothing of the fact that the version of ESP-IDF currently present in the released Arduino framework is older than the newest version of this framework which has been released by Espressif, which fixes a number of bugs that we have run into while developing this software, the most notorious of which was a default POST header size for HTTP transactions that was preventing our web admin from working correctly with the Chrome browser.

 

So Oscar started taking by ripping out the dependencies on Arduino.h, and with each error that happened, wrote equivalent functions and classes to replace the functionality lost with Arduino, calling into ESP-IDF as needed. This has been a very slow process, and involved traversing the entirety of the code-base (as each of us was actively working on code!) and stealthily replacing Arduino calls with fnSystem, et al, calls.

 

Oscar reached a point where the code had been thoroughly re-bound in our new libraries, and functionality was working as expected, so he decided to create a new project under the platformio directory called FujiNet_idf, which was a project that only links the ESP-IDF framework, and does not link Arduino, at all. After roughly a week of work, the code compiled, and two days after that, it booted its first disk. The hard work in infrastructure to rid ourselves of the Arduino dependencies has paid off, and the amount of working functionality after the first successful build surprised all of us, for sure.

 

So what’s next?

 

I’m taking a couple of weeks away, to relax, while Oscar continues to debug and refactor the ESP-IDF version of the code, with the goal of attaining feature parity with the current production version. The biggest problem at present is dealing with pauses in serial output at high speeds. We suspect a timing issue that we need to resolve (now that we are one layer closer to bare metal), and hopefully will get this resolved swiftly.

 

Now that @mozzwald has officially done an initial production test run of 50 units, the pressure is on to button up what we have, to get it ready to put on these production units. This will be precisely what we have of the various peripherals D, P, R, and N, as well as SAM, with an emphasis on fixing bugs in CONFIG (which Rick aka 8bitandmore is helping with), and we will be putting together a seamless way to upgrade FujiNet firmware as we flesh out more of the functionality for the rest of this year, and going forward.

 

I have, in anticipation of the delivery of these initial 50 test units started writing a test plan full of test procedures, which not only serve to validate, but to instruct the functionality of the #FujiNet.

 

I want to thank everyone who has contributed blood, sweat, and tears to this project. It is because of all of us, that we have one of the greatest peripherals ever to connect to an Atari computer. I hope that with this project being done entirely out in the open, that it creates an atmosphere that entices people to contribute to something truly fun and amazing. It is also my hope that by doing all of this work out in the open, that we inevitably ensure that this device stays useful for the future of the Atari community, and that it becomes a model for how to bolt a usable network interface onto retrocomputing platforms.

  • Like 14
  • Thanks 2
Link to comment
Share on other sites

I've been thoroughly impressed with your tireless dedication to this project, Thom.  That post really highlights just how much has happened over a relatively short time.  It would be a big accomplishment for any team, but it's particularly amazing when you consider the small group of people involved and that it's all happened during "free time".  Congratulations, everyone.  I'm happy to have been able to lend a hand in my own way, and am really looking forward to seeing what comes in the next few months.  Of course, the most exciting part will be seeing what other people are able to do with #FujiNet once it's out there and the community starts hacking with it.

 

On a more personal note, I want to add that everyone I've virtually met so far in this project - @tschak909, @mozzwald, @jeffpiep, and everyone else - has been incredibly smart, kind, and generous.  It's rejuvenating knowing there are really wonderful people out there in the community.

 

Edited by jamm
  • Like 8
  • Thanks 2
Link to comment
Share on other sites

Hello Oskar

 

17 hours ago, jamm said:

It's rejuvenating knowing there are really wonderful people out there in the community.

 

In non-CoVid-times, I visit a couple of Atari 8 bit meetings in Germany that usually last 2.5 to 3.5 days.  At those meetings, I meet a lot of ABBUC members.  I've experienced that you can meet wonderful people from the Atari 8 bit community in real life.  This year, two of those meetings have been postponed.  And I miss the meetings and the people.

 

BTW last year, our president for 34 years stepped down.  When I think of how we thanked him and how we planned that, I feel very proud to be part of that bunch of people.

 

Sincerely

 

Mathy

  • Like 1
Link to comment
Share on other sites

I am proud to be a paying ABBUC member, too. They did a full write-up on FujiNet in the ABBUC Magazine #140, (with full color cover too! it was total amazeballs!) They have thanked me twice in epic fashion in the last decade, and it's been a very heartwarming experience.

 

Here's a shot of the magazine on my desk!

Thomas Cherryhomes on Twitter: "#Atari8bit #FujiNet has a cover ...

 

Are they basically waiting for hardware to show up, at this point?

 

 

  • Like 8
Link to comment
Share on other sites

Because we sold out of the initial run so quickly, @mozzwald has set up a registration form for interested #FujiNet buyers, in order to gauge the size of the next run. As before, $65 with case, $55 without case. You will get an e-mail when the next run happens.

https://fujinet.online/order-interest/

 

Thank you all for your patience and interest.

  • Like 9
Link to comment
Share on other sites

17 hours ago, tschak909 said:

Because we sold out of the initial run so quickly, @mozzwald has set up a registration form for interested #FujiNet buyers, in order to gauge the size of the next run. As before, $65 with case, $55 without case. You will get an e-mail when the next run happens.

https://fujinet.online/order-interest/

 

Thank you all for your patience and interest.

In regards to the JTAG option, It indicates for developers. Can you conform that if one does not have the JTAG they can still update the firmware?

Link to comment
Share on other sites

25 minutes ago, orpheuswaking said:

In regards to the JTAG option, It indicates for developers. Can you conform that if one does not have the JTAG they can still update the firmware?

The only reason you'd want JTAG is if you were developing/debugging the FujiNet firmware. The port mates with the cable supplied with the Espressif ESP-PROG. The case is designed with a small thin area above the recepticle that can be cut out with a razor blade to allow the flat ribbon cable an exit.

 

I do not expect very many people to need/want this port. If you don't know what JTAG is for, you probably won't need it ?

 

You can always update FujiNet firmware with the MicroUSB port. We plan to implement Over-The-Air (OTA) updates which could be done over WiFi.

  • Like 2
  • Thanks 1
Link to comment
Share on other sites

22 hours ago, tschak909 said:

Because we sold out of the initial run so quickly, @mozzwald has set up a registration form for interested #FujiNet buyers, in order to gauge the size of the next run. As before, $65 with case, $55 without case. You will get an e-mail when the next run happens.

https://fujinet.online/order-interest/

 

Thank you all for your patience and interest.

Sad I missed out on the first order (not relation to Star Wars) run.  Thanks for adding this option to be notified.

  • Like 1
  • Haha 1
Link to comment
Share on other sites

6 hours ago, mozzwald said:

The only reason you'd want JTAG is if you were developing/debugging the FujiNet firmware. The port mates with the cable supplied with the Espressif ESP-PROG. The case is designed with a small thin area above the recepticle that can be cut out with a razor blade to allow the flat ribbon cable an exit.

 

I do not expect very many people to need/want this port. If you don't know what JTAG is for, you probably won't need it ?

 

You can always update FujiNet firmware with the MicroUSB port. We plan to implement Over-The-Air (OTA) updates which could be done over WiFi.

I prefer the JTAG for 2 reasons, 1) I am hoping to get skilled enough to do coding.  2) I have in the past had my bacon saved by being able to reprogram things.  Do we have failsafes in place for firmware updates?

Link to comment
Share on other sites

4 minutes ago, leech said:

I prefer the JTAG for 2 reasons, 1) I am hoping to get skilled enough to do coding.  2) I have in the past had my bacon saved by being able to reprogram things.  Do we have failsafes in place for firmware updates?

Firmware updates can be done completely without the JTAG. 

I've used it for debugging purposes on mine, and honestly it's pretty slow, so even for debugging I only use it very rarely.

 

  • Like 1
Link to comment
Share on other sites

6 minutes ago, jamm said:

Firmware updates can be done completely without the JTAG. 

I've used it for debugging purposes on mine, and honestly it's pretty slow, so even for debugging I only use it very rarely.

 

Even if the local firmware is in a weird state?  When I got my SuperVidel, that was the only way I got it to work.

Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
  • Recently Browsing   0 members

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