Posts by markusC64

Quote from auron

Challenge accepted

Super. Dann kann ich ja zukünftig den in Entwicklung befindlichen g64conv Nachfolger damit testen.

PS: g64conv kann den 8250-Flux nach .g64 konvertieren - bei der Entwicklung

a) war die Überlegung: Wenn .d82 reicht, würde jemand eher nicht den ganzen Aufwand mit 100 TPI Laufwerk und so treiben. Also möchte man eher die GCR Daten haben - oder gleich was P64 artiges.

b) war die Überlegung: Bei Bedarf könnte ja g64conv erweitert werden um eine Konvertierung nach .d82

Das .g64 kann g64conv natürlich - wie jedes G64 - nach .txt konvertiert werden, so dass man den Inhalt sehen kann.

Inzwischen hat g64conv jedoch einen Feature-Freeze zu Gunsten des Nachfolgers, so dass .d82 Support im Nachfolger reinkommt.

Quote from auron

Was ich bräuchte wäre eine physische Disk, um meinen Proof-of-concept Hardware Hack überhaupt zu testen.

Meine SFD 1001 ist zwar noch beschäftigt, aber das Zwischenergebnis sieht so aus, als würde die Erstellung einer Diskette funktionieren. Aus unerfindlichen Gründen habe ích die SFD 1001 jedoch ausschließlich an der ZoomFloppy zum Laufen bekommen. Egal, für diesen Zweck reicht das ja.

Lasse gerade per d82copy die Test-/Demodiskette drauf kopieren, damit prüft ist, dass die Diskette es auch wirklich tut. Denn ich habe nur bereits benutzte Disketten...

Kannst die bespielte Diskette Du kostenlos haben im Tausch gegen einen Kryoflux / Greaseweazle Dump.

Ich glaube, das passt schon. Parser vergiss bitte nicht, dass ich mit einem Panasonic HD Diskettenlaufwerk für den PC 1/3 der Tracks einer SFD 1001 Diskette fehelrfrei auslesen konnte... dass es nicht mehr ist, liegt natürlich an 100 TPI vs. 96 TPI.

Ich muss mal schauen, ob es mein Laufwerk noch tut. Falls ja, könnte ich eine Samplediskette bespielen.

Quote from andato77

...die aufwändige Festlegung auf ein (nachzuahmendes) Laufwerk wird ein Grund sein weil

man ja mit dem Panasonic nur eine gewisse Zahl Laufwerke "nachbilden" kann.

Das will man nicht. Man möchte eigentlich das relevante in GreaseWeazle einbauen, so dass man die Laufwerksdetails per Config übergibt... so viele verschiedene Laufwerke scheint es eh nicht zu geben. Halt die 48 bzw. 96 TPI und die 100 TPI. Bei der Spur 0 Lage scheinen sich die Gruppen einig zu sein, nur zwischen beiden Gruppen gibt es keine Übereinstimmung. Warum auch, 96 tpi und 100 rpi passen ja eh nicht zusammen.

Auch wenn das aus dem Kryofluxforum ist: Mit Kryoflux macht das bestimmt keinen Spaß, weil man in dtc.exe da nichts reinbekommt.

Habe ich das aus dem Kryofluxforum richtig verstanden und man kann mit dem dort beschriebenen Hardwaremod in Verbindung mit dem Floppydisk-Mod (wegen negativer Spuren) dann die Spuren mit 1/8 Spur Abstand anfahren?
Dann müsste man ja nur mathematisch ein "nächster davon zu den 100tpi Spuren" ermitteln und müsste es gelesen bekommen.

Aber kontaktiere doch mal Keir (der Autor von GreaseWeazle), der ist im Allgemeienn sehr hilfsbereit und könnte mit der GreaseWeazle Anpassung vermutlich helfen.

Quote from andato77

Du sprichst von g64conv und seinen Fähigkeiten in Richtung 825ß.

Hast Du und mit welchem 100tpi eingelsen?

Leider nicht. Ich habe einem 96 tpi Laufwerk eingelesen - erfahrungsmeäß sind so ca. 1/3 der Tracks lesbar. Genug, um zu beurteilen, dass g64conv das Auswerten hinbekommt. Zu wenig, um den Dump sinnvoll gebrauchen zu können.

Quote from andato77

Bevor ich die Frage vergesse, kann Greaseweazle auch SCP? Aber wichtiger ist die Frage nach dem Laufwerk.

Ja. Greaseweazle kann sowohl SCP als auch Kryoflux als fluxbasierte Images.

Edit: Unter Berücksichtigung, dass 100 TPI Laufwerke rar sind, ist ein Ansatz wie in https://forum.kryoflux.com/vie…p=14363&hilit=8250#p14363 vielleicht auch nicht verkehrt. Geht aber nur zusammen mit den wohlbekannten Mod, um negative Tracks anfahren zu können... Die "Track 0" stelle eines 100 TPI Laufwerkes entspricht nämlich einen negativen Track auf einen 96 TPI Laufwerk.

Stimmt. Beim üblichen Data Becker Kopierschutz (der entgegen der Ankündigung aus dem Handbuch doch nicht so doll war) sollte auch eine ZoomFloppy ein brauchbares Image hinbekommen.

Im Hinblick auf Preservation wäre ein Kryofluxdump (oder ander Flux-Hardware) jedoch eindeutig zu bevorzugen.

Hat sich geklärt:

Quote from Greg Nacu

All the .t files in the //os/s/ or //os/h/ or other header directories are for headers that include comments and notes. And then those get their labels exported to corresponding filenames in the same directory but with a .s or .h extension (to make including them faster and more efficient on a C64).
So, if filejobs.t is one byte longer, it might just be an extra space or something in the comments, which I didn't consider a change sufficiently important to flag the file for inclusion in the next update

Übersetzung:

Alle .t-Dateien in den Verzeichnissen //os/s/ oder //os/h/ oder anderen Header-Verzeichnissen sind für Header, die Kommentare und Anmerkungen enthalten. Diese werden dann in entsprechende Dateinamen im selben Verzeichnis exportiert, aber mit einer .s- oder .h-Erweiterung (damit sie auf einem C64 schneller und effizienter eingebunden werden können).

Wenn filejobs.t also ein Byte länger ist, könnte es nur ein zusätzliches Leerzeichen oder etwas anderes in den Kommentaren sein, was ich nicht als wichtig genug erachte, um die Datei für das nächste Update zu markieren

Immer diese Fehler... wie der ein oder andere bemerkt haben wird, ist C64 OS 1.04 verfügbar. Dafür gibt es zwei Updatepakete: 1.04.upd1.0p.car für das Update von Version 1.0p und 1.04.upd1.03.car für das Update von Version 1.03.

So weit, so gut. Aber eine Datei ist in beiden lt. meinen Analysen verschieden:

"os/s/filejobs.t" ist im ersten Updatepaket 616 Bytes groß und im zweiten 617 Bytes.

Das riecht irgendwie nach einem Fehler...

Wenn man jetzt noch wüsste, welches die korrekte Datei ist, dann könnte man Tipps verteilen.

Naja, Greg wird das schon noch untersuchen.

Quote from Micha52

Bei der Ultimate II+L sollte man vorsichtig sein, die kann keine Wiederherstellung, wie ist es mit der Ultimate 64 Elite?

Prinzipiell hat die U64E auch das Problem der nicht eingebauten Wiederherstellung. Anderseits ist jetzt schon etwas Zeit vergangen und man hört von keinen Problemen.

Daher meine Einschätzung: Nicht gefährlicher als die Updates bis einschl. 3.10a. Kann man also machen - und muss nicht direkt abraten.

2× Nein.

Bei den letzten Versionen bin ich "ohne" immer gut hingekommen.

Beim Flash könnte sich das lohnen, neim Settings rücksetzen hat Gideon inzwischen in jedem Gerät (nach Änderungsliste) eine Funktion drin, die die Settings beim Poweron nicht mit einlädt. Das kombiniert mit der Rücksetzfunktion in der F5-Funktioon selber reicht eigentlich.

Quote from Lynx

Hätte vermutet, dass die Brick-Gefahr primär für die U2+L bestand und der letzte Schliff dafür erfolgen musste. (?)

Eine Sache, die es noch zu klären gilt... das ist in der Kombination in der Tat etwas verwirrend. Anderseits erinnere ich gerne daran, dass die Brickursache für die 3.10i (U2+L) meines Wissens entweder nicht gefunden wurde oder nicht belastbar gefunden wurde. Vermutungen mag Gideon haben (oder auch nicht), jedoch sind Vermutungen ja kein Wissen.

Wohl wahr, aber die Änderungsliste sieht mir noch immer nach der von 3.10i aus. Da wird keiner so recht schlau raus.

Ich weiß aber, dass GeoRAM + UCI jetzt zusammen gehen. Außerdem hat Gideon allgemein am Timing geschraubt.

Edit: Habe die Changenotes von 3.10i und 3.10j maschinell verglichen - außer der Versionsnummer keine Änderung. Also kein Informationsgehalt...

Endlich mal gute Nachrichten!

Ja. Anderseits sieht man am U64, dass der Synthmark die Taktfrequenz ziemlich genau trifft. Also ist der im Grunde in der Lage, den Takt gut zu messen.

Der Synthmark hat aber auch jede Menge Eintelergenisse von verschiedenen Disziplinen, die beim U64 fast alle gleich gut sind. Außer I/O und Colorram, die haben nur 40x. Da raktet die U64 runter, kann hinkommen. Colorram muss schließlich den VIC zeitgleich auch noch bedienen, das kann also etwas weniger. Und I/O, da kommt es eben drauf an...

So wird es beim TC64 auch etwas geben, was der richtig gut kann und was er weniger gut kann und runtertakten muss. Die verlinkten Synthmark Einzelergebnisse sagen, dass er manches mit 20x Tempo kann. Was eigentlich heißen muss: Er hat 20 MHz, wie soll er ansonsten manches mit 20x schaffen?!

Die 10x vom TC 64 ist ein Durschnittswert von 21 Einzelergebissen - da darf man doch mal genauer hinschauen, oder?

Hier sind die Einzelergebnisse vom TC64:

http://wiki.icomp.de/wiki/C64_Benchmarks

Einige Benchmarks schaffen Faktor 20, andere aber nur Faktor 2, einer Faktor 1.5.

Für mich sieht das also so aus: Der Taklt beim TC64 also 20 MHz sein, der ziemlich oft runtergetaktet wird.

Quote from Goethe

- 1541UltimateII+ (hab noch nie probiert, ob die überhaupt am DCRim C128 Modus funktioniert...)

Ja, geht. Werner das so im Einsatz.

Ich tippe mal drauf, dass die REU nicht vollständig motskaliert bei 48 MHz. Für 48 MHz üblich müsste die REU dann ja Speichrzugriffe mit 96 Zugriffen / Mikrsekunde heimgekommen - denn pro Takt wird ein Byte übertragen beim original C64.

Wäre naheliegend... und wer das mal mit Floppy gemacht hat (MegaAss assemblieren), de weiß dass die Floppy (also auch die RAM Floppy) dabei ordentlich zu tun hat.

Aber klar:

48 Mhz: 49,69x

40 MHz: 40,84x

32 Mhz: 33,50x

24 Mhz: 24,87x

20 Mhz: 20,59x

16 bMhz: 16,36x

14 Mhz: 14,28x

12 Mhz: 12,20x

10 Mhz: 10,13x

8 Mhz: 8,08x

6 Mhz: 6,04x

5 Mhz: 5,02x

4 Mhz: 4,03x

3 Mhz: 3,00x

2 Mhz: 2,00x

1 Mhz: 1,00x

Wenn ich Baldige Tina anschalte, gehen die Werte eicht nach unten - aber wer würde das im Wettrennen um die beste Performance machen?!

Color-RAM und I/O snd bei 48 MHz so ziemlich die einzige Ausreizen: Nur 40x.

Sicher, dass der TC64 nur 10 MHz Takt hat?

Finde leider auf die Schnelle keine Angabe...

Quote from darkvision

Bist Du Dir da sicher? Ultimate64 mit Turbo-Firmware? 40MHz?

Ich hab das TC64 und in einigen Benchmarks ist es schneller als die SCPU, das U64 dürfte es aber nicht schlagen...

Ich denke auch, dass das TC64 den Ultimate 64 nicht schlagen kann, der sogar 48 MHz abliefert, und dabei die zur vollen Verfügung hat, weil er keine Badlines nachbilden muss (aber kann).

GEOS relevant sind 23 Sekunden für das Assemblieren von MegaAss 5.1 von und auf REU 1581 zu schlagen - das ist nicht einfach zu schlagen. Selbst VICE schlägt das nur auf wirklich guter Hardware.