a 8x8-s táblázattal rontunk a felbontáson, ami a rendes osztással majdnem 15 bit, a táblázattal meg csak 8 lenne, nem?

Elvileg ugyanaz az eredmény ha nem hibás a kód, még a kerekítés is (itt a DE a bemenet és a HL a kimenet, talán jobban is lehetne optimalizálni):

Viszont ha fel tudunk menni 12KHz-re, mi legyen a maximum sebesség turbós gépen? 48KHz ? (ha Zozón múlik lesz 16 MHz-es EP is )

Magasabb mintavételezési frekvenciánál rosszabb a frekvencia konverzió pontossága, de nem tudom, ez a gyakorlatban mennyire jelent problémát a 48 kHz egyébként jobb minőségéhez képest. Ilyenkor a zaj frekvenciája 8.36 bites lenne, a többi hullámformánál pedig 12.36 bites.

A hangerő byte konvertáló táblázata még hatékonyabb lehetne így:
- négyszögjelnél hangerő * 4 + 1
- egyéb hullámformáknál hangminta táblázat kezdőcíme / 128

Ezzel a megoldással ebből a rutinból:

ez maradna (tulajdonképpen lehetne inline is, mert csak néhány utasítás):

Szerk.: ez azonban nem működik a 8 bites DAC használatakor. Ilyenkor lehetne a táblázatban 8-szoros hangerő + 1, és utána még egy ADD A,A csak négszögjelnél, aminek a helyére 6 bites D/A esetén NOP kerül.

Szerk. 2: a PWM (B regiszter) elvesztése javítva.

Szerk. 3: egy csatorna vezérlése módosítva:

az eredeti kód:

Itt a négyszögjel hangereje mindig nyolcszoros (+1), csak a léptetés iránya változik a DAC felbontásától függően. Kis mértékben rövidült a letiltott megszakítás időtartama is.

Valamit említettél a PWM-re is, hogy invertálva lenne az igazi?

Igen, valójában ez lenne pontos:
de nem tudom, hogyan lehetne ezt helyesen megoldani lassulás nélkül, ezért talán nem érné meg, mivel az invertált PWM egyébként nem sokat változtat a hangon.

Elméletileg a leírt módosítások készen bekerültek még csak 10KHz-es lejátszással, valami nem stimmel, nem szól olyan jól, mint a régi, lehet elszúrtam valamit a táblakreálásnál, ma megnézem, és ha pont úgy szól, mint a régi, akkor emelek a digi lejátszás sebességén.

A táblázatok tartalma 10 kHz-es mintavételezési frekvenciánál:

freqMultTable[n] = (n * 197) & 255
freqMultTable[n + 256] = (n * 197) / 256
volumeConvTable[n] = (n & 31) * 8 + 1    - ha négyszögjel vagy 0 hangerő
volumeConvTable[n] = ((triangleTables / 256) + (n & 31) - 1) * 2    - háromszögjel
volumeConvTable[n] = ((sawtoothTables / 256) + (n & 31) - 1) * 2    - fűrészjel
volumeConvTable[n] = ((noiseTables / 256) + (n & 31) - 1) * 2    - zaj

Eljutottam én is a sebességállításhoz, a hangzásbeli különbséget az okozta, hogy a négyszögjel hangerőtábláját csak 4x+1-gyel generáltam, nem 8x+1-gyel.
11904 Hz-en az 50Hz-es SID-ek stabilan működnek, a 150Hz-es Paperboy is jó, a 200Hz-es HVSC fagyizik
11363 Hz-en minden működik, a HVSC-nél előfordul, hogy a kicsomagolás után kevesebb, mint egy másodperc a várakozási rész.
Melyik legyen a végső beállítás 11363, vagy 10870 Hz?

A 10870 megbízhatóbbnak tűnik, és az is jobb az eddigi 10000-nél. Esetleg 11364 csak 50 Hz-es file esetén, de az tovább bonyolítaná a sebesség beállítását. Vagy ha lehetne még gyorsítani a megszakítás kezelésen. Ha a kicsomagoló rutin nem használná az IX regisztert sem, akkor azzal 10 ciklus/hangminta lenne megtakarítható video megszakítás nélkül az IX-et számlálónak használva. De így a kivezérlésjelző és a raszter megjelenítésével probléma lehetne (villogás), mert a frissítésük "véletlenszerű" LPB-nél történne fix pozíció helyett.

Igen, pláne gyorsabb vezérlésű SID esetén, mint a HVSC, én az eslő megoldásra szavaznék, a másodiknál tényleg jelentős gyorsulást okozna hangmintánként 10 ciklus, a kijelző zavar egyelőre.

a másodiknál tényleg jelentős gyorsulást okozna hangmintánként 10 ciklus, a kijelző zavar egyelőre.

Egyéb lehetőségek gyorsításra:
- video megszakítás figyelése a főprogramban, -25 ciklus, de nem egyszerű megoldani, különösen mivel a DAVE megszakítás tárolói nem használhatók az adott megszakítás tiltásakor (Plus/4-en ilyenkor is olvashatók)
- a már említett IX regiszter nélküli (valamivel lassabb) kicsomagoló rutin, a hangminta lejátszásnál a DE' cseréje IX-re (+4 ciklus), viszont a DE'-t fix 8013h értékre állítva gyorsabb gyűrűmoduláció (-9 ciklus) és megszakítás törlés (-3 ciklus). Így a video megszakítás kezelése nem változik, de csak 8 ciklus a gyorsulás és bonyolultabb a gyűrűmoduláció vezérlése

Már értem a problémát, ha nem tiltjuk a videó megszakítást, akkor a videó megszakítás törlésével lesznek gondjaink, ha töröljük minden Dave megszakításban, akkor nem jut a program az 50Hz-es vezérléshez, ha nem töröljük ,akkor végtelen ciklusba kerül a Dave megszakítás ha videó megszakítás alatt kerültünk oda , és a másik probléma, hogy minden di-vel , és ei-vel az 50Hz-es csekkolást is ki/be kell kapcsolni (ez a kisebbik probléma, szinte nem is az )
Én azt hittem, hogy kikapcsolt videó megszakítás mellett legalább az interrupt byte elérését az LPT-ben jelzi a 0b4h port.

Jelzi, de csak a 4. bit. Így nehezebb megoldani, mert a bit változását kell figyelni, és az LPT-nél is fontos hogy a VINT bit elég hosszú ideig legyen 0 és 1 is ahhoz, hogy ne vesszen el megszakítás.

Na erre emlékeztem én is, de most a teszt alatt valahogy sose volt a 4. bit beállított. Betettem a figyelést a kicsomagoló rutinba két helyre: a Read8bit.L1-re, és a readencodedvalue-ba, és a várakozásba a halt után. Azt nem néztem, milyen hosszú a VINT-es LPB.