letzter Beitrag von FXXS am
ZitatWas ich gerade feststelle ist, dass all diese crt's aus diesem Thread nicht mit einer Ultimate II gestartet werden können, obwohl diese ja EF kompatibel ist.
Alle vorherigen EF Releases konnten das ja auch. (zuletzt Supercycle) Woran liegt's?
das problem ist das der der damals das crt format für easyflash definiert hat dabei leider den punkt "einfachheit" ignoriert hat, so das ein loader für dieses format der wirklich jede denkbare konstellation versteht nicht ganz einfach ist. der loader im chameleon menu hat da auch noch probleme mit images die mit bestimmten tools gemacht wurden.
Schade... Wäre ja auch zu schön gewesen... 
Aber Moment...
Es läuft ja offenbar auf dem EF und im Emu.
Ist das Problem dann die Kompatibilität der UII?
Oder kann man die Spiele so biegen das sie dann auch dort funzen?`
ZitatMan kann in dem header von einem crt einstellen, welchen "Wert" die game/exrom leitungen haben. Damit wird eingestellt, ob es sich um ein 8k, 16k oder ultimax modul handelt. Simons Basic z.B. startet als 8k modul (es sind aber 16k) und schaltet bei bedarf zw. 8k und 16k modus um. DCM ignoriert diesen wert, und versucht ihn aus der bank-belegung zu erraten. Startet also Simons Basic im 16k modus - was aber wiederum dann zum absturz fuehrt.
man sollte bei cartridges die keine "standard" game module sind grundsätzlich diesen wert ignorieren und aus der crt id ermitteln - da in der vergangenheit eine menge tools diesbezüglich falsche files produziert haben. bzw, eigentlich ist die angabe redundant - da sie sich ja eindeutig aus der crt id ergibt - und darum haben einige tools die scheinbar einfach ignoriert bei solchen cartridges.
zu den easyflash crt files die auf der 1541u nicht starten fällt mir noch ein.... eventuell kann man die lauffähig machen in dem man diese einmal mit cartconv in ein binary und dann zurück in ein crt file wandelt - zumindest sind dann die bänke in der standardreihenfolge in der sie ein simpler crt loader vmtl erwartet.
zu den easyflash crt files die auf der 1541u nicht starten fällt mir noch ein.... eventuell kann man die lauffähig machen in dem man diese einmal mit cartconv in ein binary und dann zurück in ein crt file wandelt - zumindest sind dann die bänke in der standardreihenfolge in der sie ein simpler crt loader vmtl erwartet.
Könnte das mal jemand testen? Würde mich sehr freuen, wenn das funktionieren würde! 
man sollte bei cartridges die keine "standard" game module sind grundsätzlich diesen wert ignorieren und aus der crt id ermitteln
Hmm... xbank hat nur eine ID also muss man es aus den feldern lesen (oder neue ID's einfuehren, nicht die beste idee bezueglich kompatibilitaet) - bei den meissten oder gar allen anderen crt's gebe ich dir aber recht.
Zitatzu den easyflash crt files die auf der 1541u nicht starten fällt mir noch ein.... eventuell kann man die lauffähig machen in dem man diese einmal mit cartconv in ein binary und dann zurück in ein crt file wandelt - zumindest sind dann die bänke in der standardreihenfolge in der sie ein simpler crt loader vmtl erwartet.
kann es sein, dass die 1541u keine 16k "CHIPS" erkennt/unterstuetzt?
doku, bereich "CHIP", offset 0xe-0xf.
Zitatxbank hat nur eine ID also muss man es aus den feldern lesen
xbank ist eh ein kapitel für sich und wäre lieber mal ein eigenes format für easyflash geworden - das ignoriere ich bei der betrachtung von crt files komplett, weil irrelevant. hätte hakan damals realisiert das es sich dabei garnicht um einen hardware typen handelt hätte es auch keine extra id gegeben, vermutlich =P
Zitatkann es sein, dass die 1541u keine 16k "CHIPS" erkennt/unterstuetzt?
keine ahnung. grundsätzlich sollte man sich da aber auf eine standardpaketgrösse für das jeweilige crt format festlegen - die paketgrösse ignoriert jeder mir bekannte crt loader ebenso. (und in vielen fällen auch sämtliche andren angaben im paket selbst).
xbank ist eh ein kapitel für sich und wäre lieber mal ein eigenes format für easyflash geworden - das ignoriere ich bei der betrachtung von crt files komplett, weil irrelevant. hätte hakan damals realisiert das es sich dabei garnicht um einen hardware typen handelt hätte es auch keine extra id gegeben, vermutlich =P
kann sein, wobei ich immer klar gemacht habe dass es keine hardware ist. aber jetzt auch egal. hatte sogar schon zwischenzeitlich darueber nachgedacht doch ein eigenes format zu erstellen - aber jetzt wo es schon eine id gibt...
Zitat
keine ahnung. grundsätzlich sollte man sich da aber auf eine standardpaketgrösse für das jeweilige crt format festlegen - die paketgrösse ignoriert jeder mir bekannte crt loader ebenso. (und in vielen fällen auch sämtliche andren angaben im paket selbst).
nu die definition sagt halt dass das paket 8k oder 16k seien kann, und solange keiner die definition aendert sollten lieber alle programme das auch so unterstuetzten - was bis jetzt alle bekannten programme machen, ausser dem U, wenn es daran liegt. (und ich glaube es gibt sogar CHIPS mit 4k in besonderen modulen)
Zitatnu die definition sagt halt dass das paket 8k oder 16k seien kann,
nicht ganz, laut der definition ist die länge sogar beliebig in der praxis gibt es 4,8,16,32k - je nach cartridge
Zitatund solange keiner die definition aendert sollten lieber alle programme das auch so unterstuetzten - was bis jetzt alle bekannten programme machen
wie gesagt, andere paketgrössen als 8k gibt es ja - aber nicht gemischt oder beliebig, sondern genau eine grösse abhängig vom jeweiligen crt typ. wenn du zb ein AR crt file bastelst und darin statt 4*8k paketen 2*16k reinmachst wird das auch nirgendwo funktionieren. wirklich beachtet wird diese angabe wiederum nur bei "normalen" standardmodulen, und das auch nur weil es ultimax cartridges gibt die nur 4k haben
im zweifelsfall ein crt mit cartconv erzeugen und die struktur 1:1 übernehmen, dann funktioniert das auch überall in cartconv kann man auch gut sehen wie praktisch alle tools die mit crt umgehen arbeiten - ausser bei standardcartridges wird alles per id zugeordnet und die angaben im file ignoriert.
Zitatausser dem U, wenn es daran liegt.
supersnapshot hat 16k bänke im crt file, grundsätzlich sollte es also gehen. ich würde aber wie gesagt davon ausgehen das genau eine paketgrösse pro crt id unterstützt wird. und das sind laut der aktuellen spezifikation bei easyflash 8k 
supersnapshot hat 16k bänke im crt file, grundsätzlich sollte es also gehen. ich würde aber wie gesagt davon ausgehen das genau eine paketgrösse pro crt id unterstützt wird.
Das sollte man wirklich, wobei es mich immernoch wundert, dass da die stupiden Parser von anno dazumal nicht gebacken bekommen, die Files ordentlich zu lesen. Der CRT-Parser in EasyProg ist vielleicht 50 Zeilen lang, läuft auf dem C64 (im Gegensatz zu Emus oder z.B. der 1541U, die mit Speicher nicht so sparsam umgehen zu brauchen) und parsed beliebige Kombinationen von Bank-Größen.
Wie gesagt, ich stimme aber zu, dass man aus Kompatibilitätsgründen die "üblichen" Größen benutzen sollte.
und das sind laut der aktuellen spezifikation bei easyflash 8k
Eine falsche Spezifikation wird nicht dadurch richtig, dass sie irgendwo im Vice-Tree rumpurzelt. EasyFlash CRTs können verschiedene CHIP-größen enthalten. Und wenn jetzt wieder so ein Hardcore-Argument kommt, dass CHIP aber einem physikalischem Chip entsprechen sollte, dann müsste da entweder 2 * 512k stehen oder wenn es den Hardcore-Interpretern um ROML/ROMH-Banken geht, dürften in keinem anderen CRT 16k-Bänke sein. Beides wäre Quatsch. Die Angabe mit den 8k-Bänken in EF hat irgendwer frei erfunden.
Ah, und das problem lag sogar wo anders:
denn in der 1. bank hatte ich 0xe000 als ladeadresse genommen, da das modul ja schliesslich im ultimax modus arbeitet. is nu auf 0xa000 geaendert.
p.s. in der vice-cart-beschreibung ist definitiv noch ein anderer fehler: dort sind die game/exrom leitung vom easyflash so beschrieben wie bei einem 8k crt (ja ich weiss, dass man diese angaben eh' lieber ignorieren sollte [ausser bei normalen und xbank crt's])
EDIT: ich hatte die aufloesung in den anderen thread gepostet, da es dort angebrachter ist - evtl. kann ja mal ein mod diese gaze diskussion umziehen, da es hier ja um die fertigen crt's geht.
denn in der 1. bank hatte ich 0xe000 als ladeadresse genommen, da das modul ja schliesslich im ultimax modus arbeitet. is nu auf 0xa000 geaendert.
Das ist einer der Design-Fehler im ursprünglichen CRT-Format
ZitatEine falsche Spezifikation wird nicht dadurch richtig, dass sie irgendwo im Vice-Tree rumpurzelt.
daher der smilie man muss auch dazu sagen das dieses dokument von peter schepers ja eigentlich keine spezifikation ist, sondern eine dokumentation des ist-zustandes (welche nötig wurde weil das format so schlecht spezifiziert ist). die eigentliche spezifikation (ich finds grad auf der schnelle nicht auf der ccs seite, das hier sieht aber halbwechs "aktuell" aus - man sieht leicht wie outdated und unvollständig das ist) erwähnt easyflash nichtmal
ZitatEasyFlash CRTs können verschiedene CHIP-größen enthalten. Und wenn jetzt wieder so ein Hardcore-Argument kommt, dass CHIP aber einem physikalischem Chip entsprechen sollte, dann müsste da entweder 2 * 512k stehen oder wenn es den Hardcore-Interpretern um ROML/ROMH-Banken geht, dürften in keinem anderen CRT 16k-Bänke sein. Beides wäre Quatsch.
eine möglichkeit hast du vergessen: die grösse entspricht der grösse der bank die das cartridge bei beschreiben des bank registers umschaltet - das trifft für viele (nicht alle =P) cartridges zu. (physische chipgrösse wäre an der stelle ganz fiess, da es cartridges gibt die mal mit 2*8k und mal mit 1*16k rom daherkamen)
ZitatDie Angabe mit den 8k-Bänken in EF hat irgendwer frei erfunden.
ja, derjenige welcher es in vice implementierte :o)
Ich hab mal nen neuen Thread draus gemacht.
sl FXXS
