Heiß, heißer, FujiNet

1 ... 4, 5, 6, 7, 8, 9, 10, 11

Re: Heiß, heißer, FujiNet

von nortobor » So 7. Jun 2020, 13:37
Hallo,

die Kabel sind gekauft, also Standart für diese Steckbretter (ca. 25 cm lang), Die Stifte vom Splitter sind etwas stärker, daher gehen sie ziemlich stramm rauf.
Ich lasse sie aber so, da ich mit dem SIO noch andere Versuche und Messungen durchführe.

Versuche mit FUJI habe ich aber aufgegeben , autorun.atr lädt (also Kabelverb. o.k.) aber keine Anzeige von WIFI-Netzwerken (multilator-rev2.ino)

Re: Heiß, heißer, FujiNet

von tschak909 » So 7. Jun 2020, 21:56
@nortobor: If you are building for ESP32, you should use the PLATFORM.IO bring-up:
https://github.com/FujiNetWIFI/atariwif ... RM.IO-code

The Arduino code was meant for feasibility prototyping, and we have long since stopped maintaining it.

---

@nortobor: Wenn Sie für ESP32 bauen, sollten Sie das PLATFORM.IO-Bring-Up verwenden:
https://github.com/FujiNetWIFI/atariwif ... RM.IO-code

Der Arduino-Code war für Machbarkeits-Prototypen gedacht, und wir haben schon lange aufgehört, ihn zu pflegen.

Re: Heiß, heißer, FujiNet

von tschak909 » Mo 8. Jun 2020, 06:04
One last video for this weekend, showing where things are with regards to high speed N, that is speeds above standard SIO rate on the N: device. It is possible if you have an appropriate high speed patch, but it still needs work...as you will see... https://youtu.be/IEMGwmkidWQ

---

Ein letztes Video für dieses Wochenende, das zeigt, wo die Dinge in Bezug auf die hohe Geschwindigkeit N stehen, d.h. Geschwindigkeiten über der Standard-SIO-Rate auf dem N:-Gerät. Es ist möglich, wenn Sie ein entsprechendes Hochgeschwindigkeits-Patch haben, aber es muss noch bearbeitet werden... wie Sie sehen werden... https://youtu.be/IEMGwmkidWQ

Re: Heiß, heißer, FujiNet

von tschak909 » Mi 10. Jun 2020, 02:50
#Atari8bit #FujiNet I am spending this week writing unit tests for participating beta testers. https://github.com/FujiNetWIFI/atariwif ... sting-Plan

---

#Atari8bit #FujiNet Ich verbringe diese Woche damit, Unit-Tests für teilnehmende Betatester zu schreiben. https://github.com/FujiNetWIFI/atariwif ... sting-Plan

Re: Heiß, heißer, FujiNet

von tschak909 » Di 16. Jun 2020, 02:42
#FujiNet #Atari8bit Wir nehmen jetzt Reservierungen für die ersten 50 Produktionseinheiten entgegen. Das Reservierungsformular ist nun offen, bis es vollständig ausgefüllt ist. Sie können sich unter https://fujinet.online/reservation/ anmelden.

Re: Heiß, heißer, FujiNet

von tschak909 » Di 16. Jun 2020, 03:30
Yow! sold out in under an hour. THAT WAS FAST!

-Thom

Re: Heiß, heißer, FujiNet

von skriegel » Di 16. Jun 2020, 08:02
Mist, da war ich wohl zu langsam. Aber da wird ja sicher noch mehr kommen, oder? :)

Re: Heiß, heißer, FujiNet

von tschak909 » Di 16. Jun 2020, 16:32
Natürlich. :) Dieser Produktionslauf war ein kleiner Test, um die Entwicklungskosten zu decken. Wir werden noch viel mehr verdienen.

Da dieses Projekt öffentlich ist, werden wir, sobald dieser Produktionslauf abgeschlossen ist, neben den bereits veröffentlichten Schaltplänen und der Firmware auch die Builddateien freigeben, so dass jeder Hacker oder Anbieter eine solche bauen kann. Dies stellt sicher, dass das Projekt über unsere Möglichkeiten der Herstellung hinaus lebt.

-Thom

Re: Heiß, heißer, FujiNet

von tschak909 » Mi 17. Jun 2020, 02:32
Oscar Fowler (@jamm) hat hart daran gearbeitet, die #FujiNet-Firmware zu überarbeiten, die Aufrufe an die Arduino-Bibliothek zu entfernen und sie durch Aufrufe an das ESP-IDF-Framework zu ersetzen. Dies bedeutet letztendlich schnellere Boot-up-Zeiten und eine effizientere Nutzung der Ressourcen auf der ESP32.
Warum tun wir das?
Als wir mit diesem Projekt begannen, wurde jedes einzelne Feature als völlig autonome Arduino-Skizze geschrieben, eine Skizze für jedes Feature, das wir testen wollten. Auf diese Weise konnten wir schließlich schnell testen, ob das, was wir taten, auch wirklich durchführbar war. Über einen Zeitraum von zwei Monaten haben wir schnell fast vierzig Testskizzen angefertigt. Arduino ermöglichte es uns, uns auf die Implementierung von genügend Logik zu konzentrieren, um eine beliebige Anzahl von SIO-Peripheriegeräten zu implementieren, und bot eine Fülle von Klassen und Funktionen, die wir nicht implementieren mussten.
In der Zwischenzeit hatte Jeff Piepmeier (@jeffpiep) dafür plädiert, dass PLATFORM.IO für die Erstellung der Produktions-Firmware verwendet werden sollte. Dieser Fall wurde mit einigen sehr soliden Gründen angeführt, nämlich dass es viel einfacher war, die verschiedenen Code-Bits in separate Bibliotheken aufzufächern und sie aus dem Hauptcode heraus zu nutzen. Es bot auch einen sehr netten Editor in Form von VS.CODE, der sowohl in Bezug auf die Benutzerfreundlichkeit als auch auf die Skalierbarkeit wirklich eine nette Verbesserung gegenüber dem Arduino-Editor darstellt. Jeff konnte seine ersten Arbeiten an der Druckeremulation in PLATFORM.IO durchführen. Er begann auch damit, die Arbeit, die sich unter der Multilator-Skizze zusammengefunden hatte, in nette C++-Klassen zu zerlegen, die auf einige wenige Bibliotheken verteilt waren, und den virtuellen SIO-Bus zu implementieren, den wir innerhalb des Hauptcodes brauchten, um all diese verschiedenen virtuellen Geräte miteinander zu verbinden. Ende Januar waren alle Arbeiten am Multilator in eine weiche Landung gerutscht, und wir waren vollständig auf die PLATFORM.IO-Codebasis umgestiegen.
Es war wunderbar zu sehen, wie die Geräte D: R: und P: unter einem Dach zusammenarbeiteten. Dank der harten Arbeit aller Beteiligten kam alles zusammen und funktionierte beim ersten Mal fast vollständig, wobei die Fehler in den nächsten Wochen behoben wurden, und im Februar hatte ich mit der Arbeit an den ersten Teilen dessen begonnen, was das N:-Gerät werden sollte.
Jeff fand auch Zeit, im SAM-Sprachsynthesizer eine nette kleine Überraschung einzubauen. Ich hatte vor geraumer Zeit einen Port von SAM nach C gefunden und hatte mich daran erinnert, ihn an Jeff weitergegeben, und an einem Wochenende im März begann #FujiNet zu sprechen.
In der Zwischenzeit hatten wir im März dringend benötigte Hilfe von Rick Lopez alias 8bitandmore erhalten, der ein FujiNet aus Schaltplänen baute und damit begann, das R:-Gerät zu verbessern und zu optimieren, um es noch besser arbeiten zu lassen und Fehler zu beheben.
Und wir bekamen eine besondere Überraschung von Marcin Sochacki (@TheMontezuma), der ebenfalls ein ESP32 auf einem Brotbrett baute und SIO2BT-Unterstützung beisteuerte!
Im Laufe des März begann ich langsam damit, mehr von dem N:-Gerät in Form der TCP- und UDP-Protokolladapter herauszuarbeiten. Während ich die Firmware für diesen Teil des Systems implementierte, wurde eine Reihe von Testprogrammen geschrieben, die über SIO mit dem #FujiNet sprachen, um den Low-Level-Betrieb verschiedener Teile des Codes zu verifizieren, den der N:-Handler schließlich verwenden würde. Dadurch wurde die Anzahl der Debugging-Punkte auf einen statt zwei minimiert, und die Netzwerkfunktionen begannen sich zu etablieren.
In der Zwischenzeit, im April, erhielten wir Hilfe und Beiträge von Oscar Fowler (@jamm), der damit begann, den Code zu sichten und langsam zu überarbeiten, um ihn besser zu machen.
Wir begannen im Mai mit einer neuen Hardware-Revision, die einige Probleme beseitigte, auf die ich weiter unten eingehen werde, und ich begann mit der Erweiterung von N: zur Handhabung von Netzwerk-Dateisystemen auf Dateiebene.

Als wir all diese Funktionen ausarbeiteten, stießen wir auf Probleme:
* Die Druckemulation saugte RAM. Die 320.000 auf der ESP32, zu der wir umgezogen waren, weil uns die 80.000 für die ESP8266 zur Verfügung stehenden Widder ausgingen, waren ebenfalls erschöpft, was zu Zusammenstößen und Stabilitätsproblemen führte. Die Erstellung einer PDF-Datei erfordert eine Menge RAM! Dies wurde durch eine weitere Hardware-Revision gelöst, die den Arbeitsspeicher auf das für ESP32 verfügbare Maximum (8 Megabyte PSRAM) erhöhte.
* Auch die Bluetooth-Emulation beanspruchte nicht nur wertvollen RAM-, sondern auch Flash-Speicherplatz. Die Lösung bestand nicht nur darin, den RAM-Speicher zu vergrößern, wie wir es oben getan haben, sondern auch die Menge des Flash-Speichers auf die maximal verfügbare Menge (16 Megabyte) zu erhöhen.
* Während wir alles zusammenbanden, wurde deutlich, dass sich die Anlaufzeiten aufgrund des hohen Initialisierungsaufwands enorm verlängerten. Verschärft wurde dies durch den Zeitaufwand für die Prüfung des PSRAM. Während die ganze Initialisierung stattfand, konnte das FujiNet während dieser Zeit auf nichts vom Atari reagieren und, was noch wichtiger war, nicht hochfahren. Es wurde klar, daß wir eine feinere Kontrolle über den Initialisierungsprozeß haben mußten, um nicht nur die Initialisierungszeit zu verkürzen, sondern auch um Aspekte der Initialisierung fein zu priorisieren und zu verschieben, um gerade genug vom Gerät hochzubringen, daß es zumindest auf das Starten des CONFIG-Programms reagieren konnte, während der Rest des Gerätes im Hintergrund initialisieren konnte.
* Die seriellen E/A-Routinen, die letztendlich den SIO-Verkehr senden und empfangen, sind nicht so effizient, wie sie sein könnten. Das Timing von SIO ist absolut kritisch, da die Antwortzeiten für Dinge wie die Bestätigung (ACK) in Mikrosekunden erwartet werden, und die gepufferte Beschaffenheit der UARTs bedeutete, dass wir den UART spülen mussten, um sicherzustellen, dass Dinge wie die Bestätigungspakete (ACK) rechtzeitig gesendet wurden, es bedeutete, dass die weitere Übertragung von Daten um einige Millisekunden verzögert würde, und obwohl dies nicht nachteilig ist, bedeutet es, dass es schneller gemacht werden kann, aber nur, wenn wir die Hardware direkt kontrollieren.
Zusätzlich zum Arduino-Framework (und Frameworks wie Pumbaa und Simbaa, die es erlauben, andere Sprachen wie Python und Lua zum Schreiben von Code zu verwenden) bietet PLATFORM.IO die Möglichkeit, Projekte zu erstellen und zu verwalten, die für das ESP-IDF-Framework geschrieben wurden. Das ESP-IDF-Framework ist das Herstellerframework, das von Espressif für die Entwicklung von C- und C++-Software für ESP32-Projekte bereitgestellt wird. Ein Großteil der Arduino-Klassen sind tatsächlich als Wrapper um ESP-IDF implementiert, und dieser nicht benötigte Wrapper kann entfernt werden.
Darüber hinaus sind viele der flexiblen Optionen, die in ESP-IDF zur Verfügung stehen (wie z.B. die Angabe einer größeren Anzahl zulässiger TCP-Verbindungen, die Einstellung der Puffergrößen, die Änderung der Art und Weise, wie das Hochfahren und die Initialisierung durchgeführt wird, usw.), unter der Arduino-API einfach nicht verfügbar, wir müssen diese Funktionen direkt erreichen. Ganz zu schweigen von der Tatsache, dass die Version von ESP-IDF, die derzeit im veröffentlichten Arduino-Framework vorhanden ist, älter ist als die neueste Version dieses Frameworks, die von Espressif veröffentlicht wurde. Diese Version behebt eine Reihe von Fehlern, auf die wir bei der Entwicklung dieser Software gestoßen sind, von denen der berüchtigtste eine Standard-POST-Header-Größe für HTTP-Transaktionen war, die unseren Web-Administrator daran hinderte, korrekt mit dem Chrome-Browser zu arbeiten.

Also begann Oscar damit, die Abhängigkeiten von Arduino.h herauszureißen, und mit jedem Fehler, der auftrat, schrieb er äquivalente Funktionen und Klassen, um die mit Arduino verlorene Funktionalität zu ersetzen, und rief bei Bedarf ESP-IDF auf. Dies war ein sehr langsamer Prozess, bei dem die gesamte Code-Basis durchquert wurde (da jeder von uns aktiv am Code arbeitete!) und heimlich Arduino-Aufrufe durch fnSystem-Aufrufe u.a. ersetzt wurden.
Oscar erreichte einen Punkt, an dem der Code in unseren neuen Bibliotheken gründlich neu gebunden worden war und die Funktionalität wie erwartet funktionierte. Daher beschloss er, ein neues Projekt unter dem Platformio-Verzeichnis namens FujiNet_idf zu erstellen, ein Projekt, das nur den ESP-IDF-Rahmen und überhaupt nicht Arduino verbindet. Nach etwa einer Woche Arbeit wurde der Code kompiliert, und zwei Tage später wurde die erste Festplatte gebootet. Die harte Arbeit an der Infrastruktur, um uns von den Arduino-Abhängigkeiten zu befreien, hat sich ausgezahlt, und der Umfang der funktionierenden Funktionalität nach dem ersten erfolgreichen Build hat uns alle überrascht, ganz sicher.
Und wie geht es weiter?
Ich nehme mir ein paar Wochen Auszeit, um mich zu entspannen, während Oscar weiterhin die ESP-IDF-Version des Codes debuggt und refaktoriert, mit dem Ziel, Feature-Parität mit der aktuellen Produktionsversion zu erreichen. Das größte Problem ist derzeit der Umgang mit Pausen in der seriellen Ausgabe bei hohen Geschwindigkeiten. Wir vermuten ein Zeitproblem, das wir lösen müssen (jetzt, da wir eine Schicht näher am blanken Metall sind), und wir hoffen, dass wir es schnell lösen können.
Jetzt, da @Mozzwald offiziell einen ersten Produktionstestlauf von 50 Einheiten durchgeführt hat, besteht der Druck, das, was wir haben, zu knöpfen, um es für diese Produktionseinheiten bereit zu machen. Dies wird genau das sein, was uns von den verschiedenen Peripheriegeräten D, P, R und N sowie SAM zur Verfügung steht, wobei der Schwerpunkt auf der Behebung von Fehlern in CONFIG liegt (bei der Rick alias 8bitandmore hilft), und wir werden eine nahtlose Möglichkeit zur Aktualisierung der FujiNet-Firmware zusammenstellen, während wir für den Rest dieses Jahres und in der Zukunft die Funktionalität weiter ausbauen.
In Erwartung der Auslieferung dieser ersten 50 Testeinheiten habe ich begonnen, einen Testplan voller Testverfahren zu schreiben, die nicht nur der Validierung, sondern auch der Anleitung der Funktionalität des #FujiNet dienen.
Ich möchte allen danken, die mit Blut, Schweiß und Tränen zu diesem Projekt beigetragen haben. Es ist unser aller Verdienst, dass wir eine der besten Peripheriegeräte haben, die je an einen Atari-Computer angeschlossen wurden. Ich hoffe, dass dieses Projekt ganz unter freiem Himmel durchgeführt wird und eine Atmosphäre schafft, die die Menschen dazu verleitet, zu etwas wirklich Lustigem und Erstaunlichem beizutragen. Ich hoffe auch, dass wir durch die Durchführung all dieser Arbeiten unter freiem Himmel unweigerlich sicherstellen, dass dieses Gerät für die Zukunft der Atari-Gemeinschaft nützlich bleibt und dass es zu einem Modell dafür wird, wie man eine nutzbare Netzwerkschnittstelle auf Retrocomputer-Plattformen schraubt.

Re: Heiß, heißer, FujiNet

von nortobor » Do 18. Jun 2020, 14:25
Hallo tschak909,
vielen Dank für die lange Erläuterung in deutsch für unser ABBUC-Forum.
Bin an dem FujiNet sehr interessiert und habe ja auch einige, leider erfolglose, Versuche unternommen (nach dem Artikel im ABBUC-Magazin von Montezuma).
Mir geht es nicht vorrangig um eine fertige Hardware, sondern auch um die Verbindung ATARI XL/XE (8-Bit Technik aus den 1980 zigern) mit Technik heutiger Zeit- 2020.

Nicht so gut fand ich den Inhalt der Sätze --"Aufrufe an die Arduino-Bibliothek zu entfernen und sie durch Aufrufe an das ESP-IDF-Framework zu ersetzen." und
"Die harte Arbeit an der Infrastruktur, um uns von den Arduino-Abhängigkeiten zu befreien, hat sich ausgezahlt"
Es ist natürlich euer Projekt und ihr seid sicher erfolgreich, das zeigt ja auch, daß die ersten 50 Bestellungen schnell weg waren.
Mir wäre natürlch eine "Arduino-Abhägigkeit" lieber.

Wünsche Euch viel Erfolg und hoffe, daß hier im deutschem ABBUC-Forum sich mehr für diese Projekt interssieren. :goteam:

Hello chak909,
thank you very much for the long explanation in german for our ABBUC-Forum.
I am very interested in the FujiNet and have made some, unfortunately unsuccessful, attempts (after the article in the ABBUC magazine of Montezuma).
I am not primarily interested in a finished hardware, but also in the connection of ATARI XL/XE (8-bit technology from the 1980s) with technology of today's time - 2020.

I didn't like the content of the sentences -- "remove calls to the Arduino library and replace them with calls to the ESP-IDF framework" and

"All the hard work we put into the infrastructure to free us from the Arduino dependencies has paid off"
It is of course your project and you are certainly successful, which also shows that the first 50 orders were quickly gone.
Of course, I'd prefer an "Arduino addiction".

Wish you good luck and hope that more people are interested in this project here in the German ABBUC-Forum.

Translated with http://www.DeepL.com/Translator (free version)

Re: Heiß, heißer, FujiNet

von tschak909 » Do 18. Jun 2020, 19:55
@nortobor -

Es gab viele Gründe, warum wir Arduino von unserem Projekt ausschließen mussten. Der größte war, dass die Arduino-Klassen ESP-IDF umhüllen und Annahmen treffen, die in unserem Anwendungsfall nicht funktionieren.

Da die ESP32- (und ESP8266)-Versionen des Arduino-Frameworks das ESP-IDF-Framework umhüllen, machte es für uns keinen Sinn, sie weiterhin zu verwenden, wenn es nicht nur Fehler gab, die uns betrafen, sondern auch, dass wir eine feinere Steuerung der Hardware benötigten.

Ein Beispiel dafür ist der durch die Serial flush()-Funktion verursachte Overhead: Sie wartet buchstäblich, bis der FreeRTOS Spin-Lock vollständig abgeschlossen ist, was zwischen 1 und 10 Millisekunden dauern kann. Um dies zu umgehen, muss man direkt mit dem UART-Register sprechen.

Arduino hat uns sehr gut gedient, und es ermöglichte uns, die Durchführbarkeit jeder einzelnen Funktion schnell zu testen, aber eigentlich ist es für uns ein Hindernis für die Zukunft, so dass wir auf das Vendor-Framework portiert haben, das weitgehend erfolgreich war.

---

@nortobor -

There were many reasons that we had to excise Arduino from our project. The biggest was that the Arduino classes wrap ESP-IDF, and make assumptions that don't work in our use case.

Since the ESP32 (and ESP8266) versions of the Arduino framework wrap the ESP-IDF framework, it did not make sense for us to continue using them, when there are not only bugs which affected us, but that we needed finer grained control of the hardware.

One example of this is the overhead imposed by the Serial flush() function: it literally waits until the FreeRTOS spin-lock is completely finished, which may take anywhere from 1 to 10 milliseconds. The way around this is to talk to the UART register directly.

Arduino did serve us very well, and it allowed us to quickly test the feasibility of each individual feature, but it is actually an impediment for us, going forward, so we have been porting to the vendor framework, which has been largely successful.

-Thom

Re: Heiß, heißer, FujiNet

von tschak909 » Do 18. Jun 2020, 22:22
#Atari8bit #FujiNet Da die erste Auflage so schnell ausverkauft war, hat @mozzwald ein Anmeldeformular für interessierte #FujiNet-Käufer eingerichtet, um den Umfang der nächsten Auflage abzuschätzen. Wie zuvor, $65 mit Etui, $55 ohne Etui. Sie erhalten eine E-Mail, wenn der nächste Lauf stattfindet.

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

Ich danke Ihnen allen für Ihre Geduld und Ihr Interesse.

---

#Atari8bit #FujiNet 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.

Re: Heiß, heißer, FujiNet

von Mathy » Fr 19. Jun 2020, 00:57
Hallo Leute

Bin mir noch nicht sicher ob Ich diese Hardwarelösung haben will oder zB. die von Dropcheck/Lenore (oder beide), aber wir könnten doch eine Sammelbestellung organisieren, oder? Mit Auslieferung auf der Fujiama.

Tschüß

Mathy

Re: Heiß, heißer, FujiNet

von Montezuma » Fr 19. Jun 2020, 09:39
Mathy hat geschrieben:Hallo Leute

Bin mir noch nicht sicher ob Ich diese Hardwarelösung haben will oder zB. die von Dropcheck/Lenore (oder beide), aber wir könnten doch eine Sammelbestellung organisieren, oder? Mit Auslieferung auf der Fujiama.

Tschüß

Mathy


Ich empfehle allen, die sich das leisten können, #Fujinet bei den Entwicklern zu bestellen und damit die Entwicklungskosten zurückzuzahlen.
Insgesamt kostet aber ein Gerät für EU Nutzer: $65 + Versand aus den USA + Einfuhrgebühren, wahrscheinlich knapp unter 100€.
Das Ziel von Thomas und das Team ist, dass #Fujinet zu den gängigsten SIO Geräten gehört. Deswegen nach dem erfolgreichen Produktionslauf, werden alle Unterlagen veröffentlicht, damit sich jeder ein #Fujinet selbst bauen kann.
Thomas wünscht sich sogar, dass jemand hier vor Ort die Produktion organisiert, damit die hohe Versandkosten, Einfuhrgebühren, etc. entfallen und so viele User, wie möglich #Fujinet benutzen können.
Ich habe bereits Jürgen per E-Mail angefragt, ob er daran Interesse hätte.

Wenn die Kosten gesenkt werden (zum Beispiel durch Verzicht auf das Gehäuse), könnte #Fujinet als Jahresgabe an alle ABBUC Mitglieder verteilt werden. Bunsen hat diese Idee vor ein paar Monaten begrüßt.
Damit würden sich für den Club neue Möglichkeiten eröffnen, zum Beispiel:
- die ganze PD Bibliothek, könnte über TNFS Server online verfügbar gemacht werden und damit direkt von Atari Rechner erreichbar
- genauso ABBUC Magazin Disketten
- praktisch alle Web Inhalte könnten für den 8-bit Atari verfügbar gemacht werden
Die Liste ist lange noch nicht vollständig...

Re: Heiß, heißer, FujiNet

von tschak909 » So 21. Jun 2020, 23:26
#Atari8Bit the first game for #FujiNet is a Free Internet Chess Server (FICS) client called ChessNet written by @bocianu using MAD Pascal! Amazing work! https://youtu.be/JdKTFl_uzIM

---

#Atari8Bit die erste Partie für #FujiNet ist ein Free Internet Chess Server (FICS)-Client namens ChessNet, der von @bocianu unter Verwendung von MAD Pascal geschrieben wurde! Erstaunliche Arbeit! https://youtu.be/JdKTFl_uzIM

Re: Heiß, heißer, FujiNet

von tschak909 » Mi 8. Jul 2020, 20:57
#Atari8bit Hello, everyone. I've been busy with a move to a new house, and getting not only my house set up, but putting IRATA.ONLINE back on-line in the new house, as well as getting my lab set up.

Everything is mostly set up at this point, and I've resumed both my day job and work on IRATA.ONLINE and #FujiNet. The rest of this post deals with #FujiNet.

I have had to get a couple of purchases with the funds that have come in from Patreon, thanks to all that have contributed:

* My development laptop (TMA-1) is suffering from thermal battery expansion which has warped my case. $250 from the Patreon was used to submit a warranty service request for on-site service to replace both my battery (which is four years out of warranty) and the bottom battery cover which has been damaged. This will happen in the next few days, as soon as my Dell representative confirms my on-site appointment.

* My capture device which was being used to record all the various #FujiNet videos has died, and I decided to replace it with a proper capture device that can plug into my RetroTink 2X upscaler, an Elgato HD 60 S+, for $216 all in.

I am in the process of continuing on N: development. The code is now self-relocatable, thanks to the ultd example provided by Jon Halliday (@flashjazzcat), the N: code now runs successfully under SpartaDOS, and is smaller than the ACTION! based relocator, as well as being more efficient.

At this point, N: needs:
* An implementation of BINARY LOAD for both MyDOS and SpartaDOS.
* Make ?DIR work in SpartaDOS
* Implement directory listing for WEBDAV (HTTP/S)
* Implement the rest of 8.3 to long filename translation. This is difficult because we need to implement a sort of filename cache.
* (maybe) deal with the fact that SpartaDOS upper-cases ALL CP input. grrr.

Furthermore, N: also needs functional XML and JSON parsers that we can embed and interface to.
This is, by and large, the last 20% of N: development, which will take a significant chunk of time, along with debugging every possible combination of DOS/DUP that can use the N: device.

More to come, but I wanted to give everybody an update over the last two weeks!
-Thom

---

#Atari8bit Hallo, zusammen. Ich war mit einem Umzug in ein neues Haus beschäftigt und war nicht nur damit beschäftigt, mein Haus einzurichten, sondern auch damit, IRATA.ONLINE in dem neuen Haus wieder online zu stellen und mein Labor einzurichten.

Im Moment ist alles weitgehend eingerichtet, und ich habe sowohl meinen Tagesjob als auch meine Arbeit an IRATA.ONLINE und #FujiNet wieder aufgenommen. Der Rest dieses Beitrags befasst sich mit #FujiNet.

Mit den Geldern, die aus Patreon eingegangen sind, musste ich einige Käufe tätigen, dank all derer, die dazu beigetragen haben:

* Mein Entwicklungs-Laptop (TMA-1) leidet unter thermischer Batterieausdehnung, die mein Gehäuse verformt hat. $250 von der Patreon wurden verwendet, um eine Garantieanforderung für einen Vor-Ort-Service einzureichen, um sowohl meine Batterie (die vier Jahre außerhalb der Garantiezeit ist) als auch die untere Batterieabdeckung, die beschädigt wurde, zu ersetzen. Dies wird in den nächsten Tagen geschehen, sobald mein Dell-Vertreter meinen Vor-Ort-Termin bestätigt.

* Mein Capture-Gerät, mit dem all die verschiedenen #FujiNet-Videos aufgenommen wurden, ist abgestorben, und ich habe mich entschlossen, es durch ein geeignetes Capture-Gerät zu ersetzen, das an meinen RetroTink 2X Upscaler, einen Elgato HD 60 S+, angeschlossen werden kann, und zwar für $216 insgesamt.

Ich bin gerade dabei, die Entwicklung von N: fortzusetzen. Der Code ist jetzt dank des ultd-Beispiels von Jon Halliday (@flashjazzcat) selbstrelozierbar, der N:-Code läuft jetzt erfolgreich unter SpartaDOS, ist kleiner als der auf ACTION! basierende Relocator und außerdem effizienter.

An diesem Punkt benötigt N::
* Eine Implementierung von BINARY LOAD sowohl für MyDOS als auch für SpartaDOS.
* Damit ?DIR in SpartaDOS funktioniert.
* Implementierung der Verzeichnisauflistung für WEBDAV (HTTP/S)
* Implementieren Sie den Rest der Übersetzung von 8,3 zu langen Dateinamen. Dies ist schwierig, da wir eine Art Dateinamen-Cache implementieren müssen.
* (vielleicht) mit der Tatsache umgehen, daß SpartaDOS ALL CP input in Großbuchstaben schreibt. grrr.

Darüber hinaus benötigt N: auch funktionale XML- und JSON-Parser, die wir einbetten und mit denen wir eine Schnittstelle bilden können.
Dies sind im Großen und Ganzen die letzten 20 % der Entwicklung von N:, was einen beträchtlichen Teil der Zeit in Anspruch nehmen wird, zusammen mit dem Debuggen jeder möglichen Kombination von DOS/DUP, die das N:-Gerät verwenden kann.

Es wird noch mehr kommen, aber ich wollte alle in den letzten zwei Wochen auf den neuesten Stand bringen!

Re: Heiß, heißer, FujiNet

von tschak909 » Sa 11. Jul 2020, 03:32
#Atari8bit #FujiNet Wenn Sie denjenigen auf der Liste der ersten 50 helfen können, das N:-Gerät zu hacken, entweder auf der Atari-Seite oder auf der #ESP32-Seite, wenden Sie sich bitte an Thomas Cherryhomes, da ich an die Grenzen dessen stoße, was ich debuggen kann, und Leute gebrauchen könnte, die schlauer sind als ich.

-Thom

Re: Heiß, heißer, FujiNet

von tschak909 » So 12. Jul 2020, 02:14
#FujiNet #Atari8bit Der hier gezeigte Atari8bit verwendet das Gerät N: in Ataris Music Composer-Cartridge zum Laden/Speichern von Kompositionen über das Netzwerk. Bin jetzt im neuen Büro, kann mein Mikrofon noch nicht finden, also kein v/o, ABER ich benutze mein neues Elgato HD 60 S+ zu meinem RetroTink 2X, schönes Video! https://www.youtube.com/watch/?v=BunrKCZueKI

Re: Heiß, heißer, FujiNet

von tschak909 » Mo 13. Jul 2020, 01:53
#Atari8Bit #FujiNet works successfully with FoReM XE Pro 5.4, after a few additions to the R: device code. Now I just need to see how to properly set up the file areas, if anyone can help, pls let me know. https://youtu.be/fcJXjjroA-U

Re: Heiß, heißer, FujiNet

von tschak909 » Sa 18. Jul 2020, 04:06
#FujiNet #atari8bit Oh schau! Es ist Weihnachten im Juli! Die ersten 50 Produktionsplatten sind bei @mozzwald eingetroffen! Als nächstes werden die Steckverbinder darauf montiert! Anschnallen, Leute! Diejenigen von Euch, die die ersten 50 Stück bestellt haben, werden bald ihre Bestellung erhalten!

fujiboards.jpg
fujiboards.jpg (248.47 KiB) 4423-mal betrachtet
1 ... 4, 5, 6, 7, 8, 9, 10, 11