Větu s odkazy jsem opravil a vypichuji ještě zvlášť.
Sony TC-K461S, něco málo o servisu... (8.7. 2023 15:45)
Soupis spínačů s poznámkami je v bodě [4].
Dokumentaci jsem našel u Maďarů (na stránkách hifiengine.com to chtělo registraci).
Přečtení programu z kazety v moderním PC
Moderátor: Moderátoři
Pracuju na dílně jako učen v OZM na Hostivaři, našel jsem to tam mezi obřím bordelu, při záchraně pár kousků (celého auta až po strop) při úklidu skladu. Takže těžko říct kde to tam sloužilo, jsou tam a byly tam aasi všechny možné streoje co tady koho napadnou. Kazetu jsem zkoušel přehrávat m mono přehrávači Sharp který se používal u Atariho, mám tady totiž jednoho atariho s kompletní výbavou, ale bohužel jenom toho atariho se oživit nepodařilo ten už to má asi za sebou. Zdenka houšku jsem kontaktovat nezkoušel zatím.
judeware píše:Větu s odkazy jsem opravil a vypichuji ještě zvlášť...
To toho moc neříká.
Kdybys tak měl servisní manuál (ke stejným mechanikám mám jeden tady, ale tento model uměl jen kazety IEC-I a IEC-II, takže tam nějaké kontakty chybí), bylo by víc věcí jasných.
Jestli je ten kontakt HALF určený pro kazety s dalším vylamovacím okénkem (na konci vývoje se pokoušeli výrobci například i o automatické rozeznání "dolbyované" kazety, což tady asi nebude, protože by nerozeznal, kterou verzí je záznam dolbyovaný), to zjistíš jen po kompletaci - třeba i do prázdného pouzdra kazety v místě kontaktu vyřízni díru, vraž ji do mechaniky a na displeji by se mělo něco objevit.
Nebo si stáhni manuál. Je v něm i to, kam si máš zavěsit řemínky při montáži panelu s motorky.
TeslaPC píše:V čase 13:13 a 17:56 do toho někdo promluvil.
obchodník konec, logik startPotPalo píše:To čo sa tam hovorí by mohlo naznačovať niečo o obsahu.
gardnerova hra konec
herniarcheolog.blogspot.com /gardnerova hra
/obchodník
/logik
Sháním hasičák s CO2 "sněhový", raději funkční.
(Nemusí mít platnou revizi.)
(Celkově budu raději, když se to obejde bez papírů.)
(Nemusí mít platnou revizi.)
(Celkově budu raději, když se to obejde bez papírů.)
Možno je to blbý nápad, ale podľa tých krátkych blokov a sústavného nosného signálu usudzujem, že by to mohol byť aj pokus o prenos programu cez telefónnu linku, čiže niečo ako prvý modem pre 8-bitový počítač. Počujeme iba jednu stranu, druhá strana zrejme potvrdzovala príjem každého bloku alebo žiadala o opakovanie. Inak si neviem predstaviť prečo by bol signál rozdelený do tak malých kúskov s tak dlhými zavádzačkami medzi nimi.
Je na čase vymeniť primátora Bratislavy, a celú tú neschopnú pakáž okolo.
Tak nevím.
Když se kouknu na ten signál, tak jsou tam dva druhy přechodu z maxima do minima a naopak: rychlý trvající asi půl milisekundy a pomalý trvající asi milisekundu. Ty rychlé přechody jsou vždy v páru. Takže řekněme, že dva rychlé přechody znamenají jedničku a jeden pomalý znamená nulu.
Když si ty bity vypíšeme, tak zjistíme, že v datech je každý devátý bit nulový (drtivou většinou). Takže nejspíš je 0 start-bit a 1 stop-bit.
Když to načteme po bajtech, tak to vypadá asi tahkhle (začal bych to číst v čase 12:10, tam by měl začínat ten Obchodník):
https://uloz.to/file/W41gZHUpNRbt/q-txt#!ZGuvMwR1ZwOyAJIwBJZmZQVjZmqzqTWFGaEXnmqiIycCZwH5
Akorát nevíme, jestli je první LSB nebo MSB. A taky je ty bajty možná nutné negovat (kdyby byl start bit 1 a stop bit 0). Ten nahranej soubor je LSB first a není znegovanej, ale zkoušel jsem všechny 4 kombinace.
Zkoušel jsem v tom hledat nějaké texty, ale nenašel (i když jsem zkoušel všechny 4 kombinace). V tom výpisu je nejdřív čas, pak hexa hodnota, pak znak (ASCII) a pak znak (EBCDIC). Ty znaky se zobrazují jen pro písmena a číslice. A koukal jsem do toho jako blázen, ale žádný text jsem v tom nenašel.
A ani mi to nepřipadá na nějaký strojový kód. Spíš mi to připadá, jakoby každý blok byl jedna řádka v basicu nějak zakódovaná, ale jak? Taky je každý blok jinak dlouhý. Je to záhada.
Když se kouknu na ten signál, tak jsou tam dva druhy přechodu z maxima do minima a naopak: rychlý trvající asi půl milisekundy a pomalý trvající asi milisekundu. Ty rychlé přechody jsou vždy v páru. Takže řekněme, že dva rychlé přechody znamenají jedničku a jeden pomalý znamená nulu.
Když si ty bity vypíšeme, tak zjistíme, že v datech je každý devátý bit nulový (drtivou většinou). Takže nejspíš je 0 start-bit a 1 stop-bit.
Když to načteme po bajtech, tak to vypadá asi tahkhle (začal bych to číst v čase 12:10, tam by měl začínat ten Obchodník):
https://uloz.to/file/W41gZHUpNRbt/q-txt#!ZGuvMwR1ZwOyAJIwBJZmZQVjZmqzqTWFGaEXnmqiIycCZwH5
Akorát nevíme, jestli je první LSB nebo MSB. A taky je ty bajty možná nutné negovat (kdyby byl start bit 1 a stop bit 0). Ten nahranej soubor je LSB first a není znegovanej, ale zkoušel jsem všechny 4 kombinace.
Zkoušel jsem v tom hledat nějaké texty, ale nenašel (i když jsem zkoušel všechny 4 kombinace). V tom výpisu je nejdřív čas, pak hexa hodnota, pak znak (ASCII) a pak znak (EBCDIC). Ty znaky se zobrazují jen pro písmena a číslice. A koukal jsem do toho jako blázen, ale žádný text jsem v tom nenašel.
A ani mi to nepřipadá na nějaký strojový kód. Spíš mi to připadá, jakoby každý blok byl jedna řádka v basicu nějak zakódovaná, ale jak? Taky je každý blok jinak dlouhý. Je to záhada.
Všechno by bylo jasnější, kdyby někdo podle zvuku opravdu jednoznačně poznal, do jakého stroje to patří. Pak by bylo zřejmé, jaký je formát záznamu. Když si odmyslíme prostý přenos bitů (podobný na "všech" strojích), tak další vlastnosti se liší podle značky osmibiťáku (mnohdy i jeho typu). Start bit před oktetem (0/1/není), oktet MSB/LSB napřed, stop bit za oktetem (0/1/není), různé pauzy (ticho), případně sekundy stálého "tónu"... To je kombinací a variant!
Brněnká dokumentace k ROM Sharpa to popisuje docela pěkně.
Kazeťáku se týkají strany 20 až 24.
Zdrojový text programu s Basicu rozhodně nebýval v ASCII formě, jakou člk vidí při výpisu programu příkazem "LIST". Ano, je tam kódování.
Ale opět - počítač od počítače jiné. 
Dva bajty číslo řádku, "token" (basický příkaz jednobajtovým čísem), parametry (mnohdy viditelné jako čitelné ASCII), oddělovací dvojtečka mezi příkazy na řádku a 00 hex na konci. Tak nějak to měl Sharp.
Brněnká dokumentace k ROM Sharpa to popisuje docela pěkně.
Kazeťáku se týkají strany 20 až 24.
Zdrojový text programu s Basicu rozhodně nebýval v ASCII formě, jakou člk vidí při výpisu programu příkazem "LIST". Ano, je tam kódování.
Ale opět - počítač od počítače jiné. Dva bajty číslo řádku, "token" (basický příkaz jednobajtovým čísem), parametry (mnohdy viditelné jako čitelné ASCII), oddělovací dvojtečka mezi příkazy na řádku a 00 hex na konci. Tak nějak to měl Sharp.Nejaký text tam hádam bude aj v ASCII. Zameral by som sa na kód medzery, teda 32. Binárne je to 00100000. Tie nuly a jednička v strede tam nejako budú, to je celkom viditeľné. A keď už nájdeme medzeru, tak okolo nej by malo byť ďalšie zmysluplné písmeno. A tak ďalej...
Je na čase vymeniť primátora Bratislavy, a celú tú neschopnú pakáž okolo.
Aha. Tak když se každý bajt prožene určitou funkcí, tak vznikne čitelný kód (opět bych to četl od 12:10):
https://uloz.to/file/1FT53VUxODy6/q-txt#!ZJAvAmR2ZGV5AGAvAmAuLGt1BGRlBGM5ER9PMRc5K1cYAQOwZj==
Ta funkce má ještě mouchy, asi ji budu muset vyladit.
Zajímavé je, že pole se nemusí dimenzovat.
Nemůže to být IQ-151?
https://uloz.to/file/1FT53VUxODy6/q-txt#!ZJAvAmR2ZGV5AGAvAmAuLGt1BGRlBGM5ER9PMRc5K1cYAQOwZj==
Ta funkce má ještě mouchy, asi ji budu muset vyladit.
Zajímavé je, že pole se nemusí dimenzovat.
Nemůže to být IQ-151?
Je to sice daleko od záchrany a luštění obsahu dat u kazeťáku (náznak detailů jazyků v osmibitových domácích strojích), ale budiž -> pole proměnných (se stejným písmenem, dolněným číselným indexem) implicitně neexistují. Je na to příkaz DIM. Pro zajímavost uvádím odkaz na brožuru MZ-800 owners manual: (.pdf OCR) Potíž je, že osmibiťáci chodí spíš na jiná fóra, někdo z nich by ty zvuky určitě poznal. Co znám já, jsem už dřív vyloučil (a jiní).Zajímavé je, že pole se nemusí dimenzovat.
Super praca. Mozno to fakt bude IQ-151: https://www.sapi.cz/iq151/umrom.php
Tu su nejake ukazky programov a vsetky nazvy premennych maju len jeden znak:
https://www.root.cz/clanky/graficke-moz ... ni-iq-151/
Další zajímavostí je způsob ukládání dat na magnetofonovou pásku. Z důvodu zjednodušení a unifikace výstupu (obrazovka, tiskárna, děrná páska) se data ukládají pouze jako čistý text složený z ASCII znaků a jednotlivé řádky jsou odděleny znaky CR+LF, bez možnosti pojmenovat program (většinou se dával název do prvního řádku programu který obsahoval REM a název) a také bez jakéhokoliv kontrolního součtu. Jednotlivé řádky byly při nahrávání rovnou zpracovávány a přidávány do programu (tak jako by je uživatel psal z klávesnice) což si vynutilo dělat při záznamu pauzy mezi jednotlivými řádky tzv. meziblokové mezery.
Tu su nejake ukazky programov a vsetky nazvy premennych maju len jeden znak:
https://www.root.cz/clanky/graficke-moz ... ni-iq-151/
Dvouznakové, tj. 26² proměnných poskládaných z písmen anglické abecedy (minus rezervovaná slova, jako IF, ON). A např. takový Sharp mohl mít názvy i delší (bez toho, aby se ohlásila "SYNTAX ERROR"), ale jen první dva znaky byly platné. Takže např. VO je totéž, co VOCAS a TE je totéž, co TERMIT.To znamená, že proměnné asi můžou být jen jednoznakové...
Zajímavé čtení (u onoho autora vždy) -> Programovací jazyk BASIC na osmibitových mikropočítačích
http://www.iq151.net/download/Skolni_Mikropocitac_IQ151.pdf:
Jestliže v programu je použita indexovaná proměnná
s maximálně třemi indexy, pro kterou nebylo deklarováno pole
deklarací DIM, provede se automaticky rezervování paměti pro toto
pole, kde maximální hodnoty indexů jsou rovny 10.