[Binair] Vanaf Cassetteband weer naar programma

[Richard]

Ik heb dus een *.wav met een programma erop ( 1-en & 0-en)

0 = 3700hz voor 5 milliseconden opgevolgt door 2400hz 2,5 milliseconden
1 = 3700hz voor 2,5 seconden opgevolgt door 2400hz 5 milliseconden

Is er een programma om deze 1-en en 0-en te filteren

Als ik deze lijst met 1-en en 0-en heb, hoe krijg ik die dan weer omgezet naar een hexadecimaal programma (Is dat uberhaupt mogelijk)

Voor diegene die er geen touw aan vast kunnen knopen:

Een kerel heeft een programmaatje geschreven voor een heel erg oude computer, hij heeft dit programmaatje op een cassettebandje geplaatst, alleen hij is de sourcecode kwijt, maar heeft het bandje met het programma nog wel. Hij heeft dit bandje omgezet naar *.wav, hier vanuit wil ik dus die source gaan vissen.

[Sponge]

http://www.nvg.ntnu.no/bbc/software.php3

Daar staat ergens "Read/Write Tapes". Dat is het enige programma, wat ik gezien heb in m'n hele internet tijd . Verder heb ik totaal geen idee over deze programma's, of het source heeft, of niet e.d... weliswaar kun je wel meer van deze programma's vinden.

Zelf heb ik overigens hier geen ervaring mee

[Pogostokje]

Bedenk dat als de samplefrequentie van de WAV niet EXACT overeenkomt met de frequentie van dat bandje met wow & flutter meegerekend je niet goed uitkomt.

In de praktijk denk ik dus dat dit never nooit gaat werken.

[CyberSnooP]

Pogostokje schreef op 30 november 2002 @ 17:33:
Bedenk dat als de samplefrequentie van de WAV niet EXACT overeenkomt met de frequentie van dat bandje met wow & flutter meegerekend je niet goed uitkomt.

In de praktijk denk ik dus dat dit never nooit gaat werken.

In de praktijk heeft het jaren lang gewerkt , alleen makkelijk is 't niet

[Verwijderd]

Grappig probleem dit. Het lijkt me persoonlijk dat dit never lukt. Normaliter heb je source code wat wordt geoptimaliseerd door een compiler en dan wordt gelinked naar een programma.

In dit geval heb je een programma (binair) omgezet naar een .wav file en mogelijk kun je inderdaad de 1 en 0-en er weer uit krijgen en dan heb je dus weer een programma maar dan heb je nog steeds de source code niet terug. Je kunt niet domweg (lijkt mij) van binair naar source code aangezien zo'n compiler en de linker optimalisatie slagen maken in de code. Je zult dus in ieder geval rekening moeten houden dat je een decompiler nodig bent en wel voor dat specifieke platform/taal waarin het programma geschreven is. Denk ik.

[Richard]

Het programma opnieuw schrijven is misschien dus wel sneller dan op deze vrij exotische manier de zooi weer terug zien te halen?

Ik denk dat ik sowieso wel een makkelijkere oplossing heb gevonden. Het gehele programma vanaf tape door een ander in die computer laten laden. En dan in de adresseringen gaan kijken welke hex-getallen erin staan. Als iemand dat dan aan mij doorstuurd, ben ik ook geholpen uiteraard.

[Pogostokje]

CyberSnooP schreef op 30 November 2002 @ 18:13:
[...]
In de praktijk heeft het jaren lang gewerkt , alleen makkelijk is 't niet

Ik weet niet zeker of je mij echt begrijpt, dus ik zal nog een poging doen het iets te verduidelijken.

Natuurlijk, vroeger werkte PC's met tapes en dat werkte goed. Maar je hebt er nu een extra vertaalslag tussen zitten: naar WAV. Als je in dat WAV bestand gaat zoeken naar 1'en en 0'en dan moet een enkele bit natuurlijk wel overeenkomen met een vastgestelde lengte in je WAV file. Anders weet je nooit waar de ene bit begint en waar de andere eindigt. Je weet ook niet of je misschien zelfs compleet gegevens mist. En die methode moet zo goed werken dat een slechte opname geen roet in het eten gooit en ook wow/flutter geen invloed heeft.

Daarnaast heb je nog een ander probleem, wat gedeeltelijk al is aangestipt door Smasr ... de code die op tape staat is waarschijnlijk niet de source van je programma. Als het een gecompileerd programma is dan haal je de source nooit meer terug, maar ook al is het een simpel 'BASIC' programma (wie kent ze niet) dan heb je nog te maken met dat de source niet letterlijk op tape staat. Je hebt niet gezegd om welke computer het gaat, maar bv. de Commodore 64 bewaarde in zijn geheugen en op tape echt niet letterlijke source, elk commando had zijn hexadecimale vertaling en die werd opgeslagen. Dan moet je daar dus ook een vertaallijst van hebben. Dus al zou je de letterlijke waardes kunnen uitlezen uit je WAV bestand dan heb je nog het probleem dat je daarmee niet de source terug hebt.

Ik denk dat ik sowieso wel een makkelijkere oplossing heb gevonden. Het gehele programma vanaf tape door een ander in die computer laten laden. En dan in de adresseringen gaan kijken welke hex-getallen erin staan. Als iemand dat dan aan mij doorstuurd, ben ik ook geholpen uiteraard.

Daar zou ik dus ook nog niet te zeker van zijn, om bovengenoemde redenen.

[ Voor 12% gewijzigd door Pogostokje op 01-12-2002 10:31 ]

[Olaf van der Spek]

Pogostokje schreef op 01 december 2002 @ 10:30:
Als je in dat WAV bestand gaat zoeken naar 1'en en 0'en dan moet een enkele bit natuurlijk wel overeenkomen met een vastgestelde lengte in je WAV file. Anders weet je nooit waar de ene bit begint en waar de andere eindigt. Je weet ook niet of je misschien zelfs compleet gegevens mist. En die methode moet zo goed werken dat een slechte opname geen roet in het eten gooit en ook wow/flutter geen invloed heeft.

Als je per halve ms kijkt wat de frequentie is en dat 'afrond' naar een van de twee bekende frequenties, daarna de lengte van stukken met dezelfde frequentie berekent en twee van die lengtes telkens converteert naar een bit dan is de conversie redelijk robuust.

[CyberSnooP]

OlafvdSpek schreef op 01 december 2002 @ 12:50:
[...]
Als je per halve ms kijkt wat de frequentie is en dat 'afrond' naar een van de twee bekende frequenties, daarna de lengte van stukken met dezelfde frequentie berekent en twee van die lengtes telkens converteert naar een bit dan is de conversie redelijk robuust.

Bedenk wel dat bijvoorbeeld door het langzamer afspelen van de tape je opeens niet meer netjes uitgelijnde tijden hebt. Ik zou daarom iedere keer analyseren op welke sample de overgang zit van de een naar de andere frequentie en vanaf dat punt weer verder gaan lezen.

Verder moet 2,5 ms lang genoeg zijn om daaruit te kunnen onderscheiden of het toontje 3700Hz of 2400Hz is. Wat je uiteindelijk voor gegevens krijgt als je alle bitjes achter elkaar plakt is van latere zorg (al kun je natuurlijk willen voorkomen alle moeite voor niks te doen).

Wat ik als eerste zou gaan onderzoeken is hoe je, gegeven een reeks opeenvolgende samples uit een WAV-file, de gemiddelde frequentie bepaald. Moet te vinden zijn denk ik.

_{Tis wel een leuke en volgens mij haalbare uitdaging, ookal krijg je er de source misschien niet mee terug}

[Richard]

Ik heb net van iemand per mail de source gekregen, vond mijn oplossing wel een leuke uitdaging. maar dis wel wat makkelijker:

code:

0200 A2 EA    LDX SET NO. OF LOOPS FOR 1 SECOND
   2 CA       DEX
   3 A5 60    LDA STORE HOURS IN Fb
   5 85 Fb    STA
   7 A5 61    LDA STORE MIN'S IN FA
   9 85 FA    STA
   b A5 62    LDA STORE SEC'S IN F9
   d 85 F9    STA
   F 86 63    STX SAVE X
  11 84 64    STY (NOT NECESSARY, FILLER)      HR    MIN    SEC
  13 20 1F 1F "SCANDS" (DISPLAY TIME)         1 0    1 0    0 1
  16 A6 63    LDX                              Fb     FA     F9
  18 A4 64    LDY                            (0060) (0061) (0062)
  1A E0 00    CPX TO LOOP (TO 0202)
  1C d0 E4    BNE
  1E F8       SED SET DECIMAL MODE TO AVOID HEX DIGITS             -|
  1F 38       SEC SET CARRY                                         |
  20 A9 00    LDA                                                   |
  22 65 62    ADC ADD A+C+M-->A (0+1+SEC-->ACC.)                    |_ COUNT
  24 85 62    STA STORE IN 62 (SEC) (ACC--> 62)                     |  SECONDS
  26 d8       CLD CLEAR DECIMAL MODE FOR "SCANDS"                   |
  27 C9 60    CMP TO LOOP (TO 0200) (RESETTING LOOP FOR NEW SECOND) |
  29 d0 d5    BNE                                                  -|
  2b F8       SED                                                  -|
  2C 38       SEC SAME AS SECONDS                                   |
  2d A9 00    LDA                                                   |
  2F 85 62    STA RESET SEC TO 00                                   |
  31 65 61    ADC ADD 0+1+MIN-->ACC                                 |_ COUNT
  33 85 61    STA STORE IN 61 (MIN) (ACC-->61)                      |  MINUTES 
  35 d8       CLD                                                   |
  36 C9 60    CMP TO LOOP (TO 0200)                                 |
  38 d0 C6    BNE                                                  -|
  3A F8       SED SAME AS MINUTES                                  -|
  3b 38       SEC                                                   |
  3C A9 00    LDA                                                   |
  3E 85 62    STA RESET SEC TO 00                                   |_ COUNT
  40 85 61    STA RESET MIN TO 00                                   |  HOURS
  42 65 60    ADC ADD 0+1+HRS-->ACC                                 |
  44 85 60    STA                                                   |
  46 d8       CLD                         FOR 24 HR CLOCK           |
  47 C9 13    CMP                           47 C9, 24               |
  49 d0 b5    BNE                           Ab A9, 00              -|
  4b A9 01    LDA WHEN HOURS REACH 13,      4F C9, 00
  4d 85 60    STA RESET HOURS TO 1
  4F C9 01    CMP TO LOOF (TO 0200) 
  51 F0 AD    BEQ
0253 20 5C 18 DISPLAY 0000

[Soultaker]

Ik zie daar alleen maar code om tijd mee te tellen; dat lijkt me geen volledige oplossing.

Hoe kom je trouwens aan dat cassettebandje? Heb je al uitgezocht in hoeverre die casettebandjes een standaardformaat bevatten?

Van mijn MSX-tijd kan ik me herinneren dat je doorgaans externe cassette lezers/schrijvers had en die zullen dan ook wel voor verschillende soorten homecomputers beschikbaar zijn geweest. De kans is dus groot dat je zo'n bandje gewoon op een MSX kan uitlezen en wegschrijven naar een diskette (die dan weer in de PC kan). Dat is een stuk makkelijker en betrouwbaarder.

Op de MSX werd BASIC broncode (waarin veel programma's toen nog - al dan niet gedeeltelijk - geschreven werden; zeker eigengemaakte programma's) gecodeerd weggeschreven. Je krijgt er dan dus geen nette broncode uit, maar een binaire reeks die door (bijvoorbeeld) MSX BASIC automatisch omgezet wordt in 'echte' broncode.

[thomaske]

offtopic:
Sorry, HK-mode (kon het niet laten):
rename het wavje eens naar exe! En dan proberen te runnen!

[Soultaker]

thomaske schreef op 02 december 2002 @ 12:58:
rename het wavje eens naar exe! En dan proberen te runnen!

Erm, niet doen voor je 'm uitgebreid gescanned hebt op virussen! Die oude MSX-virussen worden tegenwoordig niet meer door Norton en McAfee opgepikt, dus als er per ongeluk eentje in zit, dan betekent dat een ramp van wereldformaat!

[ Voor 10% gewijzigd door Soultaker op 02-12-2002 13:05 ]

[Creepy]

Soultaker schreef op 02 december 2002 @ 13:04:
[...]
Erm, niet doen voor je 'm uitgebreid gescanned hebt op virussen! Die oude MSX-virussen worden tegenwoordig niet meer door Norton en McAfee opgepikt, dus als er per ongeluk eentje in zit, dan betekent dat een ramp van wereldformaat!

Volgens mij mist er een smiley?

[.oisyn]

thomaske schreef op 02 december 2002 @ 12:58:

offtopic:
Sorry, HK-mode (kon het niet laten):
rename het wavje eens naar exe! En dan proberen te runnen!

uhm ja, samples komen dus echt niet overeen met echte x86 instructies. Moet jij eens proberen een exe naar .wav om te zetten en dat op een bandje zetten, en vervolgens weer inlezen en weer naar .exe converteren, en dan voor de grap eens erachter komen dat die 2e exe echt totaal verschilt tov de eerste.

Pogostokje schreef op 01 december 2002 @ 10:30:
Natuurlijk, vroeger werkte PC's met tapes en dat werkte goed. Maar je hebt er nu een extra vertaalslag tussen zitten: naar WAV. Als je in dat WAV bestand gaat zoeken naar 1'en en 0'en dan moet een enkele bit natuurlijk wel overeenkomen met een vastgestelde lengte in je WAV file. Anders weet je nooit waar de ene bit begint en waar de andere eindigt. Je weet ook niet of je misschien zelfs compleet gegevens mist. En die methode moet zo goed werken dat een slechte opname geen roet in het eten gooit en ook wow/flutter geen invloed heeft.

Dat is echt geen probleem als je met redelijke kwaliteit wavs werkt. De data op het bandje is gecodeerd dmv frequenties een bepaalde tijd te laten lopen. Zoiets kan behoorlijk wat kwaliteitsverlies ondersteunen. De bandjes van vroeger hielden hun magnetische lading ook niet zo goed vast hoor, dus de kwaliteit ging echt snel achteruit... Toch was het altijd geen probleem om die data in te lezen. Bovendien is het de amplitude die achteruit gaat, het geluid wordt wat zachter en er komt ruis in. De originele frequenties blijven echter, zeker als het zuivere zijn (wat het geval is). Denk eens aan je crappy telefoon lijn die echt enorm veel kwaliteitsverlies heeft, terwijl de centrale ook gewoon de tonen van je toetsen herkent, wat overigens een mix is van 2 verschillende frequenties

Dan zit je echter nog wel met het probleem dat CyberSnooP naar voren brengt, namelijk dat die tapes niet helemaal op dezelfde snelheid worden afgespeeld. Dat is echter geen probleem als je bedenkt dat de golflengte van 2400 Hz meer dan 1.5 keer zo lang is dan 3700 Hz. En hoewel de afspeelsnelheid niet zuiver constant zal zijn, zal het echt geen factor 1.5 schelen

[thomaske]

.oisyn schreef op 02 december 2002 @ 14:15:
uhm ja, samples komen dus echt niet overeen met echte x86 instructies. Moet jij eens proberen een exe naar .wav om te zetten en dat op een bandje zetten, en vervolgens weer inlezen en weer naar .exe converteren, en dan voor de grap eens erachter komen dat die 2e exe echt totaal verschilt tov de eerste.

sorry, het was niet de bedoeling dat het serieus overkwam

[TD-er]

Je zou een programma kunnen schrijven wat het gemiddeld aantal samples berekent, van 1 periode (dus 2 golf) en dat over een aantal golven.
Zoals al eerder is aangegeven, zit er een factor 1:1,5 tussen beide freq's.
Tel bijvoorbeeld het aantal 0-doorgangen.
Om te zien wat ik bedoel, zou je de wave file kunnen openen in een wave editor en dan net genoeg inzoomen, dat je net wel de 2400 Hz kunt onderscheiden en net niet de 3700 Hz.

Dus zo ingewikkeld is het niet om frequenties te kunnen onderscheiden.

[pkouwer]

gewoon interesse: waarom zou je een prog op casette zetten ?

[Richard]

pkouwer schreef op 02 december 2002 @ 15:18:
gewoon interesse: waarom zou je een prog op casette zetten ?

Probeer jij hier dan maareens een Hardeschijf of CD-Brander aan te hangen :



Het apparaat werkt nieteens met een gemodde Cassetteplayer, maar gewoon het ding wat aan je stereo hangt:

Soultaker schreef op 02 december 2002 @ 12:49:
Ik zie daar alleen maar code om tijd mee te tellen; dat lijkt me geen volledige oplossing.

Dat is juist wel de bedoeling, mijn KIM-1 wil ik weleens aan mensen laten showen onder een plexiglazen plaatje. Om dan toch een realtime "presentatie" van deze microcomputer te kunnen geven, is zo'n programmaatje wel erg leuk.

[ Voor 2% gewijzigd door Richard op 02-12-2002 15:33 . Reden: quote-tags stonden verkeerd. ]

[Soultaker]

* Soultaker snapte het even niet meer.

[ Voor 91% gewijzigd door Soultaker op 02-12-2002 19:59 ]