6 csatornás, sztereó hangkártya TVC-hez SAA1099P-vel.

[Atka72]

Visszakanyarodva az SAA1099-hez:
A meglévő SAA DLL-t nem sikerült sehogy beüzemelni vb alatt, ezért inkább elkezdtem leprogramozni.
A mellékelt demó mutatja a jelenlegi eredményt.
A frekvencia és zaj generátorok, mixerek, amlitúdó szabályzó kész van.
A burkoló görbe előállítása számomra nem volt teljesen világos, még csak nagyjából működik
Sajnos elég hamisak a hangok valamiért, pedig az oktáv váltások jól működnek és a megadott adatokat írtam bele.
Manuálisan is lehet állítani mindent, lehet vele kísérletezni, hogy mi nem stimmel.
Oszcilloszkóp kimeneten lehet ellenőrizni a hullámformát.
Ha a buffer méret/20ms/ nem egész szémú többszöröse hangok hullámhosszának akkor eléggé brummog.Ez volt a gond a TVC hangjával eddig is. Kéne rá valami jó megoldás.

[RetroHW]

Atka72, ez egész jól szól . Még emlékszem mikor az emulátort kezdted írni, és a videó állandóan csíkozott a formban. Csak arra akartam célozni, hogy előbb utóbb biztos lesz rá megoldás . Régen zenéltél is nem? Vagy csak rosszul emlékszem?

Zozosoft köszönöm az infót, még nem ástam bele magam annyira, csak fantáziálgatok. Igyekszem bővíteni az ismereteimet .

[Kiss Károly]

RetroHW: tárt karokkal várjuk a leírást a tvc oldalra kirakható formátumban

[RetroHW]

sprite kezelést meg ami még eszünkbe jut.

Kissé offtopic:
Múltkor néztem, hogy van egy IC ami 32 spriteot kezel, 6 dolcsi körül van. Az MSX2-ben volt használatos.
Lényeg a lényeg, még erre is van emuláció C-ben.
http://mamedev.org/source/src/emu/video/v9938.c.html
Bár ennek a realtime emulációjához kevés lenne szerintem a mikrovezérlő.
Magam részéről biztosan nem használnék FPGA-t a jelenlegi nem túl tartós gyártástechnológia miatt. Ahhoz drága, hogy hamar kinyúvadjon. Akkor inkább a 6 dolcsis 20 éves IC.
Fejlesztésnél viszont biztos hogy jobb az eredeti vas, mert az lehet az etalon. Lehet "mérni". Utána meg lehet csinálni költséghatékonyan, de kell egy viszonyítási pont a finomhangoláshoz. Ha emulációval kezdünk, sosem tudjuk, hogy hol csúszik a dolog az eredeti, jól működőhöz képest.
Ez csak az én személyes véleményem.

[VaszicsApoca]

Ezzel az IC-el csak a sprite "képesség", vagy "plusz monitor" kezelés (színek stb) is megvalósulhatna? Úgy tudom az MSX-ek Z80 alapú, de "szuper" gépek voltak, szinte...

[RetroHW]

Akkor feltehetőleg nem állunk messze a "szuper" géptől, mert a Z80 3,5MHz-en ment az MSX2-ben is, a leírások szerint, minimum 64K rammal. Sajnos nem volt szerencsém ilyen géppel élőben találkozni, főleg programozni. Viszont a Yamaha láthatott valami fantáziát a Texas Instruments(http://en.wikipedia.org/wiki/Texas_Instruments_TMS9918) videóvezérlőjében ha továbbfejlesztette. Ebből lett a V9938(https://en.wikipedia.org/wiki/Yamaha_V9938).
A video chip programozási leírása elég "elmászott" gondolkodásra utal. A színkezelés csak részlegesen változna, mert egy 512 színű palettából 16 színt lehetne megjeleníteni a palettás módban, a fix RGB módban pedig 256 szín jelenhet meg elvileg egyszerre. A kitöltést, vonalhúzást, másolást is hardverből tudja, ez azért elég sok terhet levesz a proci válláról.
Az eredeti TVC-s sprite modulnál mindig mikor megakad a szemem, az jár a fejemben, hogy mi a manó lehet a dobozban? Milyen elgondolás szerint épült?

[PeterGriffin1]

Az eredeti TVC-s sprite modulnál mindig mikor megakad a szemem, az jár a fejemben, hogy mi a manó lehet a dobozban? Milyen elgondolás szerint épült?

Most hogy már a belsejéről is láthatunk képeket, még elgondolkoztatóbb, vajon mégis mit tudhatott?
Annyi sejthető, ha a szabványos bővítőcsatlakozóra lehetett kötni, akkor csak az alap 16 színt használhatta.
Amúgy itt-ott mintha cirill betűk is feltűnnének az IC tokokon. Gyanús, hogy inkább Mo.-on szerelték össze, az angolok csak tervezték.

[RetroHW]

Jé, valóban vannak róla fotók . Összehasonlításképpen, az ATARI 2600 TIA(Television Interface Adapter) két player, két "rakéta" spriteot, két fél playfield-et kezelt+ezeknek az ütközéseit. http://www.atariage.com/2600/archives/schematics_tia/
Ennél egy kicsit bonyolultabb a TIA belső felépítése ránézésre, szerintem ezért sem lett a "mienkből" semmi.

[teki]

A Yamaha V9938 idealisnak tunik videokartya projekthez (MSX video chip):

http://bitsavers.informatik.uni-stuttgart.de/pdf/yamaha/Yamaha_V9938_MSX-Video_Technical_Data_Book_Aug85.pdf

Van belole par ebay-en.
Szinten portokon keresztul kommunikal (mint az audio), sajat video ramja van, igy nem kell a rendszer memoriahoz hozzaferes. (out utasitasokkal lehet masolni vram-ba).
Van kompozit es RGB kimenete.

[Atka72]

A portokon keresztűl írni a videómemóriát? Nem lenne nagyon lassú?
Van itt egy összehasonlító teszt róla.
http://map.grauw.nl/articles/fast_loops.php#unrolling

Miért ne legyünk akkor maximalisták? Ha már videókártyát fejlesztünk hozzá én egy 3D támogatású , OpenGL-t értő kártyát tudnék elképzelni. Nem tudom van e kész ilyesmi, de ha nincs azt lehetne FPGA-ba égetni pl.
Persze a 64KB már nem lenne elég hozzá, úgyhogy pár MB ram belepozását is meg kéne oldani.
Igaz a TVC innentől képességeit tekintve már a videókártya perifériája lenne inkább.
Emulátorban egyébként biztos fogok ilyet csinálni, de hardveresen nem tudom megérné e az erőfeszítést azon kívűl hogy mindenki be... tőle. / tulajdonképpen egyszerűbb egy PC-t kötni a portokra, vagy nem?/
Azt hiszem kéne nyitni egy őrült ötletek topicot is:)

[RetroHW]

Van belole par ebay-en.

Van, de az újabb kiadású V9958 ami teljesen kompatibilis vele, olcsóbb is. Erre írtam, hogy 6 dolcsi körül van.
http://www.ebay.com/itm/1x-NEW-YAMAHA-V9958-V-9958-DIP64-DIP-64-IC-CHIPS-/360651527084?pt=LH_DefaultDomain_0&hash=item53f88193ac
Igazi hajhullás lenne megírni hozzá az alaprutinokat, bár lehet hogy ezt is el lehet érni valahol a neten, mert Z80 alapú gépekben és konzolokban használták.

Igaz a TVC innentől képességeit tekintve már a videókártya perifériája lenne inkább.

Bizony, kicsit elrugaszkodna a dolog a 8-bites világtól . A legelső OpenGL-t támogató lapka nem PCI csatolófelülettel készült?

Remélem hamar megjönnek az AY-jaim, kíváncsi vagyok a hangjukra .

[Atka72]

Érdekes hogy az saasound.dll - ből kivett frekvencia adatokkal is teljesen hamisak a dallamok. Lehet ezért? Ezt az utalást találtam benne:
/Ha jól értem nem mindegy az adatok érkezésének sorrendje de hogy is van ez pontosan?/

// loads the buffered new octave and new offset data into the current registers
   // and sets up the new frequency for this frequency generator (i.e. sets up m_nAdd)
   // - called during Sync, and called when waveform half-cycle completes

   // How the SAA-1099 really treats new data:
   // if only new octave data is present,
   // then set new period based on just the octave data
   // Otherwise, if only new offset data is present,
   // then set new period based on just the offset data
   // Otherwise, if new octave data is present, and new offset data is present,
   // and the offset data was set BEFORE the octave data,
   // then set new period based on both the octave and offset data
   // Else, if the offset data came AFTER the new octave data
   // then set new period based on JUST THE OCTAVE DATA, and continue
   // signalling the offset data as 'new', so it will be acted upon
   // next half-cycle
   //
   // Weird, I know. But that's how it works. Philips even documented as much.

[RetroHW]

Ha csak az oktáv van frissítve, akkor az annak megfelelő periódusidőt állítja be.
Ha az offset akkor meg csak azt.
Ez kb. úgy hangzik, hogy beállítom az oktávot és annak mondjuk a legalsó hangján szólal meg. Ha pedig csak a hangjegyet, akkor mondjuk a legalsó oktáv hangjaként szólal meg.
Mintha a másik regiszter tartalmát randomra állítaná be vagy defaultra.
Szerintem ez így nem logikus.
Az emulációnál ha csak az offset íródik át, újra be kell küldeni az oktáv adatot is. Tehát figyelni kell hogy mikor ír csak az egyikbe meg csak a másikba és ki kell egészíteni az előzőleg beküldött adatokkal, amit aztán újra be kell küldeni.
De ez így elég furán hangzik, mert ha az IC így működne, akkor a programocska ami lejátssza a zenét gondoskodna a hardveres bugról hiszen az eredeti meg megy rendesen.
Ráadásul azt írja, hogy csak akkor kezeli rendesen, ha előbb megy be a hangjegy és utána az oktáv adat, különben a következő ilyen váltásnál a másik hangot fogja ehhez az oktávhoz rendelni és akkor aztán tényleg hamis lesz .
De ha ez igaz, akkor az eredeti hardver ugyanazzal a szoftverrel hogyhogy jól működik?
Van egy tök jó kis leírás, amit félig lefordítottam már magyarra, persze TVC-re átgyúrva, de még nem fejeztem be. Abban is azt írják, hogy a sorrend fontos:
http://velesoft.speccy.cz/samcoupe/saa1099/saa1099-doc5-en.png

[Atka72]

Ez nekem így elég zavaros. Ki tudnád próbálni a kártyán hogy mi az igazság?
Azt kéne tudni mikor módosul a kiadott hang , oktáv vagy frekvencia regiszter íráskor, vagy mikor.
Valamihez hozzá kell biztos rendelni, mert egyszerre nem lehet 2 regisztert írni úgyhogy oktáv váltáskor a hangok midíg ugrálnának. Ebből is látszik hogy még a legegyszerűbb dolgok is bonyolultá válnak ha a dokumentáció hiányos. A kártya nem csak 20 ms-enként tud új hangot kiadni az emu viszont igen és az utoljára beállt regiszterek hangja fog hallatszódni. Valami kezd derengeni...De elvileg a tracker progi is csak 20 ms-enként küld új adatokat nem?

[RetroHW]

Igen, a tracker progi 20ms-onként van meghívva. Ő ilyenkor módosítja a hangokat. És ha lefagy a gép, vagy kilépsz anélkül, hogy kikapcsolnád az IC-t akkor az utolsó hang marad a regiszterekben.
Mindjárt átrágom a datasheeteket újra, hátha valami elkerülte csak a figyelmemet, bár szerintem logikusan úgy nézne ki a működés, ha módosítok bármit oktávot vagy hangot, akkor az oktáv vagy hang módosul.