SD2IEC mit superschnellen burst routinen

Nur zur Klarstellung: Im Augenblick kann das nur die dort gepostete 0.8.2-Version, in den offiziellen Quellen ist es noch nicht drin bis einige Details geklärt und Probleme beseitigt sind (mindestens ich würde mich sehr dararan stören, wenn sd2iec nicht funktioniert so lange eine Datasette am C64 angeschlossen ist)

Zitat

... ich würde mich sehr dararan stören, wenn sd2iec nicht funktioniert so lange eine Datasette am C64 angeschlossen ist)

Was ist denn der technische Grund, warum eine angeschlossene Datasette ein Burst-Laufwerk stört? Ich habe an meinem C64(alt) eine (Original-CBM-) Datasette und eine 1571 und 1581 gleichzeitig angeschlossen und das geht. Warum gibt es mit dem einem Burst-Laufwerk Probleme und mit dem anderen nicht?

Cassette-Read liegt beim C64 auf demselben Port wie SRQ (Leitung des serielen Ports, die nur im Burst-Mode genutzt wird)

Normalerweise stört das nicht, weil die Datasette die Leitung nicht beeinflußt, solange sie kein Band abspielt.

Einige Datasetten-Typen scheinen das aber nicht zu wissen.

Und manche Laufwerke (man sagt es der 1581 nach, aber nicht der 1571?) vertüsddeln sich anscheinend mit der Burst-erkennun, wenn die Leitung beim 64er aktiv ist- der ja normalerweise keinen Burst-Modus kennt..

Zitat von mc71

Normalerweise stört das nicht, weil die Datasette die Leitung nicht beeinflußt, solange sie kein Band abspielt.

Einige Datasetten-Typen scheinen das aber nicht zu wissen.

Manche Orginal-Commodore-Datasetten ziehen die Leitung im "Ausgangszustand" ohne Band auf Low, das ist genau die Situation an der sich schon die 1581 störte. Da die 1571 damit aber keine Probleme hat sollte sd2iec aber IMHO keine Implementierung mit einem solchen Mangel bekommen. Mal ganz zu schweigen von den diversen Platinen, bei denen der SRQ-Pin am AVR einfach offen ist und wegen abgeschaltetem Pullup (sonst braucht die Umschaltung zwei Befehle) beliebigen Mist einfangen kann.

Zitat von Unseen

Mal ganz zu schweigen von den diversen Platinen, bei denen der SRQ-Pin am AVR einfach offen ist und wegen abgeschaltetem Pullup (sonst braucht die Umschaltung zwei Befehle) beliebigen Mist einfangen kann.

Wie ist denn bei der PeterSieg Platine der SRQ-Pin beschaltet?

Zitat von sebbi

Wie ist denn bei der PeterSieg Platine der SRQ-Pin beschaltet?

Das ist eine der Platinen, bei denen der Pin (PC3, Pin 25 des AVR) einfach offen ist.

Dachte ich mir fast. Dann verzichte ich lieber darauf, die gepatchte Firmware zu flashen und benutze mein FC3 zum Speeden oder warte, bis von Dir eine funktionierene aktuelle Version released wird.
Danke!

Wer sich diese Version flasht, wird eh ein SRQ-Kabel anlöten und höchst selten eine Datasette anschließen

Eine stabile Version könnte auf den 'read boot sector' Befehl des 128ers warten und dann erst die Burst-Erkennung freigeben? Nur mal so als quick and dirty hack in den Raum gestellt.

Ich habe eine version in Arbeit die die "Fast serial"-Erkennung so macht wie es vorgesehen war.

Wenn ATN Down dann schauen, ob 8bit via SRQ/DATA rein geshiftet werden, vom Master also C128.
Und erst dann selbst 8 Bits via SRQ zum Master shiftet und dann nicht stumpf wie bisher auf SRQ low wartet.

Ist aber nocht nicht gänzlich funktional.

EDIT: und insbesondere wird der Patch ja erst aufgenommen, wenn der Original-Author hydrophilic mit Unseen Kontakt aufnimmt.

Zitat von mc71

Wer sich diese Version flasht, wird eh ein SRQ-Kabel anlöten und höchst selten eine Datasette anschließen

Ich fände es schon irgendwie unpraktisch, wenn ich selbst an sd2iec nicht mehr weiterentwickeln könnte weil es bei mir nicht mehr läuft.

Zitat

Eine stabile Version könnte auf den 'read boot sector' Befehl des 128ers warten und dann erst die Burst-Erkennung freigeben? Nur mal so als quick and dirty hack in den Raum gestellt.

Funktioniert nur am C128 und nicht mit modifizierten C64 mit Burst (z.B. FSD-System-Kernal), funktioniert nur für Device 8, funktioniert nicht wenn man mit GO64 in den C64-Modus des C128 wechselt (Tape-Read und SRQ werden da von der Hardware modusabhängig getrennt bzw. verbunden).

Zitat von abraXxl

EDIT: und insbesondere wird der Patch ja erst aufgenommen, wenn der Original-Author hydrophilic mit Unseen Kontakt aufnimmt.

Und bevor mir da jemand etwas schlimmes unterstellt: Ich überlege schon seit längerem die Lizenz von "nur GPLv2" auf GPLv3, evtl. "GPLv3 oder später" umzustellen - das geht allerdings nur wenn jeder der mal Code beigetragen hat dem zustimmt. Wenn ich jetzt ein Codestück von jemandem reinhole den ich nicht kontaktieren kann müsste die Lizenz entweder bei der alten bleiben oder das Tolle Neue Feature[tm] sofort wieder rausfliegen.

Also soweit ich das aus dem commodore128.org-Forum beurteilen kann hat Hydrophilic den "Hack" für die Burstroutinen erstmal nur als Proof of Concept für seinen Media Player 128 entwickelt. Ich glaube allen C128-Usern wäre am besten gedient, wenn das sauber in die SD2IEC-Firmware integriert werden kann, ggf. also der Burst-Mode hierfür auch nochmal "neu" entwickelt wird. Gäbe es das commodorebounty-Projekt noch hätte ich jetzt schon gespendet. Nach der GEOS-Kompatiblität des SD2IEC wäre es mit dem Burst-Modus endlich ein "vollwertiges" Laufwerk für den C128, auch der CP/M-Modus würde davon stark profitieren. Eigentlich müsste jbrain, der auch das uIEC verkauft doch starkes Interesse daran haben (ich glaube von ihm kam ja auch die dickste Spende für die GEOS-Kompatibilität).

Es ist zweifelsohne mehr als beachtlich was das SD2IEC schon alles leistet, aber als C128-User hätte man sich damals auch nicht mit einer 1541 zufrieden gegeben

Es ist normalerweise nur für den C128 Intressant. Am C64 müßte man anpassungen Vornehmen, Das Rom ändern und 2 Kabels Einlöten. Eine Anleitung steht im Buch 1571 Intern von Data Becker.

Zitat

Nur Interesse halber: darf ich fragen was die Absicht dahinter ist? Was hat eine Umstellung für Konsequenz, was für Vorteile (wegen Nachteile würde es ja niemand machen)?

Die Absicht dahinter ist es, die Änderungen in der GPLv3 auszunutzen. Die Tivoisierungs-Klausel wird z.B. für sd2iec wahrscheinlich nie relevant werden, aber falls du jemals die GPLv2 gelesen hast solltest du wissen, dass es eigentlich nicht reicht wenn man den Quellcode einer veränderten Version im Internet zum Download anbietet - in der GPLv3 ist das anders.

BUMP.

Ist das noch in Entwicklung? Gibt es Fortschritte? Wo darf ich Bestechungsgelder/Spenden hinsenden?
So klein kann die "Nachfrage" doch nicht sein, oder?

Zitat von tokra

Ist das noch in Entwicklung?

Ich habe hier einen als "v5" gekennzeichneten angepassten Patch von abraxxl rumliegen und hatte bisher den Eindruck als ob da noch eine Version folgen sollte - bei nochmaliger Lektüre der PMs bin ich mir da aber nicht mehr so sicher ob das nicht schon die "finale" Version war. Falls ich mal Zeit finde versuche ich den einzubauen und ggfs. auftauchende Probleme zu fixen.

Zitat

So klein kann die "Nachfrage" doch nicht sein, oder?

Anscheinend schon?

Das ist noch in Entwicklung. Es gibt eine v6, die ich noch nicht ganz durch getestetet habe und es solle eine v7 folgen, die die AVR-Assemblerroutinen in C abbildet für die lpc17xx-Plattform von Unseen.

Problem ist das es ohne Änderungen nur auf dem uIEC von Jim Brain wirklich funktioniert. Die neuen Routinen und Ergänzungen zur IEC-Statemachien den bisherigen Betrieb zum Beispiel auf PeterSieg/Larsp Platinen udn die Kompatibilität nicht einschränken sollen. Larsp/PeterSieg-Layout hat kein angeschlossenes SRQ bzw. es muss manuell nachgerüstet werden.

Da ich beruflich/lebenstechnisch gerade etwas eingespannt, bin liegt das Projekt gerade etwas auf Eis. Als Kompromis versuche ich die v6 zeitnah fertig zu machen und zu Posten, sodass zumindest der AVR Teil aslo die Hauptplattform schon funktioniert.

Also für C128-Nutzer hätte das schon einen echten Mehrwert, denke ich. Gerade CP/M ist ohne Burst-Mode unbenutzbar und andere Speeder gibt's da gar nicht. Die Frage ist wohl, wieviele echte C128-User es gibt. Seinerzeit wurden zwar 4 Mio C128 verkauft (gegenüber 20 Mio C64), aber davon sind wohl doch einige im 64er-Mode versauert...