Posts by 1570

Kommt auf den Emulator an. VICE kann wohl Paddles nicht richtig bzw. hat da einen Hack drin, der die PC-Mouse gegenüber dem C64 als "Paddles" erscheinen lässt: https://sourceforge.net/p/vice-emu/feature-requests/264/

Das Problem an der Stelle ist aber nicht die Machbarkeit, sondern dass keiner konkrete Hardware am Laufen hat und gpz gegenüber konkret formulieren kann, was er will/braucht.

Vielleicht sollte sich jemand(tm) den Hexagon-USB-Adapter schnappen, da noch Paddle-Support ranbasteln und VICE einen Patch schicken. Ist vermutlich Sache eines Wochenendes...

Quote from -trb-

Es würden sich dann halt vermutlich noch weitere Probleme ergeben als einfach nur Werte auslesen und die weiterreichen.

Ist bis auf die Bauform des Verbinders exakt das gleiche Problem wie die alten analogen PC-Joysticks für den "Gameport" via USB anzuschließen, und dafür gibt's auch kommerzielle Adapter um die 20€. Tatsächlich wäre das in dem Fall hier evtl. auch eine Lösung: Einfach so einen Adapter nehmen und statt des Gameports dort 9-Polige anlöten bzw. sich einen Adapter 9pol=>Gameport basteln.

Quote from -trb-

Am C64 werden die analoge Eingabegeräte übrigens vom SID ausgewertet. Ganz kurz gefasst sollte damit klar sein, dass sich das nicht mal eben so implementieren lässt.

Klar könnte ein Microcontroller prinzipiell Paddles/Potentiometer über seine A/D-Wandler auslesen und den Wert über USB/HID dem PC als Input weiterreichen. Macht dieser Adapter nur nicht.

Quote from OliverW.

Deswegen hat der nanoSwinSID auch keine Paddles Unterstützung.

Wenn ich mich recht entsinne, kann der SwinSID nicht auf den C64-Bus schreiben, weil sein ATmega das vom Timing her nicht hinbekommt (bzw. die SwinSID-Firmware bekommt's jedenfalls nicht hin). Andere Hardware (z.B. das Kung Fu Flash oder das Sidekick64) hat das Thema durchaus abgehandelt, und die ganzen CPLD-basierten Designs von Zeugs, die am C64-Bus hängen, sowieso. Ist aber eine ganz andere Baustelle.

Quote from Nico

Ist ja die Frage ob der Kernal einmal vom EF auf den Cevi geladen wird oder ob es permanenten Zugriff auf EF benötigt. Weiß das jemand?

Die Frage beantwortet sich eigentlich selbst: Der Kernal ist 8KBytes groß, der C64 hat 64KBytes RAM, und diverse Programme benutzen das RAM bis aufs letzte Byte. Wo sollte der C64 denn den Kernal "eben so" mal zwischenspeichern, selbst WENN man das RAM dann irgendwie schaltungstechnisch als Kernal-ROM erscheinen lassen könnte?

...und letztes ist eben nicht so eben möglich, siehe https://www.c64-wiki.de/wiki/PLA_(C64-Chip) und wie schon geschrieben die EF3-Doku. Das ist mittleres Hexenwerk.

Quote from Snoopy

Leerzeichen sind bei Zahlen immer Trennzeichen (wenn auch offensichtlich in vielen BASIC-Varianten nicht so deklariert).

Pffff! BASIC V2 war seiner Zeit massiv voraus und hatte offensichtlich schon Digit Separators. Da wo C und Java und Go sich nicht zum Leerzeichen getraut haben, hat Commodore einfach Mut bewiesen!

Quote from HeisseLuft

Daher habe ich mich gefragt, wenn schon so ein enormer Geschwindigkeitswachs , nur durch die Verwendung alternativer Datentypen möglich ist (ohne Cmpileranweisungen wie „fastfor“ etc. ) , warum finde ich keine BASIC Erweiterungen die dies anbieten?

Der Geschwindigkeitzuwachs von Basic Boss kommt ja eben nicht nur durch weitere Datentypen.

Echte Integer etc. sind nur ein Teil, der die höhere Geschwindigkeit ausmacht.

Insbesondere erzeugt Basic Boss Maschinencode aus dem BASIC-Programm.

Den originalen BASIC V2-Interpreter musst Du Dir vorstellen, als würde da jemand sitzen und ein chinesisches Kochrezept Stück für Stück mit einem Wörterbuch übersetzen und dann die Schritte des Rezepts ausführen.

Basic Boss währenddessen nimmt das chinesische Kochrezept, übersetzt das komplett nach Deutsch und gibt's Dir dann. Du kannst das Rezept dann natürlich "einfach so" lesen und "ausführen". Das ist toll schnell und einfach, aber man darf nicht vergessen, dass vorher ein Übersetzer viel Zeit und ggf. auch Fachwissen in die Übersetzung investiert hat.

Vor- und Nachteile eines Compilers:

• Die separate Übersetzung ist ein Schritt, der (vorgelagert) Zeit braucht (= der Compiler braucht Zeit fürs Compilieren. Einfach nach Editieren RUN und sofort geht's los ist nicht).
• Das Ergebnis der Übersetzung braucht Platz. (= das Compilat muss irgendwo gespeichert werden bzw. würde ansonsten Platz im knappen RAM verbrauchen, zusätzlich zum Original-Programm)
• Findet man in der Übersetzung eine Ungereimtheit, ist es nicht so einfach, im Original die entsprechende Stelle zu finden. (=> für gute Fehlermeldungen wie z.B. "Division durch Null in BASIC-Zeile X" zur Laufzeit muss für den erzeugten Code Debug-Info mitgespeichert werden => Platzverbrauch)
• Ein Unterbrechen des Kochens und Anschauen des Sprachzustands ist nicht wirklich möglich. (okay, da klappt's mit dem Gleichnis nicht so gut ;). Beim BASIC-Interpreter kann man mit RUN/STOP das Programm unterbrechen, sich die aktuellen Variablen anschauen und sogar ändern und dann per CONT das Programm weiterlaufen lassen. Das geht mit einem Compilat nicht so ohne Weiteres, u.a. weil Variablen eventuell nur noch in Registern und nicht mehr Speicherstellen gespeichert werden und so weiter)
• Es gibt keine Möglichkeit, das Originalrezept Schritt für Schritt auszuführen. (= hat man nur einen Compiler, gibt es keinen Direktmodus. Der BASIC-Direktmodus ist aber eine tolle Sache zur Bedienung des Rechners und zum Lernen der Sprache. Ohne Direktmodus kein LOAD"*",8,1!)
• Es ist wahrscheinlicher, dass jemand mit Wörterbuch und dem Originalrezept was Essbares produziert, als dass das Zweiergespann "Übersetzer" und "Koch (mit übersetztem Rezept)" was Essbares produziert, bzw. in letzterem Fall müssen beide wirklich wissen, was sie tun, damit insbesondere nicht ein schlechtes/unklares übersetztes Rezept rauskommt (= ein Interpreter ist relativ einfach, ein guter Compiler währenddessen ist eine sehr komplexe Geschichte).
• Dafür ist ein gutes übersetztes Rezept einfach viel schneller zu lesen (ein gutes Compilat läuft viel schneller als lediglich interpretierter Code).

Morgen dann das Ganze als Autovergleich.

Quote from Mike

LOAD"$",8,1 lädt auch beim VC-20 nicht an die 'richtige' Stelle

Das war im C64-Wiki fehlerhaft, das sollte "PET" heißen, nicht VC-20. Ist bereits korrigiert.

Siehe auch das 1541-ROM:

http://unusedino.de/ec64/technical/aay/c1541/ro41ec9e.htm

Schon ulkig, dass das Directory einfach laufwerksseitig als BASIC-"Programm" verpackt wurde. Ein Hoch auf Hacks!

Mit der Argumentation lassen sich die Ports aber schon nicht als Eingang nutzen, denn schließlich stören Joystick-Bewegungen dann die Tastaturabfrage.

Klar muss man beim Keyscan die Ports wieder zurücksetzen (oder eine eigene Routine schreiben, die das macht, und/oder nur Tasten benutzen, die so in der Tastaturmatrix liegen, dass sie von den benutzten Joyport-Leitungen unabhängig sind).

Ja, man kann die Leitungen auch als Ausgang benutzen (Open Collector). Z.B. der Tiny Eprommer aus der 64'er macht das.

Nö. Das JiffyDOS-Protokoll holt lange nicht alles aus der Seriellen raus, siehe sd2iec-Eintrag im C64-Wiki. Jiffy schafft mit sd2iec ca. 20-25fach, ein AR-ähnliches Protokoll schafft fast 40fach. Du kannst auch mal in den Quelltext von SJLOAD schauen, der Transfer-Loop ist da voller NOPs ;).

Das AR (teil)dekodiert GCR zwischen den Bytes, ohne Zusatz-ROM. Wenn es dann zwischen den Sektoren noch nichtmal zum Daten übertragen absetzen müsste, bräuchte es auch nicht die Sektor-Header vorgelagert scannen und könnte so den ganzen Track in einer Umdrehung auslesen, wo alle anderen Speeder zwei oder drei Umdrehungen brauchen. (also zumindestens stelle ich mir das naiv so vor )

Quote from Diddl

Du arbeitest wochenlang an der Sache, hunderte Stunden, und dann sind die bereits existierenden immer noch schneller oder zumindest gleich.

Och im Emulator ist das doch fix zusammengeschustert, zumal man "nur" die Ideen bestehender Speeder zusammenbringen muss.

Aber es ging mir auch gar nicht darum, das zu haben oder zu bauen, sondern aus Interesse.

Anscheinend gibt's gar keine Schnelllader, die das RAMBOard benutzen? Finde ich seltsam, denn es bietet sich dafür schließlich an.

MeGALoDOS ist cool, aber schon recht weit von der Fragestellung "Wie weit kommt man durch den Einsatz eines neuen RAM-Bausteins in die Floppy?" weg.

Necrofadenzeit!

*Eigentlich* *könnte* man ja nur mit einer RAM-Erweiterung einen schicken Schnelllader basteln. Z.B. den Action Replay-Code nehmen und so umbauen, dass er einen ganzen Track in einem Rutsch einliest und dekodiert. Damit dürfte man in Bereiche von 25-30facher Geschwindigkeit kommen, schätze ich mal (ohne das jetzt nachgerechnet zu haben), also 12-16kBytes/Sekunde - was sonst nur Parallelspeeder schaffen. Hat sich daran schon jemand versucht oder gibt's sowas gar schon? Der Charme an der Lösung wäre, dass der Umbau relativ einfach ist und das eher hässliche Parallelkabel entfällt.

Quote from adtbm

Ist es bekannt, warum die LarsP Varianten unter Umständen "wackelig" sind ?

Soweit ich mich erinnere, wurden die mit der Umstellung auf den ATmega1284P nötig.

Die ATmega1284P (deren größeres Flash für die neueren Firmwares nötig ist) haben leicht andere Specs als die alten ATmega32 für ihre Ausgänge, die auch in der Praxis für Probleme sorgten (k.A., wann genau, vermutlich mit mehreren Laufwerken oder langen Leitungen).

Shadowolf hat deswegen damals die drei/vier zusätzlichen IRLML 2402-Mosfets eingefügt, mit denen das dann auch mit 1284P innerhalb der IEC-Specs läuft. Lässt sich vermutlich auch hier im Forum noch irgendwo nachlesen.

Und weil die drei Mosfets zusammen 54 Cents und eine Minute Lötarbeit kosten und "das ja auch so funktioniert", werden sie häufig weggelassen. Und ein Jahr später sucht man dann den Fehler.

Zuverlässig? Eins mit dem echten SD2IEC v1.2-Aufbau (mit drei/vier Transistoren als IEC-Treiber), also insbesondere NICHT die "LarsP"-Varianten, die am IEC-Bus u.U. etwas wackelig sind.

Und natürlich eins mit ATmega1284P und Quarz nehmen, sonst funktionieren ggf. Schnelllader nicht richtig und/oder man bekommt keine neuere Firmware drauf.

Am "Markt" gibt's ziemlich Wildwuchs, insofern am besten beim Verkäufer nachfragen, um was es sich bei der Hardware jeweils genau handelt.

Für https://www.c64-wiki.com/wiki/Comparison_of_fast_loaders haben wir damals den 64'er Speed Test genommen, den gibt's wohl auch in einer überholten Version hier: https://e4aws.silverdr.com/projects/speed_test/

Quote from NoobTracker

unterstützt ein SD2IEC keinen Fastloader, also muss man auf eigens gebastelte IRQ-Loader oder so verzichten. Das Problem nur ist, dass meines Wissens nach das Lesen und Speichern über die Kernalroutinen ein blockierender Prozess ist

sd2iec unterstützt sehr wohl Fastloader, insbesondere auch DreamLoad, das eben ein IRQ-Loader ist und speziell für Laden im Hintergrund designt wurde, also nimm doch einfach das. Spannend, dass das bisher im Thread noch niemand erwähnt hat...

Zu SJLOAD - das ist nur die C64-Seite und benötigt eine Floppy mit JiffyDOS bzw. sd2iec oder ähnliches.

Quote from GeTE

Das hat immrer diesen selbstgefrickelten "Charme" wie früher mit der Laubsäge aus Sperrholz schief gesägten Kästen.

Du hast aber dann vermutlich noch keine SLA-Drucker gesehen. Siehe z.B. https://www.techstage.de/ratge…-ab-200-Euro-4549009.html

Quote from GeTE

Aber die Welt hat sich gedreht, vielleicht wird es die hierzulande niemals mehr geben

Sowas bekommt man aber sonst auch DIY mit einem SLA-Drucker und sowas wie 3D Printing Resin Purple hin (falls die Farbe nicht ganz passt, einfach selbst mit transparentem Harz plus Pigmenten mischen).

Ah okay. Eine Option wäre ja auch noch, die Sektoren zu lesen, wie sie kommen, und das Umsortieren sofern nötig nachgelagert auf C64-Seite machen zu lassen. Ich hatte es so verstanden, dass z.B. Mafiosinos Trackloader (liest Spur in zwei Umdrehungen) es so macht, kann mich aber irren. Ist ja auch die Frage, wie viel Leistung ggf. nachfolgendes Umsortieren dann frisst.

Und wieso ist das AR6 dann soviel schneller als das FC3?

Hi! Ich wollte im C64-Wiki was zur internen Funktionsweise der Fastloader des FC3 und des AR6 schreiben - eher auf High Level.

Was ich bisher dazu finden konnte...

Zum FC3 Doku aus sd2iec, da frage ich mich, woher der Block Counter kommt bzw. wie der Code im Laufwerk den generiert, da es ja dafür die Abfolge der Blöcke/Sektoren auf der Diskette a priori kennen müsste, sich das aber erst beim Einlesen ergibt. Macht der Code zufälligerweise erstmal einen "Scan"-Durchlauf pro Spur, um die Verkettungsbytes zu lesen? Würde erklären, wieso das FC3 langsamer als das AR6 ist, da das eine Umdrehung kosten würde.

Zum AR6 gibt's auch Doku aus sd2iec - das scheint ein reiner Trackloader zu sein, der vermutlich ähnlich dem von Mafiosino auf Laufwerksseite die Sektoren so liest, wie sie eben reinkommen, und dem C64 das korrekte Zusammenpuzzeln überlässt. Anscheinend passiert das so sogar beim Einlesen des Directories und beim Öffnen einer Datei? GCR-Dekodierung passiert aber noch im Laufwerk?

Stimmt das so? Hat jemand zufälligerweise noch weiterführende Links oder eigene Erkenntnisse?