Völlig egal. Zwei Byte, was auch immer, vorne dran und schon läufts. ![]()
Es geht einfach nur darum, den Code um 2 Bytes nach hinten zu verschieben.
UNIPROM64 - eine universell einsetzbare EPROM-Platine für den C64
-
GI-Joe -
13. März 2015 um 21:17 -
Erledigt
Es gibt 314 Antworten in diesem Thema, welches 102.080 mal aufgerufen wurde. Der letzte Beitrag (
-
-
Völlig egal. Zwei Byte, was auch immer, vorne dran und schon läufts.

Ja, so macht es Deine C64-EPROMMER-Software.
Aber meine Frage ist jetzt: verhalten sich die anderen C64-EPROM-Programme auch so ?Hintergrund: ich versuche es gerade in die FAQ´s des UNIPROM64-Manuals aufzunehmen

-
Aber meine Frage ist jetzt: verhalten sich die anderen C64-EPROM-Programme auch so ?
Es gibt keinen Grund, warum sie es nicht tun sollten. Aber eine Menge dagegen.
(EDIT: umformuliert)
EDIT2: Mit fällt leider gerade kein angemessener Vergleich ein.
-
Zitat
Völlig egal. Zwei Byte, was auch immer, vorne dran und schon läufts.

Es geht einfach nur darum, den Code um 2 Bytes nach hinten zu verschieben.Nu ja, das ist nicht ganz so richtig....
Es kann passieren, dass beim umwandeln von einer .bin, oder .rom Datei die ersten beiden Bytes "verschwinden", weil daraus für das ROM File im .d64 Image eine Ladeadresse gebastelt wird.
Je nachdem mit welchem Tool du das machst.
Dann mit einem HexEditor VORM umwandeln zwei Bytes davor setzen. Am besten "$00 $10", oder "$00, $20". Das ist dan die Ladeadresse vom File in Low und Highbyte.
Im Prinzip ists egal was du davor setzt, solltest dann beim Programm des Eprommers ab NICHT an Originaladresse laden, sondern $1000 oder $2000 angeben. Damit bist du auf der sicheren Seite, - auch wenn du ein 32K Eprom brenn möchtest.Die fehlenden Bytes am 64er nachzubasteln ist komplizierter - geht aber natürlich auch.
-
EDIT2: Mit fällt leider gerade kein angemessener Vergleich ein.

Jetzt aber: Die Frage ist ungefähr so sinnvoll wie: "Müssen Basic-Programme immer mit RUN gestartet werden?"
Natürlich kann man auch ein Programm schreiben, das unbedingt mit GOTO 20 gestartet werden muss, aber das ist nun mal nicht sinnvoll.
Falls ein Eprommer-Programm die Datei einfach mal so an die in der Datei vorhandene Ladeadresse lädt, wäre das ein Bug und nichts anderes. -
Es gibt keinen Grund, warum sie es nicht tun sollten. Aber eine Menge dagegen.
Das sehe ich exakt genau so !
EDIT2: Mit fällt leider gerade kein angemessener Vergleich ein.

nur hilf das jetzt auch nicht wirklich weiter

Im Prinzip ists egal was du davor setzt, solltest dann beim Programm des Eprommers ab NICHT an Originaladresse laden, sondern $1000 oder $2000 angeben. Damit bist du auf der sicheren Seite, - auch wenn du ein 32K Eprom brenn möchtest.
Ich habe nun in Manual mal $2000 geschrieben - sollen mich doch Alle lünchen, die damit nicht einverstanden sind

.... oder vom Besseren überzeugen - dann kann ich´s ja noch nachbessern.
Falls ein Eprommer-Programm die Datei einfach mal so an die in der Datei vorhandene Ladeadresse lädt, wäre das ein Bug und nichts anderes.
Ja, stimmt ! Und darum ist es eigentlich egal, welche Werte die beiden Bytes haben, also liege ich (bzw. Hucky - thx) mit $2000 auch nicht schlecht. Danke - es bleibt also so !
Das aktualisierte Manual wurde gerade hochgeladen.@MacBacon: [remember] ich hab von Dir noch keine PRG/EPROM-Files erhalten - bin also noch auf standby
[/remember] -
Zitat
Falls ein Eprommer-Programm die Datei einfach mal so an die in der Datei vorhandene Ladeadresse lädt, wäre das ein Bug und nichts anderes.
Einfach so machen die Programme es nicht. Man muss wählen. Zumindest bei den meisten. Bei manchen kann man auch nur die Ladeadresse angeben - kann nicht an original Adresse laden. -
Ich meine das der QuickByte II keine 2 Bytes vor der Datei braucht... müsste mal wer testen.
-
Zitat
Ja, so macht es Deine C64-EPROMMER-Software.
Nein, mein Eprommer hat das nicht automatisch gemacht. Ich musste die 2 Bytes mit einem Hexeditor hinzufügen.ZitatIch meine das der QuickByte II keine 2 Bytes vor der Datei braucht... müsste mal wer testen.
Habe ich. Deshalb ist das Thema ja gerade aufgekommen. -
Naja, wer brennt auch heutzutage noch mit dem alten Brotkasten.

Äähhhh, ich.
ICH auch

Wenn man ein Eprom für einen C64 verwenden möchte, sollte man es oldschoolmässig auch auf dem C64 brennen!

Der Tiny-Eprommer V2 z.b. funktioniert wunderbar, für Eproms zum Einsatzzweck am C64.Eproms für den Cevi werden mit nem Eprommer am Cevi gebrannt!

alles andere ist ketzerisch

So, Ihr verrükten Retro-EPROM-Brenner
Ich habe heute mal ein UNIPROM64-EPROM zusammengetüftelt, wo die TinyEPROMMER-Software und ein Haufen Modulgeneratoren mit daruf sind. War z.T. gar nicht so einfach, weil einige EPROM-Generatoren waren Nachlader von den Hauptmenu´s der EPROMMER-Software´n (äähmm - wie ist eigentlich die Mehrzahl von 'Software' ??
)Mit diesem EPROM habt Ihr alles schön auf einem Haufen und schön schnell verfügbar.
Warum der TinyEPROMMER ?
Na weil DER nach wie vor gut verfügbar ist und am Userport hängt und das UNIPROM64-Modul hängt dann gleichzeitig am Expansionsport.Ich habe keine Ahnung, ob und wie die einzelnen C64-Modulgeneratoren funzen - eine Rückmeldung bei nicht/fehlerhafter Funktion wäre schön
Achso - bitte nicht falsch verstehen: diese Modul-Generatoren erzeugen keine UNIPROM64-EPROM-Files - hierfür sind nach wie vor die UNIPROM64-EPROM-Generatoren zu verwenden !Auch weiß ich nicht, ob es noch andere C64-Modulgeneratoren gibt - weiß Jemand von Euch noch irgend Einen, der noch mit rein könnte ?!?
Wie auch immer, das EPROM ist eh fast voll (ca. 18 Blocks free) - viel passt also nicht mehr rein
Ich hab 64kb-Multifile_Tiny-Eprommer_Modul-Generatoren mal mit in die EPROM-Kollektion mit aufgenommen - wurde gerade hochgeladen

-
Also beim Quickbyte 2 und glaube auch Tiny Eprommer kann man die Adresse des Buffers einstellen.
Somit sollten die sich nicht für die Adresse in der Datei interessieren. Aber die 2 zusätzlichen Bytes braucht er schon. -
Moin liebe UNIPROM64-Freunde

Aufgrund einiger Anfragen zur Bedienung des Multifile-EPROM-Generator´s unter Windows (cygwin-Version des Generators) habe ich einmal das das Kapitel 9 und die FAQ´s des UNIPROM64-Manuals überarbeitet/erweitert.
Es wurden die Seiten Seiten 24,25,28,29,30 bearbeitet.
Das neue Manual wurde gerade hochgeladen und ist über den Bitte melde dich an, um diesen Link zu sehen. erreichbar.Über Feedback/Kritik würde ich mich freuen - besonders falls sich Fehler eingeschlichen haben oder ich noch etwas vergessen habe

Viel Spaß

-
Ja, ist sehr verständlich geschrieben und hilfreich das Update! Bei mir hat es auf jeden Fall damit geklappt...

Oliver W.
-
Ich hab hier ein Uniprom64 mit Gianna Sisters drauf, das auf einer 250425 manchmal nicht richtig funktioniert. Mit einer anderen '425 geht es immer und mit einer '469 auch. Also denke ich das Uniprom ist soweit OK.
Der Effekt ist, dass er bis zur Meldung "DECRUNCHING NOW ... 32-K-CARTCRIDGE-GENERATOR CODED BY GI-JOE!" kommt und stehenbleibt. Das Geflimmer im Border kommt nicht mehr. Manchmal läuft es auch, ich hab aber noch kein System dahinter gefunden.
Das fragliche Mainboard läuft aber soweit problemlos, auch das Dead Test Modul findet keine Speicherfehler o.ä.
Was kann das sein?Installiert ist ein 27C256 mit 100ns, alle Dip-Schalter stehen auf 'On'.
-
Das fragliche Mainboard läuft aber soweit problemlos, auch das Dead Test Modul findet keine Speicherfehler o.ä.
Was kann das sein?hmm, also ganz spontan fällt mir jetzt gerade ein verschmutzter Expansionsport-Stecker ein. Checke Das mal bitte mit viel Licht und viel Vergrößerungsoptik

Dass ein ULTIMAX-Modul in dem Rechner funzt bedeutet nicht zwangsläufig, daß ein Modul mit Bankswitching auch funzt bei verschmutzten EX-Port-Kontakten....EDIT: Die rechte (EXROM)LED muß ausgehen, wenn Du diesen Decrunching-Screen siehst !
Hast Du auch fein die Hinweise im Manual/Seite 6 umgesetzt ? Wenn nicht, bitte unbedingt machen !!
An sonsten teste doch mal ein anderes EPROM/EPROM-File man weiß ja nie .... -
hmm, also ganz spontan fällt mir jetzt gerade ein verschmutzter Expansionsport-Stecker ein. Checke Das mal bitte mit viel Licht und viel Vergrößerungsoptik

Kontakte sehen gut aus, auch unter der Lupe. Hab sie trotzdem mal vorsichtig nachgebogen und versucht zu reinigen, kein Erfolg.
EDIT: Die rechte (EXROM)LED muß ausgehen, wenn Du diesen Decrunching-Screen siehst !
Sie geht aus, dann passiert aber meistens nix mehr.
Hast Du auch fein die Hinweise im Manual/Seite 6 umgesetzt ? Wenn nicht, bitte unbedingt machen !!
Du meinst das Anfasen der Platine? Hab ich gemacht.
-
An sonsten teste doch mal ein anderes EPROM/EPROM-File man weiß ja nie ....
haste dies auch schonmal versucht ?
Hmm, schon komisch, daß es auf anderen Rechnern funzt ...

-
Ich hab jetzt das gleiche File auf ein anderes EPROM gebrannt, das funktioniert problemlos.
Das EPROM, das nicht immer geht ist ein ST MC27C256B-10F1
Das funktionierende: NM27C256Q-150
Sind etwa 100ns zu schnell?Das problematische EPROM läuft wie gesagt in anderen Rechnern problemlos, nur in der einen '425 startet es nur bei jedem x-ten mal Einschalten bzw. resetten. Wenn es aber durch das Entpacken durchkommt, läuft das Spiel ganz normal.
Ein erneutes Löschen und Neuprogrammieren brachte keine Besserung.
Als ich gestern mein SD2IEC angesteckt hab (zum Laden eines RAM-Testers), kam es mir so vor, als wenn es mit angestecktem SD2IEC etwas häufiger startete... kann aber auch Einbildung sein...
-
Irgendwo hier habe ich mal gelesen, daß bei EPROMs "schneller" nicht immer besser ist (war das im Zusammenhang mit der EPROM-PLA ?? kann sein ...).
Als ich gestern mein SD2IEC angesteckt hab (zum Laden eines RAM-Testers), kam es mir so vor, als wenn es mit angestecktem SD2IEC etwas häufiger startete... kann aber auch Einbildung sein...
messe doch mal an dem "Problemboard" die Versorgungsspannung im eingeschaltetem Zustand am Userport Kontakt 1 und 2.
-
Am Expansion Port liegen 5,0V an, die kommen auch an den ICs auf dem Uniprom64 an (Ziegelnetzteil).
Äh meintest Du wirklich Userport? Egal, da wäre es auch 5,0V. -