Test Drive für die SCPU
Einmal laden und dann spielen. Die 20mhz können während das Spiels wahlweise mit F1 und F3 an- und ausgeschaltet werden.
Viel Spass damit
Stephan
Du bist in Begriff, Forum64 zu verlassen, um auf die folgende Adresse weitergeleitet zu werden:
Bitte beachte, dass wir für den Inhalt der Zielseite nicht verantwortlich sind und unsere Datenschutzbestimmungen dort keine Anwendung finden.
letzter Beitrag von Stephan Scheuer am
Test Drive für die SCPU
Einmal laden und dann spielen. Die 20mhz können während das Spiels wahlweise mit F1 und F3 an- und ausgeschaltet werden.
Viel Spass damit
Stephan
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
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).
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
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. Ich hab gerade eben erst meine FD am offenen Herzen operiert. Wer weiß wie lange das noch gut geht...
ich lade mal die testversion von mean streets hoch. diese ist zu 96% fertig.
einfach mal zum testen, ob die ladezeit noch ok ist. das spiel sollte mit allen laufwerken funktionieren.
stephan
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.
Aber ist anderes Thema.
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.
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.
eine abfrage ob schnalllader oder nicht, ist nich sonderlich schwer zu coden.
ich dachte eher an eine automatische erkennung. so braucht der user nicht sändig fragen zu beantworten wie z.b.
fastload aktivieren? trainer? high-score laden? high-score zurücksetzen? ect.
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.
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
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.
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.
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.
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?!?
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
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
anhang: katakis scpu. neu ,mit dem exo-getbyte decruncher. das game kannst du testen
Det läuft Auch von einem SD2IEC. Ladezeit 23sek.
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.