Heiß, heißer, FujiNet

Moderatoren: Sleeπ, andymanone

Benutzeravatar
Sleeπ
Beiträge: 1618
Registriert: 18.06.2021 20:58
Has thanked: 101 times
Been thanked: 304 times
Kontaktdaten:

Re: Heiß, heißer, FujiNet

Beitrag von Sleeπ »

von Erhard » So 7. Jun 2020, 08:58
Hallo Nortobor,

wo hast Du die Kabel her, mit denen Du das Experimentierboard mit dem SIO-Splitter verbindest?

Selber gemacht?

CU, Erhard
Sleeπ

Benutzeravatar
Sleeπ
Beiträge: 1618
Registriert: 18.06.2021 20:58
Has thanked: 101 times
Been thanked: 304 times
Kontaktdaten:

Re: Heiß, heißer, FujiNet

Beitrag von Sleeπ »

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)
Sleeπ

Benutzeravatar
Sleeπ
Beiträge: 1618
Registriert: 18.06.2021 20:58
Has thanked: 101 times
Been thanked: 304 times
Kontaktdaten:

Re: Heiß, heißer, FujiNet

Beitrag von Sleeπ »

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.
Sleeπ

Benutzeravatar
Sleeπ
Beiträge: 1618
Registriert: 18.06.2021 20:58
Has thanked: 101 times
Been thanked: 304 times
Kontaktdaten:

Re: Heiß, heißer, FujiNet

Beitrag von Sleeπ »

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
Sleeπ

Benutzeravatar
Sleeπ
Beiträge: 1618
Registriert: 18.06.2021 20:58
Has thanked: 101 times
Been thanked: 304 times
Kontaktdaten:

Re: Heiß, heißer, FujiNet

Beitrag von Sleeπ »

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
Sleeπ

Benutzeravatar
Sleeπ
Beiträge: 1618
Registriert: 18.06.2021 20:58
Has thanked: 101 times
Been thanked: 304 times
Kontaktdaten:

Re: Heiß, heißer, FujiNet

Beitrag von Sleeπ »

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.
Sleeπ

Benutzeravatar
Sleeπ
Beiträge: 1618
Registriert: 18.06.2021 20:58
Has thanked: 101 times
Been thanked: 304 times
Kontaktdaten:

Re: Heiß, heißer, FujiNet

Beitrag von Sleeπ »

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

-Thom
Sleeπ

Benutzeravatar
Sleeπ
Beiträge: 1618
Registriert: 18.06.2021 20:58
Has thanked: 101 times
Been thanked: 304 times
Kontaktdaten:

Re: Heiß, heißer, FujiNet

Beitrag von Sleeπ »

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

Benutzeravatar
Sleeπ
Beiträge: 1618
Registriert: 18.06.2021 20:58
Has thanked: 101 times
Been thanked: 304 times
Kontaktdaten:

Re: Heiß, heißer, FujiNet

Beitrag von Sleeπ »

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
Sleeπ

Benutzeravatar
Sleeπ
Beiträge: 1618
Registriert: 18.06.2021 20:58
Has thanked: 101 times
Been thanked: 304 times
Kontaktdaten:

Re: Heiß, heißer, FujiNet

Beitrag von Sleeπ »

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.
Sleeπ

Benutzeravatar
Sleeπ
Beiträge: 1618
Registriert: 18.06.2021 20:58
Has thanked: 101 times
Been thanked: 304 times
Kontaktdaten:

Re: Heiß, heißer, FujiNet

Beitrag von Sleeπ »

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.
Sleeπ

Benutzeravatar
Sleeπ
Beiträge: 1618
Registriert: 18.06.2021 20:58
Has thanked: 101 times
Been thanked: 304 times
Kontaktdaten:

Re: Heiß, heißer, FujiNet

Beitrag von Sleeπ »

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
Sleeπ

Benutzeravatar
Sleeπ
Beiträge: 1618
Registriert: 18.06.2021 20:58
Has thanked: 101 times
Been thanked: 304 times
Kontaktdaten:

Re: Heiß, heißer, FujiNet

Beitrag von Sleeπ »

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.
Sleeπ

Benutzeravatar
Sleeπ
Beiträge: 1618
Registriert: 18.06.2021 20:58
Has thanked: 101 times
Been thanked: 304 times
Kontaktdaten:

Re: Heiß, heißer, FujiNet

Beitrag von Sleeπ »

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
Sleeπ

Benutzeravatar
Sleeπ
Beiträge: 1618
Registriert: 18.06.2021 20:58
Has thanked: 101 times
Been thanked: 304 times
Kontaktdaten:

Re: Heiß, heißer, FujiNet

Beitrag von Sleeπ »

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...
Sleeπ

Benutzeravatar
Sleeπ
Beiträge: 1618
Registriert: 18.06.2021 20:58
Has thanked: 101 times
Been thanked: 304 times
Kontaktdaten:

Re: Heiß, heißer, FujiNet

Beitrag von Sleeπ »

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
Sleeπ

Benutzeravatar
Sleeπ
Beiträge: 1618
Registriert: 18.06.2021 20:58
Has thanked: 101 times
Been thanked: 304 times
Kontaktdaten:

Re: Heiß, heißer, FujiNet

Beitrag von Sleeπ »

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!
Sleeπ

Benutzeravatar
Sleeπ
Beiträge: 1618
Registriert: 18.06.2021 20:58
Has thanked: 101 times
Been thanked: 304 times
Kontaktdaten:

Re: Heiß, heißer, FujiNet

Beitrag von Sleeπ »

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
Sleeπ

Benutzeravatar
Sleeπ
Beiträge: 1618
Registriert: 18.06.2021 20:58
Has thanked: 101 times
Been thanked: 304 times
Kontaktdaten:

Re: Heiß, heißer, FujiNet

Beitrag von Sleeπ »

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
Sleeπ

Benutzeravatar
Sleeπ
Beiträge: 1618
Registriert: 18.06.2021 20:58
Has thanked: 101 times
Been thanked: 304 times
Kontaktdaten:

Re: Heiß, heißer, FujiNet

Beitrag von Sleeπ »

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
Sleeπ

Benutzeravatar
Sleeπ
Beiträge: 1618
Registriert: 18.06.2021 20:58
Has thanked: 101 times
Been thanked: 304 times
Kontaktdaten:

Re: Heiß, heißer, FujiNet

Beitrag von Sleeπ »

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
Sleeπ

Benutzeravatar
Sleeπ
Beiträge: 1618
Registriert: 18.06.2021 20:58
Has thanked: 101 times
Been thanked: 304 times
Kontaktdaten:

Re: Heiß, heißer, FujiNet

Beitrag von Sleeπ »

von tschak909 » So 19. Jul 2020, 02:19
#FujiNet #Atari8bit Hallo an alle, die dies lesen, und die vielleicht in der Lage sind, sich einzustimmen:
Ich versuche derzeit, einige Teile des N:-Geräts zu überdenken, solange ich das noch kann (während fast niemand es tatsächlich benutzt).
Das N:-Gerät besteht aus zwei Teilen: Der Handler auf dem Atari, der CIO in SIO umwandelt. Und die Firmware, die SIO in Aktionen auf dem ESP32 umwandelt.
Dies ist von grundlegender Bedeutung, da SIO blockbasiert und CIO zeichenbasiert ist. Um die Diskussion vorerst zu vereinfachen, spreche ich nur über die SIO-Schicht.
DIE SIO-SCHICHT:
Sie können die SIO-Befehle für das N: Gerät hier sehen: https://github.com/FujiNetWIFI/fujinet- ... 1-to-%2478
SIO ist Halbduplex. Sie verarbeitet Daten jeweils nur in einer Richtung, und obwohl es in der Befehlsstruktur ein Feld gibt, das an den Atari gesendet wird, um zu sagen, wie viele Bytes übertragen werden müssen, wird dies nicht als Teil des Befehlsrahmens entweder an oder von FujiNet übermittelt, was wir für READ- und WRITE-Operationen benötigen. Die beiden Bytes AUX1 und AUX2 hingegen schon. Wir müssen also duplizieren, was im DBYT-Feld in den Feldern AUX1 und AUX2 steht, so dass sie als Teil des Befehlsrahmens erscheinen und daher von der Firmware abgefangen werden können.
OPEN - stellt eine Protokollverbindung her, die Nutzlast geht an das FujiNet, und diese Nutzlast ist die N: Dateispezifikation. AUX1 wird zumindest zum offenen Modus, Bit 2 und 3 sind für Lesen und Schreiben bzw. durch den CIO reserviert, so dass wir diese spiegeln müssen.
In OPEN wird AUX2 zum Modus TRANSLATION, d.h. wie übersetzen wir eine Ende-der-Zeile-Sequenz? Derzeit: 0 = keine Übersetzung, Bit 0 übersetzt CR, Bit 1 übersetzt LF, wenn also die Bits 0 und 1 gesetzt sind, dann werden CR/LF zu und von den beiden Endpunkten übersetzt. Wenn beide CR/LF übersetzt werden, wird die Sache komplizierter, denn entweder wird ein Byte HINZUFÜGEN (im Falle der Konvertierung eines einzelnen EOL-Bytes in CR/LF-Bytes) oder ein Byte UNTERZIEHEN (im Falle der Konvertierung von CR/LF-Bytes in ein einzelnes EOL-Byte). Erinnern Sie sich, dass wir im Voraus festgelegt haben, wie viele Bytes zu lesen/schreiben sind? :)
Wenn ein STATUS-Befehl gesendet wird, werden vier Bytes zurückgegeben. BL BH CO ER, BL und BH sind die Low- und High-Bytes der Anzahl der verfügbaren Bytes (bis zu 65535), während CO verbunden ist (1 = verbunden, 0 = getrennt), und ER der Fehlercode ist, der an den CIO-Handler übergeben wird.
Nehmen wir also an, wir lesen Daten von einem HTTP-Endpunkt:
OPEN N:HTTP://www.google.com/
und in einer Schleife:
```
STATUS();
while (status.bytesVerfügbar>0)
{
READ(buf); // Verringert die Anzahl der verfügbaren Bytes.
verarbeiten(buf);
STATUS();
}
```
Als Teil der Schleife führen wir also einen Status durch, um zu sehen, wie viele Bytes verfügbar sind.
Der WEG, auf dem ich mich derzeit mit der Übersetzung befasse, besteht darin, sie buchstäblich zu fälschen, wobei die gleiche Anzahl von Bytes beibehalten wird:
Wenn CR, dann wird EOL in CR übersetzt, CR wird in EOL übersetzt.
Wenn LF, dann wird EOL in LF übersetzt, LF wird in EOL übersetzt.
Wenn CR/LF, dann wird der Sendepuffer um 1 vergrößert (und die Länge des Sendepuffers um 1 erhöht), und EOL wird zu CR, wobei LF unmittelbar danach eingefügt wird, während beim Empfang CR zu einem SPACE wird, während LF zum EOL wird.
Dadurch braucht der Empfangspuffer seine Größe nicht zu ändern. Ist dies eine schlechte Idee?
Eine Variante davon ist die Übersetzung von Verzeichnisdaten für Netzwerk-Dateisystem-Endpunkte. Sie können im OPEN-Aufruf angeben, ob Sie das Verzeichnis lesen möchten (aux1=6), aber jedes Netzwerkprotokoll führt ein Dateiverzeichnis anders aus und stellt eine Liste von Objekten in einer völlig anderen Syntax dar.
Während wir in einigen Fällen die Daten so anzeigen könnten, wie sie sind (z.B. von FTP), erwarten eine Reihe von Atari-Programmen (wie z.B. (AtariWriter) etwas, das wie das Atari-DOS-Diskettenverzeichnis aussieht. Aus diesem Grund verwenden selbst DOS-Systeme wie SpartaDOS standardmäßig ein Verzeichnisverzeichnis, das wie Atari-DOS aussieht. Das bedeutet, dass es derzeit Code in der Firmware gibt, um die Verzeichnisdaten, die von einem Protokoll zurückkommen, in etwas zu übersetzen, das wie ein DOS-2-Verzeichnis aussieht. Gegenwärtig bedeutet dies auch, dass das IST-Lesen von Verzeichnisdaten im STATUS-Aufruf erfolgt, wobei die Daten in den Empfangspuffer geleert werden, während READ den RECEIVE-Puffer auf den Atari leert und ihn anschließend für den nächsten Statusaufruf löscht.
Damit stellt sich die Frage: Gibt es einen besseren Weg? Gegenwärtig besteht der CIO-Handler auf dem Atari aus etwa 1000 Byte Code, mit 256 Byte Puffer darüber (also 1,3K im gesamten Speicherverbrauch). Er ist klein, weil alles auf dem ESP passiert, und der Handler alles durchlässt (mit einigen kleinen Ausnahmen). Die CR/LF-Übersetzung könnte z.B. im CIO-Handler auf den Atari verschoben werden, wobei etwa 40 oder so Bytes Code hinzugefügt werden, aber wie sollten wir Dinge wie die Dateiverzeichnis-Übersetzung handhaben? Ist die Handhabung im Statusaufruf der einzig vernünftige Weg, dies wirklich zu tun?
Gedanken?
Sleeπ

Benutzeravatar
Sleeπ
Beiträge: 1618
Registriert: 18.06.2021 20:58
Has thanked: 101 times
Been thanked: 304 times
Kontaktdaten:

Re: Heiß, heißer, FujiNet

Beitrag von Sleeπ »

von tschak909 » So 19. Jul 2020, 05:10
@jeffpiep hat es wieder getan! OkiMate 10-Unterstützung wurde der Druckeremulation hinzugefügt, komplett mit Farbe!
okimate10color1.PNG
-Thom
Sleeπ

Benutzeravatar
Sleeπ
Beiträge: 1618
Registriert: 18.06.2021 20:58
Has thanked: 101 times
Been thanked: 304 times
Kontaktdaten:

Re: Heiß, heißer, FujiNet

Beitrag von Sleeπ »

von tschak909 » Mo 20. Jul 2020, 04:07
#atari8bit #FujiNet Während Textübersetzungsoptionen über den AUX2-Parameter in OPEN übergeben werden können, bietet NTRANS die Möglichkeit, diesen Parameter z.B. beim Zugriff auf Netzwerkdateien zu setzen, wodurch Textformate einfach zwischen Atari und anderen Computer-Textformaten konvertiert werden können. https://youtu.be/yNanhqns3_g
Sleeπ

Benutzeravatar
Sleeπ
Beiträge: 1618
Registriert: 18.06.2021 20:58
Has thanked: 101 times
Been thanked: 304 times
Kontaktdaten:

Re: Heiß, heißer, FujiNet

Beitrag von Sleeπ »

von Rockford » Di 21. Jul 2020, 18:33
Hello Thorn,

this ist a great equipment for our A8! I missed to order one of them in the first run, but I hope there will be soon a next - or somenone here in germany who can build it for persons who can't build it be themselves (like me...)

Keep on the great work for the best computer ever built!

8bit greeetings, Holger
Sleeπ

Benutzeravatar
Sleeπ
Beiträge: 1618
Registriert: 18.06.2021 20:58
Has thanked: 101 times
Been thanked: 304 times
Kontaktdaten:

Re: Heiß, heißer, FujiNet

Beitrag von Sleeπ »

von Mathy » Mi 22. Jul 2020, 00:26
Hallo Holger, Leute

Lenore/Dropcheck arbeitet momentan u.A. am "Atari SIO2IO Externally Housed Combo board":

"This project is still in the beta design phase and it’s exact specs will change. In general it will include the MIDI2SIO in/out connections by Mytek, DB25 parallel printer adapter by Supra Microprint, a basic DB9 Rverter serial port and the finished FujiNet wireless hardware project and be self powered. It should be compatible with nearly all Atari 8bit machines and be connected via a single SIO dongle. At this point it should be able to be sold either fully assembled or as a bare board with BOM."

"Kurz" zusammengefasst:

- Ist noch nicht fertig
- Nutzt eine eigene Spannungsversorgung (Hab Ich das richtig verstanden so?)
- Wird über SIO am Rechner angeschlossen
- Hat MIDI In und OUT ports
- Hat ein einfaches Druckerinterface
- Hat eine einfache serielle Schnittstelle (Modeminterface)
- Es ist Fujinet drin
- Wird's wahrscheinlich geben als Fertiggerät und als Platine mit "Zubehörliste"

Tschüß

Mathy
Sleeπ

Benutzeravatar
Sleeπ
Beiträge: 1618
Registriert: 18.06.2021 20:58
Has thanked: 101 times
Been thanked: 304 times
Kontaktdaten:

Re: Heiß, heißer, FujiNet

Beitrag von Sleeπ »

von tschak909 » Mi 22. Jul 2020, 00:30
I really don't see the point of Dropcheck's device, as there is considerable overlap with what #FujiNet provides.

(I say this out of frustration, as they simply assumed that they knew what FujiNet was, didn't ask what it could do, much less talk to us, at all, didn't watch any of the videos to get an idea, and threw one in as an afterthought)

-Thom
Sleeπ

Benutzeravatar
Sleeπ
Beiträge: 1618
Registriert: 18.06.2021 20:58
Has thanked: 101 times
Been thanked: 304 times
Kontaktdaten:

Re: Heiß, heißer, FujiNet

Beitrag von Sleeπ »

von Mathy » Mi 22. Jul 2020, 01:19
Hello Thom

Lenore's device is an All-in-One device. Putting a couple of small devices on one PCB (and possibly in one case). None of the separate devices are of her own design. Not Mytek's/HybridArts MIDI, not Supra's Microprint, not the R-Verter.

I like the idea of having lots of small(er) devices in one case/on one PCB. It saves a lot of space and reduces clutter. It also makes it more feasible to use a separate power supply instead of the Atari feeding power to all of them.

BTW if she wants your device included in her All-in-One device, she obviously things enough people will want to have it in there. Heck, if somebody tells all the world they used something I came up with, I'm proud. It makes me feel like I did something useful for somebody (that I might not even know in real life) and they like it. That's a great feeling!

Sincerely

Mathy
Sleeπ

Benutzeravatar
Sleeπ
Beiträge: 1618
Registriert: 18.06.2021 20:58
Has thanked: 101 times
Been thanked: 304 times
Kontaktdaten:

Re: Heiß, heißer, FujiNet

Beitrag von Sleeπ »

von Montezuma » Mi 22. Jul 2020, 17:57

tschak909 hat geschrieben:
I really don't see the point of Dropcheck's device, as there is considerable overlap with what #FujiNet provides.

(I say this out of frustration, as they simply assumed that they knew what FujiNet was, didn't ask what it could do, much less talk to us, at all, didn't watch any of the videos to get an idea, and threw one in as an afterthought)

-Thom



I fully agree.
Lenore's device makes no sense.
Overlapping functionality may only cause conflicts and missunderstanding.
People will complain that things do not work, because of potencial incompatibility of the projects put together without any good reason.
If I were you I would explicitely forbid to build such monsters.
Sleeπ

Benutzeravatar
Sleeπ
Beiträge: 1618
Registriert: 18.06.2021 20:58
Has thanked: 101 times
Been thanked: 304 times
Kontaktdaten:

Re: Heiß, heißer, FujiNet

Beitrag von Sleeπ »

von tschak909 » Mi 22. Jul 2020, 18:05
I won't forbid anything, it IS a public project, and this is one of the consequences.

I'm more just disappointed and frustrated, because even after we found out that this was happening, and we went to them and tried to impart what we were going to do, they still chose to do it their way, as is their perogative...

(they = Dropcheck and Mytek btw)

-Thom
Sleeπ

Benutzeravatar
Sleeπ
Beiträge: 1618
Registriert: 18.06.2021 20:58
Has thanked: 101 times
Been thanked: 304 times
Kontaktdaten:

Re: Heiß, heißer, FujiNet

Beitrag von Sleeπ »

von tschak909 » So 26. Jul 2020, 21:37
#FujiNet #Atari8bit Hier sehen wir, wie das CONFIG-Programm in etwas umgestaltet wird, das viel einfacher zu warten und zu lesen ist. Ich mache einen kleinen Sprung durch den Code und zeige, was geändert wird und warum. https://www.youtube.com/watch?v=otHcdlx2gBk
Sleeπ

Benutzeravatar
Sleeπ
Beiträge: 1618
Registriert: 18.06.2021 20:58
Has thanked: 101 times
Been thanked: 304 times
Kontaktdaten:

Re: Heiß, heißer, FujiNet

Beitrag von Sleeπ »

von JoSch » Mo 27. Jul 2020, 15:41

Mathy hat geschrieben:
BTW if she wants your device included in her All-in-One device, she obviously things enough people will want to have it in there. Heck, if somebody tells all the world they used something I came up with, I'm proud. It makes me feel like I did something useful for somebody (that I might not even know in real life) and they like it. That's a great feeling!

Sincerely

Mathy




Mathy,

sie weiß, dass genug Leute das Gerät haben wollen, weil sie eine Abstimmung über ihre Projekte gemacht.
Das All-in-one Board hat halt gewonnen.

Grüße Jochen
Sleeπ

Benutzeravatar
Sleeπ
Beiträge: 1618
Registriert: 18.06.2021 20:58
Has thanked: 101 times
Been thanked: 304 times
Kontaktdaten:

Re: Heiß, heißer, FujiNet

Beitrag von Sleeπ »

von tschak909 » Mo 10. Aug 2020, 01:21
#Atari8bit The rewrite for #FUJINET CONFIG is nearing completion, and is now supporting directory pagination, and mounting long filenames! Now to implement the rest... https://youtu.be/mw_qp7KIZW8

---

#Atari8bit Die Neufassung für #FUJINET CONFIG steht kurz vor dem Abschluss und unterstützt nun die Paginierung von Verzeichnissen und das Mounten langer Dateinamen! Um nun den Rest zu implementieren... https://youtu.be/mw_qp7KIZW8
Sleeπ

Benutzeravatar
Sleeπ
Beiträge: 1618
Registriert: 18.06.2021 20:58
Has thanked: 101 times
Been thanked: 304 times
Kontaktdaten:

Re: Heiß, heißer, FujiNet

Beitrag von Sleeπ »

von tschak909 » Fr 14. Aug 2020, 18:19
#Atari8bit #FujiNet In this (admittedly very long video) I take a deep dive through CONFIG 2.0 and the decisions made during rewrite to show why they were done and to show resulting benefits. https://www.youtube.com/watch?v=Bjyj8PJuxpY

---

#Atari8bit #FujiNet In diesem (zugegebenermaßen sehr langen Video) mache ich einen tiefen Tauchgang durch CONFIG 2.0 und die Entscheidungen, die während der Neufassung getroffen wurden, um zu zeigen, warum sie gemacht wurden und um die daraus resultierenden Vorteile aufzuzeigen. https://www.youtube.com/watch?v=Bjyj8PJuxpY
Sleeπ

Benutzeravatar
Sleeπ
Beiträge: 1618
Registriert: 18.06.2021 20:58
Has thanked: 101 times
Been thanked: 304 times
Kontaktdaten:

Re: Heiß, heißer, FujiNet

Beitrag von Sleeπ »

von tschak909 » Sa 15. Aug 2020, 19:08
#FUJINET #ATARI8BIT Because the Read Directory call can specify a length in AUX1, we can give it double duty displaying the primary file list, and a view for longer filenames. https://youtu.be/ZeoVxVRA3Eo

#FujiNet #Atari8bit CONFIG now mounts disks quicker, by returning to the file list after selecting the disk slot for the previous entry. https://youtu.be/LBJBzn_ghdc

---

#FUJINET #ATARI8BIT Da der Aufruf Read Directory eine Länge in AUX1 angeben kann, können wir ihm eine doppelte Aufgabe zuweisen: die Anzeige der Primärdateiliste und eine Ansicht für längere Dateinamen. https://youtu.be/ZeoVxVRA3Eo

#FujiNet #Atari8bit CONFIG mountet Platten jetzt schneller, indem es nach der Auswahl des Platteneinschubs für den vorherigen Eintrag zur Dateiliste zurückkehrt. https://youtu.be/LBJBzn_ghdc
Sleeπ

Benutzeravatar
Sleeπ
Beiträge: 1618
Registriert: 18.06.2021 20:58
Has thanked: 101 times
Been thanked: 304 times
Kontaktdaten:

Re: Heiß, heißer, FujiNet

Beitrag von Sleeπ »

von tschak909 » So 23. Aug 2020, 18:18
#Atari8bit #FujiNet schaut, was kommt! @mozzwald hat den ersten Durchgang der MIDIMAZE-Unterstützung in die Firmware integriert! Er verwendet den UDP-Port 5004, und wir müssen herausfinden, wie wir am besten mit mehreren Playern umgehen können...

Pic here: https://twitter.com/tschak/status/1297566116399767552
Sleeπ

Benutzeravatar
Sleeπ
Beiträge: 1618
Registriert: 18.06.2021 20:58
Has thanked: 101 times
Been thanked: 304 times
Kontaktdaten:

Re: Heiß, heißer, FujiNet

Beitrag von Sleeπ »

von tschak909 » Di 25. Aug 2020, 07:08
Oscar Fowler hat hart an der Implementierung der ATX-Disk-Image-Unterstützung für kopiergeschützte Titel gearbeitet! ATX-Dateien werden als Ganzes von ihrer Quelle (Netzwerk oder lokal) zwischengespeichert, damit die Timings genau sind. https://youtu.be/0Z08VjOL548
Sleeπ

Benutzeravatar
Sleeπ
Beiträge: 1618
Registriert: 18.06.2021 20:58
Has thanked: 101 times
Been thanked: 304 times
Kontaktdaten:

Re: Heiß, heißer, FujiNet

Beitrag von Sleeπ »

von tschak909 » Di 25. Aug 2020, 07:08
Oscar Fowler hat hart an der Implementierung der ATX-Disk-Image-Unterstützung für kopiergeschützte Titel gearbeitet! ATX-Dateien werden als Ganzes von ihrer Quelle (Netzwerk oder lokal) zwischengespeichert, damit die Timings genau sind. https://youtu.be/0Z08VjOL548
Sleeπ

Benutzeravatar
Sleeπ
Beiträge: 1618
Registriert: 18.06.2021 20:58
Has thanked: 101 times
Been thanked: 304 times
Kontaktdaten:

Re: Heiß, heißer, FujiNet

Beitrag von Sleeπ »

von tschak909 » Sa 5. Sep 2020, 04:44
#Atari8bit #FujiNet - @jeffpiep hat den Kassettencode erfolgreich vom SD-Laufwerk portiert und es dazu gebracht, ein Spiel zu starten! Jetzt müssen wir ihn an die Geräte-Slotmaschine anschließen, um ihn nutzbar zu machen. https://youtu.be/yqypoj09or8

---

#Atari8bit #FujiNet - @jeffpiep has successfully ported the cassette code from the SDrive, and gotten it to boot a game! Now we need to hook it into the device slot machinery to make it usable. https://youtu.be/yqypoj09or8
Sleeπ

Benutzeravatar
Sleeπ
Beiträge: 1618
Registriert: 18.06.2021 20:58
Has thanked: 101 times
Been thanked: 304 times
Kontaktdaten:

Re: Heiß, heißer, FujiNet

Beitrag von Sleeπ »

von tschak909 » Mi 9. Sep 2020, 06:27
#Atari8bit #FujiNet verfügt über einen eingebauten XML-Parser und wird hier zum Parsen der WEBDAV-Antwort von einem lokalen Webserver verwendet, um eine brauchbare Verzeichnisliste bereitzustellen!
WIN_20200908_23_09_07_Pro.jpg
WIN_20200908_23_09_07_Pro.jpg (45.62 KiB) 7054 mal betrachtet

-Thom
Sleeπ

Antworten

Wer ist online?

Mitglieder in diesem Forum: 0 Mitglieder und 1 Gast