C=Foorumi

Hei,

Minulla on .d64 image (ohjelma, develop-64 assembler) joka lerpulle tallennettuna toimii hieman omituisesti, ja ohjelma itse ei käynnisty.

Tarkemmin tilanne on seuraava. Löysin tuon ohjelma .d64 imagen, ja katsoin sitä Star Commanderilla (v 0.83). Huomiota kiinnitti että kun image on "avattu" ja sen hakemistolistaus näkyy, niin siinä yläreunassa lukee 35 (eli tracks /urat) +err. Tuota +err merkintää en ole nähnyt muiden omien, taikka valmislevykkeistä tehtyjen imagejen tiedoissa.
Kopsasin kokeeksi tiedostot imagelta PC:lle (486 / MS-DOS6.0) ja kokeilin ohjelmaa PC64 emulaattorissa. Se näytti toimivan normaalisti.

Tallensin imagen lerpulle, ja kun C64:lla ja 1541 asemalla ottaa hakemistolistauksen, niin ihmettelin kun pari tiedostonimeä on eri nimet, mitä star commanderilla katsottuna (tiedosto @s.prg oli s    2284.prg, tai jotain sinnepäin) ja lisäksi noiden tiedostojen nimet listauksessa jatkuvat seuraavalle riville!, ikäänkuin nimessä olisi niin paljon merkkejä tai välilyöntejä, että tulisi "rivinvaihto". Tällaista en ole aiemmin nähnyt.

Ohjelma latautuu normaalisti siihen saakka, kun se ilmoittaa ylikirjoittavansa tiettyjen muistipaikkojen sisällön, ja pyytää valitsemaan kahdesta vaihtoehdosta. Riippumatta kumman muistialueen tuohon valitsee, se jatkaa hetken latautumista, ja sitten kone palaa C64:sen aloitusruutuun, ihan kuin olisi näppäilty SYS64738 ??

Mikähän tuossa voisi olla vikana? Ilmeisesti imagella on ohjelma ja kaikki sen tiedostot niinkuin pitääkin, koska se emulaattorissa toimii. Entä mitähän se 35(tracks) +err tarkoittaa? Voisko siinä olla joku kopiosuojaus juttu, mikä on joku tarkoituksellinen levyvirhe?
Kokeilin kahdella eri käyttämättömällä lerpulla, ja myös siten että kopsasin tiedostot star commanderilla imagetiedostosta manuaalisesti yksi kerrallaan lerpulle.
Star commanderissahan on myös disk editori jossa näköjään voi katsella levyn /imagen sisältöä, mutta vaikka sillä voisikin jotain tehdä, niin ei valitettavasti oma osaaminen riitä.
Onko kenelläkään mitään vinkkiä asiaan?

kannatas laittaa varmaan se image jakoon niin sitä vois muutkin tutkia ja analysoida ?

Hei,

Joo, tosiaan. Olisi hienoa jos joku osaisi sille tehdä jotain. Nyt image tässä viestin liitteenä.

Lisäys: Ja se ohjelma käynnistyy, LOAD"D",8,1
Tuo "D.PRG" lataa ohjelman, ja pitää olla tuo 1:nen käskyn lopussa.

Muuten ihan normaali levykuva mutta virhe siellä tosiaan piilee (Track 2, Sector 2: Error 23 - Checksum error in data block). En ole itse puljannut Star Commanderin kanssa joten levylle kirjoittamisen suhteen olen vähän huono auttamaan, onkohan tuossa esimerkiksi sellaista optiota joka kirjoittaisi imagen lerpulle sellaisenaan virheineen päivineen koska jotainhan tuossa matkalla täytyy muuttua jos oikealta levyltä ei enää toimi - joku erroreiden automaattikorjaus kirjoittaessa voi hyvinkin pistää homman kärsälleen jos kopiosuojaus tms yrittää sellaista levyltä hakea.

Lainaus käyttäjältä: romppainen - tammikuu 28, 2018, 09:34
Muuten ihan normaali levykuva mutta virhe siellä tosiaan piilee (Track 2, Sector 2: Error 23 - Checksum error in data block). En ole itse puljannut Star Commanderin kanssa joten levylle kirjoittamisen suhteen olen vähän huono auttamaan, onkohan tuossa esimerkiksi sellaista optiota joka kirjoittaisi imagen lerpulle sellaisenaan virheineen päivineen koska jotainhan tuossa matkalla täytyy muuttua jos oikealta levyltä ei enää toimi - joku erroreiden automaattikorjaus kirjoittaessa voi hyvinkin pistää homman kärsälleen jos kopiosuojaus tms yrittää sellaista levyltä hakea.

Tuossa eri tallennus optioiden kokeilussa voisi olla ideaa.
Kun Star Commanderin alasvetovalikoista aloitetaan copy disk, niin siinä tulee ponnahdus ikkuna, jonka valikoiden optioista kolme (*-merkityt) on näköjään oletuksena, tai ainakin minulla olleet valittuina useamman imagen lerpulle siirrossa. Vaihtoehdot on:

(1-valikko)
Format destination disk
Copy multiple disks with index
Use disk side letters in index
*Auto skip existing files
Check BAM ID against header ID
Show source DIR before copy

(2-valikko)
*Full disk copy
BAM disk copy
Safe BAM disk copy
Manual selection

(3-valikko)
No format conversion
*Commodore disk
Disk image
GCR coded disk image
Diskpacked zipcode
Sixpacked  zipcode

Nuo 3 ja 2-valikoiden valinnat tuntuu järkeviltä, koska Commodore levykettä oltais tekemässä, ja "täysi kopio", mahdollisine tarkoituksellisine virheineen.
Tuon 1-valikon "Auto skip existing files" tarpeellisuutta en oikein ymmärrä, tyhjille levyille kun olen imageja siirtänyt. Kokeilin tätä kyseistä imagea myös ilman että se oli valittuna.
Käsittääkseni tuo "Check BAM ID against header ID" vaikuttaa levyn sisältöön, kannattaisiko kokeilla? Tosin miten kahta eri asiaa voidaan verrata toisiinsa, BAM ID vs. header ID? Ilmeisesti en vain ymmärrä, mitä se itse asiassa tarkoittaa.
Suht hataralla pohjalla olevaa pohdintaa...

tuo on ilmeisesti jonkin sortin suojaus miksi hakemisto on sekaisin
ja tarkoitus kai on ettei sitä näkis lainkaan jos sen korjaa niin loaderi "D" ei löydä fileitä
vastaavasti file copioijat eivät myöskään osaa onkia oikeaa nimeä levyltä

2.2 track on hieman outo koska datana siellä ei ole mitään outoa
BAM näyttää että alue levystä on tyhjää täynnä. tosin trckit eivät ole levyllä ihan
sitä mitä ne tavallisesti ovat siksi epäilenkin jotain kopiosuijaus yritystä

mitä tulee tuohon Assebleriin niin se on aivan kammottava... 8(
no tässä nyt sitten 2.2 track korjattuna testaapa mitä se sanoo...

Lainaus käyttäjältä: virgo - tammikuu 29, 2018, 18:05
tuo on ilmeisesti jonkin sortin suojaus miksi hakemisto on sekaisin
ja tarkoitus kai on ettei sitä näkis lainkaan jos sen korjaa niin loaderi "D" ei löydä fileitä
vastaavasti file copioijat eivät myöskään osaa onkia oikeaa nimeä levyltä

2.2 track on hieman outo koska datana siellä ei ole mitään outoa
BAM näyttää että alue levystä on tyhjää täynnä. tosin trckit eivät ole levyllä ihan
sitä mitä ne tavallisesti ovat siksi epäilenkin jotain kopiosuijaus yritystä

mitä tulee tuohon Assebleriin niin se on aivan kammottava... 8(
no tässä nyt sitten 2.2 track korjattuna testaapa mitä se sanoo...

Hei,

Kiitoksia paljon, kokeilen tänään tallennusta levykkeelle, ensin samoilla Star Commanderin optioilla kuin millä tähänkin asti olen käyttänyt.
Mitä olen netistä lukenut, niin kyllähän tuota assembleria on esim. ööh, kammottavaksi luonnehdittu... mutta on jotkut kehuneetkin.
Sattumalta jokunen vuosi sitten ostin sellaisen kirjan, missä on ohjelmointi harjoituksia ja siinä käytetään tuota assembleria.

ihan järjen säilyttämiseksi tässä huomattavasti parempi Assy
jos tokeneiden kanssa tulee ongelmia niin neuvon mielelläni !
annat vain linkin malli koodiin niin muutan sen Turbo yhteensopivaksi

samalla sivulla käyttöohjeet ja lisää on youtubessa tms.
oikea levy image löytyy sivun oikeasta ylä kulmasta

load"tmp *",8,1
sys4096*8

http://turbo.style64.org/

Hei,

Kokeilin pari kertaa eri tallennus optioilla, mutta valitettavasti se käyttäytyy samoin. Kaatuu latausvaiheesssa sen jälkeen kun on valittu kumman muistialueen ohjelma ylikirjoittaa.

Tallensin samalla tavoin kuin ennenkin, ja sitten "BAM disk copy" asetuksella, ero näytti olevan että se tapahtui nopeammin kuin "full disk copy". Hakemistolistaus näytti C64:lla ja 1541:sellä edelleen samalta. Tämä ei taida tästä kummemmaksi muuttua, mutta kiitos kuitenkin.

Kokeilen jossain vaiheessa tuota ehdottamaasi assembleria, ja minulla on myös Esko Ensio Pipatin Mikroassemblerista joku kolmasosa koodia naputeltuna yhdestä kirjasta.

tuo Track 2.2 on varmasti suojaus koska ohjelma hakee sitä träkkiä ilman että siellä olisi mitään haettavaa...
ja siksi ohjelma luultavasti kaatuu koska virhe ei ole oikean  ?!?

VICEssä se kyllä toimii kunhan laittaa RealDrive ominaisuuden päälle

BAM copio tarkoittaa että ei kopioida koko levyä vaan ne lohkot joissa BAM mukaan on jotain
siksi sen on nopeampi kuin normaali kopio eli se jättää esim. 2.2 trakin kirjoittamatta

kuten edellä kirjoitin hakemistoa ei voi korjata ilman että ohjelma lakkaa toimimasta
toki sen voi hakkeroida mutta siihen en jaksanut lähteä  ei ohjelma ole niin hyvä !

Alkoi kiinnostaa tämä hakkerointi asia.
Luin Inside the commodore DOS kirjasta että nuo errorit oli nimenomaan niitä konsteja millä kopiosuojauksia tehtiin. Kirjassa oli myös listattuna Basic ohjelmia, millä pystyy tekemään eri erroreita levykkeelle. Tein sitten yhdellä ohjelmalla error 23:sen track 2:sen 2 sektorille, ja ohjelma latautuu nyt ja näyttää toimivan normaalisti.

Tosin sellainen epäkohta on, että ihan latautumisen loppuvaiheessa 1541:nen vilkuttaa punaista lediä ja täräyttää lukupään rajoittimeen. Ikään kuin melkein tulisi luku-häiriö ja sitten se hakee sitä 1 sektoria. Tuollaisena en viitsi mitään ohjelmaa käyttää, että joka kerta hakkaa lukupää rajoittimeen. Eikai nuo kopiosuojatut levyt alun perin sellaisia olleet?

Tuli mieleen, että tekikö ohjelma levylle "liian rajun errorin"? Romppaisen havainnon mukaan siellä imagessa on checksum error (23) in data block. Kun sektorilla on sekä data että header block, niin ehkä se ohjelma tuhosi ne molemmat, ja se häiritsee latausta levyltä? Ohjelma ilmoittaa vain ylimalkaan tuhoavansa sektorin.
Jospa katson ensin Star commanderin disk editorissa tuota sektoria, ja sitten vertaan C64:sen levy editori ohjelma di-sectorilla oikean levyn samaa sektoria.

nimenomaan noi asema toimii kun yrittää lukea virheelistä uraa
lukupään  siirto ei mene uralle 1 vaan yrittää hakea uraa 0 johon se ei pääse rajoittimen vuoksi
( tämä toimenpide on täysin normaalia aseman toimintaa eikä aiheuta ongelmia useammankaan kerran jälkeen )
kun uraa ei tämänkään jälkeen pysty lukemaan luku led jää vilkkumaan virheen merkiksi
se että tämä vihje jätetään näkyviin kertoo vain laiskasta ohjelmoinnista

virhe uraa on turha yrittää korjata koska silloin teet ohjelmasta toimimattoman version
ohjelma nimen omaan odottaa aseman ilmoittavan luku yrityksen jälkeen tiettyä virheilmoitusta
levyasemalta ennen kuin se jatkaa. jos sitä ei tule ohjelma  suorittaa resetin

C64 disketti editoritkaan eivät pysty uraa lukemaan enkä ole vielä löytänyt editoria jossa olisi nibleri
ominaisuuta joka siihen luultavasti pystyisi

se mitä Star Commanderi uralle tekee on luultavasti putsaa sen standardi formaattiin tai jättää sen kirjotamatta kokonaan
mitään dataa ura ei sisällä se vain on tehty lukukelvottomaksi

hakkeroinnilla lähinnä tarkoitin tuon Loaderin hackaamista ja file nimien muuttamista jotta hakemiston voisi esittää
normaalissa formaatissa

Hei,

OK, eli se ei olekaan pahaksi että lukupää menee rajoitinta vasten. Jostakin muistan sellaista lukeneeni että sen kohdistus voisi mennä ajan kanssa pieleen, mutta hyvä jos olikin turhaa huolehtimista. Oliko noissa eri ohjelmissa ja peleissä paljonkin tuollaisia kopiosuojauksia?

Star Commander on kyllä aika pätevä ohjelma siinä mielessä, että se automaattisesti korjaa tuollaisen. Lukukelvottomalla kohdalla, missä ei ole dataa, ei tosiaan sitten voi olla mitään toiminnallisuuttakaan.

Käsitin tuon hakkeroinnin väärin. Se olisi varmaan melko vaikeaa, ainakin siinä inside the Commodore DOS kirjassa todettiin niin, ja sitten ratkaisuna esitettiin ne ohjelmat (jotain 10 eri ohjelmaa) joilla pystyy tuottamaan eri erroreita.

Perkelettäkö tällaisten kanssa turhaa saikkaamaan, joskus on ihan tervettä mennä laiskana miehenä siitä mistä aita on matalin: Freezeriä kehiin ja exomizerilla löysät pois, mitään menua en jaksanut ruveta vääntämään joten versiot täytyy vain ladata levyltä erikseen, ei pauku lukupää ja vaikuttaisi toimivan 

Googlasin juuri Freezerin ja Exomizerin, wau. Täytyy kokeilla tuota imagea, kiitoksia!