sd2iec - Floppycode extrahieren - MMC2IEC

Follow the white C64!

Monday, February 15th 2010, 8:25pm

sd2iec - Floppycode extrahieren

Hallo, insbesondere Unseen,

hast du irgend ein Tool oder eine Einstellung mit der du Floppycode von Custom-Loadern extrahierst? Um z.B. die Floppyseite zu reverse engneern um einen AVR-sd2iec Ersatzzu erstellen?
Kann man die serielle Konsole von sd2iec dazu misbrauchen? Als Hardware zum Testen hätte ich ein Lochrasteraufbau und ein LarsP/PeterSieg MMC2IEC.

Insbesondere geht es mir z.B. um den Loader von Nippon als ein kleine Projekt von mir.

cya

Go to the top of the page

Unseen

hat ein Parallelkabel und wird es benutzen!!1

Posts: 3,677

Date of registration: Jun 16th 2007

2

Monday, February 15th 2010, 8:54pm

Quoted from "abraXxl"

hast du irgend ein Tool oder eine Einstellung mit der du Floppycode von Custom-Loadern extrahierst?

Zum Mitschneiden die Firmware mit CONFIG_UART_DEBUG=y und CONFIG_DEADLOCK_ME_HARDER=y compilieren, damit die ans Laufwerk geschickten Befehle im Terminal komplett mitlesbar sind - in den Releases ist mindestens die letzte Option immer aus, da mit ihr der AVR unter Umständen stehenbleibt. Falls das beim Dumpen passieren sollte: CONFIG_UART_BUF_SHIFT erhöhen (Vorsicht: Erhöhung um 1 verdoppelt den Speicherbedarf!) und evtl. CONFIG_BUFFER_COUNT reduzieren (nicht unter 3) um Speicher an anderer Stelle einzusparen.

Im Logfile des Terminalprogramms sind dann Hexdumps aller Kommandos, die man zB mit dem angehängten Perl-Script in eine PRG-Datei umwandeln kann.

Unseen has attached the following file:

cmdparse.zip (845 Byte - 7 times downloaded - latest: Oct 24th 2010, 12:53pm)

	Quellcode
1 2 3	10 x=rnd(-1294):fori=1to52:x=rnd(1):next 20 fori=1to5:printchr$(rnd(1)11+69);:next 30 printint(rnd(1)4711)-3590

Go to the top of the page

abraXxl

Follow the white C64!

Posts: 374

3

Thursday, October 21st 2010, 3:01pm

Hey,

hast du fuer das Feature CONFIG_CAPTURE_LOADERS=y auch schon ein angepasstes Perlskript an der Hand? Mann mus das Rad ja nicht zweimal erfinden.

CONFIG_DEADLOCK_ME_HARDER=y scheint auf dem 1284 nicht so katastrophale Auswirkungen zu haben wie noch auf dem 644 der sich z.B. bei "Dreamload" gerne mal weggehängt hat, wenn ich dies eingeschaltet hatte.

Wie ist eigntlich die Zuordnugn zwischen ATN/CLK/DATA und den Bits von $1800 in der Floppy bzw $dd00 im CeVi? Ich Suche entweder falsch oder ich seh es nicht.

Go to the top of the page

Unseen

hat ein Parallelkabel und wird es benutzen!!1

Posts: 3,677

Date of registration: Jun 16th 2007

4

Thursday, October 21st 2010, 6:40pm

Quoted from "abraXxl"

hast du fuer das Feature CONFIG_CAPTURE_LOADERS=y auch schon ein angepasstes Perlskript an der Hand? Mann mus das Rad ja nicht zweimal erfinden.

Nein, weil ich es bisher noch nicht verwenden musste (genauergesagt: Weil die Leute die eine damit compilierte Version bekommen haben sich mit "Da wurde nichts gedumpt" zurückgemeldet haben - das Problem war jeweils an anderer Stelle)

Quoted

CONFIG_DEADLOCK_ME_HARDER=y scheint auf dem 1284 nicht so katastrophale Auswirkungen zu haben wie noch auf dem 644 der sich z.B. bei "Dreamload" gerne mal weggehängt hat, wenn ich dies eingeschaltet hatte.

Das sollte bei gleicher UART-Buffer-Grösse bei beiden Chips genauso katastrophal wirken. Falls du beim 1284 einen grösseren UART-Buffer verwendest ist natürlich klar wieso es da besser funktioniert - die Chance dass der Puffer gerade voll ist sinkt dann.

Anekdote am Rand: uIECs hatte mal am C128 ein Deadlock-Problem bei dessen Bootversuch, weil Jim mit Configs mit DEADLOCK=y und IIRC nur 64 Byte UART-Buffer-Grösse geschickt hat - der war an der Stelle voll und uart_putc wartete ewig auf freie Zeichen weil es mit gesperrten Interrupts irgendwo im IEC-Code aufgerufen wurde.

Quoted

Wie ist eigntlich die Zuordnugn zwischen ATN/CLK/DATA und den Bits von $1800 in der Floppy bzw $dd00 im CeVi? Ich Suche entweder falsch oder ich seh es nicht.

C64, 1541/1571, 1581

	Quellcode
1 2 3	10 x=rnd(-1294):fori=1to52:x=rnd(1):next 20 fori=1to5:printchr$(rnd(1)11+69);:next 30 printint(rnd(1)4711)-3590

Go to the top of the page

abraXxl

Follow the white C64!

Posts: 374

5

Thursday, October 21st 2010, 6:59pm

Quoted from "Unseen"

Zitat von »abraXxl«
hast du fuer das Feature CONFIG_CAPTURE_LOADERS=y auch schon ein angepasstes Perlskript an der Hand? Mann mus das Rad ja nicht zweimal erfinden.

Quoted from "Unseen"

Nein, weil ich es bisher noch nicht verwenden musste (genauergesagt: Weil die Leute die eine damit compilierte Version bekommen haben sich mit "Da wurde nichts gedumpt" zurückgemeldet haben - das Problem war jeweils an anderer Stelle)

Ich hatte ohne Problem auf einer 8MB Karte den AR6-FL den von Nippon und den von NosDos (Defende of The Crown) gedumped. Erst mal nur zum Test das waren halt die Games, die ich auf der SD hatte.

Quoted from "Unseen"

Zitat

CONFIG_DEADLOCK_ME_HARDER=y scheint auf dem 1284 nicht so katastrophale Auswirkungen zu haben wie noch auf dem 644 der sich z.B. bei "Dreamload" gerne mal weggehängt hat, wenn ich dies eingeschaltet hatte.

Quoted from "Unseen"

Das sollte bei gleicher UART-Buffer-Grösse bei beiden Chips genauso katastrophal wirken. Falls du beim 1284 einen grösseren UART-Buffer verwendest ist natürlich klar wieso es da besser funktioniert - die Chance dass der Puffer gerade voll ist sinkt dann.

Jo, wo du es sagt ich sehe gerade in meiner Config ist CONFIG_UART_BUF_SHIFT=7 (=> 128bytes) und bei =6 steigt er bei mir bei Dreamload aus.

Bzgl der IEC-Leitungen an der Floppy bzw. im Cevi sind einige davon ggf. Invertiert hast du auch nocch Aufstellung dazu wie sich die Pegel H/L von Floppy zu CeVi Seite verhalten? Ich meine in NLQs Jiffy disass was dazu geshen zu haben, finde es aber nicht mehr.

Go to the top of the page

Unseen

hat ein Parallelkabel und wird es benutzen!!1

Posts: 3,677

Date of registration: Jun 16th 2007

6

Thursday, October 21st 2010, 7:16pm

Quoted from "abraXxl"

Ich hatte ohne Problem auf einer 8MB Karte den AR6-FL den von Nippon und den von NosDos (Defende of The Crown) gedumped. Erst mal nur zum Test das waren halt die Games, die ich auf der SD hatte.

Klar, funktionieren tut das Feature - aber da die Speeder-Probleme der zwei Leute an anderer Stelle lagen brauchte ich bisher noch keinen Dump-Konverter.

Wenn du beim AR6 versucht hast den 1541-Speeder zu dumpen hast du übrigens nur den Transferteil erwischt, der den eigentlichen Speeder beschleunigt ins Laufwerk lädt. Der ist allerdings eh recht eklig und D64-Layout-spezifisch (das Laufwerk wird angewiesen, komplette Tracks zu übertragen - angefangen mit 18, das AR6 sucht die Datei auf C64-Seite aus dem Directory raus), der für die 1581 und auch der mit @K- (oder +?) erreichbare Alternativspeeder sah bei oberflächlicher Betrachtung leichter nachbaubar aus.

Quoted

Bzgl der IEC-Leitungen an der Floppy bzw. im Cevi sind einige davon ggf. Invertiert hast du auch nocch Aufstellung dazu wie sich die Pegel H/L von Floppy zu CeVi Seite verhalten?

Bei den Floppylaufwerken sind die Pegel sowohl in Eingangs- als auch in Ausgangsrichtung invertiert, d.h. eine 1 im Register ist Low auf dem Bus. Beim C64 ist die Ausgangsrichtung invertiert, die Eingangsrichtung nicht.

	Quellcode
1 2 3	10 x=rnd(-1294):fori=1to52:x=rnd(1):next 20 fori=1to5:printchr$(rnd(1)11+69);:next 30 printint(rnd(1)4711)-3590

Go to the top of the page

abraXxl

Follow the white C64!

Posts: 374

7

Thursday, October 21st 2010, 8:37pm

Quoted from "Unseen"

Zitat von »abraXxl«

Ich hatte ohne Problem auf einer 8MB Karte den AR6-FL den von Nippon und den von NosDos (Defende of The Crown) gedumped. Erst mal nur zum Test das waren halt die Games, die ich auf der SD hatte.

Quoted from "Unseen"

Klar, funktionieren tut das Feature - aber da die Speeder-Probleme der zwei Leute an anderer Stelle lagen brauchte ich bisher noch keinen Dump-Konverter.

Quoted from "Unseen"

Wenn du beim AR6 versucht hast den 1541-Speeder zu dumpen hast du übrigens nur den Transferteil erwischt, der den eigentlichen Speeder beschleunigt ins Laufwerk lädt. Der ist allerdings eh recht eklig und D64-Layout-spezifisch (das Laufwerk wird angewiesen, komplette Tracks zu übertragen - angefangen mit 18, das AR6 sucht die Datei auf C64-Seite aus dem Directory raus), der für die 1581 und auch der mit @K- (oder +?) erreichbare Alternativspeeder sah bei oberflächlicher Betrachtung leichter nachbaubar aus.

Ich hatte mir für Trackloader einmal was überlegt, weis aber nicht ob mein Modell passt.
Zur Übung wollte ich versuchen den Nippon-Lader (auch D64 spezifisch) zu implementieren. Dort habe ich schon aus dem C64-Code eine State-Maciine für die Floppy reverse engineered. Will aber noch schauen, ob im Floppycode noch Überraschungen stecken.

Zum Trackloader-Modell:
Auf D64-Images bzw. Track basierten Imageshat mein kein Problem, solange im C64-Code nicht irgendwo gescheckt wird ob Tracks/Sectors ausserhalb der gütigen Range liegen, dass sollte aber im Floppycode besser passieren.

Geht man davon aus dass diese Checks nicht C64 implementiert werden, muss "nur" der SD2IEC Code geschrieben werden.
Zur nativen FAT Partition: Ich gehe ich davon aus, dass die oben genannten T/S-Checks nicht auf C64_Seite sind.
Weiterhin gibt es keine T/S. Man könnte also im SD2IEC-Floppy-Code eine Fake-BAM generieren, welcher zu den Files im FAT-Dir eindeutig zu identifizieren Fake-T/S-Paare generiert. Danach ist es idR ja nur noch ein geschicktes Übertragen des gefakten T/S-Chains des Files mit dem jeweiligen Protokol.

Ich weis nicht ob und wie schnell es umsetzbar ist. Das Modell müsste AFAIK passen, doch ob ich es je schaffe genug Kenntnisse in C Ass und dem SD2IEC Code zu haben um diese Idee zu implementieren, weis ich nicht.

Go to the top of the page

Unseen

hat ein Parallelkabel und wird es benutzen!!1

Posts: 3,677

Date of registration: Jun 16th 2007

8

Thursday, October 21st 2010, 9:17pm

Quoted from "abraXxl"

Weiterhin gibt es keine T/S. Man könnte also im SD2IEC-Floppy-Code eine Fake-BAM generieren, welcher zu den Files im FAT-Dir eindeutig zu identifizieren Fake-T/S-Paare generiert.

Ja, die Idee gibts schon länger... Im Falle des AR-Loaders müssten man IIRC ein File pro Track faken, ich meine mich zu erinnern dass das Laufwerk lediglich eine Tracknummer mitgeteilt bekommt und immer alle Sektoren davon überträgt.

Implementieren würde ich das allerdings trotzdem nicht: Man kann plötzlich weder andere Partitionen noch andere Verzeichnisse ansprechen und die Regeln für den Dateinamens-Vergleich ändern sich unvorhersehbar.

	Quellcode
1 2 3	10 x=rnd(-1294):fori=1to52:x=rnd(1):next 20 fori=1to5:printchr$(rnd(1)11+69);:next 30 printint(rnd(1)4711)-3590

Go to the top of the page

abraXxl

Follow the white C64!

Posts: 374

9

Sunday, October 24th 2010, 4:26am

Hi,

ich habe mich gerade an dem FastLoader von Nippon probiert. Sektoren lesen klappt auch schon

Schreiben muss ich noch implemntieren.

Nur sind die Disk-Change-Buttons tot. Ich vermute das bestimmt irgendwelche Designprinzipien von sd2iec missachtet habe.

@Unseen: Hast du ggf. Kommentare zum Code? Und wie ich die Diskchange-Buttons wieder an bekomme?

Diff im Anhang.

Danke

abraXxl has attached the following file:

nippon.v0.diff.txt (4.05 kB - 10 times downloaded - latest: Oct 25th 2010, 11:42am)

Go to the top of the page

Unseen

hat ein Parallelkabel und wird es benutzen!!1

Posts: 3,677

Date of registration: Jun 16th 2007

10

Sunday, October 24th 2010, 12:47pm

Quoted from "abraXxl"

Nur sind die Disk-Change-Buttons tot. Ich vermute das bestimmt irgendwelche Designprinzipien von sd2iec missachtet habe.

Die funktionieren nur wenn man sie auch abfragt - die IEC-Hauptschleife macht das selbst, Fastloader sollten zu geeigneter Zeit (d.h. an Stellen an denen gewartet wird) gelegentlich check_keys() aufrufen.

Quoted

Hast du ggf. Kommentare zum Code? Und wie ich die Diskchange-Buttons wieder an bekomme?

Keine Tabs im Quellcode
Funktionen, die nur im aktuellen Quellcodefile benötigt werden als static deklarieren, dann kann gcc besser optimieren
Den vorhandenen Codestil nachbauen wäre nett...
Eine Anreihung von uart_putc für statischen Text sieht reichlich dämlich aus, wofür gibts denn sonst uart_puts_P(PSTR("Text!"))
Keine Tabs im Quellcode
Du darfst dich durchaus darauf verlassen, dass der Clock-Interrupt normalerweise aus ist
Ist das Timing des Loaders unkritisch genug, dass man die Interrupts nicht sperren muss?
Pufferallokation ohne Abfrage ob sie erfolgreich ist halte ich für schlechten Stil
Keine Tabs im Quellcode
ATN-IRQ am Ende wieder einschalten iist nicht nötig (macht die IEC-Schleife selbst), Clock-IRQ einschalten ist gefährlich (der ist nur für Dreamload)
Protokolldoku im doc-Unterverzeichnis fehlt

	Quellcode
1 2 3	10 x=rnd(-1294):fori=1to52:x=rnd(1):next 20 fori=1to5:printchr$(rnd(1)11+69);:next 30 printint(rnd(1)4711)-3590

Go to the top of the page

abraXxl

Follow the white C64!

Posts: 374

11

Monday, October 25th 2010, 2:56am

Danke für die Tipps. Ich hatte eigentlich versucht den Codestyle deines Codes beizubehalten. Ist mir offenbar nicht gelungen. Ich habe jetzt die Tabs entfernt und dem Vim via tabstop=2:shiftwidth=2:expandtab auf deinen Indent/Align-Style angepasst.

Die Disk-Change-Buttons funktionieren jetzt.
Sector Write für Savegames ist auch implementiert. Save-Games laden und speichern geht auch.

Ich hatte den ATN-Irq zunächst wieder zugelasssen, da für mich das Protokol sehr viel Syncronisierungen drin hat und daher AFAIK nicht besonders Timingkritish ist.
Ich musste den ATN IRQ jedoch wieder ausgeschaltet lassen, sonst kam die Machine nach einer Zeit aus dem tritt, was dann auf der Cevi-Seite in einer Endlosschleife bei $0bf0 endet.
Mit ATN-IRQ aus ist mir das bisher noch nicht wieder passiert, ausser ich hatte sehr viel Serielles Debug im Code.

> Keine Tabs im Quellcode

> Funktionen, die nur im aktuellen Quellcodefile benötigt werden als static deklarieren, dann kann gcc besser optimierenDen vorhandenen
[x] done
> Codestil nachbauen wäre nett...
jupp, mea culpa
> Eine Anreihung von uart_putc für statischen Text sieht reichlich dämlich aus, wofür gibts denn sonst uart_puts_P(PSTR("Text!"))
[x] done
> Du darfst dich durchaus darauf verlassen, dass der Clock-Interrupt normalerweise aus istIst das Timing des Loaders unkritisch genug, dass man die Interrupts nicht sperren muss?
Timining beim Init des Idle Loops kritisch
> Pufferallokation ohne Abfrage ob sie erfolgreich ist halte ich für schlechten Stil
Ja, kein guter Stil.
> ATN-IRQ am Ende wieder einschalten iist nicht nötig (macht die IEC-Schleife selbst)
[x] ausgebaut
> Clock-IRQ einschalten ist gefährlich (der ist nur für Dreamload)Protokolldoku im doc-Unterverzeichnis fehlt[
[x] nicht mehr verwendet

Sichte doch bitte die nächste Version.
Ich habe wieder einen Diff sowie eine kommentierte Version des Floppy-Codes hier angehängt.
Da ich gerade eine längere Runde gespielt habe, bekommt der Patch von mir das Prädikat "works for me TM".
Zusätzlich ein Patch für das Makefile (target doxygen, Kann es sein das du "." im PATH hast?)

abraXxl has attached the following files:

nippon.v2.diff.txt (4.3 kB - 4 times downloaded - latest: Oct 25th 2010, 10:47am)
sd2iec.iec-cmds.asm.txt (8.28 kB - 1 times downloaded - latest: Oct 25th 2010, 6:58am)
doxygen.diff.txt (378 Byte - 1 times downloaded - latest: Oct 25th 2010, 6:58am)

Go to the top of the page

Unseen

hat ein Parallelkabel und wird es benutzen!!1

Posts: 3,677

Date of registration: Jun 16th 2007

12

Monday, October 25th 2010, 10:49am

Quoted from "abraXxl"

Ich hatte den ATN-Irq zunächst wieder zugelasssen, da für mich das Protokol sehr viel Syncronisierungen drin hat und daher AFAIK nicht besonders Timingkritish ist.
Ich musste den ATN IRQ jedoch wieder ausgeschaltet lassen, sonst kam die Machine nach einer Zeit aus dem tritt

Das könnte daran liegen, dass bei aktivem ATN-IRQ ein ATN low mit DATA low von Laufwerksseite beantwortet wird - im allgemeinen eher nicht das was man möchte.

Quoted

>Protokolldoku im doc-Unterverzeichnis fehlt

Fehlt weiterhin?

Quoted

Sichte doch bitte die nächste Version.

Später, gerade keine Zeit.

Quoted

Zusätzlich ein Patch für das Makefile (target doxygen, Kann es sein das du "." im PATH hast?)

Es kann vor allem sein, dass ich doxygen nicht verwende.

	Quellcode
1 2 3	10 x=rnd(-1294):fori=1to52:x=rnd(1):next 20 fori=1to5:printchr$(rnd(1)11+69);:next 30 printint(rnd(1)4711)-3590

Go to the top of the page

abraXxl

Follow the white C64!

Posts: 374

13

Tuesday, October 26th 2010, 1:02am

Quoted from "Unseen"

Protokolldoku im doc-Unterverzeichnis fehlt

Im Anhang hier.

Quoted from "Unseen"

Zitat

Zusätzlich ein Patch für das Makefile (target doxygen, Kann es sein das du "." im PATH hast?)

Quoted from "Unseen"

Es kann vor allem sein, dass ich doxygen nicht verwende.

Das mag natuerlich sein.
Da ich vermute, dass das Makefile am besten unter linux, cygwin oder ähnlichen Unix-Like umgebungen benutzt wird und dort ausser unter Cygwin
der PATH idR "." nicht enthält, halte ich diesen Patch für sinnvoll.

abraXxl has attached the following file:

nippon-loader.txt (11.55 kB - 3 times downloaded - latest: Oct 26th 2010, 7:25pm)

Go to the top of the page

abraXxl

Follow the white C64!

Posts: 374

14

Tuesday, October 26th 2010, 11:14pm

Danke für die Inklusion vom Nippon-Loader

Hast du vom AR6-Loader den Stage1 und Stage2 Part als Dump? Wie identifiziert die AR6 die 1581? Auch via 0xfffe? Hast du den Loader bzw. den @K+ loader auch schon als Dump?
Koenntest du die ggf. anhängen?

cya

Go to the top of the page

Unseen

hat ein Parallelkabel und wird es benutzen!!1

Posts: 3,677

Date of registration: Jun 16th 2007

15

Tuesday, October 26th 2010, 11:30pm

Quoted from "abraXxl"

Hast du vom AR6-Loader den Stage1 und Stage2 Part als Dump?

Schlimmer, als teilweise kommentiertes Disassemblat. Ich habe damit aufgehört als es klar war, dass das Ding nur in D64-Images funktionieren kann.

Quoted

Wie identifiziert die AR6 die 1581? Auch via 0xfffe?

Ja

Quoted

Hast du den Loader bzw. den @K+ loader auch schon als Dump?

1581 auf jeden Fall (der wird in einem Zug mit M-W hochgeladen), K+ IIRC nicht.

Oh, der AR6-1581 ist sogar komplett durchkommentiert auf Platte - könnte ich eigentlich mal eben einbauen.

Unseen has attached the following file:

ar6-81.asm (4.94 kB - 6 times downloaded - latest: Oct 28th 2010, 1:55am)

	Quellcode
1 2 3	10 x=rnd(-1294):fori=1to52:x=rnd(1):next 20 fori=1to5:printchr$(rnd(1)11+69);:next 30 printint(rnd(1)4711)-3590

Go to the top of the page