Ich konnte nichts dazu finden, was die Software erwartet. Vermutlich egal, solange der Inhalt stimmt, oder?
Eher nicht egal, weil die Datei sonst nicht geöffnet werden kann. Vermutlich muss es eine PRG-Datei für die Tiny-Eprommer-Software sein.
Es gibt 56 Antworten in diesem Thema, welches 6.845 mal aufgerufen wurde. Der letzte Beitrag (
Ich konnte nichts dazu finden, was die Software erwartet. Vermutlich egal, solange der Inhalt stimmt, oder?
Eher nicht egal, weil die Datei sonst nicht geöffnet werden kann. Vermutlich muss es eine PRG-Datei für die Tiny-Eprommer-Software sein.
Ich hab den Quickbyte2.. da isses genausoso und ich musste das auch erst verstehen. Die ROM Files ausm Internet haben die zwei Byte meist NICHT, denn wenn man am PC brennt, wird nichts abgeschnitten. Deswegen müsstest Du bei ROMs ausm Netz die Bytes ranfrickeln.
Ist das nicht beim 64er generell so? Oder gibt es irgendeinen Brenner, dessen Software die 2 Adressbytes als Nutzdaten verwendet?
Ist das nicht beim 64er generell so? Oder gibt es irgendeinen Brenner, dessen Software die 2 Adressbytes als Nutzdaten verwendet?
ja, das wird so sein und das wollte ich damit sagen, dass ich es am QB lernen musste, obwohl hier ja nach dem Tiny Eprommer gefragt war.. weil es eben damals immer so war (PRG file) und heute im Netz ist es eigentlich immer ohne. Wenn man die dann einfach so auf ein d64 schiebt und am C64 brennt, dann geht das in die Hose.
Daher ja meine Abgrenzung.. wenn es ein (C64) zeitgenössischer Brenner ist, dann immer MIT und wenn es ein moderner ist (TL.. bla) dann OHNE.
Bisschen schade, dass nicht die eine Zeile Test dafür damals in die Software übernommen wurde (sowas in Richtung if endaddr and 255 <> 0 then print"da stimmt was nicht")...
..schade schon, aber woher hätte damals einer wissen sollen, dass es mal files geben wird, die nicht PRG konform sind, oder gar einem sagenumwobenen sogenannten INTERNET entstammen.
ok, PRG hatte ich ebenfalls probiert mit dem selben Fehler. Vielleicht mache ich was falsch. Ich habe ein 8K Rom. Algo & Eprom Typ auf 2764 12V eingestellt. Anschließend lade ich die Datei, wobei ich den vollständigen Ausdruck angebe "KimHex.PRG". Dann werde ich nach Adressen befragt, die ich auf Default belasse (3000 etc.) und zum Schluss betätige ich mit Ja.
Müsste so passen oder. Vielleicht teste ich noch mal mit einem frischen Rom.
Naja, PRG sind auch einfach nur Bytes, und lange nicht jedes PRG hat tatsächlich eine Startadresse in den ersten Bytes, man denke nur an die ganzen Highscore-Save-Dateien.
Speziell die Eprom-Dumps sind nichtmal ausführbar oder auch nur an eine bestimmte Adresse gebunden, da würde die Ladeadresse also nochmal extra wenig Sinn machen.
Das wurde vermutlich eher so gemacht, weil das Splitten von Dateien so per "Laden in separaten Monitor, Dateien einzeln speichern" einfacher war (und Monitore nunmal mit Ladeadresse speichern).
muellerarmack Lass mal Groß-/Kleinschreibung weg bzw. zeig hier Screenshots vom Directory und der Eingabemaske.
Hier ein Bild des Image, ich hatte auch mit den anderen Formaten gespielt, daher ist auf dem Image so viel los
Bitte melde dich an, um diesen Anhang zu sehen.
die Dateien mit "HEX"-Suffix habe ich um zwei Bytes erweitern.
Dann einfach kimhex als Dateinamen angeben. "PRG" gehört auf C64-Seite nicht zum Dateinamen dazu, der C64 hat solche Hacks wie "Dateinamenerweiterung" nicht nötig und hat echte Metadaten im Verzeichnis. ![]()
Hier ein Bild des Image, ich hatte auch mit den anderen Formaten gespielt, daher ist auf dem Image so viel los
Bitte melde dich an, um diesen Anhang zu sehen.
die Dateien mit "HEX"-Suffix habe ich um zwei Bytes erweitern.
Da hast du die aber ein schönes Directory mit vielen doppelten Dateinamen gebaut. Das muss natürlich erstmal aufgeräumt werden. Am besten alles löschen, was nicht prg ist. Ansonsten das was 1570 sagt. Die Endungen werden beim C64 natürlich nicht mit angegeben. Auf dem C64 sind das nämlich keine Endungen.
ok, PRG hatte ich ebenfalls probiert mit dem selben Fehler. Vielleicht mache ich was falsch. Ich habe ein 8K Rom. Algo & Eprom Typ auf 2764 12V eingestellt. Anschließend lade ich die Datei, wobei ich den vollständigen Ausdruck angebe "KimHex.PRG". Dann werde ich nach Adressen befragt, die ich auf Default belasse (3000 etc.) und zum Schluss betätige ich mit Ja.
Ich kenne die Software nicht gut, aber kannst du an der Stelle, wo der Fehler kommt, vielleicht das Monitorbild fotografieren? Welche Adressen gibst du bei "Adresse im EPROM" als Anfangs- und Endadresse an?
ok, hat sich schon erledigt. Es lag in der Tat an der Endung. Ich hatte einen Test ohne Endung gemacht, allerdings da hatte ich noch nicht das Rom um die zwei Bytes manipuliert.
Nun mit Manipulation und OHNE Endung klappt es einwandfrei.
Nun hänge ich noch am Brennen fest. Habe zwei gebrauchte 256er mit dem UV-Licht gelöscht. Über die Testfunktion des Programms wird mir das auch bestätigt. Sicherheitshalber erneut
das Rom ausgelesen und passt, alles schön leer.
Wenn ich nun Jiffydos brennen will, bekomme ich sofort die Fehlermeldung, dass das erste Bit nicht gelöscht werden konnte. Bei der Nachkontrolle über den
Hex-Mon seh ich dann auch, dass das erste Bit gesetzt ist.
Ich teste jetzt noch ein anderen Eprom. Es sind zwei Test-Eproms von damals. Vielleicht sind sie auch nicht mehr so fit.
To be continued und vielen Dank schon mal!
Hier ein Bild des Image, ich hatte auch mit den anderen Formaten gespielt, daher ist auf dem Image so viel los
Bitte melde dich an, um diesen Anhang zu sehen.
die Dateien mit "HEX"-Suffix habe ich um zwei Bytes erweitern.
Da hast du die aber ein schönes Directory mit vielen doppelten Dateinamen gebaut. Das muss natürlich erstmal aufgeräumt werden. Am besten alles löschen, was nicht prg ist. Ansonsten das was 1570 sagt. Die Endungen werden beim C64 natürlich nicht mit angegeben. Auf dem C64 sind das nämlich keine Endungen.
ja, haste recht, aber Du siehst, dass die "Hexen"
eindeutig sind
Ich habe hier einen Eprommer, allerdings für Dos, der macht genau das wenn er es mit Eproms zu tun hat, die er nicht mag. Versuch es mal mit Eproms von einem anderen Hersteller.
Micky
Der EPROMer ist richtig aufgebaut? Da gab es einige Verwirrung bei der Bestückung der Joystick-Platine, siehe Bitte melde dich an, um diesen Link zu sehen. und Bitte melde dich an, um diesen Link zu sehen. in Bitte melde dich an, um diesen Link zu sehen. (soweit ich das verstehe benutzen die Conrad-Platinen andere Steckverbinder und sind falsch beschriftet oder sowas).
danke, nun habe ich noch einen NFC Eprom mit 8KB getestet. Gleiches verhalten. Ok, da muss ich noch mal tiefer forschen. Irgendwo ist da der Wurm drin.
Ich habe hier auch einen Conrad Tiny-Eprommer (ehem. als Bausatz geholt) und der hat auch seine Probleme mit 2764 mit dem gleichen Phänomen!
27256er Eproms (12V) brennt er aber anstandslos...
Ich lese also interessiert mit, damit ich für obiges Problem eine Lösung mitbekomme...
Wenn die 2764er Eproms Schrott sind, dann ist das halt so.
Mit einem Rex Goliath 9655 Brenner habe ich bisher noch gar nix zuwege gebracht...
Dann habe ich noch einen vom damaligen Besitzer selbst gebauten (also Platine geätzt, bestückt) Eprommer, für den ich leider keine Software habe...
Grüße,
ko.ma
der hat auch seine Probleme mit 2764 mit dem gleichen Phänomen!
27256er Eproms (12V) brennt er aber anstandslos...
[,,,]
Wenn die 2764er Eproms Schrott sind, dann ist das halt so.
Was sind das genau für 2764? (Foto?)
Ich habe auch viele Eproms geschenkt bekommen.
Waren auch aus der C64 Anfangszeit. Sie ließen sich löschen,
aber beim brennen zeigten sie Dein Phänomen.
Bit nicht gelöscht.
Mit nem neueren Eprom ging es. Die sind wohl irgendwann auf.
Merkwürdigerweise haben die "größeren" Eproms ab 27128 einwandfrei
funktioniert.