Eine Ausnahme sind die Geräte von Atari, die auf einer Stereospur die Daten, auf der anderen eine Musikspur zur Untermalung des Ladevorgangs unterbrachten."
Die Creativision bzw der Dick smith Wizzard konnte das auch! Eine coole Anwendung davon war das DemoTape...
https://www.youtube.com/watch?v=bXKFag4x6EU
Ladevorgang startet im Video bei 6:30min...
Lg. TOM:0)
Aber ich dachte, der PET sollte zu einem Termin vorführbereit sein.
Naja, ist er ja im Wesentlichen. Wir hatten ihn ja vor einer Woche schon gedanklich aus dem Plan rausgenommen als wir die Reparatur in der Nacht zum Samstag abgebrochen haben. Und jetzt tut er ja. Da würde ich mir eher Sorgen machen dass er wieder nicht mehr geht wenn er paar Stunden an ist.
Sehr löblich finde ich jedenfalls diese Seite. Es gibt bei der Commodore Datasette scheinbar 3 Sicherungsmechanismen.
-Ein Parity-Bit pro Byte.
-Ein simples XOR über je 192 Byte.
-Generell eine Wiederholung von jeweils 192 Byte.
Nachtrag: https://www.c64-wiki.de/wiki/A…ungsformat_der_Datassette
Auch wieder ohne Link. 
Das war eine meiner Informationsquellen, als ich mich damals damit beschäftigt habe. Das war 2016, keine Wunder, dass ich das meisten schon wieder vergessen habe.
Wenn man wayback braucht ist es u.U. echt schon paar Tage her. Gut, dass es wayback gibt!
Ist doch schon!?
Ich fresse mich gerade mit python durch das space-invaders.wav da ist mir etwas aufgefallen. Und zwar komme ich da ja auf meiner echten Maschine nicht rein ins Spiel. Es heißt ja "press any key to start" und dann A/4/6 für fire/left/right. Aber bei mir bleibt das Spiel immer im attraction mode und ich habe links unten ein inverses Herzchen was komisch aussieht. Nun sehe ich in dem Header von dem WAV eine $2300 als Endadresse. Aber mein PET hat ja nur 8 KiB, ergo ab $2000 gibts kein RAM. Kann es sein, dass das Spiel oder zumindest meine konkrete Version erst auf einer 16 KiB Maschine richtig funktioniert?
Ich glaube, es gibt eine Space Invader Version, die bei mir auf dem PET auch nicht lief. Hattest du die vorher mal in Vice getestet?
Ein falsches Header-Ende bedeutet natürlich noch nicht automatisch, dass das nicht läuft. Die Frage ist, wie große das Programm wirklich ist.
Wie wurde denn die WAV-Datei erzeugt. Häng das Programm doch einfach mal hier an. Du bist leider immer etwas sparsam mit Infos.
Und die WAV-Datei zu debuggen ist natürlich auch einen Methode.
Wollt ihr das nicht lieber auslagern ?
Wenn jemand Infos ueber Spiele, Demos und aehnliches sucht
in diesem Fred, findet er mehr technisches ueber Datasetten
als ueber das eigentliche in der Ueberschrift.
Ne, nicht persoenlich gemeint. Ich finds nur echt unuebersichtlich inzwischen !
Ansnsten coole und Wissenswerte Infos. Respekt an euch Profis !!
Kann man den Fred umbenennen?
"Wir machen einen Bj. 1978 PET 2001-8 fit für dessen Ausstellung auf der Hack & Make in Nürnberg"
oder so.
Das WAV habe ich von "Oldie" / Seite #5 / Post #127.
Mit was er es erzeugt hat bzw. wo er die Datei her hat muss er sagen. Ich habe sonst nichts. Und der VICE frisst kein WAV als Tape-File habe ich vorhin getestet. Wollte ich nämlich auch schon checken ob mans da reinbekommt und wie es dann dort laufen würde. Krass wäre, wenn ich mit meinem Python soweit komme, dass ich die Daten aus dem WAV rausbekomme und dann sonstwie doch in den VICE reinkriege. Und dann mal zwischen 8 KiB und 16 KiB umschalten und gucken was es dann macht.
Perfekt. Ich hab derweil als Abfallprodukt der WAV-Analyse gecheckt, wie so ein BASIC/Maschinensprache-Programm von Tape in den Speicher kommt.
Wie man in Post #187 sieht, ist die Zieladresse $0401. Das ist die Standardzieladresse beim PET für Basic-Programme. Beim C64 wäre es $0801. Und dann werden da 14 Byte Basic-Programm hingeladen und danach kommt direkt der Maschinencode.
gelb: Der 16-Bit Pointer auf die nächste Zeile. $040d, dort steht dann $0000, das Zeichen für Ende-des-Programms. D.h. ein LIST wird später genau die Zeile
10 SYS(1039)
auf den Bildschirm schreiben. Wobei #1039 in Hex $040f ist, der erste rote Befehl, ein $EA=NOP.
grün: die Zeilennummer #10 == $000a
grau: $9e ist das BASIC-Token für "SYS".
blau: Das ist tatsächlich einfach ~ASCII für "(1039)", also als 6 Buchstaben geschrieben. Man kann sich gleich vorstellen wie lange das dauert bis der BASIC-Interpreter da drüber ist.
Habe jetzt ein bischen wegen den Space Invaders geforscht. Auf
http://www.cbmhardware.de/cbmgames/ -> Shoot'em'Up
gibt es eine 2001 und eine 3001 Version. Beide sind bytemäßig exakt gleich groß (7169 Bytes). Die eine läuft im VICE/PET 2001 mit 8 KiB (oder mehr) fehlerfrei, die andere schaut im Emulator genauso aus wie auf meinem echten PET und läuft dann aber wie man schon vom Namen her erwarten würde im VICE/3001 fehlerfrei.
Also Entwarnung. man muss nur die richtige Version für die Maschine haben und ich habe erstmal die falsche.
Das Fehlerbild ist:
-Statt der Highscore Liste kommt ein zweites Mal "PLAV SPACE INVADERS". Dieser Text bleibt dann auch im Spiel stehen.
-Inverses Herzchen links unten
-"Schießkopf" ist zu hoch
-Man kommt gar nicht in den Spielmodus rein. (nix mit PUSH ANY KEY)
Mein WAV-Analyzer ist auch schon operabel. Und ich muss sagen, dass mir das WAV aus Post #187 sehr suspekt ist. Erstensmal ist es eine Version von Space Invaders die auf meinem PET 2001 eben nicht läuft - da kann sie aber nix dafür. Dann sind da lauter so komische Pausen drin mit Knacksern die glaube ich nicht sein müssten. Aber das schlimmste ist, und da wunderts mich warum es trotzdem überhaupt lädt: Der Header und die eigentlichen Programmdaten kommen jeweils 2x nacheinander in dem WAV, so solls ja sein. Die Wiederholung des Headers ist auch korrekt. Aber in der Wiederholung des Hauptteils kommt nur Bullshit. Und ich hätte erwartet, dass die Laderoutine bei der ersten Abweichung einen Error anzeigt und abbricht aber nichts davon ist der Fall.
Jedenfalls hab ich mich dann nach Tools umgesehen und bin gleich beim ersten erfolgreich gelandet.
https://sourceforge.net/projects/wav-prg/
Ich hatte keinen Bock auf Konsolenzeug, meine Empfehlung: Klicke "Files", Klicke "WAV-PRG and Audiotap installer" und klicke "WAV-PRG 4.0.1+Audiotap 2.0".
Das sind sonst etliche Einzelprojekte und dlls die man erstmal zusammenbringen muss. Mit dem Installer läuft hingegen auf Anhieb und mit GUI.
Jedenfalls kann das Tool PRG->WAV und WAV->PRG und massig anderes Zeug und es funktioniert scheinbar.
Dann hab ich erstmal das WAV von Post #187 nach PRG gewandelt. Funktioniert. Der Anfang des PRG-Files ist identisch mit dem was ich im Netz gefunden habe siehe Post #195. Hinten dran hängt aber besagter Datenmüll, den mein Python eben auch sieht.
Dann habe ich damit den 2001er Space Invaders PRG nach WAV gewandelt. Mein Python konnte daraus gleich mal korrekt das ursprüngliche PRG wieder rausziehen. Dann das WAV aufs Handy, per Klinke und Sony-Küchenstereo aufs Band. Band im PET eingelesen. Gleich der erste Ladeversuch ohne Fehlermeldung. Spiel spielt fehlerfrei incl. User Port / CB2-Sound mittels 470k-Ohm Wiederstand in einen Mono-Akku-Speaker mit 57k-Ohm Innenwiderstand. Damit komme ich (glaube ich...) von TTL (also 5V Amplitude) auf ein Zehntel runter also 500 mV Amplitude was so grob im Bereich des Homerecording-Pegels von -10 dBV liegen sollte (Soll: 316mV Effektivwert) . Falls ich mir mal einen halbwegs soliden Adapter machen sollte, muss ich das mal mit dem Scope überprüfen. Die Lautstärke passt jedenfalls zufällig, ich habe nämlich gar kein Stellrad für selbige.
Aber in der Wiederholung des Hauptteils kommt nur Bullshit. Und ich hätte erwartet, dass die Laderoutine bei der ersten Abweichung einen Error anzeigt und abbricht aber nichts davon ist der Fall.
Das fände ich aber doof, wenn die Laderoutine nur dann lädt, wenn jeweils alle Blöcke und ihre Wiederholung korrekt sind.
Das verdoppelt nicht die Chancen, ein Programm zu laden, sondern halbiert sie.
Habe jetzt ein bischen wegen den Space Invaders geforscht. Auf
http://www.cbmhardware.de/cbmgames/ -> Shoot'em'Upgibt es eine 2001 und eine 3001 Version. Beide sind bytemäßig exakt gleich groß (7169 Bytes). Die eine läuft im VICE/PET 2001 mit 8 KiB (oder mehr) fehlerfrei, die andere schaut im Emulator genauso aus wie auf meinem echten PET und läuft dann aber wie man schon vom Namen her erwarten würde im VICE/3001 fehlerfrei.
Also Entwarnung. man muss nur die richtige Version für die Maschine haben und ich habe erstmal die falsche.
Das kommt mir alles so bekannt vor.
Ich hatte im Laufe der ganzen Diskussion ganz vergessen, dass du das WAV nicht selber erzeugt hattest. Ich habe das damals mit diesem Windows-Tool gemacht. Aber du bist ja bald soweit, dass du das mit eigener Software tun kannst.
Als Zwischenschritt bietet sich das schon erwähnte TAP-Format an. Das wird von vielen Emulatoren gelesen. Vice kann es glaube ich auch erzeugen. TAP nach WAV zu wandeln ist ein 3-Zeiler (wenn man eine Lib zum Erzeugen von WAV-Dateien hat).
Nein, ich hab's nicht in 3 Zeilen geschafft, aber ich habe es auch ohne fertige Lib gemacht. 
Allerdings habe ich mein Programm nie unter realen Bedingungen getestet. Weil ich das auch nur gemacht habe, um die verschiedenen Formate zu verstehen. Wirklich gebraucht habe ich es zu diesem Zeitpunkt nicht mehr. Ich hatte mein Programm getestet, in dem ich die erzeugten WAV-Dateien mit dem wav-prg Tool wieder in PRG-Files zurückverwandelt habe.
Ich hab's jetzt auch im Internet wiedergefunden:
WAV-PRG and Audiotap: from Commodore tapes to PC and back
Was mir noch eingefallen ist, als ich mir die Screenshots angesehen habe. Man kann ja das Zielsystem wählen (VC20, C64, PAL oder NTSC). PET müsste VC20 entsprechen (1 MHz Systemtakt). Die haben alle leicht unterschiedliche Timings, die, wenn man sich vielleicht sowieso schon im Grenzbereich befindet, noch eine zusätzliche Fehlerquelle darstellen. Aber eigentlich sollte die Laderoutine im PET das ausgleichen, weil sie sich auf die Bandgeschwindigkeit synchronisiert.
Was mir noch eingefallen ist, als ich mir die Screenshots angesehen habe. Man kann ja das Zielsystem wählen (VC20, C64, PAL oder NTSC). PET müsste VC20 entsprechen (1 MHz Systemtakt). Die haben alle leicht unterschiedliche Timings
Da hab ich gleich ins Klo gegriffen und VC20/PAL gewählt und dann ging nichts. Hab dann recherchiert dass der einen clk = 1.1 MHz hat und das somit die ungeeigneteste Einstellung war, neben C16 natürlich. Die Grundeinstellung C64-PAL ist wahrscheinlich die beste. Fehler 1.5%.
Overview
| PET 2001 | 1.0 MHz |
| C64-PAL | 0.9852486 MHz |
| C64-NTSC | 1.0227273 MHz |
| VC20-PAL | 1.10 MHz |
| VC20-NTSC | 1.02 MHz |
| C16-PAL | 1.76 / 0.885 MHz |
| C16-NTSC | ??? |
Das fände ich aber doof, wenn die Laderoutine nur dann lädt, wenn jeweils alle Blöcke und ihre Wiederholung korrekt sind.
Das verdoppelt nicht die Chancen, ein Programm zu laden, sondern halbiert sie.
Meine Erwartungshaltung wäre gewesen:
1. Header lesen
2. Header-Wiederholung lesen und gegen die Erstlesung vergleichen. Sofort LOAD ERROR wenn was nicht stimmt
3. Daten ins RAM lesen
4. Daten-Wiederholung wie [2]
Datensicherheit geht imho immer vor! Nur wenn alle 3 Sicherungsmechanismen nicht angeschlagen haben kommt nach LOAD -> READY, ansonsten LOAD ERROR. Aber wie schon gesagt, es ist nicht so implementiert.
Anhand der Prüfsummen sollte erkannt werden, ob die Datenblöcke OK sind.
Somit müsste gelten:
Beide Datenblöcke incl. korrekter Prüfsummen gleich: Perfekt.
Datenblöcke unterschiedlich, bei einem Prüfsummen korrekt: Geht doch.
Prüfsummen bei beiden Datenblöcken falsch, egal ob Daten gleich oder unterschiedlich: load error.
Anhand der Prüfsummen sollte erkannt werden, ob die Datenblöcke OK sind.
Somit müsste gelten:
Beide Datenblöcke incl. korrekter Prüfsummen gleich: Perfekt.
Datenblöcke unterschiedlich, bei einem Prüfsummen korrekt: Geht doch.
Prüfsummen bei beiden Datenblöcken falsch, egal ob Daten gleich oder unterschiedlich: load error.
Ohne die Laderoutinen im PET zu kennen, wird das wohl so gemacht. Alles andere wäre Unsinn.
Ich glaube aber nicht, dass die beiden Blöcke verglichen werden. Man nimmt einfach den ersten mit korrekter Prüfsumme.
Datensicherheit geht imho immer vor! Nur wenn alle 3 Sicherungsmechanismen nicht angeschlagen haben kommt nach LOAD -> READY, ansonsten LOAD ERROR.
Nein. Das wäre hier nicht im Sinne des Anwenders. Der will mit größtmöglicher Wahrscheinlichkeit sein Programm wieder geladen bekommen.
Für Leute, die auf Datensicherheit so einen großen Wert legen, gab es professionelle und teure Computer. Die arbeiten nicht mit Home-Computern.
Ein Grundprinzip beim Produktmanagement: Nie die Zielgruppe aus den Augen verlieren.
Da hab ich was aus der "Anfangszeit".
Hab eben in alten Elcomp Zeitschriften geblättert und folgendes gefunden:
ist halt abtipp Programm.
Könnte guter Test für das Tapedrive sein.
mfg. Klaus Loy
Könnte auch ein Test für ne OCR sein. Ready für VICE incl. dem _ der dann zum Pfeil-nach-links wird.
10 goto 900
100 print ".tape test"
110 poke 59468,12
120 print:x$="leader":gosub 500
130 x$="data" :gosub 500
140 x$="error":gosub 500
150 input "tape unit";t
160 if t>2 or t<1 goto 150
170 poke 241,t
180 sys(2280):end
500 print "..."
510 print ". ._";x$
520 print "..."
530 return
900 z=2280
910 read x:if x=999 then 100
920 poke z,x:z=z+1
930 goto 910
1000 data 32,59,248,120,166,241,202,240,21,206
1001 data 19,232,169,144,141,78,232,173,64,232
1002 data 142,8,2,41,239,141,64,232,16,11
1003 data 238,17,232,169,52,141,19,232,141,7
1004 data 2,169,80,141,25,2,169,9,141,26
1005 data 2,88,32,30,249,44,19,232,16,248
1006 data 162,2,160,0,169,32,149,56,181,48
1007 data 240,6,148,48,169,160,149,56,202,16
1008 data 239,165,56,141,122,128,165,57,141,242
1009 data 128,165,58,141,106,129,32,54,247,16
1010 data 206,48,204,0,32,92,9,44,64,232
1011 data 44,16,232,76,126,230,174,73,232,173
1012 data 72,232,236,73,232,208,245,160,255,140
1013 data 72,232,140,73,232,224,252,114,8,224
1014 data 255,208,7,201,80,144,11,230,50,96
1015 data 224,254,208,16,201,96,144,12,165,232
1016 data 41,252,240,3,230,48,96,230,232,96
1017 data 169,0,133,232,230,49,96,999
mal blöd zwischenrein gefragt. Wer von den üblichen Verdächtigen wäre an der Veranstaltung dann da? Nürnberg ist von hier nicht sooo weit weg.
hast das jetzt mit OCR eingelesen oder was ? So war das aber nicht gedacht. Das war abtipp Ware damals.
Da würde ich mir keine Gedanken machen, dass ein OCR-Programm das gelesen hat. Jedenfalls nicht ohne erhebliche Nacharbeit.
Also mit dem Space Invaders WAV ist es noch bisle anders. In dem Datenbereich hinter dem Header kommt
1. BASIC (SYS)
2. Maschinencode
3. Schmodder
Und alles drei wird perfekt wiederholt und deswegen funktioniert imho das Laden.
Und in dem Schmodder fallen Textpassagen auf. Kommt jemandem hier das bekannt vor aus irgendeinem anderen Spiel vielleicht?
L SOON BE AN
ADVENTURER GRANDMASTER! ONE RANK AWAY...---RANK 2
TUM TUM-TUM TUM...TUM TE TUM TE DUM DE
TUM...A REAL ADVENTURER GRANDMASTER...
BOY OH BOY! CAN I SHAKE YOUR HAND???
YOU SHOULD:
PLAY AGAIN (Y/N)
NEW IMPROVED VERSION !!
MY SUBMARINE DOCKED IN THE CITY OF ATLANTIS
A CORRIDOR FILLED WITH WATER
Jedenfalls ist durch diesen Schmodder der gesamte Datenbereich so groß dass das Spiel dann über das Ende des 8 KiB RAM hinausgeschrieben wird. Aber da das ja nur unbenutzter Schmodder ist macht das gar nichts aus. Trotzdem könnte man sich mal anschauen was nun genau der Unterschied zwischen der 2001er und 3001 Version des Spiels ist.
hast das jetzt mit OCR eingelesen oder was ? So war das aber nicht gedacht. Das war abtipp Ware damals.
Da würde ich mir keine Gedanken machen, dass ein OCR-Programm das gelesen hat. Jedenfalls nicht ohne erhebliche Nacharbeit.
Exakt. Habs Bild (allerdings in besserer Qualität als hier im Thread) durch die OCR geschickt und dann erheblich nachkorrigiert. War aber spaßiger als es abzutippen. Abtippen ist noch schlimmer als eine Datasette ohne Zählwerk zu benutzen. 
