Forum64

Also eigentlich wollte ich die letzten Tage mal ein bisschen am Source schnitzen.

Aber weiter gekommen als der letzten Version von Unseen beizubringen das sie sich mit 0.11 melden soll bin ich noch nicht.


Was ich eigentlich gerne machen würde ist, dem Ding mal "M-W" beizubringen.
Nur, nach zwei Tagen verstehe ich immer noch nicht, wie der Kommando-Parser überhaupt funktioniert, jedenfalls macht er nicht einmal annähernd, was ich von ihm erwarte.

Kann mir jemand sagen, wo die Kommandos verarbeitet werden?

Eigentlich dachte ich in "interface.c", genauer in Interface_handler().
Die Verzweigung auf die verschiedenen Pfade FAT/D64/T64/... ist reichlich obskur.

Aber selbst wenn ich das ignoriere und mich einfach mal in fat_cmd() einklinke und dann ein OPEN 1,8,15 sowie PRINT#1,"M-W" absetze, passiert nichts weiter, als ob der Code eben nicht angesprungen wird.

Edit:

Hmm, das gibt eine Reaktion in fat_cmd():

OPEN 1,8,15,"M-W"

Kann es sein, dass PRINT# garnicht funktioniert?

Eine richtige Beschreibung vom IEC wäre mal praktisch...

Quoted

Original von Shadowolf
Kann es sein, dass PRINT# garnicht funktioniert?

Die MMC2IEC-Software arbeitet doch intensiv mit Timeout-Loops.

Ist jetzt nur so eine Vermutung, aber könnte es sein, dass zwischen dem OPEN und dem PRINT# im MMC2IEC ein Timeout auftritt, da zwischen der Ausführung von zwei seperaten BASIC-Befehlen evtl. zuviel Zeit vergeht?

Wenn dem so ist, könnte man evtl. den Delay mal testweise ein wenig höher setzen.

CU
Kratznagel

Quoted

Originally posted by Shadowolf
Aber selbst wenn ich das ignoriere und mich einfach mal in fat_cmd() einklinke und dann ein OPEN 1,8,15 sowie PRINT#1,"M-W" absetze, passiert nichts weiter, als ob der Code eben nicht angesprungen wird.

Ja, die Kommandos werden nur geparst wenn sie beim Open-Kommando angegeben werden und nicht wenn sie danach mit PRINT# gesendet werden. Der vermutlich passende Ort um letzteres nachzurüsten wäre interface.c, Zeile 816ff - da wo ich "ugly fix for JiffyDOS" hingekritzelt habe.

Auf dem Bus sieht das (teilweise aus dem Gedächnis) so aus, unter ATN gesendete Bytes stehen in (), alle Zahlen in Hex:
- OPEN1,8,15,"foo": (28 ff) "foo\n" (3f)
- PRINT#1,"bar": (28 6f) "bar\n" (3f)
- CLOSE1: (28 ef)

Wenn ich den Kram noch richtig in Erinnerung habe akzeptiert die 1541 maximal 42 Byte lange Kommandos und führt diese erst aus nachdem ein Byte mit EOI empfangen wurde, Daten nach den ersten 42 Byte werden verworfen.

[size=1]Seltsam, beim kurzen Test sehe mal gCLggggA3f und mal gCLgggEgA3f bei OPEN... Aber das Timing ist eh noch nicht komplett geprüft.[/size]

Quoted

Eine richtige Beschreibung vom IEC wäre mal praktisch...

Use the disassembly, Luke. ;-)

Quoted

Original von Unseen

Quoted

Originally posted by Shadowolf
Aber selbst wenn ich das ignoriere und mich einfach mal in fat_cmd() einklinke und dann ein OPEN 1,8,15 sowie PRINT#1,"M-W" absetze, passiert nichts weiter, als ob der Code eben nicht angesprungen wird.

Ja, die Kommandos werden nur geparst wenn sie beim Open-Kommando angegeben werden und nicht wenn sie danach mit PRINT# gesendet werden.

Super, also doch an der falschen Stelle gestochert.
Naja, jetzt bin ich gerade in fat_cmd() und der Debugger macht mich irre.
Aus irgendeinem Grund bekomme ich keine Breakpoints in neuen Code.

Quoted

Der vermutlich passende Ort um letzteres nachzurüsten wäre interface.c, Zeile 816ff - da wo ich "ugly fix for JiffyDOS" hingekritzelt habe.

Na, einen Ansatz-Punkt habe ich ja jetzt wenigstens zum weiteren Spielen.

Quoted

Auf dem Bus sieht das (teilweise aus dem Gedächnis) so aus, unter ATN gesendete Bytes stehen in (), alle Zahlen in Hex:
- OPEN1,8,15,"foo": (28 ff) "foo\n" (3f)
- PRINT#1,"bar": (28 6f) "bar\n" (3f)
- CLOSE1: (28 ef)

Wenn ich den Kram noch richtig in Erinnerung habe akzeptiert die 1541 maximal 42 Byte lange Kommandos und führt diese erst aus nachdem ein Byte mit EOI empfangen wurde, Daten nach den ersten 42 Byte werden verworfen.

[size=1]Seltsam, beim kurzen Test sehe mal gCLggggA3f und mal gCLgggEgA3f bei OPEN... Aber das Timing ist eh noch nicht komplett geprüft.[/size]

Quoted

Eine richtige Beschreibung vom IEC wäre mal praktisch...

Use the disassembly, Luke. ;-)

Na, da wird ja noch richtig Freude aufkommen...

Quoted

Ist jetzt nur so eine Vermutung, aber könnte es sein, dass zwischen dem OPEN und dem PRINT# im MMC2IEC ein Timeout auftritt, da zwischen der Ausführung von zwei seperaten BASIC-Befehlen evtl. zuviel Zeit vergeht?

Zuerst habe ich das mit einem kleinen BASIC Programm versucht,
erzeugt quasi auch keine Reaktion...

Also mit Assembler wollte ich eigentlich nicht mehr anfangen.
Die Jahre als C64-Coder haben mir eigentlich gereicht soweit.

Aber die Idee was gemeinsames zu machen klingt erstmal sehr vernünftig.

Ich komme allerdings nicht mal dazu alleine was zu machen...

mhh...wollt mal fragen ob hier ein sticky "MMC2IECSoftware Thread (Kein Laberthread!)" angelegt werden kann, wo die letzten softwareupdates (eventuell letzten bootloaderversionen) und alle zusatzsoftware, tools für die MMC2IEC zum download bereitsteht. Langsam seh ich hier nicht mehr durch..

ahh...ich seh grad den sammelthread mmc2iec. Das könnte ja dann als "sticky" markiert und gepflegt werden.

Hallo Leute, Software zusammen entwickeln ist das Stichwort.


Ich bin ja auch dran Jiffidos in C-Code zu packen.
Das hatte einer meiner Leute bereits angefangen und den Ass-Code den ich vom NLQ habe in C gepackt.
Leider ist das nicht fertig geworden, und ich habe leider nicht genug C errfahrung um es schnell fertig zustellen.

Ich werder in den nächsten tagen alle Quellcodes, die ich habe in BerliOS einstellen. http://www.berlios.de/

Wer möchte kann sich dazu gesellen.

Mein Traum ist die CMD HD so gut wie es geht zu ersetzen.

Primäres Ziel ist OPEN IEC Routinen in C für Jedermann um alle möglichen Dinge an den IEC Bus zu hängen.

z.B. diskettenwechler, Blumengießer, neue Druckerinterface mit Jiffi und und und.

Freue mich schon darauf...

Supi!

CU
Kratznagel

Ich hoffe der eine oder andere hatte es noch nicht ;-)
(Nicht das ich hier schon wieder Eulen nach Athen trage..)

Hier eine Doku zu den JiffyDOS Routinen... Word 7..
Habe zwar auch eine PDF Version, das ZIP ist aber zu groß um es hier hochzuladen..

Evtl. ja brauchbar um die Firmware des mmc2iec weiter zu bringen..

Peter

Noch eine blöde Frage..

Könnte es was bringen, die mmc2iec mal mit einem anderen C64 Kernal zu betreiben..? Einer der an einer unveränderten 1541 auch eine schnellere Ladezeit bringt..? Oder ist das so Quatsch..?

An C64 Kernal Roms habe ich:
speeddos
exos v3
superdos
cockroach
(einer der sich mit Armageddon or Peace meldet?)

Roms gibts unter anderem auch hier:
http://members.optusnet.com.au/vortex69/…MPUTER/ROM.html

Peter

Quoted

Originally posted by PeterSieg
Könnte es was bringen, die mmc2iec mal mit einem anderen C64 Kernal zu betreiben..? Einer der an einer unveränderten 1541 auch eine schnellere Ladezeit bringt..? Oder ist das so Quatsch..?

Nein, die laden einfach nur Schnellladercode in die 1541, der vom MMC2IEC mangels 6502 nicht ausgeführt werden kann.

Quoted

speeddos

Läuft, aber die Directoryausgabe mit F7(?) sieht etwas kaputt aus weil SpeedDos die Formatierung ändern will und das MMC2IEC ein etwas anderes Directory schickt als erwartet.

Quoted

exos v3

Hängt

Quoted

superdos
cockroach

Kenne ich beide nicht.

Mir ist da eben was aufgefallen :

Wenn ich während eines Ladevorgangs run/stop drücke bleibt die grüne LED an und ich muss den C64 aus- und wieder einschalten, damit er wieder was lädt (ansonsten kommt nur "device not found".

Der Fehler tritt aber nur beim Laden von "$", "<" ,"<<" oder Verzeichnissen bzw. M2i oder D64/T64 auf.
Lade ich ein PRG und breche ab, kommt es nicht dazu.

Wäre nett, wenn man das demnächst beheben könnte !

Das kommt dann , wenn das Laufwerk nicht mit einem irq in dem Moment klar kommt.

IEC Laufwerke müssen mehrere Sachen glaichzeitig machen.
Z.B. wenn beim übertragen von Daten via GET nach jedem Byte ein irq kommt und der c64 irgend was Anderes machen darf und danach weiter in diesem kanal lesen....

Hat schonmal jemand über GEOS-Unterstützung seitens des MMC2IEC nachgedacht? Da gibt's wohl zwei Probleme - zum einen den Fastloader, zum anderen den sektorweisen Zugriff auf die Diskette. Wie wäre es zum Beispiel, Unterstützung für Block-Read und Block-Write in die Firmware einzubauen? Dann müsste man "nur" noch einen MMC2IEC-Treiber für GEOS (ohne Fastloader, nur B-R/B-W) schreiben, wenn ich richtig liege. Oder gäb's noch andere Möglichkeiten?