Lehet, kb annyi lenne az értelme, mint a Speccysnek
Legegyszerűbb sztem Basicben lenne, amit írtál is, vagy más magas szintű nyelven megírni.

nem a c010h hivasa boritja fel az lpt-t joval a 3. hivas utan jon az lpt allitas, belapozza a page2-re FD-t, es atallitja C4-re a 83-as portot, ez pozicionalja rossz helyre az LPT-t, es maga a C program. Igen, ezert nem szeretem en se a C programokat, vagy egyeb mas nyelven irt programokat debuggolni, mert nehez rajonni epp hol is jar, mit csinal. A klikk azert olyan lassu, mert az "LPT" jelen esetben egy tobb ezer soros kepet definial, egeszen addig tart, amig eljut a megfelelo pozicioban egy olyan byte-ig, amiben a reload bit be van allitva. Azt nezd meg, hogy a C forrasodban allitod-e direektben a 82-83 portokat, ha nem, akkor melyik fuggveny teszi ezt a meghivottak kozul.

ugyanezt hasznaltam en is , es egy ures 32K-s ramdisket hoztam letre, es addig neztem, mig a 0c010h-bol vissza nem ter. mekkora ramdisket hoztal letre?

Ha van RAM Drive-od, akkor nem kéne, nálam nem volt, akkor arra várt, amikor csináltam egyet, akkor tovább ment, csak az első lekérdezésig teszteltem.

van egy jo hirem, meg egy rossz, nem fagy a program, olyan meghajtot kerdez le, amiben nincs lemez, Retry or abortra var nalam, es hiaba teszek be a b-be is image-et, marad a hiba.

szerintem az a baj, hogy a hulye C miatt nagyon alacsonyan van mar az sp (00bf)-en, amikor az exdos meghivodik, de nezem tovabb.

ilyen konfigot meg nem lattam, sf3 kartyad van?

lehet tobb szinu a sprite, mondjuk a lab itt is lehet kek, az sokat nem lassit szinte semmit, sajnos az ilye trukkoktol mi elesunk, c64-en is igy csinaltak tobb szinu nagy felbontasu sprite-t, abban a programban, amit en kezdtem el, ott tobb szinu kis felbontasu sprite-ot csinalnak igy.