Most néztem az LPT-t, elméletileg 100 raszter sorra mehet a VINT bit, 48 a volume kijelző alatt az Enterprise feliratig, és 52 a reload bitig, mivel nem akarunk interruptot, csak a figyelni a VINT beállítást, így pakolhatunk egymás utáni LPB-kbe VINT bitet, működnie kell, nem?

Nem probléma, ha több egymást követő LPB-ben van beállítva a VINT bit, az is folyamatosnak számít, a NICK egyébként is minden sorban újraolvassa. A pozíció és hosszúság választásánál fontos, hogy ne villoghasson a raszter. A VINT lefutó élét egyszerűbb figyelni, akkor törölhető a CPL utasítás.

Viszont ezzel a megoldással bonyolultabb, legalábbis annak érzem, a két ciklusvaltozo szamolasi értéke, mert mind a kettőnek változnia kell különböző vezerlesi frekvenciaknal, hogy a lehető legpontosabbak legyünk.

Ez eddig is így lett volna, de most rosszabb a pontosság vagy nagyobb tartományban kell keresni. Például:

12500, 50 Hz: 12500 / 50 / 5 = 250 / 5 = 50
12500, 60 Hz: 12500 / 52 / 4 = 240.4 / 4 = 60.1
11905, 100 Hz: 11905 / 60 / 2 = 198.4 / 2 = 99.2
11364, 150 Hz: 11364 / 40 / 2 = 284.1 / 2 = 142
11364, 200 Hz: 11364 / 57 / 1 = 199.4 / 1 = 199.4

A raszter megjelenítésén is lehetne módosítani, mivel annak a villogása okoz problémát, a teljes háttér mentése és visszaállítása helyett például csak egy vagy két sorban (előtte/utána az iránytól függően) visszaállítani az eredeti háttérszínt, amit lehetne fixen az egyik nem használt paletta színben is tárolni. Ez rövidebb ideig fut és kevésbé villog ha nem jó az időzítés.

A kivezérlésjelzőnél már említettem az egy LPB-s megoldást, ez ugyan nem sok időt takarít meg, de jobb a semminél.

Nagyon jó ötlet az előtte/mögötte szín visszaallitas, meg is csinálom majd holnap, ma sörözős, zsibbados nap van
A kivezerlo egy LPB-s megvalósítását megnézem, már nem emlékszem pontosan miért csináltam külön LPB-sre, lehet helysporolas miatt, de az új megoldással az LPT-n is lehet spórolni, úgyhogy sztem menni fog.
Az 5,4,2,2,1 szimpi, vagy megnézem mi sül ki a 4,4,2,2,1-gyel kerekitessel.

Van egy kis gond, előre tettem a videó rutint (gyorsított mindennel), és még így is fagy 12,5KHz-en a Last Ninja 2 12-es számában, előbb jön egy hangvezérlés "megszakítás", és mikor már jól televágta a vermet az adatokkal, és elkezdi feldolgozni, jön egy videó "megszakítás", és ez már rossz helyre tér vissza. Vygy  a lapozás okozza a gondot, vagy a verem, mára elfáradtam, szerintem majd holnap nézegetem még.
Mit szólsz a gagyi megoldásomhoz?
Frekvenciának megfelelően beállítja a második ciklus értékét, majd ez az érték x (Dave osztó+1) x vezérlési frekvencia = az osztó
500000 / osztó / 2 , ha van carry, akkor felfelé kerekítés adja meg az első ciklus értékét.

Szerk.:
A lapozással van gond, lehet a vezérlő rutin elején ki kéne kapcsolni a visszalapozást, és a végén meg bekapcsolni?

Szerk. 2:
Hú de nehezen jöttem rá a megoldásra, az aktuális 2. lapot el kell menteni a verembe , probléma megoldva, csatoltam a forrást is, még a vezérlési sebességektől függő beállításokat módosítani kell a gagyi beállításomhoz is, pláne ha beépül a freqdiv.s.

Csatolmányok törölve.

Talán célszerűbb lenne először a vezérlést futtatni, akkor a video megszakítás nem zavarja a lejátszás időzítését, bár nem tudom, ez hallható különbséget jelent-e. A lenti módosítás ezt próbálja megoldani, de nem támogatja a második osztás és kijelzés nélküli speciális esetet. Viszont csak 50 Hz-es frekvencián figyeli a billentyűzetet, és a vezérlésen gyorsít egy keveset.

Igen ,erre gondoltam én is, csak attól tartottam ,hogy akkor meg villog, mert a vezérlés a leghosszabb, bár a VINT bites range mozgatásával ez is orvosolható, mert nagyjából konstans hosszú a vezérlés

Elvileg a 3. lap is problémát okozhatna, de ilyen eset az időzítés miatt talán nem fordulhat elő.

Igen, ilyen még nem fordult elő, ezért nem bolygattam

Ennek az az előnye lenne, hogy tetszőleges frekvencián futhatna, és nem csak 50 Hz többszörösein fix osztókkal.

Miután említetted a tetszőleges frekvenciát a ciklusos megoldásnál, jutott eszembe, hogy ezt így is meg lehetne csinálni, nem tudom gyakorlatban mekkora jelentősége van, van-e olyan SID, ami extrém vezérlési frekvenciát használ, annyi, hogy a turbós gépekre még nincs kész a ciklus érték módosítás, azon még egylőre csak gondolkoztam, a legpontosabb talán az lenne, ha az 500000-es osztót szoroznánk fel a sebesség függvényében, és utána osztani, és a kapott értéknek függvényében beállítani a két ciklusváltozót, a legegyszerűbb meg a kapott ciklusáltozókkal játszani a gép sebességétől függően.

Ezeket a változtatásokat nem tudtam tesztelni, mert hiányzik a kép:

Bocs, nem szeretem annyira az INCLUDE-ot, meg INCBIN-t használni, mert mindig megfeledkezem a fájlokról, most pótlom.

A VINT hosszúságát szerintem nem érdemes 156 sornál nagyobbra állítani, a figyelésénél a 0 és az 1 állapot is fontos, 50% kitöltési tényezőnél lehet a legritkábban tesztelni megszakítás elvesztése nélkül.

Ha kevés a hely a veremben, akkor a jelenleg 75h címen kezdődő kód kerülhetne az IRQ rutin elé is, az EXOS terület már egyébként is felülíródik.

Jogos, én csak azt tartottam szem előtt, hogy képen való ténykedés véletlenül se történjen, amikor épp azon jár az elektronsugár, amúgy a ciklusváltozóink miatt a jelenlegi beállítás mellett se volt bukta
Egyelőre nem volt gond a verem mérettel, mindig a lapozás okozta galiba miatt írta túl azt is, most kb 110 byte van szabadon a veremre.

A freqdiv.s egyszerűen minden lehetséges osztóval próbálkozik egy bizonyos tartományban, és azt használja, amelyikkel a legpontosabb a frekvencia  (egyenlő pontosságnál pedig azt, amelyikkel az első osztó nagyobb). Ez kissé pazarló megoldás, bár a 40 és 62 közötti kereséssel 22-25 ms a futásideje (156 soros VINT esetén nagyobb értékek is lehetnének). Esetleg kereshetne a második osztó alapján, annak kisebb a használható tartománya, 1-10 elég lenne turbós gépeken is.

Jó ötlet, nekem tegnap az jutott eszembe, amikor megláttam a freqdiv.s-t, hogy adhatná a második osztót, és az alapján már külön lenne számítva az első a 150 Hz pontatlansága miatt.

Újabb próbálkozás:
[ Guests cannot view attachments ]     (szerk.: javítottam az LPT hibákat)

Nagyon jól hangzik, egyelőre még csak letöltöttem, remélem holnap lesz időm egy picit foglalkozni vele, no meg az LPT hibák javítását is , kíváncsi vagyok mit szúrtam el

Az LPT-t valójában részben én rontottam el, de a státuszsor korábban is hibás volt (margók).

Kisebb optimalizálás az előző változathoz képest, de kevesebb szabad hely marad a vermben (-5 byte):
[ Guests cannot view attachments ]

A kicsomagolásra várakozás hibás volt, ezt javítottam, néhány további (minimális) optimalizálás mellett.
[ Guests cannot view attachments ]