Forum64

Mein erster Versuch mit Atmega1284 ist fehlgeschlagen, vom hoffnungsvollen Open1541 Projekt hört man leider auch nix mehr. Das Thema läßt mich irgenwie nicht los, deshalb habe ich einen neuen Anlauf gestartet, mit einem Cortex M4 (Discovery Board).

Ich denke jetzt, dass es machbar ist mit dem Discory Board. Und ich werde das Projekt voran treiben. Zur Zeit entwickle ich die Software aber am PC und portiere das ganze später zum Discovery. Am PC lässt es sich einfach wesentlich komfortabler arbeiten.

Man wird sowohl das 1541 DOS als auch das aktuelle Image File ganz einfach wechseln können. Neben dem standard 1541 DOS wird Speed-DOS und evt. Proffessional DOS unterstützt werden. Natürlich sollen alle seriellen Protokolle funktionieren, wie Jiffy DOS und auch alle Exoten die fix in diversen Spiele und Demos implementiert sind.

Das Imagefile Format ist etwas, das mich noch beschäftigt. Natürlich wird D64 unterstützt, aber das ist ja das ungünstigste Format überhaupt. Speziell für einen 1541 Emulator, der die GCR Daten liest und daher am liebsten pure GCR Daten aus einem Imagefile bekommen würde.

Was wäre denn für ein bestehenden Imageformat zu empfehlen? Ich möchte ungern ein neues Format in Umlauf bringen, obwohl mir der Gedanke durchaus schon gekommen ist. Einfach ein plain 1541 GCR Format, je nach Spur mit maximalen Anzahl an GCR Daten die vorkommen kann plus etwas Reserve. Was meint ihr?

Quoted from "jackdaniels"

wobei eine native unterstützung von d64 schon top wäre!

Die native Unterstützung gibt es bereits. Die Umwandlung erfolgt "on the fly".

Das ist gar nicht das Problem. Will man hingegen Kopien von originalen Disketten abspielen, muss man halt erst ein Imagefile haben. Ein D64 versagt in der regel schon bei einfachen Schutzmethoden kläglich.

Quoted from "Unseen"

Was spricht denn gegen G64?

Das G64 Format hört sich für mich ideal an. Bis auf den Header mach ich das im Moment ganz ähnlich mit gemounteten D64 Images. Statt der empfohlenen Tracklänge 7928 habe ich halt 8K verwendet.

Ein möglicher Schwachpunkt des G64 ist, dass es nur eine Speedzone für den ganzen Track gibt: ($015C-015F: Speed zone entry for track 1)

Wenn jemand mehr als eine Speedzone auf einem Track verwenden würde, könnte man das nicht darstellen ...


Aber gut, nothing is perfect.

Quoted from "Unseen"

d.h. ein Track kann nur ein Vielfaches von 8 Byte enthalten und die Bitrate ist auch nur Byteweise angebbar.

Aha interessant. Aber ist das bei einer 1541 überhaupt relevant?

Die Bitrate lässt sich bei einer 1541 ja sowieso nur mit 2 Bit (4 Bitraten) einstellen.

Ein Vielfaches von 8 Byte oder 8 Bit? Eine 1541 kann ja Folgen von Syncs nicht wirklich trennen, insofern kann man die Tracklänge ja beliebig "faken"?


Ich sag mal so, G64 wird in den allermeisten Fällen sehr gut reichen.

Es geht nur langsam weiter, wegen Zeitmangel. Die Emulation der 1541 am PC läuft jetzt mal rund. Es läuft jetzt die 6502 Emulation, die beiden VIA inklusive Timer und IEC Bus Hardware.

Damit ich es testen kann, habe ich einen kleinen Monitor implementiert. Neben single step, disassemblieren, memory dump kann der Monitor auch DOS Kommandos senden und Status abfragen. Die IEC Routinen dafür stammen direkt aus dem XS-1541 Code.

Die virtuelle 1541 spricht mit mir ...




Muss ich mir jetzt Sorgen machen um meinen PC? Er wirkt so schizophren:

• ein Teil des PC glaubt er ist eine 1541
  
• der andere Teil glaubt ein XS-1541 zu sein
  
• die beiden Teile sprechen miteinander mittels einem uralten 8 Bit Protokoll in urlangsamer Geschwindigkeit von 400 Byte pro Sekunde ...
  

Sektor lesen und schreiben geht nun tadellos, Aber das Kommando zum Formatieren einer Diskette (N0:xxx,ii) erweist sich als echter Prüfstein für die Emulation ...

Eigentlich dachte ich, dass ich die 1541 schon vorher ziemlich gut gekannt habe. Doch man kann/muss immer dazu lernen, man kann immer noch tiefer ins Detail gehen. An der Stelle möchte ich mich bedanken bei den Erstellern der Doku "All avbout your 1541", ohne dieser Seite könnte ich das Emulator Vorhaben vermutlich nicht weiter führen.

Jedenfalls eignet sich der PC Emulator hervorragend zur Analyse. Ich werde ihn auch nach dem Projekt behalten und weiter entwickeln. Denn er ist auch nützlich für die Analyse von beliebigem anderen Floppy Code: Dolphin DOS, Prologic DOS, Professional DOS, Speeder ...

Formatieren geht nun auch endlich. Nur verteilt das DOS die Sektoren noch nicht optimal, ich frag mich ob das an meiner Emulation liegt oder am DOS?

Quoted from "sauhund"

wobei die sektoren nie vollkommen gleichmässig verteilt werden, es gibt am ende eine relativ grosse lücke (verglichen mit den andren)

Aha, dann ist es ja ok so.

Ich dachte eigentlich, genau DAS sollte verhindert werden mit der komplizierten herumrechnerei, die Commodore da fabriziert. Ich hätte da einfach einmalig pro Bitrate die Anzahl Bytes für eine Umdrehung gemessen, dann die Restbytes errechnet und durch die Anzahl Sektoren +1 dividiert. Dabei tut der da seltsame Dinge, mal zwei, wieder ausprobieren ... eher ne empirische Ermittelung.

Am PC läuft es jetzt ziemlich sauber. Reiner C Code (Pelles C). Es sind noch einige Tests zu machen, um die Dinge noch zu optimieren.

Allerdings geht zur Zeit nur D64 und auch da kein zurückschreiben. Ich lese D64 in ein internes Format, wo lesen und schreiben ziemlich perfekt läuft. Diese Datei ist quasi das Abbild der aktuell eingelegten Diskette. Solange ich kein neues Disk Image mounte, arbeitet der Emulator mit dieser Datei direkt.

Da ich D64 in ein internes GCR Format wandle, ist G64 sehr leicht unterstützbar. Offen ist also

• D64 zurückschreiben
  
• G64 lesen
  
• G64 zurückschreiben
  
• so kleiner Dinge wie Schreibschutz (wegen Diskettenwechsel)
  

Diese Dinge werde ich aber zur Zeit nicht implementieren. Zuerst wird es auf die Zielplattform portiert. Das ist der nächste große Milestone.


Allerdings beschäftigt mich noch das "exakte GCR Timing". Exaktes Timing ist implementiert, aber leider auch etwas CPU lastig. Ich beschäftige mich mit Optimierungen, die den Ablauf nicht negativ beeinflussen. Es wird aber darauf hinaus laufen, dass man den 6502-Emul einstellen kann, wie exakt die Emulation gemacht wird. Je nach dem ist es Zyklusgenau (aber langsam) oder eben ungeanau (dafür viel schneller).


Die Timeline ist also:

• Code Cleaning und Optimierung
  
• Umsetzung auf die Zielplattform STM32F407
  
• STM32F407 Adapter auf arm2iec anfertigen
  
• testen, testen, testen ...
  
• bugfix, bugfix, bugfix ...
  
• restliche Dinge wie G64, Sonderbefehle (@CD, @MD, @RD, @LR, @LK, @OPT, @...)
  
• Evaluierung LPC1768/1769, damit das arm2iec direkt unterstützt wird
  
• Verbesserungen: andere Kernel (Jiffy, Speed-DOS, Dolphin, Prof-DOS), Sonderlösungen (eigene Kernelverbesserungen ...)