Hallo Besucher, der Thread wurde 5,8k mal aufgerufen und enthält 27 Antworten

letzter Beitrag von Stephan Scheuer am

Test Drive für die SCPU

    Etwas mehr Info wäre toll...


    hab das 7z entpackt und das D81 auf ein SD2IEC kopiert... wenn ich das D81 öffne wird mir da ein weiteres D81 angezeigt?


    Wenn ich dann das erste File lade+starte sehen ich zwar den F1/F3-Screen, aber erst nach der Leertaste tut sich was. Mit dem SD2IEC ist das aber nicht kompatibel (unknown drivecode). Von der RAMLink wollte das auch nicht...


    Habs dann auf eine FD kopiert und auf #8 geswitched... läuft :thumbsup:


    :thnks:

    Ups. ich dache, es wäre soweit alles klar weil ich es in den thread CMD-Hardware gepostet habe.
    Und ja, es läuft nur mit einer 1581. ich habe einen schnelllader eingesetzt, der auch heute fertig an die scpu angepasst wurde.
    der lader benutzt eine 24bit adressierung und zudem nutzt dieser auch 20mhz.
    wenn eine version für ander laufwerke gewünscht wird, werde ich das machen.


    Achja, wenn ich eine floppy-erkennungsroutine im netz finde, code ich ein schnelllader, der auf allen bekannten laufwerken funktioniert.
    wenn ich nichts im netz finde, muss ich die drive-erkennungsroutine auch selber coden. :)
    ich war richtg erstaunt, wie schnell der 1581-fastloader ist.



    stephan

    In "Games for other Drive" hast Du schon eine Test Drive Version, welche von anderen Laufwerken (HD-Native und SD2IEC) läuft.


    Nur muss halt bei dieser Version die SCPU auf 1 MHZ geschaltet (Test Drive) bzw. ausgeschaltet werden (Test Drive 2).


    Es sind halt keine SCPU-Versionen.


    Und ja bin der Meinung, sollten auf allen CMD Laufwerken (inkl. Native-Partitionen) funktionieren.
    Als Schnellader gibt es JiffyDOS (CMD). 8o


    Ne, im Ernst; danke für die Version und die Information auf welchen Laufwerken es läuft.


    Gruss C=Mac.

    Naja... das es für die SuperCPU war, also das war mich auch klar. Nur das man auch ein reales Laufwerk benötigt war mir nicht klar, vor allem weil ja der F1/F3-Screen erscheint.


    Um das SD2IEC beim Fastloader auszuschließen... Den Befehl "M-R",$00,$03,$03 an das Laufwerk senden. Wenn da "00," (von "00, OK, 00, 00") zurückkommt ist die Wahrscheinlichkeit extrem hoch das es ein SD2IEC ist. Reale Laufwerke liefern da Speicherwerte zurück. $0300 ist RAM-Speicher, da müsste man schon vorher Code platzieren damit der Test ins leere läuft.
    Ich hab für GEOS die Hardwareerkennung mit dem Test überarbeitet, verschiedene User haben da schon bestätigt das es funktioniert (Danke an markusC64 an dieser Stelle).

    ok, jiffidos ist recht schnell und sehr kompatibel.
    ich habe "means streets scpu" auch fast fertig. es waren 211 dateien,insgesamt 2388 blocks.
    nach dem exomizer waren es nur noch 1524 block und eine datei. das zu laden dauer mit jiffidos bedeutend länger als mit dem 1581-fastloader.



    @ darvision


    die boot datei wird ganz normal geladen. das 304-block große file wird mit dem schnelllader geladen und decruncht.
    das ist nicht nur ein schnelllader sondern ein exomizer leveldecruncher, der die daten gleich in die ram-card ab $030000 lädt.



    stephan

    Zitat von darkvision

    Ich hab für GEOS die Hardwareerkennung mit dem Test überarbeitet, verschiedene User haben da schon bestätigt das es funktioniert

    Funktioniert wirklich gut, auch das Wechseln zwischen den LfW/Image ist problemlos möglich. :thumbup:
    Aber ist anderes Thema.



    Zitat von Stephan Scheuer

    ok, jiffidos ist recht schnell und sehr kompatibel.

    Ja ist schnell, aber nicht der Schnellste; z.B. TurboDOS ist schneller. ;(
    Auch sehr kompatible ist JD, wobei hier es auch Ausnahmen gibt. Zum Beispiel zerstört - ein aktives Laufwerk JD - Soul Crystal Disketten. ;(


    Von daher bin ich der Meinung: Gib dem User die Wahl.
    Schnellader Ja/Nein.


    Ja ich weiss, es ist wieder ein zusätzlicher Programmieraufwand, welcher ich als Ahnungsloser nicht mal abschätzen kann. ||



    Zitat von darkvision

    Stellt sich halt die Frage ob man lieber kompatibel sein will und das laden auf mehr Geräten funktioniert oder eine 1581/FD voraussetzt damit es 10sek. schneller geht.

    Wenn's klar kommuniziert wird, für was es ist; spielt es eigentlich keine Rolle.


    Gruss C=Mac.

    Zitat von Stephan Scheuer

    einfach mal zum testen, ob die ladezeit noch ok ist. das spiel sollte mit allen laufwerken funktionieren.

    SD2IEC(DriveCode Error) + RAMLink funktionieren nicht... FD geht aber. Ladezeit... wow... bei 1500Blocks verstehe ich den Wunsch nach einem Fastloader... aber bei der Ladezeit wäre mit ein Fortschrittsbalken lieber. Hab jetzt nicht gestoppt, aber gefühlt 60sek oder mehr...


    Zu mehr fehlt mir aber gerade die Zeit, hab das Spiel angespielt, kenne es aber nicht. Das war bei TestDrive anders.

    Zitat von darkvision

    SD2IEC(DriveCode Error) + RAMLink funktionieren nicht... FD geht aber. Ladezeit... wow... bei 1500Blocks verstehe ich den Wunsch nach einem Fastloader... aber bei der Ladezeit wäre mit ein Fortschrittsbalken lieber. Hab jetzt nicht gestoppt, aber gefühlt 60sek oder mehr...
    Zu mehr fehlt mir aber gerade die Zeit, hab das Spiel angespielt, kenne es aber nicht. Das war bei TestDrive anders.

    komisch, dass es mit der ramlink nicht funktioniert. es handelt sich um eine exomizer getbyte on-the-fly-decrunch routine.
    außerdem gibt es kein floppy code im lader.


    achja, die ramlink muss auf adresse 8 eingestellt werden. laufwerksadresse egal, das ist eine sache, die ich noch unbedingt im lader einbauen muss

    Zitat von Stephan Scheuer

    achja, die ramlink muss auf adresse 8 eingestellt werden. laufwerksadresse egal, das ist eine sache, die ich noch unbedingt im lader einbauen muss

    RAMLink fest auf 8? Oder reicht SWAP8?
    SWAP8 hatte ich nämlich getestet... aber das tutet nicht... und bevor ich das ändere kopiere ich das lieber auf eine FD. Dort hat das mit SWAP8 funktioniert.

    Zitat von darkvision

    RAMLink fest auf 8? Oder reicht SWAP8?
    SWAP8 hatte ich nämlich getestet... aber das tutet nicht... und bevor ich das ändere kopiere ich das lieber auf eine FD. Dort hat das mit SWAP8 funktioniert.

    Spielt dies für eine Software eine Rolle?


    Bzw. gibt es da einen - feststellbaren - Unterschied?


    Bei Swap8 hat ja die RL die ID 8.


    Gruss C=Mac.

    ok, das kann sein, dass die getbyte routine mit open und close commands arbeitet., die nicht mit dem sd2iec oder der ramlink kompatibel sind.
    vielleicht liegt es auch am level decruncher. leider fehlt mir die hardware um das zu testen. die älteren scpu-anpassungen besitzen keinen level-decruncher.
    soweit ich weiß. laufen diese von der ramlink. ganz sicher bin ich mir da aber nicht.

    Ich frag mal was ganz böses, wahrscheinlich werd ich jetzt gelyncht.


    Aber trotzdem.


    Was bedeutet eigentlich SCPU-Anpassung?


    - Es wird das RAM der SCPU benutzt; könnte auch mit einer REU oder GeoRAM gehen.
    - Es werden Fehler, welche durch den höheren Takt (20 MHZ) entstehen beseitigt.
    - Es werden "Befehle" der SCPU-CPU benutzt


    Gruss C=Mac.

    Zitat von Stephan Scheuer

    vielleicht liegt es auch am level decruncher.

    Also bei der RAMLink fängt der Bildschirm nicht an zu flackern und auch die Drive-LEDs flackern nicht.


    Zitat von Stephan Scheuer

    ok, das kann sein, dass die getbyte routine mit open und close commands arbeitet.,

    Das erste was ich am Laufwerkstest mache ist der obige "M-R"-Befehl weil das SD2IEC äußerst allergisch auf verschiedenste Floppy-Befehle reagiert. Auch Fastloader funktionieren nur wenn vorher einprogrammiert. Das SD2IEC ist ja nur ein Datenspeicher, für mich also völlig OK.
    Ich kenne jetzt die Routine nicht, aber wenn das SD2IEC "Unknown Drivecode" meldet dann wohl weil da "M-E" verwendet wurde?!?


    Zitat von C=Mac

    Was bedeutet eigentlich SCPU-Anpassung?

    Ich seh das so: Laden aller Disketten in das SCPU-RAM... wozu hat man denn 16Mb wenn man sonst alles von Disk laden muss... ?(


    Ich finde das übrigens echt genial... Danke @ Stephan für die Arbeit :thnks:

    danke! es wird weitere anpassungen geben.
    meine gecodeten maker-programme funktionieren nun zu 100%. die ramdisk hat nun den mvn befehl. der wird genutzt, wenn die bank nicht überschritten wird.
    bei überschreitung der bank wird "lda adresse,x , sta adresse,x" genutzt.


    sorry, ich werde langsam senil. natürlich ist bei "mean streets" auch der 1581-fastloader verbaut. nur nicht 20mhz optimiert. sonst würde der bedeutend schneller laden.


    anhang: katakis scpu. neu ,mit dem exo-getbyte decruncher. das game kannst du testen

    ok, da bin ich beruhigt.
    ich werde "test drive" und "mean streets" mit einer auto-erkennung ausstatten.
    wenn ein inkompatibles laufwerk gefunden wird, wird immer die get-byte routine genutzt.
    bei der 1581 ist der schnelllader bedeutend schneller als jiffidos. die 304 exomized blocks werden in etwa 15 sek geladen.


    ich bin gerade dabei meine georam routinen weiter zu coden. das ist eine ganz schöne frikelei mit $dffe und $dfff.
    da kanm ich die tabellen, die mein file-maker produziert, gut gebrauchen.