Hawker17

10 minuten geleden, dionoid zei:

Hoe heb je Python geinstalleerd? Heb je daarbij de checkbox "Add Python to $PATH" aangevinkt?

Nee, ik wist niet dat dat een vereiste was. Ik ga de boel weer deïnstalleren.

Ik heb net Python succesvol geïnstalleerd. Bij pip install pyserial kreeg ik een foutmelding. Daarna via Appdata naar het script pip verwezen. De boel werd geïnstalleerd. Serial to file py in een map op bureaublad gekopieerd. Helaas na instructies toch weer een foutmelding, zie screenshots. Graag weer even hulp.

Dank je wel mannen voor de snelle hulp. Sukkelig regel 35 op 40 getypt en daardoor de val-instructie vergeten...

@dionoid Helaas krijg ik een fout in data. Ik kan niet ontdekken wat ik fout heb gedaan (T=7432).

2 uur geleden, dionoid zei:

 

Het starten van het Python script doe je inderdaad vanuit een Dos- of Command Prompt. De instructies waren waarschijnlijk niet heel duidelijk voor mensen die nog niet eerder met Python hebben gewerkt, dus ik heb e.e.a. aangepast:

https://github.com/p2000t/software/blob/master/utilities/cassette-dumper/README.md

 

Ik heb heel benieuwd of het dumpen van jouw band 20A wel goed gaat als je het Python script gebruikt. Let wel dat dit Python script ingesteld staat op 9600 baud (dat zie je al je het script opent in bijv. Notepad), dus als je nog SERIAL.BAS gebruikt, dan moet je de 9600 verlagen naar 2400.

 

Laat me maar weten of tape 20A nu wel volledig goed wordt weggeschreven.

Dank je wel voor de verduidelijking. Nog één keer voor de zekerheid; na het het installeren van python en het script hoef je de volgende keer alleen Cassette Dumper te runnen en python serial_to_file.py COM4 ***.cas in te geven?

Ik laat het je nog weten of 20A nu goed gaat.

4 uur geleden, dionoid zei:

De bug zit niet aan de kant van de zender (SERIAL.BAS of Cassette Dumper.cas), dus mijn vermoeden is dat het probleem zit bij de ontvanger (de PC dus) die niet alle ontvangen bytes goed wegschrijft. Waarschijnlijk zijn die bytes blijven hangen in de interne driver buffer, die niet volledig wordt geleegd als je het windows "TYPE" commando gebruikt.

In geval van de 20A.cas dump, zie ik dat het laatste blok niet volledig is weggeschreven naar de dump file. De M2000 emulator ziet dat als fout, maar omdat alle zinvolle bytes van het laatste programma (Alice) gewoon in de dump file staan, zou ie daar eigenlijk niet over moeten klagen. Ik zal die bug fixen in de M2000 emulator.

Het Python script kun je na downloaden ergens in een map bewaren en vanuit daar runnen. Er is geen installatie nodig.

Dat lijkt op een probleem met M2000 specifiek op Windows 32-bits. Ik gebruik zelf Windows 64 bits en daar zie ik dat probleem niet. Ik zal de bug registreren iig.

Die bug is inmiddels opgelost, maar er is nog geen release van. Een tussentijdse workaround is om de shift-knop ingedrukt te houden en pas los te laten nadat je de numerieke-1 ook heb losgelaten. Maar er komt binnenkort een 8.1 versie van M2000 die dit oplost.

Even kijken of ik deze bug kan reproduceren.

Dank voor je uitleg en acties in deze.

Ik begrijp het nog niet helemaal. Bij de instructies staat:

Daarna op je PC een Command Prompt (of terminal window) openen en het Python script serial_to_file.py starten, waarbij je de juiste COM poort en het doel bestand opgeeft, bijv:

python serial_to_file.py COM4 bandje-1A.cas

N.B. dit Python script heeft de library PySerial nodig, die je eenmalig installeert met pip install pyserial.

Serial to file.py run je dus niet via de dos-prompt, maar run je vanuit een map? Library PySerial installeer je toch via een installer op de website? Of moet je die via pip install pyserial via de dos-prompt installeren?

Het is allemaal nieuw voor me, dus dank voor je geduld.

@dionoid Ik merk dat wanneer ik M2000 afsluit met het X-je rechtsboven in het scherm, dat hij in taakbeheer actief blijft. Afsluiten vanuit het menu haalt hem wel netjes weg uit taakbeheer.

@dionoid Overigens nog wat opmerkelijks. Bij het openen van M2000 wordt er een map aangemaakt die ik het laatst heb verplaatst. Daarin wordt de Basic Demo Cassette (zijde a en b) geplaatst. Ik heb hiervan een screenshot gemaakt. De map 112B stond er voor het openen van M2000 nog niet.

14 uur geleden, dionoid zei:

Het origineel heeft dus in totaal 42 blokken, maar de .cas dump van @Hawker17 heeft er maar 40, dus daar zijn gegevens verloren gegaan.

 

@Hawker17: eindigde de Cassette Dumper met een foutmelding? Of gebruik je nog de SERIAL.BAS dumper?

 

Ik heb ook gemerkt dat bij sommige USB-to-serial drivers (bijv. de FTDI driver) het Windows "type" command niet alle ontvangen bytes direct naar een bestand wegschrijft, maar dat pas doet als de buffer vol is. Ik heb een Python script serial_to_file.py gemaakt die wel alle bytes goed opslaat naar file (nu ingesteld op 9600 baud, dus geschikt voor Cassette Dumper. Je kunt de baudrate in het Python script aanpassen naar 2400 baud voor als je nog SERIAL.BAS gebruikt)

Het hele proces van P2000T cassettes dumpen naar .cas bestanden is hier beschreven.

 

Ik gebruikte toen nog de SERIAL.BAS dumper. Heeft Cassette Dumper 2.1 deze bug dan opgelost? Wel jammer dat niemand me nooit eerder op het Python script wees, want ik heb nu zo'n 150 tapes op deze manier gedumpt. Het punt is dat bij een volle tape, ik vrijwel altijd een cassette fout E krijg. Op de tape zelf krijg ik deze melding niet. Een goed voorbeeld is 20a.cas met daarop Snorkel en Alice in Wonderland. Alice kun je niet laden via 20a.cas vanwege de cassette-fout. Echter, met splitape kun je het bestand wel weer prima inladen. Er gaat inderdaad e.e.a. mis.

Ik ga sowieso jouw nieuwe dumper gebruiken nu. Moet je het python script eenmaal via de dos-prompt installeren of moet je dat elke keer doen wanneer je gaat dumpen?

Ik kijk later wel of er op de eerste 150 tapes nog wat interessante zaken stonden op de laatste blokken, dan ga ik die nog wel eens apart dumpen op de juiste manier.

Verder bemerk ik regelmatig dat bij het verplaatsen van cas-bestanden ik de melding krijg dat het bestand nog in gebruik is. M2000 heb ik dan al afgesloten. Nu blijkt in taakbeheer dat M2000 soms 3x actief is, terwijl ik het slechts 1x opgestart heb. Heb jij hier een idee over? (Versie 0.8, 32-bit). Ook het probleem met de repeterende 1-en komt telkens terug (na rechtershift 1).

20A.cas

Dank voor de tip m.b.t. 102 model. Volgens mij is dit best een leuke versie. Zo heb ik nog wel meer software met bepaalde (typ)fouten. Ik zal die t.z.t. verzamelen voor de software knutselaar.

Kom net "Cursus morse opnemen" tegen. Bewaren we dat ook of trekken we ergens een grens?

107a.cas

Nice @blanka!

Gelijk een vraag aan je. Ik kom net Fruitautomaat tegen, met een bestandsgrootte vele malen groter dan dan de andere Jackpot-versies.

Ik krijg alleen een Out of Memory melding. Heb jij nog een idee om dit te fixen?

Fruitautomaat.cas

klopjacht.cas

13 uur geleden, dionoid zei:

 

Keep 'm coming

Ik vond Alggrot nog best leuk om te spelen.

Inderdaad, hoe creatief mensen nog waren met beperkte mogelijkheden. Vanaf nu plaats ik bij elk cas-bestand ook een screenshot. Zo kan ik makkelijker nagaan of ik daadwerkelijk nieuwe software heb. Dat ga ik dus ook doen bij de reeds bestaande reeks van software op Github. Of heb je daar toevallig al screenshots van?

tank.cas

alggrot.cas

Al aardig wat pacman-clones tegengekomen, maar deze is best ok. Pacman with a twist.

pacman.cas

Dat bedoelde ik dus ivm privacy. Aan de andere kant, ik zou het juist leuk vinden als mijn software weer boven water kwam.

Inderdaad, dit is de Ralph van het boek. Deze game had ik vroeger ook en ben hem slechts 1x tegengekomen op nu 150 tapes.

Triffids in L.A. (31B).cas

Grappig, die snackbar was ik ook al tegengekomen. Apart dat die administratie dus op minimaal 2 verschillende tapes heeft gestaan. Ook de bekende mooie games hebben vaak namen en adressen in de rem regels staan. Blijft lastig. Bij twijfel overleggen we wel even.

12 uur geleden, dionoid zei:

 

Helemaal mee eens dat software redden prio heeft, want misschien zijn die bandjes over 5 jaar totaal onleesbaar geworden.

Cassette Dumper geeft nu ook meer informatie over wat ie precies doet en de voortgang daarvan. 

 

Leuk weetje: Ik heb ook een "proof of concept" versie van Cassette Dumper die bytes met een baud rate van 38400 over de seriële poort van de P2000T verstuurt. Dat is dus 32 keer sneller dan de standaard ingestelde 1200 baud "seinsnelheid" van de P2000T

 

Ik ben benieuwd, als ik even tijd heb ga ik het programma intikken. Die snelheidswinst is al geweldig.

Even een praktische vraag. Waar stellen we de grens met dumpen qua privacy? Ik heb namelijk flink wat software gevonden uit privé-collecties die nooit openbaar zijn gemaakt, zowel games als utilities, tot gehele jaaradministraties aan toe.

Aan de andere kant, ik zelf zou het leuk vinden als iemand MIJN software terug zou vinden. Heb in de jaren 1984-1986 aardig wat geschreven, maar helaas alles toen voor een habbekrats verkocht. Mijn vader werkte altijd bij Philips en zo zaten wij altijd dicht bij het vuur. De P2000 ging er op het laatst nieuw uit voor 100 gulden. Had ik er toen maar wat meer gekocht. Ik had er zelfs 2 splinternieuwe cassetterecorders bij voor het geval er 1 zou sneuvelen. Dit is echter nooit gebeurd. Daarna ben ik software gaan schrijven voor de MSX op de VG8010 en VG8020.

Het verbaast me trouwens dat de meeste tapes na ruim 40 jaar nog steeds (prima) leesbaar zijn. Een enkeling zit vast, of is gebroken. Vroeger had ik met normale cassettebandjes al dat ze na een jaar of 10 aanzienlijk slechter werden.

Dank @dionoid. Ik ga Cassettedumper eerst maar even ouderwets overtypen. Leuk dat hij ook controleert op typefouten in de data. Even prioriteiten stellen qua software redden. Later ga ik me eens goed verdiepen in het overzetten van PC files naar de P2000.

Dank voor je werk Dion. Ik moet me er even in gaan verdiepen hoe ik files van de pc naar de P2000 ga krijgen, voordat ik Cassette Dumper kan gebruiken.

Helder, dank voor de uitleg jongens. Ben je ook geïnteresseerd in software die op scholen werd gebruikt en probeersels van games? Heb namelijk verscheidene pacman (met karakters) en snake versies gevonden. 

Zou het wellicht mogelijk zijn om ook een versie uit te brengen die niet eerst de tape terugspoelt? Dus dat je zelf de positie kunt bepalen van waar je gaat dumpen? Bijvoorbeeld na leesfouten aan het begin. Dan kan je met poke&h60ac,1 door de leesfouten heen wurmen. Normaliter stopt het dumpen bij de leesfout, terwijl er nog andere software op de tape staat.

19 uur geleden, dionoid zei:

 

Wat mij betreft blijft .cas gewoon de standaard. Dat formaat is inmiddels relatief wijd verspreid en converteren tussen .cas en .p2000t dumps is heel eenvoudig. Helaas bevat het .cas formaat onnodige bytes in iedere blok-header; dat is een erfenis die we hebben meegekregen.

 

Ik neem aan dat hij dat wel wist, want in de cassette-routines van M2000 leest en schrijft hij precies de juiste 32 bytes naar adres &H6030; de andere 224 bytes worden genegeerd. Ik heb sinds kort contact met Marcel, dus ik zal hem eens vragen of hij zich nog herinnert waarom de dumps te veel bytes voor de header gebruikten.

 

Momenteel ben ik een nieuwe versie van de SERIAL.BAS dump-utility aan het testen, die met 9600 bps verstuurt i.p.v. 2400 bps. Daarmee wordt het dumpen van een tweezijdige cassette bijna 5,5 minuut (328 seconden) sneller.

Rekensom: voor twee zijden van een cassette worden in het .cas formaat maximaal 2 * 41 (blokken) * 1280 (256+1024) bytes = 104.960 bytes verzonden. Dat zijn 1.049.600 bits (want RS-232 stuurt 1 start bit, 8 data bits en 1 stop bit). Met 2400 bps kost dat 437 seconden, maar met 9600 bps slechts 109 seconden. De tijdsbesparing is dus 437-109 = 328 seconden per volle cassette.

Goed nieuws zeg, dat scheelt aanzienlijk qua tijd. Nu duurt een volledige tape dumpen tussen de 10 en 11 minuten. Zou 9600 baud niet voor meer leesfouten kunnen zorgen? Ik heb nu al regelmatig dat bepaalde files worden overgeslagen of verkeerd worden ingelezen. Vaak is daar de tape de schuld van (zwaar lopen of verpulverd) of een vieze kop. Met die oude tapes is het wel zaak regelmatig de kop even te reinigen met wat alcohol.

20 uur geleden, blanka zei:

Ik denk dat Marcel de Kogel niet wist welk deel precies de header was in het geheugen. Maar het is inmiddels wel duidelijk, er is veel over geschreven in de nieuwsbrieven, erbij gekliederd in de gescande handleiding die online staat, en programma's als Cassettehulp zie je het ook zoals het bedacht is: de tapeheader staat in het geheugen op adres 6030-604F, waarbij de laatste byte de lengte in blokken aangeeft, en aftelt per blok.

De originele dumptool van M2000 sloeg 6000-60FF op als header, en daar zit bijvoorbeeld de inhoud van de toetsbuffer bij. Dus .cas bestanden bevatten allerlei random data die op het moment van dumpen in het RAM geheugen stond.

Ik ben zelf dus voorstander om met de kennis van nu dat op te slaan wat ook echt op de tape staat. Overigens heb ik een hulpje dat de inhoud weergeeft, waarmee je met een druk op de knop .cas danwel .p2000t kunt opslaan, evenals de losse files, en de data van RS232 kunt inlezen/versturen. Ik bouw nog even de RS232 functie om naar de laatste ontvangtool van @dionoid en dan zet ik m ook wel online.

Ik ben ook wel benieuwd, misschien kan @dionoid dat zien in de originele M2000 code, of de 256 bytes ook allemaal worden teruggezet. Dat zou dan rare fratsen kunnen opleveren in de emulator, zoals een opgeslagen toestand van de caps-lock.

Dank je. Dan wacht ik even op die tool voordat ik nog veel meer werk steek in het dumpen. Overigens heb ik verdacht veel Cassette Fout E-meldingen bij het dumpen van een bijna volle tape. Zou dat te maken kunnen hebben met die 1056 vs 1280 bytes en dat hij dan denkt dat de tape vol is? Op de originele tape krijg ik die Cassette Fout E namelijk niet.

Na splitape zijn alle bestanden overigens prima leesbaar.