A file-bõvítés használata talán szimpatikusabb lenne. (?)Mire gondoltál a file-bővítésnél?
Most már határozottan értékelhetõ hangok jönnek ki a gépbõl! :smt038 (Bár a Last Ninjára kicsit nehéz ráismerni... :oops:)
Hú, ez tök jó. Nekem különösen, aki marha jól ismerem a legtöbb sid zenét.Köfi :), az envelope-okat kell még javítani, ott van bibber, csak az envelope (50Hz-es megszakítással, azt megnézem még, hogy mire lehet felmenni megszakításügyileg), zaj (ott is egyszerre csak egy csatorna szólhat), és a generátor hangfrekvenciája van átvíve (István adta az ötletet a 8 kb-os táblához, ez nagyot lendített a hangok pontosságán), és a control bit csekkolása.
Szerintem nagyon jól sikerült szimulálni, vagyik átvinni amit lehet paramétert.
Mire gondoltál a file-bõvítésnél?Szerintem erre:
Szerintem erre:
Ezt nem is imerem, de az EP128.hu-n se találom, tuti én vagyok a béna. Ez a megadott helyrõl csinál egy file-listát, és onnan lehet kiválasztani a megfelelõ file-t?Itt a legutóbbi verzió. (http://enterpriseforever.com/programozas/epdos_fejlesztese-t50.0.html;msg13094#msg13094)
A letöltéseknél található Boulder Dash átiratom forráskódjában van .com file-ba beépíthető változat is (file.s), így olyan gépen is használható, amelyen nincs FILE bővítés. A bouldash.s-ben a chooseLevelFile rutinban található példa az ilyen beépített FILE használatára.Köszi szépen, ez így már szimpibb, a másik megoldás nem tetszett, be kellett volna tölteni mindig a bővítést, ha épp nincs betöltve.
A file-bõvítés használata talán szimpatikusabb lenne. (?)A mostani megoldásban mi nem szimpi?
Most már határozottan értékelhetõ hangok jönnek ki a gépbõl! :smt038 (Bár a Last Ninjára kicsit nehéz ráismerni... :oops:)
Meglepi
Egy apróság: a föl/le gombokra lehetne a tune választásnál az eleje/vége ugrás. Ez olyan sok tune-s fájlnál érdekes, mint pl a N&S.Jó ötlet, a végleges csomagban így lesz :) Igaz a 64 megás SID gyüjteményem így már keményebb dió ;)
Egy másik, hogy célszerû lenne a 8+3-as fájlnevekkel berakni a zenéket a csomagba, hogy EXOS kompatibilisek legyenek :-)
Tök jó, köszönjük! Akkor ezek szerint mégis csak sid player letta dologból... :-)Az igazat megvallva, eredetileg ez a program SAM coupé-ra lett megírva, ahhoz csináltak SID kártyát, benne van a fullos 6510-es emuláció, és a SID header elemzése, a D400-D4FFF-es tartományba írást figyelte eredetileg, ha ez történt, akkor megvizsgálta hová, és ha SID register írás volt, akkor kiírta a megfelelő portra. Ha lenne kártyánk, csak párszáz bájttal lenne rövidebb, meg a 8Kb-tos frekvenciatáblával, viszont sokkal jobban szólna :D
Már csak egy SID-es hangkártyát kéne építeni EP-re (mint anno a C+4-hez és PC-hez is csináltak), és akkor aztán tényleg tökéletesen szólna minden... :-) Gondolom a lejátszó program megírása is sokkal egyszerűbb lenne, és elférne pár száz byte-ban az egész :-)
miért kéne sid chip? akkor mitõl lenne EP-s?Ez lenne az István ötlete alapján, legalábbis, ha jól értettem :) (Sőt az összes )
pont az a lényeg hogy az EP szimulálja a sidet ahogy tudja, ettõl lesz eredeti
esetleg olyasmi lehetne hogy digi hangban tárolni a legjellemzõbb, legtöbbet használt sid hullámformát és 1-2 szólam ezt használhatná
Az igazat megvallva, eredetileg ez a program SAM coupé-ra lett megírva, ahhoz csináltak SID kártyát, benne van a fullos 6510-es emuláció, és a SID header elemzése, a D400-D4FFF-es tartományba írást figyelte eredetileg, ha ez történt, akkor megvizsgálta hová, és ha SID register írás volt, akkor kiírta a megfelelő portra. Ha lenne kártyánk, csak párszáz bájttal lenne rövidebb, meg a 8Kb-tos frekvenciatáblával, viszont sokkal jobban szólna :Dna, azt azért nem gondoltam volna, hogy 6510 emuláció is kell...
ezek szerint a .sid fájlban 6510 kód is van? és annak a futását kell emulálni?
Igen, a SID file nem csak a zenét tartalmazza, hanem a lejátszásához szükséges 6510 kódot is. A PC-s SID lejátszók gyakorlatilag egy lebutított C64 emulátort használnak.Köszi, ezt nem gondoltam volna...
na, azt azért nem gondoltam volna, hogy 6510 emuláció is kell...A 6510 emuláció szoftveres, SID hardveres, csináltak SAM Coupéhoz SID kártyát :D EP-n meg szoftveres, de nem is nevezném emulációnak, mert csak pár dolog van "emulálva" de ahhoz képest sok SID file elég jól szól. Az egyszerre 2-3 csatornán szóló zajt szeretném még megoldani, az A1,A3,A5 regiszterekre való 3x írással, nem lesz olyan jó, mint a zajcsatorna, de talán a sima négyszögjelektől jobb, és az envelope-okat szeretném javítni még. Egyelőre nem tudom miért van pár SID, ahol nagyon hamar elhalkul egy-egy hang, ilyen pl a Dizzy, de találkoztam mással is. :oops:
azt hittem, hogy csak a SID portjaira kell adatokat küldözgetni
ezek szerint a .sid fájlban 6510 kód is van? és annak a futását kell emulálni? az emuláció szoftveres (a SAM copué változatban), vagy hardveres? és az EP változatban?
az A1,A3,A5 regiszterekre való 3x írással, nem lesz olyan jó, mint a zajcsatorna
Az A6h port egyik (4.) bitjével felcserélhető a 17 bites és a 7 bites polinom számláló (a hangcsatornák alapértelmezés szerint az utóbbit használják 30h torzításnál). Ezzel jobb minőségű a zaj, én a CPC átiratokban is ezt a módot használtam.köfi, megjegyzem :)
mondjuk ezt a "minden csatornán tud szóló zajt sose értettem, itt fõleg az AY-ra gondolokNa ez igaz AY-n, gyanúsan a hangerővel játszva lehet különböző effekteket kialakítani a csatornákon.
hiszen ugyanaz a zaj 3x lejátszva is ugyanaz lesz, csak hangosabb :)
hiszen ugyanaz a zaj 3x lejátszva is ugyanaz lesz, csak hangosabb :)
Nem feltétlenül ugyanaz a zaj van minden csatornán. A SID-en más lehet a frekvencia, AY-n pedig a zaj modulálható (AND művelet) az adott csatorna négyszögjelével.A SID-en láttam, a frekvenciagenerátor adja meg a zajfrekit is, az AY-s AND-elő megoldást nem is láttam a doksiban :)
az AY-s AND-elő megoldást nem is láttam a doksiban :)
Melyik regiszterekkel lehet ezt beállítani?
A MUSICIANS könyvtárban érdemes körülnézni. Nagyon profi zenék vannak itt, és kevesebb a "trükkös", mint a játékzenéknél. Elképesztõ, milyen hangok jönnek ki néha a gépbõl :ds_icon_cheesygrin:Majd lesz az ep128.hu-n válogatott, jól szóló zenékbõl gyûjtemény? :oops:
Majd lesz az ep128.hu-n válogatott, jól szóló zenékbõl gyûjtemény? :oops:
Kerültek új zenék a SID-csomagba, ugyanakkor néhány - eredetileg benne lévõ - zenét kiselejteztem... :oops:No para :) , én meg találtam egy hibát :oops: , rájöttem, hogy miért nem hallgat el teljesen a zene pl a Last Ninja 2-ben, a sustain levelt nem vizsgáltam, hogy magasabb-e, mint a max hangerő, mostmár javítva, és átalakítva a lejátszó ABC sztereóvá.
átalakítva a lejátszó ABC sztereóvá.
Ez mit jelent? Mi az?Elsõ csatorna bal, második közép, harmadik jobb.
Nem tudom, hogy jobban szólnak-e a ring modulációt használó SID-ek
És akkor könnyen lehetne próbálgatni, hogyan szól jobban.
Egyszerre két emulátort is el lehet indítani. Én úgy próbálgattam.Én is így próbáltam :) , és sokkal jobb eredményt vártam tőle, az a bajom, hogy mintha kis recsegés szerűséget hallanék belőle, egyébként nem lenne sztem rossz, a Last Ninjákban elég furcsa a sima négyszögjel ringmoduláció nélkül,szerencsére ritkán használja :D
Esetleg kapcsolhatóra csinálni? És akkor könnyen lehetne próbálgatni, hogyan szól jobban.Megnéztem, megoldható, ha felmerül az igény, hogy a végleges verzióban kapcsolható legyen a ring mod, akkor bebiggyesztem :)
A SID gyűrűmodulációja csak háromszögjelnél működik, azaz ha a modulált csatornán van háromszögjel, a reSID forráskód (http://plus4emu.svn.sourceforge.net/viewvc/plus4emu/plus4emu/resid/wave.hpp?revision=514&view=markup) alapján (lásd az output___T()-nél).Azt vizsgálom, ha a csatornán 3szög jel van, és a gyűrűmoduláció bit be van állítva, akkor modulál a lejátszó is. (ha a csatorna control regiszterében 14h van)
Nagyobb probléma, hogy a SID háromszögjeles gyűrűmodulációja más effektust eredményez, mint a DAVE egyszerű négyszögjel XOR-olása.Értem, mondjuk ez hallható is ;)
Akkor nem is érdemes vele szórakozni?
A semminél ez is jobb :):) Akkor belefogok a kapcsolós megoldásba, lehet beépítek egy jelzést is, ha lejátszás közben ring moddal találkozik, akkor a keret jelezze.
Ring mod kikapcsolt állapotban
Sötétkék keret: ring mod 1. csatornán
Zöld: ring mod 2. csatornán
Közép kék: ring mod 3. csatornán
Ring mod bekapcsolt állapotban a keret mindig barna
Nálam - bekapcsolt ring mod esetén - mindig barna a keret.Ez így van beállítva, hogy meg lehessen különböztetni a be, ill kikapcsolt módot, ring modnál nem jelzi, hogy mikor van ring mod valamelyik csatornán, ha jobb lenne jelzéssel, megoldható az is. :) Talán a keret helyett Ring mod: ON/OFF feliratot is be lehet iktatni, csak az hosszabb megoldás.
Jó lett a lejátszó!A Ring modos lejátszásnál csak akkor lehet különbséget hallani, ha valamelyik csatorna modulált egy másikkal, ezt a ring mod kikapcsolt állapotban jelzi a keret különböző színeivel, ha közép kék a keret, akkor pont a SID egyes csatornáján van ring mod, ami a lejátszóban pont nem emulált, csak a SID 2,3-as csatorna ring modja (sötét kék, zöld keret) okoz hanghatást.
De én a ringmodos és az anélküli lejátszás között nem érzek különbséget. :oops:
Talán a keret helyett Ring mod: ON/OFF feliratot is be lehet iktatni, csak az hosszabb megoldás.
ha közép kék a keret, akkor pont a SID egyes csatornáján van ring mod, ami a lejátszóban pont nem emuláltAzt hiszem, ez volt a gond... Mondanátok olyan zenéket, amiben nem ilyen ringmod van? Eddig nem találtam, vagy nem vettem észre. :oops:
Azt hiszem, ez volt a gond... Mondanátok olyan zenéket, amiben nem ilyen ringmod van? Eddig nem találtam, vagy nem vettem észre. :oops:Last ninja I 7. song, az LN2-ben is vannak, de általában rövidek, Navy Seals, most ezek jutottak eszembe, de ettől sokkal több SID-ben találkoztam velük.
Eszembe jutott egy érdekes ötlet.Hát, én ezt nem teljesen értem. Nem írsz egy programot, ami ezt el is végzi? Akkor biztos egybõl érthetõ lenne.
ezt most nem értem :)Nem egészen, az lehet jobb minőségű lenne :D , viszont a világ RAM-ja nem lenne elég, nemhogy 640Kb, ami mindenre az :D
sid emuláció, ami wav-ra konvertál és azt játsza le?
érdekes :)
na de akkor hogy lesznek ilyen nem-négyszögjeles hangzások?Nagyrészt digi, csak a zaj nem az, 15Khz-en megy, amitől én még ettől is jobb hangokat vártam, úgyhogy arra gondoltam, hogy a 3,4szög, és fűrész jeleimmel lehet egy kis gubanc.
elég nagy frekin megy?
azért ez már majdnem digi akkor
na de ha már valami digi benne, akkor miért nem digi minden? hiszen minden sample belemehetne 1 sample-be, nem vinne több memóriátEzt az 1 samplés dolgot nem értam, a zaj azért Dave-es, mert az jobb minőséget produkál, mint a zaj sample, egyszerű tömörítés jó ötlet, de sztem ez a megoldás nem spórolna annyit, a frekvenciánál meg lehet nem is lenne elég a kevesebb bites változás, az ismétlődések lerövidítése jelentősebb (x darab y byte) rövidülést okozna, de a legjobb az ismétlődő szekvenciák bevonásával lenne, akkor sztem az összes fájl beleférne max 64 Kb-ba, csak az meg a lejátszástól venne el időt, most a megszakításbeli lejátszó adatellátása kb 5 rasztersort vesz igénybe.
sőt még valami egyszerű tömörítés is lehetne, van asszem olyan hogy csak a változást tárolják, kevesebb biten
Ez most kiszedi a SID írásokat, majd valami jobb emulációs algoritmussal "előemésztve" előállítja a DAVE adatokat?Az első fele stimmel, SID regiszter értékeket szed ki, és a volume értékeket már az envelope által módosítva, és a zaj frekvenciát már Dave-re konvertálva, és ezeket felhasználva generál hangot a különböző jelek sampléira, négyszögjel esetén van 32 négyszögjel kitöltési tényező is ( SID-en ez 4096), és ring mod.
ha 15khz-n tárolsz egy csomó dave értéket, akkor digi hangként 1 byte-ba mixelve mindent (mint digi sample!) sokkal kevesebb lenne, nem?Szerintem nem, mert a feldolgozásra került adatok 50Hz-enként lettek kigyűjtve, és ilyen sűrűséggel kerülnek feldolgozásra is, két 50 Hz-es megszakítás közben pedig szól a sample a beállított értéken, ez inkább a DTM playerre hasonlít fix samplékkal, amiken szerintem van még módosítanivaló.
vagy továbbra se értem :)
Sid.zip (5.75 kB - letöltve 7956 alkalommal.)
Ennek egészen Commodore szerű hangzása van!
Zeneszerkesztőt kéne írni, amivel lehet ilyen hangzásokkal zenét szerkeszteni EP-re.
fogj egy c64 emut, töltsd be a zeneszerkesztőt és kész :):D , ennyi, aztán már csak ki kell menteni az adatokat, és le is játszható :D
:D , ennyi, aztán már csak ki kell menteni az adatokat, és le is játszható :DMondjuk az igazi az lenne, ha a "kottát" lehetne használni, nem pedig ilyen 65xx gépikódú borzalomból kéne visszanyerni az adatokat.
Mondjuk az igazi az lenne, ha a "kottát" lehetne használni, nem pedig ilyen 65xx gépikódú borzalomból kéne visszanyerni az adatokat.Az lehet egy következő project, abba már az envelope generálást is be kéne tenni, és egy zajfrekvencia konverziós táblát. Ha ez elkészül, és igény is van egy ilyen zeneszerkesztő/lejátszóra, akkor megpróbálhatom megcsinálni.
"Kotta" esetén a különböző ismétlődő motívumok nem fogyasztanának rengeteg plusz helyet.
Mondjuk az igazi az lenne, ha a "kottát" lehetne használni, nem pedig ilyen 65xx gépikódú borzalomból kéne visszanyerni az adatokat.
"Kotta" esetén a különböző ismétlődő motívumok nem fogyasztanának rengeteg plusz helyet.
Itt is van limit, mert pl digis SID adatokat nem tudok kinyerni, csak azokat, amiket másik player lejátszik.
Mar miert ne tudnad? Elvileg irhatsz assembly-ben is egy 65xx lejatszot es belerakod egy sid file-ba es lesz benne digi is ...Hm, ez egy újabb lejátszót igényelne, tényleg megvalósítható, csak még azt nem tudom, hogy mi alapján lehetne megállítani a felvételt, újrakezdős SID-eknél, mert ugye ennél nem lenne hang.
Ha be akarom tölteni, nekem simán visszalép EP logo-hoz.Elég RAM-mal próbálod?
Elég RAM-mal próbálod?
320K nem elég neki?Nem:
Legalább 448Kb-s géppel érdemes kipróbálni, úgy biztos nem fog visszalépni az EP logóhoz, úgy tervezem majd ha kész lesz, hogy minden gépen menjen, amiben legalább 128Kb RAM van, csak a lejátszandó zenék hoszza lesz leszabályozva, 128Kb-s gép esetén kb 1 perc 45 másodperc lesz a lejátszható hossz, ha jól számoltam :D
SID2 és SID3 közül melyik hangzik jobban, nem tudok különbséget tenni.Nekem is egyformának tűnik.
Nekem is egyformának tűnik.Oké, köszi, akkor a SID3 vonalán megyek tovább, hátha lesz olyan zene, aminél fülbetűnő a különbség :D
Miért hamis ez nekem? Eredetileg is ilyen volt?Némelyik hangnál én is felfedeztem hamisakat, nem tudom én, hogy miért van, hacsak nem amiatt, hogy a samplén nem teljesen egyenletesen halad előre a lejátszás a frekvenciának megfelelően, mert a frekvencia 2 bájtos, a samplén meg a frekvencia számláló felső bájtjával halad előre.
A konvertálással sem jutottam még zöldágra... :oops:
Forgo C= logo? :-PHát az kimarad :D
csak az előbb említett okra tudok gondolni.
Mármint hogy nincs forgó C64 logó? Ez lehet az oka... :mrgreen:Egyértelmű! :ds_icon_cheesygrin:
ld a,(hl) ;frekvencia alsó érték
inc hl
ld h,(hl) ;frekvencia felső érték
push hl ;és itt tárolom el a frekvenciát, és itt követtem el a hibát is
Hol akadtál el a konvertálásnál?
elméletileg 2 lépés:
1. el kell indítani a START-ot, kiválasztani a lejátszandó SID-et, ha ez megvan, akkor a SID valamelyik songját, majd amikor véget szeretnél vetni a rögzítésnek, meg kell nyomni az ESC-et, 12 fájl generálódik
Az első pontnál. A START nekem nem indul el, visszalép az EP logo-hoz.Tipp: FILE bővítés van a rendszerben?
Na a felvevőhöz is sok-sok memória kell, mivel ott tárolja el az értékeket, és csak ESC után menti el, 24x16Kb+96Kb legalább.
Ez lehet a baj, 320K akkor nem elég neki.Milyen konfiggal próbálod?
Most már elindul, de miután kiírja a SID adatait, látszólag nem csinál semmit. 2 mega RAM-mal sem. Még a ZozoTools órája is megáll.
Én magnós konfiggal szoktamMármint FileIO-s, nem?
, 1Mb-vel, azzal nincs gond, és ha virtuális Win7 alól írom Linuxos fájl rendszerre, akkor percekig csak ír :DALT+W-vel is?
Mármint FileIO-s, nem?Igen :)
ALT+W-vel is?
Alt+W-vel hagytam egy percig, de nem is végtett file-műveletet.oké, megnézem.
A konfig nem magnós, lemezes. FileIO nincs.
A hiba javítva, az összes S64 újragyártva, mostmár hamis hangok nélkül, pár hozzászólással lejjebbi link a frissített verzióra mutat.Mármint az a pár hozzászólással lejjebbi link a letöltések közötti fájlra vonatkozik?
Mármint az a pár hozzászólással lejjebbi link a letöltések közötti fájlra vonatkozik?igen, a letöltések közötti fájlra mutat, sztem már átlapozódott a 2. oldalra :D
Itt pár hozzászólással lejjebb nem találtam linket. Pedig nem is voltam olyan link.
Akkor elvileg 10Mhz-es gépen érezhetően jobban kell majd szólnia?Elméletileg ugyanúgy kéne, mint 8MHz-en :), de sokkal jobban kéne , mint 8MHz alatt, és jobban kell szólnia, mint az előző verziónak (kivéve a zaj), mert ott bekavar a lejátszás pár fázisába az adatfeldolgozás, viszont ott meg igazi EP-n ahogy gyorsul a Dave is, úgy lesznek magasabbak a zaj hangok is. Viszont lekaptam a letöltések közül, floppys konfiggal kiakad.
http://www.hvsc.de/download/C64Music/DOCUMENTS/STIL.txt
itt van egy nyan zene sid formátumban :)
I was so excited by this update to sid player however I don't hear any difference after pressing f2... Could someone point to a good example song where the added sound is prominent? Also f4 seems to hang the program... and what is a SID card?Shit, I forgot to enabled interrupt, if f4-f6 is pressed.
SID Player v1.2 (https://enterpriseforever.com/letoltesek-downloads/egyeb-misc/?action=dlattach;attach=17075)Ez akkor ugye a SIDPLAY és SIDRPLAY programokat váltja ki, igaz?
Módosított változat, SID lejátszása történhet Dave-vel, ring moddal, vagy nélküle, és SID kártyás konfigon SID-del is. (alap Dave)
Ez akkor ugye a SIDPLAY és SIDRPLAY programokat váltja ki, igaz?Igen :), és a SID playert, ami a SID kártyára küldi az adatot.
És van még valami SIDBasic, meg SIDBasic Int, azokkal mi a helyzet?Ez a kettő más, egy 4. SIDPLAYER kinyeri SID port adatokat és kiírja file-ba, ezt játsza le (háromszög, fűrész, és négyszögjellel), pár dolog még meg van valósítva a SID-ből.
egy 4. SIDPLAYER kinyeri SID port adatokat és kiírja file-baÉs ez melyik?
És ez melyik?Szerintem az csak nálam van meg, ugyanúgy, mint az 5. verzió, ami a Dave regiszterek tartalmát menti :)
midi lejátszó nem lesz? :)Szerintem nehezítené a dolgot, hogy nem csak 3 csatorna lehet, és még egy csatornán belül is megszólalhat egyszerre lényegében akármennyi hang, akár 10-20 is.
Az ECD-Windows-ban van mod-Rockdigi (vagy valami hasonló) konverter. Ha olyan van, a midi konvertert megcsinálni sem lehet annyira vészes.
egy 4. SIDPLAYER kinyeri SID port adatokat és kiírja file-ba
A MOD formátumot valószínűleg egyszerűbb konvertálni, mivel a DTM/Rockdigi hasonlóbb ahhoz mint a MIDI-hez.Mivel MOD-ból lettek konvertálva, ez nem csoda :-) (Ill. a Rockdigiben eredeti EP zenék is készültek)
A lejátszó egyébként még nincs az ep128.hu-nItt van a zene alatt. (http://ep128.hu/Ep_Music.htm)
Itt van a zene alatt. (http://ep128.hu/Ep_Music.htm)
Ez hasznos lehetne, bár így nagyobb lenne a file mérete, nem kellene a lejátszásához szoftveres 6502 emuláció. Esetleg a SID port mentést Lua script is megoldhatná (hasonlóan az Enterball zenéjének Spectrumra konvertálásánál használt megoldáshoz), ami akár Plus/4-en is futhatna.Használtam is, a SIDplayer Basichez így generáltam adatot :) Nincs kedved egy egyszerű tömörítőt írni, ami hatékonyan tömöríti az így kinyert port adatot, és csak az aktuális bájtot szolgáltatja? Minden port értékét külön fájlba gyűjtöm.
Nincs kedved egy egyszerű tömörítőt írni, ami hatékonyan tömöríti az így kinyert port adatot, és csak az aktuális bájtot szolgáltatja?
A Spectrumos Enterball konverzióban már van ilyen, bár a hatékonysága lehetne jobb is.Béna vagyok, nem találom, pedig átlapoztam a topicot :oops:
én mind a két verziónál külön fájlba teszem minden regiszter tartalmát , és minden megszakításban eltárolom az értékeket, így marha sok adat kerül ki, de jobban tömöríthető
Erra a megoldásra már gondoltam én is, hamarosan készítek ilyen változatot is. Talán lehetne egy 16K-s blokkban 655 minta a 25 SID regiszterből (az első 655 byte a 0. regiszter, utána az 1. regiszter, stb.), ami 13.1 másodperc 50 Hz-es megszakításnál. Tömörítetlenül sem feltétlenül lenne sokkal nagyobb, mivel egy megszakítás gyakran 8 regisztert is módosít.Bocs, most megnéztem a SIDBasic-nél hogyan csináltam, csak 12 regisztert mentettem, mivel a többi nincs használatban, minden regiszter egy file:
Bár lehet, hogy itt már bármilyen tömörítés, lassítana annyit, hogy a sima SIDBasic-nél minőségromlást okozna, a SIDBasic Int-nél meg a megszakítás sebességét kéne csökkenteni.
A tömörítés itt is a már leírt módon (16K-s blokkok és szótár méret) történik.Úgy fest, akkor át kell dolgoznom a SIDBasic Int-et, bár ha a vezérlést is be kéne tenni 50Hz-es megszakításba, lehet még csökkenteni kéne a lejátszási frekvenciát. Viszont arra gondoltam, ha betenném a vezérlő rutin meghívását a kicsomagoló rutin sűrűbben futó részébe, és csak akkor meghívni, ha lenne videó interrupt, ezzel nem kéne megpiszkálni a digi lejátszást, és maradhatna a sebesség.
Átlagosan nem lassít sokat, egy blokk kicsomagolása jellemzően 0.12-0.14 másodperc, bár ez függ az adattól is, ha ilyen nagy mértékben (30x) tömöríthető, akkor az idő nagy részében csak LDIR utasítást kell futtatni. :) És a blokkok lejátszásának az időtartama 13.1 másodperc. Talán pazarlás is a gyorsabb de nagy méretű rutin használata (illetve itt biztosan, de ez csak egy példa). Azonban a lejátszásnak teljesen megszakításból kell futnia, mert a főprogramban túl hosszú ideig tart a nagy blokkok feldolgozása.
Az sokat rontana a minőségen ha 512 helyett 256 lenne egy hangminta mérete? Így egyszerűsíteni lehetne a kódon és a memóriaigény is a felére csökkenne. Az első csatorna például 28 ciklust gyorsulna:512 byte a hangminta mérete? :)
512 byte a hangminta mérete? :)
28 ciklus már egész jó, abba pl majdnem belefér a megszakítás típusának ellenőrzése.
Ha lesz időm, ránézek majd, tudsz generálni optimalizált 256 byte-os hangmintát?
Jobban meggondolva a rövidebb hangminták használatának mégis lehet hátránya: a zaj minőségét rontaná.Erre nem gondoltam, lehet ezért lett 512.
Erre nem gondoltam, lehet ezért lett 512.
Bár ha jól látom, az eredeti zaj táblázatok minden hangmintát nyolcszor ismételnek, tehát valójában csak 64 minta egy teljes ciklus. Lehetne kevésbé ismétlődő adat is, de akkor a zaj frekvencia konverzióján kell módosítani, és kevésbé is lenne pontos (nem tudom, zajnál ez mennyire probléma).Most jutottam elodáig, hogy fejtegessem én is mit csináltam :D
noisetable 8 tábla a 8 hangerore
triangletable equ noisetable+2000h 8 tábla a 8 hangerore
Szerintem 16 tábla van mindenből, de azt nem egészen értem, miért ismétlődik a pulsetable háromszor. :oops: A zajgenerátornak elvileg 16 mintát kellene előállítania a "normál" hullámformák egy periódusának az ideje alatt, ami 256 méretű ismétlődés nélküli táblánál a frekvenciát még 16-al osztva érhető el. Így azonban 8 MHz-es gépen 15625 Hz-es megszakítással gyakorlatilag csak 10 bites lenne a zaj frekvenciájának a felbontása, de kevésbé ismétlődne. 7812.5 Hz-nél így számíthatók a frekvenciák:Igen, most módosítás közben vettem észre, épp a minták méretét felezem, egyelőre manuálisan, de meguntam :lol:
- négyszög/háromszög/fűrész: SID frekvencia / 2
- zaj: SID frekvencia / 2 / (minták száma a táblázatban / 16)
A kisebb táblázatokkal lehetne minden hullámformából 32 (összesen 32K, azaz 2 szegmens), vagy továbbra is 16, de az egy lapon is elfér.
A hullámformák torzításának van jelentősége? Nem tudom, hogy ez bug vagy valójában jobb minőségű emuláció. :oops:Nem akarom rádkenni, de úgy emlékszem te ajánlottad, hogy ne legyen lineáris, mert úgy jobb lesz a kimenet :)
Szerk.: a file formátum már tartalmazza a burkológörbéket is, tehát azokat nem a lejátszó emulálja? Ha igen, akkor egy csatorna állapotának a leírásához 4 byte is elég:Igazad van, vegyesen mentek, és így is van, 12 fájlt ment az 5-ös verzióju SIDPlayer, az biztos, hogy a fent felsoroltakat mentem, azt nem tudom még milyen elrendezésben. Az biztos, hogy az 1-2 file a frekvencia, az is lehet, hogy már 16-tal osztott változatban.
- frekvencia (2 byte), zaj esetén talán már a file adatban megfelelően osztva
- PWM felső bitek (5 bit / 1 byte)
- aktuális hangerő (5 bit / 1 byte)
- hullámforma (2 bit), gyűrűmoduláció (1 bit), ezeket tartalmazhatja az előző két byte közül az egyik
Így egy 8K-s blokk 682 50 Hz-es megszakításra elég, ami kb. 13.6 másodperc.
Nem akarom rádkenni, de úgy emlékszem te ajánlottad, hogy ne legyen lineáris, mert úgy jobb lesz a kimenet :)
Igazad van, vegyesen mentek, és így is van, 12 fájlt ment az 5-ös verzióju SIDPlayer, az biztos, hogy a fent felsoroltakat mentem, azt nem tudom még milyen elrendezésben. Az biztos, hogy az 1-2 file a frekvencia, az is lehet, hogy már 16-tal osztott változatban.
Nem emlékszem erre, vagy hogy miért pont ilyen legyen (azaz a háromszög például szinusz abszolút értékéhez hasonló), de nem lehetetlen. :oops: Talán a legjobb lenne megnézni a régebbi hozzászólásokat.Nem ilyen torzításra emlékszem , olyanra hogy a magasabb értékek felé tolódjon a minta, tehát abból legyen több, ne legyen lineáris, de lehet álmodtam, mert a fórumon nem találok semmit :)
Tömörített lejátszáshoz tuti hasznos lesz az átalakított rutin, köszönöm szépen, még nem tudom, hogy mi lesz a megvalósítás, egyelőre az alap ötlet, hogy 500h egybefüggő "regiszter" adat, így 12*500h adat lesz csomagolva egy blokkba, vagy ezek többszöröse
Ezzel a megoldással (nem az egészet csomagolja ki, hanem mindig csak két blokkot, az aktuális lejátszása közben a "háttérben" készül el a következővel) a 8K blokk méret 682 50 Hz-es megszakításhoz elég: 682 * 12 = 8184 byte, és még marad 8 ahol tárolható például a ténylegesen használt adat mérete az utolsó blokknál. Ha a 3. lapra kerül a puffer, akkor a 0. és az 1. lapon lehet a bemeneti file (az itt tárolható tömörített adat korlátozza a méretét), az 1. és 2. lapon pedig a hangminták, az előbbit a megszakításkezelő rutin átmenetileg belapozza. A video RAM pedig a 3. lapon amikor az 50 Hz-es megszakítás a képernyőt frissíti. De nem tudom, megéri-e ilyen átalakítás.A jobb tömöríthetőség miatt számoltam 12*500h-s blokkal, ami eleve elvetélt, elszámolt ötlet volt, de még így is meggondolandó, hogy egyszerre 2 blokkot csomagoljak ki, az elsőben lenne az 1. hat "regiszter", a másodikban meg a 2. hat, 2 szegmenssel megoldva, de ez még odébb van, egyelőre műödjön a felezett hangmintákkal rendelkező verzió az eredeti kicsomagolással :)
de még így is meggondolandó, hogy egyszerre 2 blokkot csomagoljak ki, az elsőben lenne az 1. hat "regiszter", a másodikban meg a 2. hat, 2 szegmenssel megoldva
Nem biztos, hogy ez a megoldás ideális, de a regiszterenként rendezett adatblokk talán jobban tömöríthető, ha valamivel bonyolultabb is a lejátszása.Igen, ezen is gondolkoztam, hogyha marad elég idő, akkor esetleg érdemes-e az adatot szétszórni regiszter sorrendbe, és a mostani gyors ( veremkezelős kiolvasással olvasni ), vagy érdemes-e az általad elsőre használt regisztersorrendes tömörítésre áttérni, akkor a fájl nagyobb, de gyorsabb az olvasás.
Én meg továbbgondoltam, a tömöríthetőség miatt, hogy mindezt lehetne 2 16K-s szegmenssel, ami a lejátszást bonyolítaná, egyik az aktív adat, a másik meg az épp kicsomagolásra kerülő adat, de még a holdban se járok, ezért az egész csak puszta elmélkedés.
Igen, ezen is gondolkoztam, hogyha marad elég idő, akkor esetleg érdemes-e az adatot szétszórni regiszter sorrendbe, és a mostani gyors ( veremkezelős kiolvasással olvasni ), vagy érdemes-e az általad elsőre használt regisztersorrendes tömörítésre áttérni, akkor a fájl nagyobb, de gyorsabb az olvasás.
Tehát a ciklusban ADD HL, DE utasítás kell a következő regiszterhez. De ez 50 Hz-es frekvencián nem nagy probléma, ha 20-25% CPU idő marad erre akkor az még mindig kb. 16000-20000 Z80 ciklus. Az így rendezett 4 és fél perces Cybernoid II példa file tömörítve 11238 byte, ha viszont az egyszerűbben lejátszható R0,R1,...R24,R0,R1,... sorrendre konvertálom, akkor már 50918 byte a méret, ami lapozás nélkül nem fér el a memóriában.Engem ez meg is győzött, sorrendbe rendezett regiszterek nem lesznek tömörítve, marad az ugrálós lejátszás, és dobom is ki a veremkezelős olvasást, legalább az olvasás alatt is engedélyezett lesz az interrupt (igaz, a mostani olvasás mellett se nagyon volt interrupt vesztés)
A legjobb lenne tesztelni a tömörítést már konvertált 12 regiszteres SID adaton is.Az 1-12-ig rendezett adaton nem tudom érdemes-e a fentieket látva, de letesztelem, a lenti táblázat alapján a 8192 pedig ideális választás.
Szerk.: blokk méretek összehasonlítása, ez nem egészen pontos, de nagyjából látható a hatása a tömörítésre. 12 regiszternél valószínűleg kisebb blokk is elég hasonló hatékonysághoz, bár ezt még nem teszteltem.
1024: 55684 byte
2048: 34422 byte
4096: 23209 byte
8192: 16202 byte
16384: 11239 byte
32768: 8700 byte
65536: 7353 byte
Készítettem SID adat konvertáló programot is, ennek a kimenete (továbbra is ugyanazzal a Cybernoid II példával) 8354 byte tömörítve ha 8K a blokk méret, és 6640 byte 16K esetén. De nem tudom, jó-e a konverzió, mert nincs mivel lejátszani. :) Különösen a burkológörbe emulációnál fordulhat elő hiba. A program a sidrec.lua (https://enterpriseforever.com/sound/sid-lejatszo/msg61779/#msg61779) kimenetét konvertálja.Könnyen megeshet, hogy a burkológörbe emuláció jobb, mint a SIDPlayerben :D
Könnyen megeshet, hogy a burkológörbe emuláció jobb, mint a SIDPlayerben :D
Szerk.: négyszögjelnél probléma lehet még a hangerő szabályozása, a XOR-olós módszer valójában 1,3,5,7,... szinteket állít be, azaz nulla hangerőnél is van hang. :oops: Talán célszerűbb lenne a hangminta táblázatokban 0 és 63 értékeket használni, a XOR helyett pedig AND utasítást, így azonban a négyszögjel hangerejét 2-vel szorozni kellene, a többi hullámformánál pedig a XOR 0-t AND 63-ra cserélni.Úgy emlékszem, hogy a négyszögjel alap adatok 1fh, és 20fh, tehát valóban, ha nulla a hangerő, akkor is van minimális hang, de a többi jelnél a XOR lecserélődik AND-re. A régi 512 byte-os mintával sokkal szebben szól, van egy ötletem mi okozhatja a hibát, ma kipróbálom.
A 2. byte-ot nagy munka lenne nálad átalakítani? Azért kérdem mert nálam erre épül a 256-os ugrótábla.
A kitöltési tényezőből minf a 7 bit ki van használva :) 16 tábla, és minden egyes táblán belül 8 dinamikus változtatási lehetőség.
Ha már dinamikus változtatás, akkor talán lehetne 8 bites is, táblázat nélkül. :)Egy zseni vagy :) Dobom az ugrótáblát, amúgy is sokat gyorsult a lejátszó rutin a 256 byte-os hangok miatt, én 5 értéket néztem, ha egyik bit se volt állítva, akkor nullázta a frekvenciát. A módosítással meg kell 4 értéket vizsgálni, pont jó lesz, és ráadásul elmarad 7 darab push, és még pár utasítás ha a pulse waveform változik
Itt 5 byte kódot kell cserélni csatornánként a megszakításkezelő rutinban, ami viszont gyorsul egy keveset. De a 8 bites PWM-nél a gyűrűmoduláció is a hangerő regiszterbe kerül, és 2 bites lesz a hullámforma, tehát módosítani kell az ugrótáblát (de lehet, hogy ugrótábla nélkül is elég gyors lenne a kód).
De akkor ez lesz, ha jól értem:
00 freq low (zajnál 4 bittel eltolva jobbra, 01-re is)
01 freq high
02 b7 ring mod + b6-b5 waveforms + b4-b0 volume (00h triangle, 20 sawtooth, 40h pulse, 60h noise)
03 b7-b0 pulse waveform
Módosított konvertáló program, aminek a kimenete ilyen formátumú:Köszi szépen.
A 8 bites PWM azonban növeli a file méretét, ha ez probléma, akkor mégis célszerűbb lehet csak 7 bitet tárolni. Így viszont felszabadulhat egy bit 6 bites hangerő céljára, bár ezt nagyobb táblázatok nélkül csak a négyszögjel tudná kihasználni:Annyival csak nem növeli a méretét, szerintem maradjunk a 8 bites PWM-nél, a PWM-es megoldásodnak köszönhetően sztem befér az egész program egy szegmensbe, így 32KB csomagolt adat is belapozható egyszerre.
Köszi szépen.Annyival csak nem növeli a méretét, szerintem maradjunk a 8 bites PWM-nél, a PWM-es megoldásodnak köszönhetően sztem befér az egész program egy szegmensbe, így 32KB csomagolt adat is belapozható egyszerre.
Egy másik lehetséges megoldás Z80 kóddal generálni a táblázatokat, ez csak 128 byte és talán jobban is optimalizálható, a futásideje azonban 1.86 másodperc letiltott memória várakozással, ami lassabb lehet a kitömörítésnél. Valamivel gyorsabb lehetne a hármoszögjelet a fűrészből előállítva (vagy fordítva), mivel a hangminta értékek mindkettőnél azonosak, csak a sorrend változik. :) Szerk.: a fűrészjel pedig szorzás nélkül is megoldható lenne, hasonlóan a vonal rajzolásra használt algoritmushoz.Szuper, ez nekem szimpibb, most én is legenerálom, de a magam egyszerű módján, így kevesebb a hely, az egész tábla és kód elfér a 0-ás lapon, vagy ha nem, akkor a FILEkezelőt átteszem egy egy másik szegmensre.elméletileg semmit se kell lapozgatni (kivéve a display miatt a videó memóriát az 50Hz-es megszakításban)
A zaj itt is átalakítható hogy minden hangerőnél eltérő legyen, a "jr nz, .l4" utasítást kell "jr nz, .l5"-re cserélni.
Optimalizált táblázat generálás:Köszönöm szépen :) Eljutottam már odáig, hogy az új elrendezésű adatokat játsza le (még nem teszteltem, fájlt még nem generáltam hozzá) "folyamatos" kicsomagoló rutinoddal :), és javítottam az EXOS kompatibilitási hibát.
Ez 0.9 másodperc alatt fut le, és rövidebb is az első verziónál (128 helyett 116 byte), a kimenete pedig azonos. Így már talán megfelelő sebességű a tömörített táblázatokhoz képest is.
Még egy lehetséges fejlesztés, hogy a hangminta lejátszás frekvenciája ne csak 7.8125 vagy 15.625 kHz lehessen, hanem a Z80 órajeltől függően gyorsuljon, azaz például 10 MHz-es gépen még nagyobb lehessen, és a 6 és 7.12 MHz-nek is legyen előnye. Így ugyan bonyolultabb a frekvencia konverzió (8*16->24 bites szorzás), de szerintem lenne rá idő. Bár nem tudom, megéri-e, a legtöbben valószínűleg 4 MHz-es gépen futtatnák a programot.Jó ötlet, tuti van rá idő ,mert a jelenlegi állás szerint a processzoridő 30-40%-a szabad ,és ezt csak turbós gépen kéne végrehajtani, megspóroltam a lapozásokat, csak egy van az 50Hz-es megszakításban a display miatt.
még nem teszteltem, fájlt még nem generáltam hozzá
0-ás lapon a program, és a 3 tábla
Ha a formátum nem változott ehhez (https://enterpriseforever.com/sound/sid-lejatszo/msg61844/#msg61844) a leíráshoz képest, akkor az itt (https://enterpriseforever.com/sound/sid-lejatszo/msg61847/#msg61847) található dave_data.bin példával működnie kellene.Köszi, pár perce eszembe jutott nekem is körülnézni, csak nem jutottam odáig.
Ezt nem egészen értem, a táblázatok nem 24K területet igényelnek? :oops: Legalábbis 5 bites hangerőnél, 3 * 32 * 256 = 24576. Vagy van megoldás arra, hogy kisebb helyen is elférjen, esetleg marad a 4 bites hangerő (nem tudom, mennyire hallható a különbség)?A 3*16*256-nál maradtam a tábláknál, nem tudom mennyire hallható a különbség, szerintem jó lesz :) a négyszögjel használja a 32 hangerő értéket.
Köszi, pár perce eszembe jutott nekem is körülnézni, csak nem jutottam odáig.
A sidrec.lua hogy működik?
A 3*16*256-nál maradtam a tábláknál, nem tudom mennyire hallható a különbség, szerintem jó lesz :) a négyszögjel használja a 32 hangerő értéket.
Ja, az utolsó 8 byte-ra azt találtam ki, hogy ebből az utolsó 2 a hosszt tárolja úgy, hogy 682 - betöltött bájtok, ha az egész 8Kb-s blokk adatot tartalmaz, akkor 0000h lesz az értéke, ha csak 300 byte aktív adat van regiszterenként, akkor 382 lesz az értéke.
Csak SID kártya módban használható, ilyenkor a 0Fh portra írt regiszter értékeket menti. A file név a kód elején állítható. Problémát jelenthet hogy a SIDPLAY alapértelmezés szerint DAVE módban indítja a lejátszást, ezért azt mindig át kell állítani, és a zene eleje így elveszhet. :oops:Eddig stimmt, nyomtam bőszen az F3-at miután megadtam a betöltendő file-t.
Ha a bemeneti file nem túl nagy (6000h alatt elfér, ami ~20K méret lehet), akkor lapozás nélkül is megoldható az 5 bites hangerő. De még lapozással is gyorsabb a régi 9 bites táblázat címzésű lejátszó rutinnál. Lapozás nélkül viszont talán egy keveset lehetne növelni a frekvencián még 4 MHz-en is. Esetleg lehetne külön 4 bites verzió is ami nagyobb file méretet támogat, nem tudom, milyen gyakran lenne kevés a 20K. A tömörítésen is lehetne javítani valamennyit egy módosított epcompress verzióval, a -maxoffs használható értéke ugyanis változik a blokkon belül, az elején 8192, az utolsó byte-nál azonban még a 16383 is működne, így a fix 8192 nem optimális.Szerinted sokat számítana az 5bites hangerő használata a háromszög, fűrész, és zaj használatánál?
Eddig stimmt, nyomtam bőszen az F3-at miután megadtam a betöltendő file-t.
f = io.open("sid_data.bin", "wb")-re írtam át, hagytam egy darabig futni, majd nyomtam egy ESC-et, és elkezdtem keresgélni a fájlkeresővel, nem találta
Linux alatt megpróbáltam, de valami nem tetszik neki, be se tölti a sidplay-t, amikor betöltené a PRG-t, dob az EXOS 1 egy 0CFh-t (File IO, EXDOS nélkül), úgy emlékszem ez EXDOS hiba, most meg is néztem, File not found.
Szerinted sokat számítana az 5bites hangerő használata a háromszög, fűrész, és zaj használatánál?
Szívesen átalakítom lapozósra, elméletileg most járunk 298+interrupt T-state-nél a lapozással 334+interrupt, 12 KHz-es lejátszásra egyikkel sem lehetne áttérni.
Nyerünk a módosított EPCOMPRESS-szel annyit, hogy érdemes csak ezért módosítani?
viszont szerintem az envelope emuláció egy helyen gyorsabban lefutó adatot generált, a többi helyen jónak tűnik.
Ez az aktuális (rendszer, nem Alt+F) könyvtárba próbál menteni, ami nem biztos, hogy írható (pl. C:\Program Files\ep128emu2 normál felhasználóként). De akkor elvileg hibát kellene eredményeznie, bár Windowson nem lehet biztosan tudni. :oops: A legjobb lenne teljes útvonalat megadni, akkor egyértelmű hogy hol lesz a file. :)Érdekes, mert a snapshotot oda mentette, nálam bonyolultabb a helyzet :) X meghajtóként van bamappolva a Linux Home könyvtáramban egy könyvtár azon belül van az ep128emu2, és azon belül vannak a játszós könyvtáraim is :), hacsak tényleg nem az eredeti helyére próbálna menteni, na majd adok meg egy elérési utat.
Talán az Alt+F nem jól van beállítva? A PRG-t már ott keresi.Mostanában a Working Directory beállítása macerásabb linux alatt, ha bemegyek a könyvtárba, save -re nem áll át, csak ha beírom a könyvtár nevét, elméletileg jónak kéne lennie, mert F1-re is az ugrik fel.
Ha 12-re nem is lehetne növelni, még a 9 is jobb lenne valamivel. :)Én hiszek neked :)
Amint írtam, valójában egyszerű -maxoffs 16384 is működne a rendes verzióval, és az szerintem 20K alá csökkentené a legnagyobb file méretét, ha a javulás mértéke hasonló a Cybernoid II-höz.Csak később olvastam, mint én írtam :) Eddig azt hittem, hogy 16384-es maxoffs-szal nem működik a 8K-s kicsomagoló :).
Az nem kizárt, hogy a burkológörbe emuláció bugos (a reSID alapján készült, de egyszerűsítve), még tesztelni kellene. :oops:De :) , úgy fest én szúrtam el valamit, áttértem a 2K-s táblázataidra, és a probléma volt-nincs, és szerintem teljesen jól szól, egy helyen hallottam érdekességet, de azt nem tudom mi lehet, még. A mostani állás szerint 6000h hosszú lehet a file, de még 400h-val lejjebb is vihetném a betöltés helyét.
Mostanában a Working Directory beállítása macerásabb linux alatt, ha bemegyek a könyvtárba, save -re nem áll át, csak ha beírom a könyvtár nevét
Szerk.: egy kevés helyet azzal is meg lehetne takarítani, ha nem lennének 0 hangerejű táblázatok és a konvertáló program 0 hangerő helyett 0 kitöltési tényezőjű négyszögjelet írna.Jó ötlet, és még átteszem a file választót egy másik szegmensre, ezzel is pár KB-ot.
Vagyis nem, mert jól felülcsaptam a zaj utolsó részét.
./sid_conv infile outfile -lal mintha a default beviteli eszközről kérné az adatot, a billentyűzetről.
0 hangerejű hullámformák cseréje 0 kitöltési tényezőjű négyszögjelre:Arra gondoltam, hogy ezt megoldom a programban magában, elméletileg csak pár bájt + (mondjuk 10-30)
Arra gondoltam, hogy ezt megoldom a programban magában, elméletileg csak pár bájt + (mondjuk 10-30)
Nem tudom biztosan, hogy ennek van-e gyakorlati hátránya, a file méret ugyan 7967 helyett 7973 byte lett, de ez nem nagy eltérés és file függő lehet.Szerintem nincs, lehet olyan file, ahol épp csökkenést eredményez.
4 byte lett :)
Ha 0 a hangereje a 3 jel valamelyikének, akkor 0-ra állítja a pwm regiszert, és ráugrik a négyszögjel feldolgozásra, a hangerő regiszter amúgy is 0 volt.
Még a PWM nullázása is megtakarítható lenne, 0 hangerőnél nem jelentene hallható különbséget, és a konvertáló program eddig is nullára állította ha nem négyszögjel a hullámforma.Oké, kiveszem :)
Az nem lehet, hogy a SID frekvenica értékét felezni kell? Most felezetten hallgatom, és így nem tűnik túl magasnak, a Cybernoidnál nem tűnt fel, de csináltam egy fájlt ACE II -ből, és annál nagyon feltűnő volt.
4MHz-es procival 10KHz-es sebességgel, kevesebb, mint 1 másodperc alatt csomagolja ki a 8K-s blokkot, a processzor sebességével egyenesen arányosan nő a lejátszási sebesség is, de csak a betöltés után van sebességteszt.
call random
push af
call random
pop hl
ld l,a
random ld hl,0000h
ld a,r
xor l
add hl,hl
xor h
ld l,a
xor h
ld h,a
ld (random+1), hl
ret
A random zaj így jó lesz?
fa:c5fex címen kezdődik, elméletileg a snapshot mentéselőtte történt.
Annyit csináltam, hogy a ld hl, 3456h-t lecseréltem a következőre:
Code: [Select]call random
push af
call random
pop hl
ld l,a
ezek a snapshotok megint nem működnek nekem....
Egy ideje már van nem beta 2.0.11 (https://github.com/istvan-v/ep128emu/releases/). :oops:Le is töltöttem , csak még nem jutottam el odáig, hogy fel is tegyem, de ma fel is teszem.
A "véletlenszerűbb" zajhoz valójában elég lett volna csak az eredeti rutin végén a JR utasítást módosítani, hogy az LD C, 12h helyett az LD B, C-re ugorjon, azaz ne inicializálja újra a generátort minden táblázatnál. Az 123456h helyett más kezdőérték is lehet, ami eltérő mintát (és talán jobb hangot) eredményez. Az egyszerűbb generátor minden futásnál eltérő kimenetű, mivel az R regiszert használja.Ezt nem tudtam, ezért gányoltam bele :) De mindjárt megcsinálom az agrós javítást.
Itt eredetileg elég volt a 8 bites véletlenszám is (csak az L regiszterben), a két random hívás (+CALL/RET) szerintem lassabb a régi kódnál. :oops: Azonban az L regiszterben már véletlenszerű érték található a random visszatérésekor.Itt nekem nem a gyorsaság volt a szempont, csak az, hogy a táblák változzanak. :)
8 bites DAC 8 MHz-es CPU frekvencián:Ez sokkal jobban szól, vagy csak a hangereje miatt tűnik úgy?.
Ez sokkal jobban szól, vagy csak a hangereje miatt tűnik úgy?.
Valahogy le lehet kérdezni, hogy van-e DAC csatolva a géphez?
Mivel a zene elsősorban négyszögjelet használ, a 8 bites DAC itt talán nem sok különbséget jelent, viszont a 20 kHz-es lejátszási frekvencia valószínűleg igen. :) És valóban hangosabb a DAVE-es verziónál, de az még használhatná a már említett DTM lejátszós megoldást.Elméletileg használja, betettem az inicializálást, és áttértem az A8 AF AC regiszterek írására.
Nem tudom, mivel ilyen hardver nem igazán készült egyelőre, vagy csak prototípus lehet valahol. :oops: Zozosoft korábban említett ilyen terveket, de jelenleg a DAC csak az emulátorban létezik, ahol a portjai (F0-F3h) csak írhatók. A 8 bites kimenet kissé bonyolítja a hangerő számítását, négyszögjelnél 3 bittel kell balra léptetni, a táblázat generálásnál pedig módosítani kell a kódot (zajnál a szorzás például nem hagyhatja figyelmen kívül az A felső 2 bitjét).Ezek szerint a táblákat is módosítottad a feltöltött snapshoban?
Ezek szerint a táblákat is módosítottad a feltöltött snapshoban?
Itt a teszt verzió, egyelőre még nem foglalkoztam a zene átalakítással, úgyhogy csak az egy teszt alanyom van.
Kipróbáltam -maxoffs 16384 paraméterrel újracsomagolva (9788 helyett 8728 byte lett), így is működik, és a régebbi Cybernoid II konverzióval is. :)Szuper :) Amikor még próbálgattam a külömböző értékeket, akkor bugos volt a lejátszó, és töröltem az összeset :oops:
Igen, a korábban feltöltött Lua script módosított változatával. A Z80-as kódon legalább 3 helyen kellene változtatni (négyszögjel hangerő, háromszög/fűrész hangerő, zaj hangerő számítása), és talán még a kivezérlésjelzőn is ha az 6 bites értékeket tételez fel.Akkor csak az elején választhatóra lehetne megcsinálni, vagy közben is, de akkor hosszabb a várakozás.
jó lenne ha ez a lejátszó kiejelzni hogy mennyi cpu időt visz elAlapból 100%-ot várakozással együtt :D
Alapból 100%-ot várakozással együtt :D
Úgy kb 80%-ot ha már ki van csomagolva minden, és 100%-ot csomagolás közben 4MHz-en.
Elméletileg minden javasolt változtatás kész, az egyik osztó rutinnal szenvedtem sokat, 62500-zal rosszul osztott,kisebb értékekkel jól, aztán lecseréltem, és azóta gond egy szál se :D , meg a sidplay átalakításával.
4 MHz-en jónak tűnik a frekvencia (C5h / 256 a szorzó, és PAL C64 órajelet feltételezve a pontos érték 197.05 lenne), azonban 8 MHz-en néhány százalékkal eltér (95 lesz 98.52 = kerekítve 99 helyett). De ez lehet, hogy csak a mérés pontatlansága.Elméletileg pontosan kéne számolnia, előbb kiszámolok egy DAVE megszakítás osztót(ez pontatlan, mert a 7812 Hz osztóját a 20h*4-et osztom a processzor sebességével. de ez nem számít), ezzel elosztom a 250 KHz-et, majd ennek az értékével osztom a 256*2*3848,5-ot, majd az eredményt 2-vel, ha van carry, akkor felfelé kerekítek, és a végén betöltöm az A2-A3-ba a kapott DAVE megszakítási osztó - 1 -et.
Lehet a SID max hangerejét számoltam pontatlanul, a neten talált 985248 Hz PAL CPU sebességgel számoltam: 3848,566274642947 = 65535 * 985248 Hz /16777216
Az szerintem jó, és 4 MHz-en pontos is a C5h, csak 8 MHz-en valamiért nem a fele lett, hanem 5Fh.Lehet azért, mert nem pont duplája a frekvencia.
Megnéztem, azért :) 4MHz-en 18h+1 az osztó, és 10000Hz, 8MHz-en 0bh+1 az osztó 20833 Hz-es a lejátszás, és ahogy számoltam ehhez jó a 95.
6, 7.12, 10MHz-re is számoltok? :oops: Ezt majd betöltéskor automatikusan beállítja a progi?Kerek MHz-nként számol, és betöltéskor belövi az osztóz, mint kiderült, van kis átalalkítanivaló.
Talán elég lenne a fix DAVE frekvencia beállítás is, valódi turbós gépen a DAVE mindig a Z80-al egyenes arányban gyorsul. Ez a rutin mindenesetre a ténylegesen beállított lejátszási frekvenciából (itt 18h) számítja a szorzót:Most így működik nagyjából, csak annyi a különbség, hogy Dave 50 Hz alatt számolja a Z80 utasításokat, ez alapján dől el később, hogy emulátor alatt indult a program, vagy nem.
(Attachment Link)
Lehetne még előtte külön Z80 teszt is (utasítások száma két 1 kHz-es megszakítás között) ami felismeri az emulált konfigurációt is, annak a pontossága kevésbé fontos, a lényeg, hogy ne állítson be olyan frekvenciát amihez nem elég gyors a CPU. :)
6, 7.12, 10MHz-re is számoltok? :oops: Ezt majd betöltéskor automatikusan beállítja a progi?
A következő verzióban talán növelhetném 1250000-re (ami 10 MHz-ig elég), a lejátszó tesztelése közben bug gyanús jelenséget is észrevettem, így lehetne egy 2.0.11.2 kiadás az esetleges javítással.
Itt a teszt verzió, egyelőre még nem foglalkoztam a zene átalakítással, úgyhogy csak az egy teszt alanyom van.
Ezzel a verzióval nekem a fűrészjelből (20h hullámforma) háromszög lesz. :oops: De ezt a konvertáló programban is lehetne javítani.Áááá, én szúrtam el, a táblák sorrendjét a kiválasztásnál jól lőttem be, de feltöltésnél felcseréltem a fűrészjelet a háromszöggel, elméletileg javítva, és az osztó számítás is valódi gépen, pár kisebb módosítás mellett betettem az ext DAC lejátszást is, 1-es gomb DAVE, 2-es ext DAC, menet közben váltható, annyi, hogy ilyenkor a váltás idejére elhallgat a zene.
az osztó számítás is valódi gépen
Most BFh lett 4 MHz-es konfiguráción, de még nem néztem, hogy van-e valahol hiba.Nekem 0c5h-t dobál.
A 191-es port be van állítva a méregetés előtt?Elméletileg be, azzal kezdtem az ellenőrzést, hogy BF port hányszor van írva, egyszer, igaz a program elején.
Az lehet a probléma, hogy ZozoTools-os konfigurációval teszteltem, amivel eltérő az LPT. A teljes hossza itt is 312 sor, de a VINT-es LPB hosszúságára érzékeny a kód, mert a VINT lefutó és felfutó éle közötti időt (ami kevesebb 312 sornál) méri. Az itt (https://enterpriseforever.com/sound/sid-lejatszo/msg61942/#msg61942) található rutin (ami pontos eredményt ad) az ilyen hibák elkerülése céljából csak a lefutó éleket figyeli.Tuti az lesz, arra nem gondoltam anno, hogy lehet más VINT-es LPB méret is :oops: , oké, megnzem majd a fent található rutint
Szerk.: az eredeti EXOS LPT-ben 14 soros a VINT, ZozoTools 1.9-el csak 6 soros.
Talán nincs nagy jelentősége, de FILE: eszköznél esetleg az A6h (érvénytelen file név) hibát kezelni lehetne, az IVIEW-ben már javítottam, hogy ne kérjen végtelen ciklusban file nevet, ha a felhasználó Cancel gombbal megpróbál kilépni. :) Illetve még a bemeneti file érvényességét is ellenőrizni lehetne, hogy nem megfelelő formátumú file esetén ne fagyjon le, de ez nem biztos, hogy megérné a bonyolultabb/lassabb betöltés miatt.Jó ötlet az A6h figyelése, én a nem megfelelő formátumú fájl figyelését kihagynám, ha valaki rossz fájlokat töltöget, az megérdemli :D , hacsak nem az egyszerű ellenőrzést, ha jól tudom az első két byte itt is a fájl hossza-2 , ezt lehetne összevetni a betöltött bájtokkal, amúgy Disk configon kiterjesztés ellenőrzés van, tudom ez meg se közelíti a bemeneti fájl ellenőrzést.
hacsak nem az egyszerű ellenőrzést, ha jól tudom az első két byte itt is a fájl hossza-2
amúgy Disk configon kiterjesztés ellenőrzés van, tudom ez meg se közelíti a bemeneti fájl ellenőrzést.
A fájlnak esetleg kitalálni egy rendes EXOS fejléct?
A fájlnak esetleg kitalálni egy rendes EXOS fejléct?úgy gondoltad, mint az 5-ös fejléc esetén, csak egy új, nem használt kódot rendelni hozzá, mondjuk 62h, és betenni a file hosszát, meg esetleg még valami azonosítót?
A 8 bites ellenőrző összeg könnyen tesztelhető, így általában felismerhető a nem -m2 file, de ez még nem teljesen megbízható, és lassítja is a betöltést (bár ezen a kódon még lehetne optimalizálni):Nekem ez sem tűnik túl időrablónak :)
Hiba esetén az A értéke nem FF lesz.Ezeket meg simán be lehet tenni, hely van még bőven a FILE-t tartalmazó szegmensen :)
Néhány egyéb tesztelhető tulajdonság:
- a file mérete legalább 16 byte
- a második byte kisebb mint 32
- a második és a harmadik byte nem lehet egyszerre 0
Nekem ez sem tűnik túl időrablónak :)
Ezeket meg simán be lehet tenni, hely van még bőven a FILE-t tartalmazó szegmensen :)
Does it serve for the 4-10Mhz Z80 range?
Közben lehet rájöttem, ha nyomok egy jópofa resetet, mihelyt eléri a 0000-ás címet, akkor menti ki a töredék bájtokat. :lol:
Valóban, a felvételt a reset állítja le, hasonló megoldást más scriptekben is használtam. :oops: A legjobb az lenne, ha meg lehetne állapítani, mikor ér véget a zene, és azt figyelni (nem tudom, a PSID/RSID formátum erre ad-e lehetőséget). Talán a port írásnál is meg lehetne oldani, hogy DAVE módban is működjön a felvétel.Elméletileg meg, mert a D400-D41Fh tartalmazza a SID regisztereket, most épp azon küzdök ,hogy ha SID módba kerül a lejátszás, akkor mentsen. ha Dave-be, akkor fejezze be, egyelőre nem sok sikerrel.
A legjobb az lenne, ha meg lehetne állapítani, mikor ér véget a zene, és azt figyelni (nem tudom, a PSID/RSID formátum erre ad-e lehetőséget).Hogy mit tud, és mit nem a fájl formátum én sem tudom, de a HVSC-nek része egy Songlenghts.txt fájl. Ebből ki lehet olvasni, bár másodpercnél nincs benne pontosabb adat. Gondolom egy kicsit tovább játszva és a felvett adatokban ismétlődést keresve pontosan belőhető a tényleges hossz.
Elméletileg meg, mert a D400-D41Fh tartalmazza a SID regisztereket, most épp azon küzdök ,hogy ha SID módba kerül a lejátszás, akkor mentsen. ha Dave-be, akkor fejezze be, egyelőre nem sok sikerrel.Már kezd működni, csak a SID regiszter 0-ázása kavar be, ezért ha hosszan nyomom az F1-et, akkor leallokál több üres file-t.
A legjobb az lenne, ha meg lehetne állapítani, mikor ér véget a zene, és azt figyelni (nem tudom, a PSID/RSID formátum erre ad-e lehetőséget).Ahogy nézem a SID file headert, sajnos nem látok semmi e célra használhatót. :(
Ahogy nézem a SID file headert, sajnos nem látok semmi e célra használhatót. :(
Azt nem lehet figyelni, hogy újra az első címtől kezdi játszani? Vagy nincs ilyen?
Hogy mit tud, és mit nem a fájl formátum én sem tudom, de a HVSC-nek része egy Songlenghts.txt fájl. Ebből ki lehet olvasni, bár másodpercnél nincs benne pontosabb adat. Gondolom egy kicsit tovább játszva és a felvett adatokban ismétlődést keresve pontosan belőhető a tényleges hossz.Ez jó ötlet, le lehetne állítani a mentést egy beállított fix idő után, ami a txt file alapján lenne belőve.
acttime = os.time()
minv = 1
secv = 0
endtime = os.time() +minv*60 + secv
while os.time()~=endtime do
end
Ez így működőképes lesz? Teszt alapján 1 percig nem tudtam csinálni semmit az emuban :)
disk image-khez nem értek és nem is akarok :)Höööööööööö???? Kell ahhoz egyáltalán érteni? A ep128emu telepítésekor meg lehet adni, hogy alapértelmezetten ezzel legyenek megnyitva az ilyen fájlok. De ha akkor nem állítottad be, a jobb gombos menüben a társítással egyedileg is megadhatod az egyes fájlokra. Már ha Windows az operációs rendszered.
Szerintem célszerűbb lenne az 50 Hz-es (azaz pontosan 50.0363257 Hz-es EP-n és 50.1245732 Hz-es PAL C64-en) megszakításokat számolni egy változóban, a valós idő mérése érzékeny az emuláció sebességére.Oké, első tippem ez volt nekem is, azt gondoltam, hogy a time változó lesz a jobb választás, akkor ez alapján indulok el.
néha berakhatnátok olyan snapshotot amiben van sok sid is, mert én amiket beraktok nem tudom működésre bírni, disk image-khez nem értek és nem is akarok :)Én se használok disk image-ket, a working folderbe pakolok mindent, és FileIO-s konfiggal mindent pik-pak be lehet tölteni.
Én se használok disk image-ket, a working folderbe pakolok mindent, és FileIO-s konfiggal mindent pik-pak be lehet tölteni.
de itt ez hogy műxik? nekem amiket ide beraktatok azok a: drive-t listázzák
Az valószínűleg lemezes konfiguráció, helyette például az "ep128uk\EP_128k_Tape_FileIO.cfg"-t betöltve (Alt+Q) már használható a FILE: eszköz.
be van nekem állítva a fileio, írtam is hogy én csak azt használom mindenreIgen, de van EXDOS is a konfigban, válassz egy EXDOS mentes FileIO-s konfigot, ahogy István is ajánlotta
Talán az acttime nullázása hiányzik? Ha már elérte a lejátszási idő végét, akkor a következő file elején már azonnal acttime >= playtime lesz, így befejeződik a felvétel.igen, igen, és igen :lol: Köszi.
Az mprint hogy működik, mert tesztként betettem, de nem láttam sehol az üzenetet.
mprint ("save time elapsed")
Elvileg a monitor ablakba írja az üzenetet.Írja is, csak én nem vettem észre eddig :)
Valami nem stimmel, szerintem az envelope emulációban lehet a gebasz, leginkább a Last Ninja 2-nél jön elő, először arra gondoltam, hogy a LUA-ban rontottam el valamit, de annak a többi SID-re is hatással kéne lennie, elég sok jónak tűnik.
Az eredeti Last Ninja 2 SID file hol található? :oops: Lehet a Lua script hibája is, a file formátum nem teszi lehetővé annak a tárolását, ha egy SID regiszter egy 50 Hz-es megszakítás időtartamán belül egynél többször változik. Ez problémát okozhat például a trigger bitnél: ha a lejátszó egy új hang indítását úgy oldja meg, hogy csak rövid időre 0-ra állítja, majd azonnal 1-re, akkor ez az esemény elveszhet:A módosított sidplay ugyenilyen módon ment, 50Hz-enként az összes regiszter tartalmát, és az envelope utánzás is csak a megszakításokban fut. Egyébként tényleg olyan, mintha a sustain maradna el.
Azt nem értem, hogy egy általam módosított lua-t (sidrecn.lua lejjebb csatoltam) használtam tegnap, ami minden megszakításban kiírja a d400-d418h-t a tömbbe, miért rossz, amikor a módosított sidplay-ben ugyanezt teszem, igaz ott már a volume értékek envelope "emuláltak", de az envelope emuláció is csak a megszakításokban történik, tehát elméletileg ugyanennek a hibának ki kéne jönnie.
A trigger alatt a gate bitet érted?
Nem tudom pontosan, hogyan működik a burkológörbe emuláció a SIDPLAY-ben. :oops: De például a GARFIELD.SID-ben a problémás hangok burkológörbéje 0,9,0,9, azaz nulla a sustain, talán nem cseng le erre a szintre? Szerk.: ha jól látom, van még az 50 Hz-es burkológörbe emuláción kívül ellenőrzés a regiszterek írásakor hogy változik-e az érték, és ha igen, akkor (bár ebben nem vagyok biztos) újraindítja a burkológörbét.
Esetleg a sidrec.lua kimeneti formátumát tovább lehetne fejleszteni, hogy valamelyik nem használt bit (pl. a 3-as regiszter felső bitje) legyen a trigger kezdeti állapota az adott megszakítási ciklusban, így nem veszik el ez az információ.Így gondoltad?
Így gondoltad?
azt ne áruljuk el hogy a teljes cpu időt elviszi a lejátszás : o )
Köszi, lassan kezdem elölről a konvertálást, most gyűjtöttem ki a kiválasztott sid-ek hosszait.
Miért ne vinné el, ha a legjobb minőség a cél? :) Természetesen játékba vagy demóba épített lejátszónál lehetséges 8 kHz-es frekvencia, a gyűrűmoduláció effektus törlése, vagy egyéb gyorsítás,de 11KHz-en még jó volt.Igen, és amúgy is van kb 20% szabad CPU-nk :D , kipróbáltam 12,5 KHz-en, úgy már volt fagyi, gondolom olyan blokkoknál, aminek kicsomagolása tovább tartott.
Szerintem érdemes lenne gyűjteni a még nem konvertált file-okat is, így esetleges újabb konvertáló programnál nem kell mindet újra felvenni, és lehetőség lenne SID kártyás lejátszásra is.Igen, erre jutottam én is, egyrészt egyszerűbb mindent külön file-ba menteni, és nem egyesével konvertálni, másrészt meg jól jöhet, igen a forrás file :)
Egy hibát jelzett a sid_conv.cpp fordulás közben, de azt még én is tudtam javítani :D (78. sor bezáró zárójel hiány :) )
Itt a konverzió eredménye, amit eddig hallgattam, az jó volt, kivéve az Armalyte1 és a Dragon Ninja, előbbinél sztem vagy kevés a 10KHz, vagy használnak valami spéci cuccot, másodiknál meg a lejátszás is trükkös volt, lehet ez kevert be. Ghosts'n'Goblins1 érdekes, brekeg :D
A felvételek készítésénél érdemes lehet még nagyobb Z80 órajelet (pl. 10 MHz) beállítani, 4 MHz-en előfordulhat, hogy lassul vagy akadozik az eredeti SID lejátszása a 6502 emuláció miatt. A CYBERNO2.M64-nél például hallható ilyen probléma.Igen, nekem is feltűnt, tegnap 6MHz-en ment az emu felvétel közben, ma nem mertem, hátha befolyásol valamit, most néztem meg a Paperboyt, az meg amiatt lassú, mert legalább 100Hz-es a lejátszási sebessége, foglalkozzunk az ilyenekkel, vagy könyveljük el veszteségként ? :)
Az jutott eszembe, hogy nagyobb munka lenne betenni a lejátszandó fájlba a sebességet, helyette be lehetne tenni a lejátszóba a sebességválasztást.
A file formátumba nem lenne nehéz beépíteni, még mindig van például néhány szabad byte a blokkok végén, de tartalmazhatná esetleg EXOS fejléc is. Bár a lejátszót bonyolítaná a különböző sebességek megfelelő támogatása, és előfordulhat például 60 Hz is, ami nem 50 többszöröse. Az is egy lehetséges megoldás, hogy a konvertáló program gyorsítsa/lassítsa a felvételt, de ez rontaná a zene időzítésének a pontosságát. A sebességet a sid_conv.cpp-ben mindenesetre figyelembe kellene venni (a 20000 konstans a SID ciklusok száma két megszakítás között), hogy a burkológörbe emuláció pontos legyen.Hm, EXOS fejléc lenne a legjobb, de a legkönnyebb meg a szabad bájt talán, de a leges legkönnyebb, a lejátszóba épített, manuális váltás :D
Hm, EXOS fejléc lenne a legjobb, de a legkönnyebb meg a szabad bájt talán, de a leges legkönnyebb, a lejátszóba épített, manuális váltás :D
Melyik legyen?
EXOS fejléc nélkül egyszerű:Te a megadható frekvenciára gondoltál? Én a CIA regiszter letárolására, még mielőtt utánanéztem :D , de látom ez sem egyszerű, mert van 4 db időzíthető CIA regiszter. Lehet a sidplay-be kéne beletenni, hogy kiírja a lejátszó rutin sebességét?
Ennél a verziónál opcionális paraméterként megadható a megszakítás frekvenciája 50 és 300 között:
./sid_conv [INTFREQ [BLKSIZE]] < INFILE > OUTFILE
Ezt a paramétert a burkológörbe emuláció figyelembe veszi, és az első blokkban 1FFDh pozíciónál (ha BLKSIZE = 8192) tárolja az INTFREQ - 50-et. Azaz az alapértelmezett 50 Hz-nél a kimenet azonos lesz a korábbi verzióval.
Az EXOS fejléc is könnyen megoldható a konvertáló programban, csak még definiálni kellene a formátum részleteit. Az az előnye mindenesetre lenne, hogy ROM-ba épített lejátszó EXOS modul betöltéssel is használható lehetne, és a frekvencia érték olvasásához nem kellene először kicsomagolni az első blokkot.Elméletileg ezek mind megvannak az EP128EMU SRC folderében, csak oda kéne tenni gondolom a sid_conv.cpp-t a könyvtárba, vagy az elérési utakat bedrótozni. Egy kérdés, linux alatt hogy lehet jó futásra készen shell scriptbe ágyazva futtatni a ./sid_conv <input> outputot, ha csak úgy simán bevágtam a fájlba a 120 parancsot, és futtattam (desktopomon volt minden) , akkor az első fájlt csinálta a amíg szegmentation errort dobott, végtelenségig az első fájllal dolgozva.
Így azonban a tömörítést is a sid_conv.cpp-be kellene építeni, ami a használhatóság szempontjából praktikus is, csak a program fordítása lenne bonyolultabb, mert kellene hozzá az ep128emu forráskódja és a libep128emu.a és libepcompress.a is.
Elméletileg ezek mind megvannak az EP128EMU SRC folderében, csak oda kéne tenni gondolom a sid_conv.cpp-t a könyvtárba, vagy az elérési utakat bedrótozni. Egy kérdés, linux alatt hogy lehet jó futásra készen shell scriptbe ágyazva futtatni a ./sid_conv <input> outputot, ha csak úgy simán bevágtam a fájlba a 120 parancsot, és futtattam (desktopomon volt minden) , akkor az első fájlt csinálta a amíg szegmentation errort dobott, végtelenségig az első fájllal dolgozva.
EXOS fejléc:Úgy nézem ez még szabad.
- 00h, 4Fh (nem tudom, ezt már használja-e valami más is)
Azon gondolkoztam, hogy a LUA-t is módosítom , hogy ennek megfelelően tárolja a sebességet a 3ffdh címen, milyen kiosztasban vannak az ertekek?
0 - 50Hz
1 - 100 Hz ... ?
50-nel kevesebbet kell tárolni, azaz 0 = 50 Hz, 50 = 100 Hz, stb. Lehetne például ennél a résznél:oké :) Már értem is a mi volt a -50 Hz :)
Továbbfejlesztett sidrecn.lua::smt041
A sebesség értéket mindig fix pozícióból veszi, vagy LPT alapján ( még nem néztem, majd este ) mert EXOS LPT-t buherálom.
A 150 Hz-es Paperboy snapshotban akadozik a zene, bár elsősorban azért, mert a felvétel 4 MHz-es konfiguráción készült. :oops:Van pár cucc, ami reprodukálásra vár, Cybernoid (ebből mindkettő, vagy csak a második? ) Paperboy )
Ha a Z80 órajel növelésének nincs hátránya (nem tudom, a CIA időzítőket a lejátszó hogyan emulálja), akkor talán a legbiztosabb lenne mindet 10-20 MHz-en felvenni. :) SID kártya emuláció nélkül még így is elég gyors Alt+W-vel.CIA időzítőkre sincs káros hatással, CIA értéktől függően helyez el VINT biteket az LPT-ben :) 10-20 MHz-en tuti nem lesz gond :), én csak a 6-ra gondoltam, de egy 10-est lehet tolni neki majd.
Tuti ez lenne a legjobb megoldás, de ez iszonyú munka, nem?
Ergognomik vetette fel, hogy PLUS4emu-ban játsszuk le a SID-eket, és onnan nyerjük ki a regiszter értékeket, gondolom a megszakítások ugyanolyan pontosan mennek, mint C64-en mennének.
Nem feltétlenül, ha a "C64 emulátor" rész nagyon kezdetleges. Azaz gyakorlatilag csak a CPU, és a program bizonyos fix időközönként megszakításokat generál. Ez már csak azért is előnyös lenne, mert a SID, 2xCIA, VIC-II, stb. emulációja lassítaná a konvertálást.Gyanúsan ennyi, ami rémlik, NTSC bit, ha be van állítva, akkor 60Hz, egyébként vagy user interrupt (CIA), vagy 50Hz.
A Plus/4-ben nincs CIA (de van programozható 16 bites időzítő) és más az órajel, de talán vannak SID lejátszó programok a gépre, mivel kártyából több is készült. A PC-s program előnye elsősorban a nehézkes kézi felvétel (időtartam beállítása, zenék kiválasztása egyenként, stb.) elkerülés lenne.jogos.
Valamennyire már működik a PSID konvertáló, de a hosszúság automatikus felismerésére az ötletem nem vált be, a lejátszókban sok az önmódosító kód, és így nem ismétlődik a memória tartalma. Egyelőre csak a parancssorban lesz megadható, ez még mindig automatizálható egy shell script és a Songlengths.txt használatával. Sok file azonban hiányzik a Songlengths.txt-ből (vagy valahol van újabb verziója?).Csak arról a Songlengths.txt tudok, ami HVSC csomagban van. Azonban létezik egy SOASC, vagy valami hasonló nevezetű gyűjtemény, ami elvileg az összes HVSC-ben megtalálható SID átkonvertálva MP3-ba. Abból esetleg ki lehet olvasni a hosszakat.
Sok file azonban hiányzik a Songlengths.txt-ből (vagy valahol van újabb verziója?).Én is a legfrissebb HVSC csomagból szedtem ki a songlengthet, 48943 entry van benne, amiket én néztem, mind benne volt :)
Én is a legfrissebb HVSC csomagból szedtem ki a songlengthet, 48943 entry van benne, amiket én néztem, mind benne volt :)
Most valóban megtaláltam például a Paperboy-t, de az md5sum különbözik:Ilyen apróságokkal nem kell foglalkozni ;)
Ez a verzió még hibás lehet, de valamennyire már használható:Tehát ha jól értem, akkor már el is készült a direkt SID-ből konvertáló program első verziója?
sid_conv.cpp pontosabb 50 és 60 Hz-es időzítéssel (a tényleges PAL és NTSC C64 frekvenciákat tételezi fel a burkológörbe emulációnál):
Az időtartamok a parancssorban közvetlenül is megadhatók, az alapértelmezés 4 perc.
Az új sid_conv.cpp használható továbbra is EP-ből mentett raw-ra is?
A Paperboy nem jó, ugyan 150 Hz-es frekvenciát ismer fel a program, de így túl gyors a felvétel, 50 Hz-en lejátszva viszont jobbnak tűnik.Úgy rémlik az igazi játékból is, hogy az elején a zenét tök gyorsan játsza, és játék közben lassabban, és a SID lejátszása közben is így műxik, az első zene ugyanaz, mint a 2. csak az 150Hz-es, míg a 2. 50Hz-es, kiszámoltam a múltkor a CIA megszakítás alapján, majdnem kereken 150Hz jön ki az elsőre.
A file headerben a megszakítási sebesség csak 60, és 50 többszöröse lehet? Mert ha igen, akkor nem szórakozok a kicsomagolt első blokkból való megállapítással, hanem veszem a file headert, ez egyszerűbbnek tűnik.
Az első blokk végén már csak a "raw" formátum tartalmazza a sebességet, konvertáltnál az EXOS fejlécben található. Itt egyszerű 16 bites érték Hz-ben, és elvileg bármi lehet, de valószínűleg csak ritkán nem 50 vagy 60 többszöröse, tehát az ilyenek támogatása nem igazán lényeges.Ok, köszi, így is álltam neki végülis, itt is max 300Hz-ig megy majd a beállítás (és csak 50 Hz-enként) némi pontatlansággal az EXOS LPT egyenetlensége miatt, vagy álljak át egy saját LPT-re? (mert amúgy is van szabad szegmens)
Ok, köszi, így is álltam neki végülis, itt is max 300Hz-ig megy majd a beállítás (és csak 50 Hz-enként) némi pontatlansággal az EXOS LPT egyenetlensége miatt, vagy álljak át egy saját LPT-re? (mert amúgy is van szabad szegmens)
elméletileg működik az 50x Hz frekvencián való lejátszás max 300Hz-ig, ezt most fogom tesztelni majd a paperboyjal.
Nekem működik, azaz túl gyors (mint eredetileg). :):smt043
Szerk.: néhány ezek (https://enterpriseforever.com/sound/sid-lejatszo/msg62087/#msg62087) közül továbbra sem működik, három a fejléc szerint hangmintát használ, kettőnél lefagy az init rutin, és egy túl sok zenét/effektust tartalmaz (ami ugyan könnyen javítható lenne, jelenleg a program legfeljebb 32-t fogad el).A MYTH-ről, és a GPC-ről tudom, hogy digi van bennük (anno sokat játszottam velük), a Mythben a második tune a digi (Welcome to Myth szöveg), sidplay-jel azt átugrottam, és úgy vettem fel a harmadikat, a GPC-ben digi gitár van, lehet az első kettő tune-ban.
Próba konverzió, még nem ellenőriztem, hogy jó-e az eredménye:A Last Ninja 2, Cybernoid tuti jó, azokat konvertáltam én is, és teszteltem is :), a Paperboy első számában (a gyorsban) mintha ez egyik csatorna túl halk lenne, a többi jó.
a Paperboy első számában (a gyorsban) mintha ez egyik csatorna túl halk lenne, a többi jó.
Itt az új verzió, saját LPT-t használ, új logoval, még azon gondolkoztam, hogy egy mozgó raster bart be lehetne tenni.
Jó lett, elvileg 4 MHz-es gépen még problémás lehet az 50 Hz-nél lényegesen nagyobb sebesség, de úgy látom, 150-nél még marad elég idő, ennél gyorsabb file pedig még nem volt eddig:Köszi :) , eggyel találkoztam, a HVSC.SID 200Hz-es volt, az is ment gond nélkül, még azon gondolkozom, hogy a volume display csak 50Hz-enként legyen frissítve, csak ezt akkor át kell tennem a FILE-t tartalmazó lapra, mert már nem tudom besuvasztani a 0000-0500h területre.
Ezen egy keveset sikerült javítani a frekvencia szorzó rutin átalakításával, de így nagyobb és bonyolultabb lett, tehát nem igazán érné meg:Attól függ mennyivel lett nagyobb, és bonyolultabb, egyelőre 3 byte szabad a fent említett területen, ha a volume display elköltözne, akkor kb 30 byte felszabadulna, és esetleg a 0000h-002eh területet használhatnánk még, meg a 007a-009fh-t
Bár ez csak a konvertáló programot érinti, lehetőség lenne még arra is, hogy eredetileg 50 Hz-es file is nagyobb frekvenciájú (pl. 100 Hz-es) burkológörbe emulációt használjon, de ez növelné a kimenet méretét.
Köszi :) , eggyel találkoztam, a HVSC.SID 200Hz-es volt, az is ment gond nélkül, még azon gondolkozom, hogy a volume display csak 50Hz-enként legyen frissítve, csak ezt akkor át kell tennem a FILE-t tartalmazó lapra, mert már nem tudom besuvasztani a 0000-0500h területre.Attól függ mennyivel lett nagyobb, és bonyolultabb, egyelőre 3 byte szabad a fent említett területen, ha a volume display elköltözne, akkor kb 30 byte felszabadulna, és esetleg a 0000h-002eh területet használhatnánk még, meg a 007a-009fh-t
Továbbmentem a Ninja-ig, a Navy Seals első három (tovább ezt nem néztem) csupa 0-át csomagol ki.
Elég nagy a méretkülönbség, mert ciklus helyett egyszerűen "kiírtam" ezt 8-szor, illetve az ADD HL,DE-k helyére FEh (CP utasítás) byte került a szorzó 0 bitjeinél:Hm, holnap megnézem, lehet jól jön majd egyszer az a kis gyorsulás is :DCode: ZiLOG Z80 Assembler
add hl, hl rla add hl, de adc a, c
Ez természetesen csak a 0-2Eh területen fért el, és minden szorzó más kódot igényelne (bár a generálása történhet a FILE-os szegmensen). A CP-k helyett tulajdonképpen ki is lehetne hagyni az utasításokat, ami még gyorsabb valamivel. A hívásokat RST 0-kra lehetne cserélni, ami viszont megtakarít egy kevés helyet, és az eredeti rutin (amit ugyan használ a sebesség tesztelő kód, de ott lehetne másolata) törlése is. Azonban amint az a képeken látható, nem nagy a különbség az eredeti kódhoz képest, ezért nem biztos, hogy megéri.
A kivezérlésjelző "költöztetése" nem igényelné a hangminta megszakítás tiltását?Elméletileg nem, mert a 3-as lapra kerülne a kivezérlés, ez csak akkor okozhatna gondot, ha ezalatt az idő alatt történne még egy videó megszakítás.
Ez sid_dump bug lehet (lefagyott a 6502 kód?), holnap megnézem.simán lehet, mert gyanúsan az összes üres :)
Az IK tömörítésén talán lehetne javítani a minőség romlása árán, például a PWM, vagy eseteg a frekvencia vagy hangerő felbontásának a csökkentésével.
Elméletileg nem, mert a 3-as lapra kerülne a kivezérlés, ez csak akkor okozhatna gondot, ha ezalatt az idő alatt történne még egy videó megszakítás.
Az is egy lehetőség, hogy a video megszakítás nagy része átkerüljön a FILE-os szegmensre. Ha a hangminta lejátszás nem használja a 2. és 3. lapot, akkor a kód kerülhet a 2. lapra, a video szegmens pedig átmenetileg a 3. lapra. A szegmensek mentése, beállítása és visszaállítása ugyan lassulást eredményezne, de a több hely miatt talán jobban optimalizálható lenne a kód. Csak a szorzás gyorsítása megoldható lapozás nélkül is, ezért ennek az átalakításnak elsősorban az lehetne az előnye, ha 400h alatt is elférne a lejátszó a 0. lapon.Ez megfontolandó :) , és elméletileg nem is kell menteni a szegmenseket, simán mehetnek előre beállított értékekkel.
Ha nem probléma a nagyobb verem használat, akkor valamivel gyorsabb lehetne először mind a 12 regisztert kiolvasni (fordított sorrendben) és a verembe menteni, majd a megfelelő helyeken POP utasításokkal olvasni. Ennek az is előnye, hogy az adat feldolgozása közben már nincs szükség a kicsomagolt blokk szegmensére, így az kilapozható.Elméletileg nem, a hiba rutin került 00a0h-ra, a verem 0100h-n, és lejátszás közben +6-7 érték kerül be, a FILE-nak kellett más helyre tenni a vermet, mert az belecsúszott a hiba rutinba.
és elméletileg nem is kell menteni a szegmenseket, simán mehetnek előre beállított értékekkel.
A mentés akkor lehetne hasznos, ha video megszakítás kezelése közben történik újabb video megszakítás. Ilyesmi normál esetben ugyan nem fordul elő, esetleg a lejátszás indításakor vagy ha a megszakítás egyéb okból hosszabb ideig tiltott volt, de a probléma elkerülhető az engedélyezés előtt a B4 porton törölve a tárolókat.Végülis nem nagy időveszteség, és gondolom nem a vermet kéne hassználni a problémák elkerülése végett :), igaz nekem a 2. megoldás szimpatikusabb, még egy megoldás jutott eszembe, de ez gyanúsan lassabb, mint a regiszter mentés, ha aktív a videó megszakítás, annak elejére egy ret-et tenni, és amikor lefut az első videó megszakítás, akkor visszakerülne a push af.
A Navy Seals azért nem működik, mert felülírja nullákkal az FFFE-FFFF címen az IRQ vektort. Ha valójában nem hasznos adatot tárol ott, akkor javítható lenne az IRQ cím beállításával az init rutin futása után.Sidplay-jel műxik, nem tudom mi lehet a különbésg, egyelőre csak a kód relokálás jut eszembe, de az IRQ vektor felülírást az nem orvosolná.
még egy megoldás jutott eszembe, de ez gyanúsan lassabb, mint a regiszter mentés, ha aktív a videó megszakítás, annak elejére egy ret-et tenni, és amikor lefut az első videó megszakítás, akkor visszakerülne a push af.
Rambo-01-ben a 3. byte végig 0 (volume-ot is tartalmazó byte)
Itt valamiért a 24-es regiszter mindig 0 a sid_dump kimenetében. Ugyanez történik a PSID-et Plus/4 emulátorban betöltve és futtatva, látszólag működik, de nem ír a $D418 címre. >D418 0F után már van hangja ("f d400 d41f 0" és utána "g 400" indítja újra):Érdekes, mert sidplay is néha hallgat nagyokat egy ideig, és utána kezdődik a hangos lejátszás :D
(Attachment Link):smt041 :smt041 :smt041
- a hangerő regisztert az init rutin hívása előtt 0Fh értékre állítja 0 helyett
- a megszakítás kezelő és egyéb kód mindig a 0420h-043Fh területre kerül, de a PSID betöltése előtt EA20h-ra is, hogy lehessen megszakításból JMP $EA31-el visszatérni
- ha van play rutin cím, akkor a megszakítás vektort (FFFE-FFFF) az init hívása után újra beállítja
- 32-nél több zene egy PSID-ben nem eredményez hibát, de csak az első 32-t konvertálja (nem ideális megoldás, bár az első néhány után általában csak effektusok vannak)
az osztó (szorzó) rutin 0000h címre generálva
A raszternek van egy kis hiányossága, a CPU , és a lejátszási sebesség kitakarja, eredetileg azt akartam, hogy e kijelző mögött menjen, de sokat lassított volna, így maradt ez a megoldás, thekinthetjük fícsörnek is :D
Nagyon jó lett, ez már gyakorlatilag késznek tűnik. :)Koszi, bar a nagy resze a te otleted, en csak megvalositottam, vagy beepitettem :)
Itt valójában már nem kell az A regisztert a szorzóval inicializálni, lehet akár 0 is. De a pár byte és ciklus különbségnek nem sok jelentősége van.Ertem :)
Megoldható lenne a szöveget attribútum vagy 4 színű pixel módban kiírva, de ha ez lényegesen bonyolultabb (például már nem EXOS hívásokkal történik a megjelenítése), akkor talán nem érné meg.Ez igaz, attributum mod tan nem tenne sokkal bonyolultabba, kell egy karakterkiiro cucc, meg az attributumot kell feltolteni.
Találtam még egy kisebb hibát, ha új file választásakor (Esc) hiba történik, akkor lefagy a program, mert az EP logóhoz kilépő rutin már nincs az eredeti helyén (felülírták a hangminták).Koszi, nekem meg az jutott eszembe, hogy a interrupt delete nem mukodik jol a 300 Hz eseten.
Ha kész van az egész, akkor írtok egy "user manual"-t? :oops:Tervben van :)
A konvertálásról is? ( Ezt is gondoltam betenni )Igen, hogyan jutunk el onnan, onna, hogy a .SID letöltve, odáig, hogy szól az EP-n :-)
Igen, hogyan jutunk el onnan, onna, hogy a .SID letöltve, odáig, hogy szól az EP-n :-)Már egyszerűen :) a siddumpnak, és sidconvnak köszönhetően :) De majd lesz leírás is.
Ha már konvertálás, készítettem Windowsos (x64) csomagot a sid_dump és sid_conv programokból::smt041
Ááá, szerintem pont jó így az IK miatt nem érdemes sztem belenyúlni, legalább 6 percet át lehet alakítani, és ugyi a SID_DUMPnak időtartamot is meg lehet adni :) Én még anno a LUA-val mentettem a 6:32-es hosszú IK-t :)
Úgy értettem, csak az IK-t konvertálni rosszabb minőségűre :), 15 bites frekvenciával, 5 bites PWM-el és 4 bites hangerővel (3 sor módosítás az snd_conv.cpp-ben) a teljes hosszúságú file mérete 38094 byte-ról 34704-re csökkent. Bár azt nem hasonlítottam össze, mennyivel lett rosszabb így a hang. Csak érdekességként próbálkoztam még M0 tömörítéssel, ez 37590 méretet eredményezett, ami még a kicsomagoló nagyobb memóriaigényét sem egyenlítené ki. Az -m2 -blocksize 4096 -maxoffs 8192 (2*4K puffer) 46078-ra növelte a file méretét, viszont így 8K extra hely lehetne a betöltésére. De nem igazán érné meg, mert nem csak a lejátszót kellene átalakítani, hanem az összes többi (eddig is működő) file is nagyobb lenne.Ez egy érdekes teszt, azt gondoltam volna, hogy ezzel a butítással többet lehet nyerni, mondjuk a dupláját.
Ez a 4Ks puffer eszembe jutott nekem is, hogy nyerhetnénk vele 8k-t, de példa mutatja, hogy az a 8k el is ment a file növekedésével, igaz ez egy extra kivétel, de 2-4 K-s növekedés tuti lenne a többi fájlnál is, amik megy ugyi beférnek a mostani setupba is :)
Még azzal próbálkoztam, hogy az azonos funkciójú regiszterek egymás után kerüljenek (csatorna:regiszter helyett regiszter:csatorna szerinti rendezés), de ez is csak 38094-ről 38030-ra csökkentette a méretét, ami nem jelentős.Úgy látszik, pont jók vagyunk így :)
Ha nincs hiba, akkor csomagolom LZ-vel, kb 6K lesz, és az lesz a kész verzió.
SIDBASIC.COMHol vannak olyan fájlok, amiket ezzel lehet megnyitni és lejátszani?
Kicsit elmaradtam, nem tudtam nagyon olvasni a fórum minden részét...
Nekem 4967 byte lett (epcompress -m3 -noborderfx SIDBASIC.COM SIDBASIC.COM).Bocs rosszul emlékeztem, és 1 K-val tévedtem fölfelé, én DTF-et használtam, és úgy terveztem, hogy raw-ként becsomagolom, és úgy csinálok egy 5-ös fejlécű fájlt a kicsomagoló rutinnal, nem is tudtam, hogy az epcompressel ezt egy lépésben is lehet, így még egyszerűbb, köszi.
nem is tudtam, hogy az epcompressel ezt egy lépésben is lehet, így még egyszerűbb, köszi.
5-ös és 6-os fejlécű (.com és .ext) file-t tud önkicsomagoló rutinnal tömöríteni, az előbbinél a tömörítetlen program 4 szegmens méretű is lehet, amit az EXOS egyébként nem tudna betölteni.Ez szép, most, hogy mondod, valami rémlik, hogy láttam, csak kipotyogott a rövid memóriámból :lol:
- ha túl nagy lenne a kimeneti file (> 24336 byte), akkor automatikusan megkeresi azt a hosszúságot, ami még elfér; az IK például 4 próbálkozás után 24124 byte méretű leszCool :smt041
A sid.7z-t is cseréltem, most már van lejátszható ik.m64.Ez szép, Endinek készült? :D
Szerk.: SIDBASIC snapshot 8 MHz-es konfiguráción RAMDISK-en 303K zenével:
(Attachment Link)
Ennek a lejátszónak hogyan lehet megfogalmazni a lényegét? SID hangminták vannak letárolva, abból dolgozik?Igen.
Igen, és amúgy is van kb 20% szabad CPU-nk :D , kipróbáltam 12,5 KHz-en, úgy már volt fagyi, gondolom olyan blokkoknál, aminek kicsomagolása tovább tartott.
50 Hz-es megszakításnál úgy látom, a 11364 Hz (DAVE frekvencia = 21) még működik, bár a mozgó raszter villog a képernyő felső részén, és a 150 Hz már bizonytalan lehet. Többet kellene tesztelni, előfordulhat, hogy csak több blokk lejátszása után vagy újraindításkor jelentkezik hiba (a kicsomagolás nem tudja elég gyorsan feltölteni a puffert). Különösen újraindításnál, mert az utolsó blokk rövidebb. Gyűrűmoduláció nélkül fordított változat (- 37 ciklus) talán működhetne 12.5 kHz-en is.Nem meléxem én pontosan min teszteltem a 12.5KHz-en kívül, hogy Dave frekvencia = 21, vagy 22-n, amin stabilan működött, szerintem a gyűrűmoduláció nélküli működhetne 12,5 KHz-en is, de érdemes lenne a ring modot eldobni a nagyobb sebesség miatt?
érdemes lenne a ring modot eldobni a nagyobb sebesség miatt?
Ha teljesen nem is, esetleg lehetne külön gyűrűmoduláció nélküli verzió (feltételes fordítással), sok zene nem használja az effektust. De nem biztos, hogy megérné ezért két változatot készíteni, turbós gépeken pedig már most is elég magas a frekvencia.Igen :) , és egész jól szól már 4 MHz-en is, lehet már 6-on is tuti, de 8-on 100%
Ha jól látom, ebben a verzióban még egy FILE hiba lett javítva a Shift+Fel használatakor?Igen, amikor a FILE-t ellenőriztem, a SIDPlay miatt, akkor vettem észre, hogy azt a bájtot elfelejtettem lecserélni, amikor a legújabb FILE verzióhoz igazítottam. :)
viszont az ACE2 tuti használ filtereket, gondolom ez a nagy eltérés oka a SIDBASIC, és a "hardveres" lejátszás között,
Valóban, olyan zenét kerestem, ahol jól hallható a különbség, tehát használ szűrőt is, PWM-et, stb. Bár ez sem tökéletes, nincs gyűrűmoduláció, a hullámformák közül is elsősorban csak a négyszögjelet használja, tehát érdemes lenne még egy másikból is hasonló csomagot készíteni.A Last Ninja2-nél emléxem tapasztaltam különbséget még az én bot fülemmel is a turbós lejátszásnál. Ha jól emléxem, akkor az Exploding Fist nem nagyon használ négyszögjelet :)
A 4 és 10 MHz-es SIDBASIC közötti eltérés főleg a magas hangoknál érzékelhető, ezeknek a torzítását csökkenti a lejátszási frekvencia növelése.
specy128-ra nem akarjátok megírni ezt a sid lejátszót?Ilyenre nem lehetne megírni, csak 50Hz-es interrupt van, nem mehetne megszakításból a sample lejátszás, mellette ott van a memórialapozási hiányosság, egyszerre csak 48K-t RAM-ból a gép, kivéve +3-on, az AY-nak csak 16 szintű a volume regisztere, és azt is macerásabb címezni, mint EP-n.
biztos nagy sikere lenne specy-s körökben :)
na persze ha teljesen lefoglalja a procit akkor biztos fanyalognának sokan. de akkor is érdekes lehetne.
amúgy valami nem akar egy snapshotot csinálni amiben van sok sid, meg a lejátszó, és csak rá kelljen klikkelni és hallgatni? :)
Némi butítással nem lenne lehetetlen a Spectrumos lejátszó, de a pufferelt kicsomagolás valószínűleg nem lenne megoldható, így a formátum átalakítása nélkül legfeljebb kb. 3 percet lehetne lejátszani. Mivel csak 50 Hz-es megszakítás van, a hangminta lejátszást a DTM-hez hasonlóan kellene megoldani, a főprogramban futna végtelen ciklusban, és csak a vezérlését végezné az IRQ rutin. Így azonban fontos a megszakítás kezelés időtartamát minimalizálni. A CPU órajele fix 3.547 MHz, ezért a bemeneti file már konvertált frekvencia értékeket tartalmazhatna.És a megszakításban végzett vezérlés is rontana a minőségen, a magasabb hangoknál nagyon hallhatóan, a régi sidbasic is ilyen volt, miután megcsináltam a megszakításos verzióját, akkor vettem észre milyen sokat ront. Talán úgy lehetne javítani, de az megint lassít, ha nem a megszakításban futna a vezérlés, a megszakítás csak időmérésre lenne jó, hanem a digi lejátszó végén ugrana a vezérlésre pár utasítás erejéig, ha a vezérlés befejeződött egy frame-ben, akkor nem csinál semmit, itt meg nehéz lenne megoldani a pontos időzítést.
amúgy sima specy hangzással is jó lehetne egy sid lejátszó...Itt az a probléma, hogy 48Kb-t lát csak a speccy, ami relokálásnál okoz problémát, meg C64-en a verem is lent van 200h-n ha jól tudom, meg a 0000-00ffh a gyors elérésű terület, amit minden program használ, ezeket is ki lehetne küszöbölni talán az emulációban való áthelyezéssel, viszont olyan sid, ami relokálás után 0000-3fffh-ra kerülne, nem menne. Ezek miatt nem csináltam meg Speccy-re már, pedig gondolkoztam rajta, CPC-re, és SAM Coupéra elkészült.
esetleg ha a forrást odaadjátok nekik (pl wos fórumon), szerintem biztos lenne valaki aki fejlesztené...
az a snapshot nekem incompatible...
Ezzel (https://github.com/istvan-v/ep128emu/releases/tag/2.0.11.1) az emulátor verzióval működik.
A D/A kimenet bonyolultabb és lassabb mint EP-n, viszont a nem lineáris hangerő miatt a három 4 bites regiszter megfelelő kombinálásával (PC-s programmal optimalizált táblázatot használva) javítható a felbontás.Itt arra gondoltál, hogy a három csatorna kombinált hangerejét egyszerre kiírni a digi lejátszó rutin végén a három hangerő regiszterbe, ami átfut a konvertáló táblázaton?
Itt arra gondoltál, hogy a három csatorna kombinált hangerejét egyszerre kiírni a digi lejátszó rutin végén a három hangerő regiszterbe, ami átfut a konvertáló táblázaton?
Igen, de nem tudom, ez mennyire lenne használható a gyakorlatban. Az egyszerű 4 bites AY hangerő azonban nem lineáris, az emulátorban például ezt a táblázatot használom:Én még annyira se ;) , de ha van kedved még segíteni, akkor belefoghatunk.
0, 300, 447, 635, 925, 1351, 1851, 2991,
3695, 5782, 7705, 9829, 12460, 15014, 18528, 21845
Csináltam egy SIDBasic (https://www.youtube.com/watch?v=8UxG_sjeuyM&t=20s) videjót a jútyúbra :)Ez jó!
jó a videó, ezt már lehet mutogatni a c64-eseknek :)Emlékeid nem csalnak :)
amúgy ez most akkor ha jól értem teljesen digi. régen mintha a dave hangcsatornákat is használta volna, vagy rosszul emlékszem?
aha, hát itt van, 2012-es! ez elég 4szögjeles. viszont ezt át lehetne specy128-ra írni, nem?Ez az, aminek kell a 64K egyben, a kód relokálás, és a verem, meg az utasítások miatt gyors elérésű terület miatt az alsó szegmens, a SIDBasic más verziójára sokkal nagyobb az esély, gondolkoztam egy keveset, simán lehet használni az M64 fájlokat majd betöltésre, csak lejátszás előtt át kell dolgozni az adatokat.
https://www.youtube.com/watch?v=6CKt9noxA7s
Közben hallgatom a Youtube-on a videót. Van pár dallam, ami nagyon jó és sajnálom, hogy olyan gyorsan jön a másik utána. :DKészítése közben én is így voltam :), az elején elhatároztam, hogy kb 2 perc egy, és utána jön a váltás, az idő múlásával egyre inkább lanyhult a szabály :D
A key clicket érdemes lenne kikapcsolni a file választás idejére.Én spec szeretem, segít a pozícionálásban :)
Közben hallgatom a Youtube-on a videót. Van pár dallam, ami nagyon jó és sajnálom, hogy olyan gyorsan jön a másik utána. :D
jó a videó, ezt már lehet mutogatni a c64-eseknek :)Egy ideje már jár körbe-körbe a fejemben a kérdés, hogy milyen reakciót remélsz belőlük kiváltani?
érdekes lenne tech infókat is írni egy összehasonlító videóra, meg a simára is
Egy ideje már jár körbe-körbe a fejemben a kérdés, hogy milyen reakciót remélsz belőlük kiváltani?
pl érdekes lenne egy c64-en szimulálni az ep-s "epimgconv" konvertált raszterenként színezett képeit. 16 színnel, mindenféle villogtatással is csak valami béna eredményt adna :)
Egy ideje már jár körbe-körbe a fejemben a kérdés, hogy milyen reakciót remélsz belőlük kiváltani?"Hú, azt hittem, ilyet csak a C64 tud. Elvesztettük a hidegháborút!!! :smt010 :smt085 :smt086 :smt087 :smt088 :smt089 :smt090 "
"Hú, azt hittem, ilyet csak a C64 tud. Elvesztettük a hidegháborút!!! :smt010 :smt085 :smt086 :smt087 :smt088 :smt089 :smt090 "
hát mindenképpen érdekes technikai dolog, főleg egy olyan c64-esnek aki képben van a sid-el, hogy egy másik gépen lehet szimulálni, méghozzá nem egy mai brutál pc-n, hanem egy korabeli, hasonló teljesítményű gépen. ez minimum tök jó, tök érdekes :)Nos, ezt – másik géppel SID emulálás – több mint 25 éve megcsinálták már egy rokon masinán (+4), és az sem hatotta meg a C64 tábort. Nyilvánvalóan az ottani nyomor hangtechnikával és teljesítménnyel nehezítve nem igazán lehetett ezt a minőséget megközelíteni sem, de maga az elv és a korabeli megvalósítások nem jelentettek kisebb "áttörést". A dologgal itt is ugyanaz a probléma, mint Plus/4-en: a zenéléssel egy időben tudsz még valami érdekeset csinálni? És a válasz nagyjából ugyan az itt is, mint a pluszin: nem turbósított gépen nem sok mindent, vagy csak jelentősen visszavágott hangminőség mellett és/vagy halál kényelmetlenül programozva, de azt is csak akkor, ha szénné optimalizálod. Aztán ott van még az eredetiség kérdése. Biztosan a 64-es "levetett" zenéit akarnád használni, vagy a "platform büszkeséged" ennél egy kicsit nagyobb? Még mielőtt félreértenéd: az elért nagyszerű eredményt nem kérdőjelezem meg, és nyilván abba sem tudok érdemben beleszólni, hogy az EP-sek milyen irányt szeretnének maguknak választani.
mi a kérdés? :)
pl érdekes lenne egy c64-en szimulálni az ep-s "epimgconv" konvertált raszterenként színezett képeit. 16 színnel, mindenféle villogtatással is csak valami béna eredményt adna :)
Én még annyira se ;) , de ha van kedved még segíteni, akkor belefoghatunk.
Igen arra emlékeztem, hogy nem az, de esetleg egy próbát lehet tenni az EP-féle lejátszással is, ha az első variáció nem lenne jó.
Csináltam egy SIDBasic (https://www.youtube.com/watch?v=8UxG_sjeuyM&t=20s) videjót a jútyúbra :)
különösen tetszik a 23. perc környékén lévő zene, olyan mint egy reneszánsz tánczene.
Lesz a lejátszónak játékba fordítható verziója? (és leírás hozzá?) :oops:
Plus/4-es konvertáló programmal egyszerűen össze lehet hasonlítani, a p4fliconv (https://github.com/istvan-v/plus4emu/releases/tag/1.2.10) hasonló az EP-s változathoz.
Valószínűleg megoldható a játékba építhető verzió, bár a pufferelt lejátszásnál gyakorlatilag 50 Hz-es megszakításban kellene futnia a játéknak. Egyszerűbb játéknál talán még maradna elég CPU idő a frekvenciát 8 kHz-re csökkentve.
Iron Lord?Oké, most lebuktam, hogy csak belepörgettem a videóba, ott van a szám elején a kiválasztás a FILE menüből... :oops:
[- 4 MHz-es gépen a lejátszási frekvencia 7812.5 Hz-ről 10000 Hz-re növelve
Ez pontosan mit jelent? A 10kHz ebben az esetben mintavételezési frekvenciának számít?
eh...Csak vicceltem ezzel. Persze, meg lehet mutatni C64-eseknek, miért ne?
semminek semmi értelme...?
Nos, ezt – másik géppel SID emulálás – több mint 25 éve megcsinálták már egy rokon masinán (+4), és az sem hatotta meg a C64 tábort.
8000-bfffh is belassul ha lassú memória kerül a 3. lapra? Minden, ami a digi lejátszáshoz kell, a 2. lapon van, viszont ha lassú memória kerül a 3. lapra, akkor lassul a sebesség (01 03 07, 02-est nem használom)
Az I/O műveletek is okozhatnak lassulást, ha a 16 bites port cím páros, vagy ha memória címként értelmezve lassú memóriára mutatna.tehát a sima ld bc,0ffffh az out előtt lassulást okoz ,mert a 3. szegmensre mutat, pedig nem is csinál ott semmit?
tehát a sima ld bc,0ffffh az out előtt lassulást okoz ,mert a 3. szegmensre mutat, pedig nem is csinál ott semmit?
és ha kettéválasztom, tehát nem adom meg direktben, hanem mondjuk ld b,0ffh, ld c,b ?
Nem az LD a lassú, hanem az OUT, a 16 bites cím felső két bitje alapján is várakozást generál. Ennek ugyan nem sok értelme van, de valószínűleg így egyszerűbb/olcsóbb lehetett a hardver. :)Értem, tehát ez a része szopacs :ds_icon_cheesygrin:
High byte | |
in 40 - 7F? | Low bit | Contention pattern
------------+---------+-------------------
No | Reset | N:1, C:3
No | Set | N:4
Yes | Reset | C:1, C:3
Yes | Set | C:1, C:1, C:1, C:1
ep128emu-ban ez is emulálva van?
Akkor viszont ez hiba az emulációban, feltéve hogy nincs a különböző Spectrum változatok között eltérés. :oops:Van, csak hogy jó legyen, nem tudom hogy ebben van-e, de a késleltetési értékekben igen.
Ez a teszt program is jónak mutatja az emulációt:Még egyszer bocs, a rossz linkbe futottam bele elsőre, azt gondoltam volna a WOS pontos.
Még egyszer bocs, a rossz linkbe futottam bele elsőre, azt gondoltam volna a WOS pontos.
Közben megcsináltam a gyors verziót, ugyanarra a volume regiszterre kiírni mindent , amiit el is lehet felejteni, roszz a minősége :lol:
A sebességen még a hullámforma is változtat egy keveset, a négyszögjel 3 ciklussal gyorsabb a többinél.Húúú, ez nagyon jó ötlet, én sokkal macerásabbra gondoltam, van 3 NOP-unk (és még ez se pontos) az időzítés miatt, ezt cserélném le lassú memória esetén 2 NOP-ra, gyorsnál egy 18h,00h-ra, de ezt el is dobtam akkor, fixen belapozom majd akkor a 00h-s lapot a megszakítás végén, az elején meg az épp aktuálisat.
Az I/O várakozás miatti lassulást esetleg el lehetne kerülni azzal, ha a megszakítás kezelő rutin egyszerűen gyors memóriát lapozna a 3. lapra visszatéréskor. Ezzel ugyan lassulna az 50 Hz-es megszakítás kezelése, de nem lenne "nyávogás" a contended I/O miatt.
Gyűrűmoduláció effektus nem lesz?Egyelőre azt kiszedtem ideiglenesen, úgy gondoltam, ha lesz idő rá akkor lesz, ha nem, akkor nem :)
Közben megcsináltam a gyors verziót, ugyanarra a volume regiszterre kiírni mindentEnnek a snapshotnak mit kéne csinálnia? Nekem a ZX emu nyílik meg kiinduló állapotban és hangyák is vannak rajta, de más nem.
Ennek a snapshotnak mit kéne csinálnia? Nekem a ZX emu nyílik meg kiinduló állapotban és hangyák is vannak rajta, de más nem.Ha vársz sokat, akkor elkezd cincogni :-)
Egyelőre azt kiszedtem ideiglenesen, úgy gondoltam, ha lesz idő rá akkor lesz, ha nem, akkor nem :)
Próbálkozás táblázatos D/A konverzió megvalósítására:
Közben megcsináltam a gyors verziót, ugyanarra a volume regiszterre kiírni mindent , amiit el is lehet felejteni, roszz a minősége :lol:
Egyelőre ez a legszimpatikusabb megoldás ,de lehet neked van jobb, mi a véleményed?
3 betenni di-t és ei-t az önmódosító kódokhoz, ez jelentős lassulást eredményezne.
Éppen a JP-s megoldást ajánlottam néhány perccel korábban, de a JP módosítására egyébként is szükség lehetne a sebesség szabályozása miatt.Bocs, amikor először olvastam azt a hozzászólásod, akkor még nem volt ott, utána meg már írtam, és a fórum nem jelzett, hogy eksön történt, lehet módosításnál nem jelez. :) A JP módosul is már, attól függően hány négyszögjel lejátszás van.
Valójában elég lenne csak egy DI/EI pár, és egy (nem módosított) utasítás idejére engedélyezni a megszakítást, bár az is 8 ciklus.Ebben nem vagyok biztos a Speccy megszakításkezelése miatt, amikor letiltottam a megszakítást a volume regiszterek írásának idejére, akkor kb a megszakítások fele ugrott. :(
Ebben nem vagyok biztos a Speccy megszakításkezelése miatt, amikor letiltottam a megszakítást a volume regiszterek írásának idejére, akkor kb a megszakítások fele ugrott. :(
Még az 50 Hz-es megszakítás kezelésén lenne jó valahogyan gyorsítani, mert jól hallhatóan torzítja a hangot. :( És valószínűleg a dacTable is lehetne jobb.Csinálom most a direkt módosító kódot, többet gyorsít, mint gondoltam, sajnos a torzítást nem fogjuk tudni elkerülni, de ha kész az 50Hz-es megszakításkezelés felteszem a forrást, tuti találsz rajta még gyorsítási lehetőséget :)
A forráskód régebbi verziónak tűnik. :oops:Jól tűnik :oops: , lecseréltem a csatolmányt.
TZX változat, valamiért hibásan működik, egyelőre nem sikerült javítani:Az nem lehet, hogy rossz a loaderem? Vagy esetleg valami rendszerváltozó van az 5c00-5d00 területen?
Szerk.: a copydat rutinban inicializálatlan volt a D' regiszter.
Ez már működik, bár a minőség továbbra sem túl jó (talán a táblázatos D/A miatt sem?):Szerintem nem a táblázatos D/A, nézz meg egy régebbi verziót ,ami külön regiszter írós, az se jobb szerintem, az 50Hz-es vezérlés torzít sokat szerintem, de ha gondolod, csinálok egy külön regiszter írós legfrissebb változatot is összehasonlításképp.
Mi volt a gond? az inicializálatlan D'?
Igen.Nagyon tetszik a módosítás, legfőképp a 4,7,10,13-as eltolás, sose jutott volna eszembe ez a megoldás, én a legkevesebb írás melletti megoldásban gondolkoztam, az eszembe se jutott, hogy esetleg meg lehetne oldani írás nélkül is (vagyis gondolkoztam, hogy lehetne-e, és úgy láttam nem, pedig de :D ) Az önmódosító kódban az LD BC,xxxx C írásának kihagyása is marha jó, úgyse használja a program semmire :lol:
Az 50 Hz-es megszakításon ebben a verzióban sikerült egy keveset gyorsítani, illetve a lejátszáson is 1 ciklust (most 9991 Hz-es). A kód egy részét csak akkor frissíti, ha változik a hullámforma, de ez csak akkor éri meg, ha legfeljebb egy csatornán változik, tehát nem biztos, hogy jó ötlet. Bár az ~1000 ciklus futásidőhöz képest egyik irányban sem jelent nagy eltérést.
A TZX generáló CPP-t te csináltad?
Úgy hallom a gyorsítás jó hatással lett a lejátszásra, kevésbé torzulnak el a magas hangok.
Amúgy amikor szóba került a spectrum változat, én ilyen minőségre nem gondoltam, azt hittem ettől rosszabb lesz.
Igen, ugyanezt használtam a Specball (https://enterpriseforever.com/jatekok/enterball/msg52463/#msg52463)-ban is, csak ott még volt tömörítés is.Szép :)
én sejtettem hogy jó lehet, 16 hangerő lépcső se rossz ám :)Ja, nem a 16 hangerő lépcső miatt gondoltam, hanem az 50Hz-es vezérlő rutin miatti torzítás miatt, meg azt hittem, hogy a 10KHz-es lejátszás nem jön majd ki a mecerásabb AY portírás miatt.
amúgy a c64-nek hány bites a d/a-ja? én ott is valami 4 bitre emlékszem
amúgy a c64-nek hány bites a d/a-ja? én ott is valami 4 bitre emlékszem
4 bites a hangerő és az ADSR regiszterek, de a DAC 12 bites, amit csak a fűrészjel használ ki. A háromszögjel felbontása 11 bit, a zaj 8 bites. A burkológörbe generátor kimenete 8 bites.
huh, ez hogy jött ki nekik? :DGondolom a szokásos módon. Bob Yannes először nagyjából kitalálta mit szeretne csinálni, aztán megkapta az áramkör (~tranzisztor) keretet, és ami belefért az maradt. Tudomásom szerint az eredeti elképzelése a csókának egy 32 csatornás szintetizátor volt. Azután elment megalapítani az Ensoniqot.
érdekes...
na de ebből azért látszik hogy ezzel jó minőségű hangot lehet...
Gondolom a szokásos módon. Bob Yannes először nagyjából kitalálta mit szeretne csinálni, aztán megkapta az áramkör (~tranzisztor) keretet, és ami belefért az maradt. Tudomásom szerint az eredeti elképzelése a csókának egy 32 csatornás szintetizátor volt. Azután elment megalapítani az Ensoniqot.
azon gondolkodtam hogy most az ep-s sid szimuláció alapján fel lehet mérni hogy hány Mhz-s z80 tudná teljesen jól szimulálni a c64-et.Nemigen. A SID szimuláció nagyon sima így ügy, de még sehol sincs a szűrő. Abból is kell kettő, és a megvalósításához mindenképp kell tudni szorozni. Után jön még a képernyőszervezés esetleges eltérései a szimuláló gépen a Commodore-féle megoldástól, amiről futás közben elég nehéz eldönteni, hogy egy képernyő területre történő írást konvertálni kell a szimulátor saját formátumára vagy azt éppen változatlan formában kell tárolni, mert nem képként van az a memória használva. Van még képpont szintű finom görgetés, ami mindig a nagyobbik felbontásban működik. Többszínű karakteres mód, amiben eldöntheted, hogy az adott karakterben többszínű vagy nagy felbontású ábrázolást szeretnél. Ott van még az ECM karakteres mód, ahol 64-re van korlátozva a karakterkészlet, de a felső két bittel kiválaszthatod négy háttérszín valamelyikét. Emlékezzünk még meg a két attributum memóriáról, amiből az egyik rögzített helyen van, a másikat viszont némi megszorítással szabadon lehet mozgatni a memóriában. És akkor ott vannak a szprájtok és a VIC-II "hibáinak" sokasága, amit valós időben kellene szoftverből emulálni. Emlékeim szerint a Pentium II vagy III kezdett el az a szint lenni, amikor már többé-kevésbé épkézláb emulációt lehetett előadni, de architekturálisan az olyan rendszerek fényévekre vannak a Z80-tól.
Nemigen. A SID szimuláció nagyon sima így ügy, de még sehol sincs a szűrő. Abból is kell kettő, és a megvalósításához mindenképp kell tudni szorozni. Után jön még a képernyőszervezés esetleges eltérései a szimuláló gépen a Commodore-féle megoldástól, amiről futás közben elég nehéz eldönteni, hogy egy képernyő területre történő írást konvertálni kell a szimulátor saját formátumára vagy azt éppen változatlan formában kell tárolni, mert nem képként van az a memória használva. Van még képpont szintű finom görgetés, ami mindig a nagyobbik felbontásban működik. Többszínű karakteres mód, amiben eldöntheted, hogy az adott karakterben többszínű vagy nagy felbontású ábrázolást szeretnél. Ott van még az ECM karakteres mód, ahol 64-re van korlátozva a karakterkészlet, de a felső két bittel kiválaszthatod négy háttérszín valamelyikét. Emlékezzünk még meg a két attributum memóriáról, amiből az egyik rögzített helyen van, a másikat viszont némi megszorítással szabadon lehet mozgatni a memóriában. És akkor ott vannak a szprájtok és a VIC-II "hibáinak" sokasága, amit valós időben kellene szoftverből emulálni. Emlékeim szerint a Pentium II vagy III kezdett el az a szint lenni, amikor már többé-kevésbé épkézláb emulációt lehetett előadni, de architekturálisan az olyan rendszerek fényévekre vannak a Z80-tól.
Esetleg érdemes lehetne még a lejátszót tömöríteni, bár ez csak néhány másodperccel rövidíti a betöltést.PGyuri említette, hogy a Spectrumosok nem szeretik, annál jobb egy program ,minél nagyobb :D , épp azon gondolkozom ,hogy feltöltöm pár KB-tnyi random adattal :ds_icon_cheesygrin:
épp azon gondolkozom ,hogy feltöltöm pár KB-tnyi random adattal :ds_icon_cheesygrin:Ez gyári programokban is előfordul! :-)
kiraktam a videókat wos-ra mert nem bírtam ki hogy ne :):lol:
:lol:
Azért van egy enyhe túlzás a nearly all capabilities-ben :D
PGyuri említette, hogy a Spectrumosok nem szeretik, annál jobb egy program ,minél nagyobb :D , épp azon gondolkozom ,hogy feltöltöm pár KB-tnyi random adattal
Ha a zene 2:43-nál hosszabb, akkor az M64 lejátszhatatlan része miatt már van véletlenszerű(nek tűnő) extra adat. :)Megint elszúrtam valamit? Amikkel teszteltem, azoknál jó volt a váltás.
Megint elszúrtam valamit? Amikkel teszteltem, azoknál jó volt a váltás.
Nem úgy értettem, hogy hibás a lejátszó, csak van kihasználatlan adat a M64-ekben (amitől a Spectrumosok szerint jobb a program :)) az első 12 blokk után.Már megijedtem :lol: , jót röhögtem ,amikor PGyuri előadta ezt a történetet :D
Az 50 Hz-es megszakításon egyébként még lehetne tovább gyorsítani, bár a konvertálás betöltés után lassulna: a hullámforma/hangerő byte tartalmazhatna már konvertált értéket. Táblázatos hullámformáknál:Ezzel sztem sokat nyerhetnénk, nagyon jó ötlet.
Ez minimalizálná a v1regs rutint, esetleg (a kód méretének növekedése árán) minden csatornához külön meg lehetne írniErre gondoltam én is, igaz nem erre a direkt önmódosító kódosra, hanem az eredetit bemásolva mindenhová
Talán a dacTable is tovább javítható, de elsősorban az 50 Hz-es megszakítás rontja a minőséget.tutter a megszakítás a főkolompos :)
Ezzel sztem sokat nyerhetnénk, nagyon jó ötlet.Erre gondoltam én is, igaz nem erre a direkt önmódosító kódosra, hanem az eredetit bemásolva mindenhová
a 7-es regiszterbe 3fh írása javít a minőségen?
A fenti kódrészlet csak példa, nem feltétlenül optimális megoldás.Ahogy számolgatok, talán picit gyorsabb az LD (HL),xx, INC L .
Jónak tűnik még Hikaru ötlete is a WOS fórumról, megszakítás helyett egy számláló használata. Erre a célra használható lehetne a még szabad E regiszter, vagy (valamivel nagyobb átalakítás után) a B. 10 kHz-es lejátszási frekvenciánál 200-ról kellene számolni 0-ig (illetve kb. 197-198 figyelembe venné az 1-1.5% lassulást is), tehát 8 bites regiszter megfelelő erre a célra. Viszont a sidSynth lassulna (DEC E = +4 ciklus, DJNZ = +3 ciklus), bár a dacTable B800h-ra helyezésével megtakarítható lenne egy LD A,8, helyette OUT (C),H választhatná a 8. AY regisztert.Basszus, ha nem mondod Hikarut, akkor észre se veszem, 5 előtt olvastam, amit írt, csak a spoilert nem vettem észre.
A számláló a vezérlés több részre osztása (150 Hz és egyszerre csak egy csatorna) nélkül is gyorsabb lenne a megszakításnál, és a frekvencia sem lenne fix. Ezen kívül még megtakarítaná az IM 2-es táblázatot.
videoIRQ tiltása = -57 ciklus
EI törlése = -4 ciklus
jumpvl egyszerűbb módosítása = -10 ciklus
számláló újratöltése = +7 ciklus
Tehát 64 ciklus gyorsulás.
A D/A résznél valójában mindegyik csatornát lehetne OUT (C),H utasításokkal választani az INC H-k miatt (B8h, B9h, BAh), ha a dacTable B800h kezdőcímre kerül. Így felszabadul a DE' regiszter, ami még hasznos lehet.Értem, fasza ötlet :), már át is tettem pár dolgot 4200h-ra előkészítve a b800h-ra tételt :)
Az IM 2-es megszakítás hiánya megtakarít 257 byte-ot (illetve valamivel kevesebbet, mert a delaytbl felülírja az elejét), tehát valójában több a szabad hely, eseleg a dacTable elé is kerülhetne kód a lassú video szegmens helyett.Igen, azt is beleszámítottam :) Azt akarom elérni, hogy az 5d00h töltési hossz megmaradjon :)
Szerk.: a Spectrumosoknak nem tetszik a turbósított magnó betöltő rutin, ezért annak a törlésével is szabadulhatna fel valamennyi hely. :)Én csak egy ilyen hozzászólást láttam, pedig jó gyors lett a töltés, egyelőre én benthagyom, de látod, a speccysek másként gondolkoznak, nem szeretik a tömörített programot, és a gyorstöltőt se :D
Úgy tűnik a módosításoknak köszönhetően az 5 raszter sorról lementünk 3-ra, és lehet csak bebeszélem, de mintha hallható is lenne a javulás.
Ha jól számolom, kb. 140 ciklust gyorsult, és még tovább lehet javítani a számlálós megoldással.Az jön most, vagyis elkezdem :), de lehet csak szerdán fejezem be .
akkor ep-n is gyorsabb lenne interrupt nélkül, nem?gyorsabb lenne, viszont nem menne az on the fly kicsomagolas, amúgy meg interrupttal is menne 11 khz-en.
persze nem lenne elég kompatibilis :) haha ez lassítja a pc-ket is :)
megalmodtam a tutit, az összes variaciora legeneraljuk előre a digi lejátszó ciklust,nem bontjuk szét a vezerlest, mivel megúsztuk az önmódosító kódot, és oda update-eljuk be az értékeket, amit majd később meg is hívunk a következő vezerlesig. Ja és így nem kell jatszadozni az idozitesekkel sem, mert időtartamra a negyszogjel lejátszó rutin is olyan hosszú lesz, mint a többi.
Ahogy számolgatok, talán picit gyorsabb az LD (HL),xx, INC L .
Négyszögjelnél valójában a másik megoldás tűnik gyorsabbnak (4 ciklus különbség), de annak a használata növelné a kód méretét. Viszont kimaradt az INC IXL. :oops: Azonban ha jól látom, a DE regiszter már nem használt, ezért címezhetné az a delaytbl-t az IX helyett, így még a PUSH IX/POP IX is megtakarítható lenne.Igen, észrevettem tegnap én is, az új kódban benne van már, és a DE-s címzés is, viszont a legújabba, az előre legenerált 8 digi lejátszó rutinhoz már nem is kell az se, ebbe kezdek bele ma :)
Nem tudom, ez hasznos-e, de ha sok az előre generált kód és táblázat, akkor azok lehetnek -raw -m2 -blocksize 8192 tömörített formátumban is, és a decompressDataBlock kicsomagolhatná a 8000h-9FFFh területre (a 2-es szegmenst átmenetileg belapozva a 3. lapra) a hangminták generálása előtt. Így a dacTable tárolásához sem kellene külön RLE formátum ha 8800h kezdőcímre kerül.Szerintem hasznos :) , mert így már a lejátszó mérete is a sokszorosára duzzad.
Az ilyen módon tömörítetendő kód külön forrás file-ba kerülne (org 8000h és a végén nullákkal feltölteni hogy a méret 8192 legyen), a különböző lejátszó változatokat makrók generálhatnák, és a dacTable beépítéséhez elég lenne egy egyszerű include "dactable.s".
Szerk.: valami ilyesmire gondoltam (bár ez nem teljes vagy optimális megoldás):
Vagy mi lenne, ha a vezérlő rutinból hívnánk meg 3x vagy akár többször JP-vel, és DE'-ben lenne a visszatérési cím?
Ezt eddig nem vettem észre, de nem rossz ötlet, bár ennek már 632 byte a tömörített mérete:Húúú, nagyon szofisztikált a megoldásod, tetszik, én nekiestem a favágó módszerrel, aminek talán annyi előnye lehet, hogy néhol picit gyorsabb lehet.
Össze kellene hasonlítani az egyszerűbb változattal, hogy valóban hallhatóan jobb-e.
Szerk.: ez így valójában nem jó, az INC E-k helyett egyenletesebben elosztva kellene futtatni a sidSynth ciklust, és nem a végén egyszerre 194-szer.
Az INC E-s megoldást még a nem "generált" lejátszóra gondoltam, nem tudom a "generáltnál" érdemes-e szétbontani a dolgokat, elméletileg ennek már "sokkal gyorsabbnak" kéne lennie. Meg gondolkoztam a visszatérésen, és kb 40 ciklust enne meg az ugrás a rutinra, előtte a DE megadása, majd a JP (HL)-es visszatérés, az EXX-ekkel, és EX DE,HL-lel megfűszerezve, megéri ez a sok elpazarolt idő? (és ezt 3x)
Mi történt, reggel láttam még egy tegnap esti hozzászólást, már nem, letörölted?
Az a megoldás, amit most töltöttél fel, jobbnak tűnik, ezért beépítettem és hamarosan elkészül a frissített csomag.Biztos?
Lehet jobban szól a 3 részre bontott változat a bonyolultabb visszatérés ellenére is, én is arra gondoltam, hogy meg kéne csinálni a két verziót, és összehasonlítani :)
Lehet jobban szól a 3 részre bontott változat a bonyolultabb visszatérés ellenére is
Most próbálkoztam azzal is, de egyelőre nem igazán vált be (vagy hibás). :oops:Ha én csináltam volna, akkor azt mondanám, hogy tuti hibás :D
A leglassabb vezérlő időtartamra 512 alatti ciklust tippeltem tegnap, de bíztam benne, hogy kevesebb lesz 500-nál is a nem szétbontottnál
Az itt található új verzióban (https://enterpriseforever.com/sound/sid-lejatszo/msg62612/#msg62612) 469-475 ciklus időt fogyaszt a 8100h-s lejátszó (2 PWM, 1 táblázat). De ha lassú memória van a 3. lapon, akkor valamivel több lehet, ilyenkor fordul elő ~500.Hm, ez nagyon jó eredmény, legalábbis szerintem :lol:
Ez a verzió fasza, én nem hallok torzítást, lehet fölösleges is a szétbontással próbálkozni, nem gondoltam volna, hogy sikerül elérni ilyen minőséget :)
Még TAP változatot kellene készíteni, úgy látom, a WOS fórumon (https://www.worldofspectrum.org/forums/discussion/54160/c64-sid-player-coming-soon-to-specy-128#latest) már többen is kifogásolják a TZX-et. :oops:Sajnos igen, nem igazából értem, mert igazi gépen jobb lenne a TZX, gyorsabban tölt, megcsinálom a TAP-ot, most épp egy képpel szüttyögtem, beleteszem a TZX változatba is, vagy csak abba tegyem bele? :D
most épp egy képpel szüttyögtem, beleteszem a TZX változatba is, vagy csak abba tegyem bele? :D
Lehet a TZX-ben is, ha nincs különösebb hátránya. Esetleg itt is használható lehetne a tömörítés, a 4200h-s kód és a képernyő (INCBIN használatával) külön forrás file-ba kerülne, és ennek a tömörített változatát kellene E000h címre kicsomagolni, majd a helyére másolni.Elméletileg nincs, én is így gondoltam, csak 0c000h címre kicsomagolva, és még a betöltőben, már be is csomagoltam , 1477 bájt lett :) , és az alsó 800h-t direkt üresen hagytam a képen, attr bájtja meg 3fh, hogy ne piszkítson bele a kód ami 4000-47ffh területen henyél :)
specy128 verzióról van már videó?Én nem csináltam, de még polírozás alatt van, a TZX-be betettem a képet, és az 50-250Hz-ig való vezérlést, most a TAP verziót kezdem.
Néhány kisebb fejlesztésre még találtam lehetőséget, például a kép C64 formátumra konvertálva jobban tömöríthető, a sebességet pedig kiszámítom a fejléc alapján, tehát 41 és 255 között bármilyen érték működik. Így többet tud az EP verziónál, bár a sebesség növekedésével egyre rosszabb a minőség.És még van egy, most a max file méret 5e80h, egy kis mókolással elérhetnénk az EP-s maximumot, az 5f00h-t.
És még van egy, most a max file méret 5e80h, egy kis mókolással elérhetnénk az EP-s maximumot, az 5f00h-t.
A fent említett módosítások már elkészültek, csak még tesztelem. Ezen kívül még megpróbálom egy forrásba építeni a TAP és TZX verziót feltételes fordítással.Oké :) Én mókolással csináltam a tapot, elkészítettem a TZX-et, és a Basic adatblokkot átmásoltam TAP-ba, majd beszúrtam mögé a kódot broken data blokként :D
Ha a sidSynthPacked is átkerül a 4200h-s területre, akkor ez könnyen megoldható. Mást talán nem is kellene oda másolni.Bőven, annyi, hogy át tettem a 4400h-ra a decompresstable-t, azt kell még elmozgatni 4600h-ra, vagy 4700h-ra, és a tap verzióban a töltési hosszat átállítani 5f10h-ra
Hm elszúrtam a lapozó regisztert, pedig több programban 7dh-t használtak, és a gyors 0B8h-s ay regiszter választás nem működik mindenhol, ezt írta Hikaru a WOS-on, de gondolom láttad te is :)
A fenti csomagok egyébként nagyjából már késznek (vagy legalábbis használhatónak) tűnnek, eltekintve az esetleges hibáktól vagy további optimalizálási lehetőségektől. A WOS-on érdemes lenne említeni a "kompatibilitási" verziót, mert úgy látszik, a Spectrum emulátorok többsége YM-et emulál. :oops:Nagyon gyors vagy, mindent megcsináltál, amit a WOS-on mondtak, meg ami ma, tegnap itt előkerült :)
Érdemes mind a kettő verziót megemlíteni? Mondjuk talán jobb az AY-s, mert az picivel gyorsabb, tehát érdemes lehet
én nem is használok mást, hacsak nem TRD-s fájlokról van szó, meg is voltam lőve a Wolf2004-nél, mert amiatt az UnrealSpeccyt kellett használnom :ds_icon_cheesygrin:Pedig írtam már LUA scriptet erre a problémára :-) (https://enterpriseforever.com/emulatorok/lua-scriptek-fejlesztese/msg29497/#msg29497)
Pedig írtam már LUA scriptet erre a problémára :-) (https://enterpriseforever.com/emulatorok/lua-scriptek-fejlesztese/msg29497/#msg29497)Óóóó, ha ezt tudom, olyan régen volt, hogy addig vissza se nyúlik a memóriám :lol:
Ez ugyan csak minimális optimalizálás amiért nem érdemes új verziót kiadni, de a C64 képet konvertáló rutint valójában nem kell 4700h címre másolni, ahol még lassabb is. Meg lehet oldani, hogy az eredeti helyén (E700h) fusson:
Azt a pár pikoszekundumot már észre se veszi senki, a súlyos konvertáló másodpercek mellett ;)
Itt a csomag újból, benne a TZX fájlok, TAP-ok, és az új forrás, így jó lesz?
Ha igen, ezt linkelem be a WOS-on.
Egyelőre csak a TAP/YM verziót néztem és a 150 Hz-es Paperboy-t, ami jónak látszik, de a következő file töltése lefagy.Hm, ilyet tapasztaltam én is tegnap, de minden verziónál csak egyszer, és én is egyszer a paperboy után, aztán betöltöttem még vagy 3x, és semmi se történt, ez vajon miért lehet? Én csak a megszakításra tudok gondolni, egész program alatt tiltott, a kis genya ROM loader engedélyezi visszatéréskor, és random a fagyi.
Itt kellene a call tapeload elé egy ld (5b5ch), a:Nekem az jutott eszembe, hogy lehet az interrupt rutin száll el, mert felülírtuk a rendszerváltozós területet, lehet az IM 2-es megoldás lesz a legjobb, meg ami eszembe jutott, megnézni a ROM rutint, hogy meg tudom-e hívni úgy, hogy ne legyen engedélyezett interrupt visszatéréskor.Code: ZiLOG Z80 AssemblerDe az is probléma lehet még, ha a ROM esetleg felülírja a már betöltött adatot.
if USE_ROM_LOADER == 0 ld hl, input_buf ; M64 input file ld de, 364dh call readBlock else ld a,10h out (0fdh),a call tapeload endif
Szerk.: az működhetne, ha csak a TAP verzióban (USE_ROM_LOADER != 0) átmenetileg tiltott lenne a megszakítás IM 2 és egyszerű RET utasításól álló IRQ rutin használatával? Az IM 2-es táblázatnak van hely például a 4500h-4600h területen.
Az AY-YM verzióknál még azt kellene megnézni, hogy a D/A nem igényel-e különböző táblázatot a legjobb minőséghez, lehet, hogy ugyanaz a hangerő érték eltérő szintet eredményez a két IC-nél.Mikre nem gondolsz :)
Úgy látom ugyanazok az értékek vannak, csak az YM dupla olyan felbontású, a leírás alapján 32 lépcsőben éri el a maximumot az AY 16 lépcsőjével szemben, de minden 2. érték ugyanaz az YM-en, mint az AY-n, az YM2149-et néztem, az YM2149F-re még nem találtam doksit
Megnéztem egy pár emulátor forráskódját, és van eltérés, de az emulátorok között is. :):lol:
Az ay_da_opt.cpp (és az ep128emu) ugyanazt a táblázatot használja, mint a FUSE. Lehet, hogy valamelyik másik emulátor pontosabb, ezt talán a WOS fórumon lenne érdemes kérdezni. Azonban gyártási pontatlanságok miatt is lehetnek eltérések, ha az egyes emulátorok valódi gépről mért értékeket használnak is, azok bizonyos mértékben különbözőek minden gépen.Megkérdezzem?
A TAP verziónál talán az is megoldás lehetne, ha a program induláskor mentené az 5B00-5CFFh területet valahol a video memória elején (pl. 4500-46FFh), és utána a tapeload rutin egyszerűen visszamásolná. Így "szabványosabb" módon lehetne használni a ROM rutinokat, ami esetleg javíthatná a kompatibilitást.Szerinted a TAP-ot nem tudják betölteni más gépeken, mert megváltozott a 48K-s ROM rutin a +2/+3 ,és egyéb gépeken?
Úgy látom, meg tudom hívni úgy, hogy ne legyen a vége EI. 0562-t kell meghívniSzerintem kb az összes játék is ezt használja (már amelyiknek nem saját loadere van). Ha jól rémlik az EP-s Spectrum Emulátorban is ez a cím van meghackkelve (plusz a save is).
Szerintem kb az összes játék is ezt használja (már amelyiknek nem saját loadere van). Ha jól rémlik az EP-s Spectrum Emulátorban is ez a cím van meghackkelve (plusz a save is).Igen, nekem is ez rémlik, a 0562h és a 0556h a hivatalos belépési pont, és van egy-két elvetemült, ami másik címet hív, amire nem emlékszem.
Próbálkoztam az előbb említett másolós módszerrel, de a Space lenyomva tartásakor lefagy, ezért visszaállítottam az eredeti megoldást. Az ay_da_opt.cpp tartalmaz ayumi (https://github.com/true-grue/ayumi/blob/master/ayumi.c) táblázatokat is, ezeknek a használata a compile.sh szerkesztésével engedélyezhető. A vezérlés gyorsult 12 ciklust, bár laphatáron valamivel lassabb lett (aminek kevesebb jelentősége van).Leginkább az IM2 használata lehet megoldás a megszakítás problémára, amit javasoltál, de ez is csak akkor fontos, ha tényleg módosult a ROM loader a különböző verzióknál, egyébként jónak kéne lennie, azt akarom még megnézni, hogy véletlenül nem marad-e az épp lejátszott szegmens a 3. lapon, mert ez okozhat gondot.
32 bites sid_conv, sid_dump, epcompress és sjasm 0.39g6:Közzé is tettem :)
(Attachment Link)
A fix 5F10h blokk mérettel való betöltést is kifogásolják, bár ennek eredeti magnós gépen működnie kellene, csak a valódi gépen magnót "emuláló" speciális hardvereknél okoz problémát. De úgy látszik, elsősorban az utóbbiakat használják. Tehát vagy a fejlécnek kellene külön blokkba kerülnie TAP esetén, vagy minden TAP file-nak tartalmaznia kellene a lejátszót is a megfelelő blokk mérettel fordítva.Igen, és igen, és igen :) Most néztem én is, válaszoltam is, a fejléces megoldás nem jutott eszembe, az egy teljesen jó ötlet, és kevésbé macerás, de a legegyszerűbb, csinál magának mindenki egy basic loadert, és vagy lecsökken a max file méret 200h-val, vagy az egészet 200h-val eltolva töltik be, majd a lejátszó bemásolja magát meg az adatot a helyére.
Lehetne a Spectrumosok számára külön rövidebb M64-eket is készíteni, tulajodnképpen nem is kellene újra konvertálni, csak egy rövid programot írni, ami kicsomagolja, 96K-ra korlátozza és újra tömöríti a parancssorban megadott összes file-t.Szerintem nem érdemes ezért új programokat írni, megnézem, lehet-e a Block editorban szétdarabolni egy-egy adatblokkot, ha lehet, akkor a csomagba betett tapokban elintézem, hogy a fejléc külön legyen, és meg is van oldva a hossz probléma, azt nem tudom, hogy az 5b00h-5bffh-ra írás a gyönyörű lemezes környezetben emulált tap-oknál okoz-e problémát.
Az ilyen csonkított file még mindig EP kompatibilis maradna, de a lejátszót egyszerűsíthetné a Spectrum specifikus formátum, illetve az ilyen célra készült sid_conv változat figyelembe vehetné a kisebb hangerő felbontást a táblázatos hullámformáknál.
Szerintem nem érdemes ezért új programokat írni
Melyik legyen?
És megvan a legegyszerűbb megoldás, mivel szerencsére fejléces tap-okat csináltam, a fejlécben el lehet tárolni a következő adatblokk hosszát, az 5b0bh címről ki is lehet olvasni a betöltés után, így ezt felhasználhatjuk a file betöltéséhez, annyi, hogy minden tap-ban meg kell adni az adatblok hosszát a fejlécben.
Az M64 rövidítés egyszerű (ugyanúgy fordítható, mint a sid_conv.cpp):Oké, a rövidítést közzéteszem ott is.
Tulajdonképpen a sid_conv.cpp is könnyen "Spectrumosítható" lenne, csak akkor mindent újra kellene konvertálni.Igen, az újrakonvertálást akarom minden áron elkerülni, azzal már nincs kedvem szüttyögni :D
Nem tudom, ezt valószínűleg a WOS-on tudják eldönteni, melyik megoldás használhatóbb. De a maximális file méret csökkenése szerintem nem lenne nagy probléma, a legtöbb zenének elég az 5D00h is, a kivételek (pl. IK) pedig rövidíthetők. Ami ilyen sok helyet igényel, az valószínűleg lényegesen hosszabb 2:43-nál. :)igen :D , az a tippem, hogy a legnagyobb fájl se érné el 2:43-as hossznál a 16kb-t sem :D
Az OUT (0FDh), A-s lapozásnál lehet, hogy érdemes lenne az A 6. bitjét beállítani (azaz például 0 helyett 40h-t írni)? Most olvasom, hogy a +2A és +3 gépeken nem működik a lapozás, ha a 16 bites cím nem 01xxxxxxxxxxxx0xb, de az adat 6. bitje nem tűnik kihasználtnak.Szerintem (de lehet rosszul gondolom) az a baj, hogy alap ROMkiosztás a +2a/+3-as gépeken a ROM0/ROM1, és nem állítottam ezen a regiszteren, ezért amikor kiadjuk a OUT (0FDh),A -t ROM1-et választjuk ki, és nekünk a ROM3 kéne.
Bár ez a többi gépen csak lassabb, mert így contended lesz a cím (1. lap).
ld a,04h
ld bc,1ffdh
out (c),a
ld a,10h
ld b,7fh
out (c),a
out (0fdh),a
Kipróbáltam, UnrealSpeccyn működik is , marad a ROM3, vagyis a 48k Basic :)
Az utolsó OUT (0FDH),A biztosan kell? Mindenesetre ez a kódrészlet csak a TAP betöltésnél lényeges, a fontosabb kérdés, hogy a többi FDh-s lapozás maradhat-e, azaz hibás a FAQ és valójában nem kell beállítani a 6. bitet?Nem, csak a teszt miatt volt benne :)
És ott van még az is, hogy ha jól tudom ezeken az újabb 128-asokon más a lassú/gyors RAM kiosztás is.Igen, de szerencsére a 0-ás , és a 2-es lap, ahogy látom mindenhol gyors, lejátszás közben ezek vannak használatban :)
Scorpionon 50h-t hozzá vagyolva működik, és +3-on is, lehet csinálok egy önmódosító kódot, ha ilyen gépeken lett betöltve a program, akkor módosítsa magát.
Bár nem sok gyakorlati jelentősége van, a sidsynth.s-ben található egy XOR A-s lapozás, amit így LD A, n-re kell módosítani, tehát kis mértékben változik az időzítés:Már működik is, épp teszteltem +3-on, most is az megy :D Szívtam vele egy keveset, mert két helyen kell patchelni, egyszer az elején, és egyszer a SidSynth kicsomagolása után :) Az időzítést itt nem módosítottam, mert csak 3 ciklussal nőtt a vezérlés, de megteszem.
Itt még az önmódosító kód megoldása sem egyszerű, mert a módosítandó utasítás külön forrás file-ban van 8 példányban, és még tömörítve is. :oops: Ezért lehet, hogy fix LD A, 40h vagy LD A, 50h kell helyette, ami még lassít egy keveset a vezérlésen.csak a fix 50h működik, tegnap elszórakoztam pár órát a tesztelésekkel, mindegyik emu (SPecemu, ZXSpin, és Unreal debugger kezelése macerás)
A sok extra kód miatt esetleg előfordulhat, hogy már nem marad elég hely a BA00h-BFFFh területen, de ha az ilyen gépeket csak a TAP verzió támogatja, akkor talán nem probléma, mert a TAP betöltő egyébként rövidebb.Megoldom, az is menjen ezeken a fostalicskákon is :D Amúgy nem lett olyan sokkal hosszabb a kód.
Hely megtakarítása céljából egyébként a kicsomagoló rutin is cserélhető lehetne a decompress_m2_new.s módosított változatára (ami rövidebb), mivel itt nem fontos, hogy ne használja a BC', DE' és HL' regisztereket. A kimenetnek sem kellene 8K-s határon végződnie, ha ez esetleg hasznos.Egyelőre jók vagyunk a 8k blokkos kicsomagolóval :)
meg remélem egyik verzióból se felejtettem megcsinálni az új időzítést számláló megoldást. (minimális lett az eltérés)
Egyelőre jók vagyunk a 8k blokkos kicsomagolóval :)
:lol:Megkérdezzem?
Én csak a két chip envelope grafikonját néztem (mert csak azt találtam), ott nem láttam eltérést.
Ha esetleg még is hasznos lenne később valamilyen célra, ez a változat 145h helyett 116h méretű, illetve a SIZE_OPTIMIZED engedélyezésével 10Dh. Bár a sebességet még nem teszteltem, és azt sem, hogy működik-e. :oops:Sose lehet tudni, bármikor hasznos lehet :)
Esetleg a legnépszerűbb vagy legpontosabb emulátor kimenetét tesztelni lehetne, ha nincs forráskód, akkor egyszerű WAV file-ba felvenni például 1 másodpercenként növekvő hangerejű hangot 0-tól 15-ig, és az alapján már lehet táblázatot készíteni.Oké, megkérdezem, melyik lehet a legpontosabb, vagy legnépszerűbb
Három mentést csináltam, a +3, és 128 SPECEMUval , a Scorpion Unreal Speccyvel készült, itt sajnos valahogy levettem a hangerőt még régebben, és nem tudom visszaállítani, remélem nem full nulla az utolsó pár érték.
0, 288, 424, 595, 893, 1363, 1875, 2984, 3582, 5715, 7849, 9812, 12415, 15359, 18431, 21845
FUSE: 0, 300, 447, 635, 925, 1351, 1851, 2991, 3695, 5782, 7705, 9829, 12460, 15014, 18528, 21845
Az a kérdés a scorpionnál, hogy azért van-e eltérés, mert az YM-es, vagy az emulátor miatt.
Ez egyszerűen tesztelhető ha ugyanaz az emulátor AY-t is tud emulálni.Óóó, megnéztem, és tud, győzzön az ember válogatni :D
valaki csinálhatna egy jobb specys videót, mert amit a wos-on találok azok mikrofonnal felvett videót, ami hát egy zenei cucc esetén nem túl szerencsés...Egész véletlenül azt nem azért csinálják, hogy bizonyítsák tényleg Spektrumról vagy klónról megy, nincs a háttérben valami csalás vagy ámítás?
Egész véletlenül azt nem azért csinálják, hogy bizonyítsák tényleg Spektrumról vagy klónról megy, nincs a háttérben valami csalás vagy ámítás?
.\epcompress.exe -raw -m2 -x sidm2.scr tmp.bin
gcc -Wall -O2 c64conv.c -o c64conv.exe -s
.\c64conv.exe tmp.bin sidc64.scr
AY/YM felismerés és D/A táblázat választás (nem biztos, hogy jól működik):Szerintem jól, EP128emu, SPecemu, ZXSpin AY lett, UnrealSPeccy meg YM, ha a fejem tetejére is álltam, hiába állítottam át kétféle AY-ra, akkor is YM lett, akkor jutott eszembe, hogy csak a volume table-t állítom, magát az emulációt nem :ds_icon_cheesygrin:
Már van Git (https://github.com/istvan-v/sidbasic), de egyelőre még nem töltöttem fel semmit.Okie, akkor szórom az infót a WOS-ra :)
Feltöltöttem a konvertáló programokat és a sidbasicSP-t, bár az utóbbi még nincs kész, egyelőre csak a TZX verziót fordítja, hamarosan beépítem a TAP változato és az esetleges frissítéseket.TAP verzióra is csinálsz egy C programot?
Továbbfejlesztett tapeenc készül, támogat TAP formátumot és betöltő nélküli kimenetet is (M64 konvertáláshoz).Nagyon profi :)
A Git frissítve, de még nem teszteltem különösebben, hogy vannak-e új hibák. :oops:Eddig se volt, legalábbis abban, amit te csináltál, bezzeg, amit én :D
tapeenc Git verzió 32 bites Windowsra:Megosztottam a WOS-on :)
(Attachment Link)
Megosztottam a WOS-on :)
g++ -Wall -O2 tapeenc.cpp -o tapeenc -s
sjasm loader.s loader.out
SjASM Z80 Assembler v0.39g6 - www.xl2s.tk
Pass 1 complete (0 errors)
Pass 2 complete
Errors: 0
sed -e 's/USE_ROM_LOADER[[:space:]]\+equ[[:space:]]\+[01]/USE_ROM_LOADER equ 0/' < sidbintSP.s > sidbintSP_tzx.s
g++ -Wall -O2 -DUSE_DACTABLE_AY ay_da_opt.cpp -o ay_da_opt -lm -s
./ay_da_opt 249
Distortion = 3.714%
g++ -Wall -O2 -DUSE_DACTABLE_YM ay_da_opt.cpp -o ym_da_opt -lm -s
./ym_da_opt 247
Distortion = 4.291%
sjasm sidsynth.s sidsynth.bin
SjASM Z80 Assembler v0.39g6 - www.xl2s.tk
Pass 1 complete (0 errors)
Pass 2 complete
Errors: 0
../../ep128emu/epcompress -raw -m2 -6 sidsynth.bin sidsynth.bin
Compressing data
100%
gcc -Wall -O2 c64conv.c -o c64conv -s
../../ep128emu/epcompress -raw -m2 -x sidm2.scr sidc64.scr
./c64conv sidc64.scr sidc64.scr
sjasm cod47scr.s cod47scr.bin
SjASM Z80 Assembler v0.39g6 - www.xl2s.tk
Pass 1 complete (0 errors)
Pass 2 complete
Errors: 0
../../ep128emu/epcompress -raw -m2 -6 cod47scr.bin cod47scr.bin
Compressing data
100%
sjasm sidbintSP_tzx.s sidbintSP_tzx.out
SjASM Z80 Assembler v0.39g6 - www.xl2s.tk
Pass 1 complete (0 errors)
Pass 2 complete
Errors: 0
./tapeenc sidbasicSP.tzx SIDBASIC loader.out 0x4253 sidbintSP_tzx.out
sjasm taploader.s taploader.out
SjASM Z80 Assembler v0.39g6 - www.xl2s.tk
Pass 1 complete (0 errors)
Pass 2 complete
Errors: 0
sed -e 's/USE_ROM_LOADER[[:space:]]\+equ[[:space:]]\+[01]/USE_ROM_LOADER equ 1/' < sidbintSP.s > sidbintSP_tap.s
sjasm sidbintSP_tap.s sidbintSP_tap.out
SjASM Z80 Assembler v0.39g6 - www.xl2s.tk
Pass 1 complete (0 errors)
Pass 2 complete
Errors: 0
./tapeenc -tap sidbasicSP.tap SIDBASIC taploader.out sidbintSP_tap.out
A mindenféle SID lejátszó verzió most már véglegesnek tekinthető?
sinclair.hu-n is kérdezik: van ennek a SIDBasicnek valami leírása is valahol?
Pontosan mikről kellene részletesebb leírást készíteni? A konvertáló programok fordításáról, a konvertálásról, az EP-s lejátszó használatáról, a Spectrum lejátszó fordításáról, a használatáról, vagy Spectrumra konvertálásról (M64->TAP/TZX)? Esetleg a többi EP-s lejátszóról?A konvertálás és használat. Szét van szórva sok hozzászólásban, praktikus lenne egy helyre (mondjuk a wikire) összeszedni a végleges verziót.
Talán az EP-s SIDBASIC is futhatna még 10 kHz-nél valamivel magasabb frekvenciánHa lehet még javítani a minőségen, akkor az jó lenne!
vagy memóriabővített gépekre lehetne olyan változata, amely kicsomagolja az egész bemenetetHa nem kéne menet közben tömörítgetni, akkor az jelentősebb frekvencia növelést tenne lehetővé?
Ha nem kéne menet közben tömörítgetni, akkor az jelentősebb frekvencia növelést tenne lehetővé?
tapeenc -tap -noldr garfield.tap GARFIELD GARFIEL.M64
tapeenc -noldr garfield.tzx 0x364D GARFIEL.M64
tapeenc -tap sidbasicSP.tap SIDBASIC taploader.out sidbintSP_tap.out
tapeenc sidbasicSP.tzx SIDBASIC loader.out 0x4253 sidbintSP_tzx.out 0x364D file1.m64 0x364D file2.m64
Még Plus/4-es változattal is lehetne próbálkozni, bár ott viszonylag népszerű a SID kártya./OFF
A Plus4worldön is átütötte az ingerküszöböt (http://plus4world.powweb.com/forum/33971) a lejátszó. És továbbra is gratula! :smt023
I suppose it works in the same way as the DigiSID player on Plus/4, and probably the ZX Spectrum had a little more processor power to execute the program than Plus/4 (when srceen is on). Actually I do not know, how he made it on AY, as it has no real PCM, and the volume control also only 16 resolution, and it should sound worse than a 4bit DAC. But it sounds like a 6 or 7 bit DAC. Or he may wrote a Viterbi routine to combine the three AY channel into one proper sound frequency?
A TED gyászos képességei a hangképzés terén azért eléggé bekorlátozzák az elérhető minőséget. Ugyan ki lehet csiholni belőle 100+ jelszintet, de közel lineáris sort csak húsz-harminc eleműt lehet ebből kiválogatni, vagy legalábbis nekem ennyi tűnik reálisnak.
0: 0.0000000
17: 0.0172128
33: 0.0347485
18: 0.0469687
49: 0.0526324
177: 0.0705558
19: 0.0770507
34: 0.0946026
20: 0.1073525
21: 0.1379074
50: 0.1430263
35: 0.1550731
22: 0.1687072
178: 0.1916032
23: 0.1998841
36: 0.2161025
24: 0.2282312
51: 0.2348493
37: 0.2778221
179: 0.3152601
52: 0.3285998
38: 0.3404048
39: 0.4040195
53: 0.4249243
180: 0.4427064
40: 0.4622360
54: 0.5244000
181: 0.5752702
55: 0.6277162
182: 0.7141309
56: 0.7244418
183: 0.8606520
184: 1.0000000
Egyelőre még az sem tűnik egyértelműnek, hogy a 100 szint hogyan érhető el bonyolultabb trükkök nélkül, nekem csak 33-at sikerült egyszerű $FF11 írással: :oops:Erre (http://plus4world.powweb.com/ma.php?maid=1550) az egykori levelezési listán megjelent hozzászólásra gondoltam. Azt nem állítom, hogy ezek mind jól elkülönülnének.
Bár a szintek nem pontosan ugyanazok, az ott található táblázat is hasonlónak tűnik, nincs 100 különböző szint, 46 után 52 következik, majd 58, 63, 72, 86 és 100 (a 99-100 eltérés zaj lehet), ami gyakorlatilag megegyezik az én táblázatommal. De ha nem csak egyszerű $FF11 írás lenne, akkor talán többet is el lehetne érni, ami azonban bonyolítaná a hangminta lejátszást./OFF
Egyébként egyszer eltöprengtem, hogy működhetne-e, ha a frekvencia regiszterek irkálásával (2x$3FD|$3FD+$3FE|2x$3FE) próbálnánk növelni a lehetséges jelszintek számát?
Ez valamennyire már működik:
(Attachment Link)
Ezt mivel lehet lefordítani? :) (A "kedvenc" assemblerem nem eszi. :oops: )
Szerk.: egyes zenéknél (pl. Paperboy) javítaná a minőséget a pulseTable invertálása, aszimmetrikus négyszögjelnél előnyösebb, ha gyakoribb a 0 szint, mert a D/A felbontása romlik a kimeneti szint növekedésével. Természetesen ugyanez a változtatás más zenéknél viszont rosszabb is lehet. :)
Mint laikus kérdezném: ezt nem lehet megoldani automatikusan már a konvertálásnál? Gondolom a táblába mentve van a kitöltési tényező, ami ha nagyobb mint 50%, akkor az értékét automatikusan át lehetne forgatni 50% alá. :)
Sőt, a legújabb verzió nem tűnik rosszabnak, vagy csak nagyon picit, mint a Speccys verzió, tök jó lett, pláne ahhoz képest, hogy csak 31 volume szinttel dolgozik :)
Nem lehetne +4-en native SID kód lejátszás mellett is megcsinálni ugyanezt?
Csak azért kérdem, mert úgy gondolom, hogy maga a zene lejátszó kód nem eszik sokkal több időt általában , mint maga a kicsomagoló rutin, de lehet rosszul gondolom. (bár belegondolva, hogy a zenevezérlő kód legalább minden 1/50 másodpercben tutira lefut, összességében többet eszik. )
PSID file legyen lejátszható konvertálás nélkül? Itt ugyan kompatibilis a CPU, tehát elvileg meg lehetne oldani, de problémás lehet például a memória kezelés, a hangminta táblázatok mellett nem biztos, hogy marad elég hely amit a PSID-ek nem írnak felül. Bár a jelenlegi verzióban is kb. 40K van fenntartva a bemeneti file és a puffer számára, csak a PSID-ek nem mindig ugyanazt a területet használják. Természetesen így a burkológörbe emulációt is a lejátszónak kellene megoldania.Jogos, erre nem gondoltam. A tippem az volt, hogy a SID-ek nagy része 15% alatti CPU-t használ, de mivel +4-en kikapcsolt kép mellett (ha jól tudom ) 1,7x-es a sebessége a C64-ének, ezért ennek simán mennie kéne, csak az a fránya memória probléma ne lenne.
Úgy érzem nem is érdemes tovább feszegetni ezt. :)
Nem rossz ötlet, csak valószínűleg nem minden PSID működne (tesztelni kellene, hol van a legnagyobb terület, amit általában nem használnak), és az M64-es verzióhoz képest a minőség is romlana valamennyit. Viszont nem kellenének konvertált file-ok, az eredeti PSID-ek kisebbek is.Igen, és elég sok kompromisszummal járna, az egyetlen előnyéhez képest, ha maradhatna a 11KHz-es lejátszás, akkor szerintem nem sokat romlana a minőség, viszont hatalmas munka lenne feltérképezni, hogy mely területeket használják legkevésbé a SID-ek, erre lehetne jó, a dinamikus tábla allokálás, aztán az önmódosító kód, de szerintem ez se lenne 100%-os megoldás, ráadásul iszonyat munka. :( A SPEmuból indultam ki, ott legalább 300 TAP-ot néztem végig, és még így is jött bőven olyan file, ami más utasításkombót használt portírásra, itt meg jöhet bőven olyan SID, ami a kiszemelt területre piszkít.
viszont hatalmas munka lenne feltérképezni, hogy mely területeket használják legkevésbé a SID-ek
00000000 00 ff ff ff ff ff 00 00 00 00 00 00 00 ff ff ff |................|
00000010 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff |................|
*
00000090 ff ff ff ff ff ff ff ff ff ff ff ff ff ff 00 00 |................|
000000a0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
000000b0 00 00 ff ff ff 00 00 00 ff 00 00 00 00 ff ff ff |................|
000000c0 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff |................|
*
00000200 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
*
000002a0 00 00 00 00 00 00 ff 00 00 00 00 00 00 00 00 00 |................|
000002b0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
*
00000310 00 00 00 00 ff ff 00 00 00 00 00 00 00 00 00 00 |................|
00000320 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
*
00000400 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff |................|
*
0000d000 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
*
0000d400 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff |................|
0000d410 ff ff ff ff ff ff ff ff ff 00 00 00 00 00 00 00 |................|
0000d420 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
*
0000dc00 00 00 00 00 ff ff 00 00 00 00 00 00 00 00 00 00 |................|
0000dc10 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
*
0000e000 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff |................|
*
00010000
Graham/Oxyron készített egy táblázatot az összes lehetséges NMOS 6502 (származék processzor) utasításról. Ebben részletesen elemezve van még az is, hogy melyek a stabil és instabil "illegális" utasítások.
Az ANC ezek szerint úgy működik, mint z80-on az AND?
Nem egészen, mert itt a C bit az S másolata lesz, de ebben az esetben az mindig 0, mert a csatornák hangminta értékei 0-63 tartományra korlátozottak.:lol: oké, értem, mókásak ezek az undokumentált utasítások :)
:lol: oké, értem, mókásak ezek az undokumentált utasítások :)Hát még az, ahogyan működnek (http://www.pagetable.com/?p=39)! (Nem mindig elérhető az oldal, mintha valami háztáji szerverről futna.)
Így lehet, hogy valamivel nagyobb frekvencia lett volna elérhető.Akkor ezt jó lenne beépíteni, ha lehet! :oops:
A SID lejátszó téma ugyan már nem tűnik aktuálisnak, de a Plus/4 verzióban van még egy-két optimalizálás ami talán hasznos lehetett volna EP-n is. A frekvenciát táblázattal konvertálja (8 bites érték szorzása 8 bites konstanssal = 512 byte méretű táblázat), és a hullámforma/hangerő byte-ot is táblázat segítségével dolgozza fel (amelynek minden eleme a megfelelő hangminta táblázat címe / 256, vagy 0 négyszögjel esetén). Így lehet, hogy valamivel nagyobb frekvencia lett volna elérhető.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?
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 ;) )
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 ;) )
Valamit említettél a PWM-re is, hogy invertálva lenne az igazi?
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.
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:Az elsőt hogyan lehetne megoldani? a kicsomagoló rutinba is beágyazni egy videómegszakítás figyelést?
- 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
É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.
ld a,c
ld (v1vol+1),a
ld d,b
; and 80h
; ld e,a
ld b,high volumeConvTable
ld a,(bc)
inc b
rra
jr c,pulse1
ld (otherw+2),a ;triangle sawtooth noise
di
ld (sidSynth.l1+1),hl
ld hl,otherw
jr wavtab1
pulse1 rrca ; * 8-bit d/a: add a, a (87h)
ld (pulsevl+1),a ;volume value
ld a,d
ld (pulsew+1),a ;pwm
di
ld (sidSynth.l1+1),hl
ld hl,pulsew
wavtab1 ;ld a,e ;ring mod
ld a,(bc) ;xor a/and d
ld (sidSynth.l2),a
de, így a volumeConvTable-ből való adat kinyeréskor előfordult, hogy a C bit be volt lőve, eredetileg egy xor a-t akartam tenni a volumeConvTable elé,de akkor eszembe jutott, hogy a hangerő kijelzőnél AND D-el vágom le a hangerő értéket, ha azt kiszedem, és az LD DE,0e01fh helyett csak LD D,0e0h-t használok, akkor még gyorsítani is lehet 3x1 + 3 ciklust a következő módosítással :) ld a,c
and 1fh
ld (v1vol+1),a
ld d,b
; and 80h
; ld e,a
ld b,high volumeConvTable
ld a,(bc)
inc b
rra
jr c,pulse1
ld (otherw+2),a ;triangle sawtooth noise
di
ld (sidSynth.l1+1),hl
ld hl,otherw
jr wavtab1
pulse1 rrca ; * 8-bit d/a: add a, a (87h)
ld (pulsevl+1),a ;volume value
ld a,d
ld (pulsew+1),a ;pwm
di
ld (sidSynth.l1+1),hl
ld hl,pulsew
wavtab1 ;ld a,e ;ring mod
ld a,(bc) ;xor a/and d
ld (sidSynth.l2),a
természetesen ez is fagyival kezdett, mert az LD DE,0e01fh-ról LD D,0e0h-ra való átállásnál nem vettem figyelembe, hogy az 0e0h-t a program írja, ezt két helyen kellett még módosítani.gondolom most optimalizálsz, a hozzászólás eltűnéséből gondolom :)
(igaz a DI-s rész 3 ciklussal hosszabb lett)
Az LD A, (BC) lehetne a DI előtt is, ez ugyan 3 byte méretnövekedést eredményez, de a FILE-os szegmensen talán nincs nagy jelentősége.Egyelőre nincsen :D , meg is csinálom, így a DI-s rész 4 ciklussal rövidebb is, mint az eredetiben.
én már azon gondolkoztam, hogy
50Hz-es vezérlést 11904 Hz-re
Módosítások eszközölve :) Legújabb teszt verzió, már ROM verzió is van a csomagban.
Egy lehetséges hiba: 4 MHz-es CPU-n 12 kHz-et ír ki, de továbbra is 11364 Hz frekvenciát állít be.Elszúrtam, mindenhol eggyel magasabb értéket állítok be, mint kéne, elszámoltam :lol:
Tehát úgy, hogy az 500 Hz legyen fix, tehát azt kell a tényleges lejátszási frekvenciából számolni, és a vezérlési sebességet meg az 500 Hz tovább osztásából?
Első körben a digi lejátszó futna addig ciklusban, amíg eléri az 500 Hz-et, ilyenkor mindig csekkolunk 4. bitet a 0b4h porton, ha aktív, akkor ugrás a display vezérlésre, majd csekkolni hogy a zenevezérlő ciklus elérte-e a 0-t, ha igen, vezérlés, egyébként visszatérés a megszakításból?
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.azért is tettem a video irq elejére, amúgy lehet a mostani teszt verzióban se villogna, ha elől lenne :-) A lefuto el figyelese jó ötlet, ha beallitom fixen az egész aktív képre a vint bitet, csak az otolso 100 sorra nem az jó megoldás is rá, nem ?
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.
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.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 :-D
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.
Van egy kis gond, előre tettem a videó rutint (gyorsított mindennel)
Hú de nehezen jöttem rá a megoldásra, az aktuális 2. lapot el kell menteni a verembe :ds_icon_cheesygrin: , 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.
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
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.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 :)
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.
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.
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.
Továbbfejlesztett freqdiv.s: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 :)
Megkeresi a legjobb pontosságot (vagy azonos pontosságnál kisebb CPU használatot) eredményező osztókat amelyekkel az alábbi (egyszerűen módosítható) feltételek teljesülnek:
- első osztó 50 és 255 között
- az ezzel osztott frekvencia >= 125 Hz (VINT teszt legfeljebb 8 ms időközönként)
- második osztó 1 és 10 között
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).Átállítottam a 46-os szélességre? :oops:
Kisebb optimalizálás az előző változathoz képest, de kevesebb szabad hely marad a vermben (-5 byte):Az szerintem még bőven belefér :), akkor lehetnénk szerintem bajba, ha vezérlés alatt meghívódna a vezérlés még párszor :D
A kicsomagolásra várakozás hibás volt, ezt javítottam, néhány további (minimális) optimalizálás mellett.hm, ki tudja milyen hibákat vétettem még? :oops:
Átállítottam a 46-os szélességre?
Az szerintem még bőven belefér :), akkor lehetnénk szerintem bajba, ha vezérlés alatt meghívódna a vezérlés még párszor :D
hm, ki tudja milyen hibákat vétettem még?
Az újabb változatban (további kód növekedés után) már átkerült 0000h kezdőcímre, így a hely biztosan nem probléma. :) Bár valószínűleg a módosítás nélkül sem lett volna.:)
Ez a hiba az egyik korábbi változtatásom eredménye volt :oops:, hiányzott egy POP AF.Pedig hibákat én szoktam véteni ;)
Erről jut eszembe, hogy a szövegeket lehetne 1-2 karakterrel beljebb tenni, mert némely monitoron kilóg :oops:Megnézem hogy néz ki, és annak függvényében elintézem az 1, vagy két karakteres tolást. :)
:)Pedig hibákat én szoktam véteni ;)
Megnézem hogy néz ki, és annak függvényében elintézem az 1, vagy két karakteres tolást. :)
Emulátoros konfiguráció javítva, illetve egyszerűbb is lett a kód, mivel mindig a getSIDPlaybackFreq-t használja a tényleges mintavételezési frekvencia mérésére. Kicsomagolásra várakozás közben működik a video megszakítás, és a 11905 Hz-es lejátszási frekvenciát 120 Hz-ig használja a program (bár nem tudom, valóban van-e 120 Hz-es file).:smt041
ha jól látom, most 40-300Hz között fogad el vezérlést, gyakorlatban nem lehet olyan SID, ami mondjuk 25Hz-es vezérléssel bír, és 300Hz fölötti?
Egy dolgot nem értek, a kód bugászása után sem, hogy a sidSynth (0000h)-n mi célt szolgál a 3 RET ? :)
25 Hz még működne 20 MHz-es gépen is (62500 / 250 / 10 Hz), tehát a 40 Hz minimum különösebb probléma nélkül 25-re csökkenthető. Bár a konvertáló programok jelenleg nem fogadnak el 50 Hz alatti sebességet. :oops: A 300 Hz valójában már nem működik 4 MHz-es gépen az első osztó 50-255 tartományra korlátozása miatt, ez a verzió csak 11364 / 50 = 227 Hz-ig használható, amit még javítani kellene.És mintha ezt említetted is volna, nem kell javítani a konvertáló programokon, nagyon jók, ahogy vannak :) , nem tudom a konvertálásom alatt dobott-e ki alacsony vezérlési frekvenciát, szerintem nem, igaz nagyüzemben konvertáltam, nem figyeltem, 99%-ban a sikertelen konvertálások RSID-ek voltak.
Csak az IRQ rutin 0038h-ra igazítását, a hely kitöltése lehetne előtte is, vagy RET helyett nullákkal. Vagy 0000h helyett 0003h kezdőcím, de akkor azt módosításnál több helyen is változtatni kellene.Így már mindent értek :) A RET-ek miatt volt gyanús, azt hittem van valami funkciójuk is.
A 300 Hz támogatására a legegyszerűbb megoldás itt (findFreqDiv) az 50-et 38-ra cserélni:Oké, módosítottam is.Code: ZiLOG Z80 Assembler
ld a, c cp 50 jr c, .l6 ; div1 < 50?
.l4: ld bc, 0ffffh ; * err
Valójában nem csak ott van hiba, a D használata a legjobb osztó tárolására (ami csak a legújabb verzióba került) okoz problémát, az .l4-nél az FFh kezdőérték (255/16 Hz eltérés, a gyakorlatban ilyen sem fordul elő) is jó lenne.Ezt most nem értem, az .l4-nél a kezdőérték alapból 0ffffh, aztán minden új számolásnál 0ffxxh, és nem tapasztaltam hibát :)
Ezt most nem értem, az .l4-nél a kezdőérték alapból 0ffffh, aztán minden új számolásnál 0ffxxh, és nem tapasztaltam hibát :)
:smt041Amennyire tudom, a teljesen "szabálytalan" frekvenciák egyáltalán nem jellemzőek. A szaporábban frissített zenéknél is a képfrekvencia egész-számú többszöröse szokott lenni a lejátszó hívásainak gyakorisága. És tényleg létezik (bár nagyon kevés) 25 Hz-es zene is. A múltkor küldtem is neked PM-ben néhány kiemelt bejegyzést a HVSC STIL.txt-jéből, mint példát extremitásokra. A játékprogramozók rendszerint örülnek, ha raszterlefutásonként egyszer gond nélkül meg lehet hívni a zenerutint. A demósok meg nagyon nem szeretik, ha a képfelépítés szinkronjától függetlenül össze-vissza mászkál időben a lejátszó rutin, mert megzavarhatja a rasztertrükköket, és ráadásul még a hallgatni is rossz lesz az ütköző prioritású programrészek miatt a zenét.
Ezen már gondolkoztam én is, hogy a köztes frekvenciáknak van-e értelme, de elméletileg lehet olyan elvetemült SID, ami mondjuk 110Hz-es megszakításon ketyeg, vagy épp 140-en :D
És tényleg létezik (bár nagyon kevés) 25 Hz-es zene is. A múltkor küldtem is neked PM-ben néhány kiemelt bejegyzést a HVSC STIL.txt-jéből, mint példát extremitásokra.És tényleg, már emlékszem is, volt köztük legalább egy, ami 25Hz-es volt. :)
Azzal volt még probléma, hogy a D-be került az addig talált legjobb osztó, az E-be pedig a ciklusban éppen aktuális, de van egy osztás a DE 16 bites értékével, így a számított frekvencia eltérés rossz. Bár így is találhatott használható (ha nem is feltétlenül optimális) osztókat.findFreqDiv_ végén a
findFreqDiv_ végén a
ld a, c ; * div1
-re szükség van? Mert findFreqDiv_ visszatérése után úgyis egy SBC A,A a következő A regisztert érintő utasítás.
Valóban törölhető (és a rutin előtt a megjegyzésből is az A), lehet csak a C-ben is.Csak kommenteltem :) , a szöveg eltolás maradt itt is, valójában az eltolt szöveges forrásba vittem fel az osztó módosításait :)
Üdv, Keresem a mekkmester zenéjét freki, hossz, szünet, hossz formátumban. Köszi
TVC verzióAzt a mindenit! :shock:
Nem tudom valakinek van-e real TVC-je, érdekelne, hogy azon megy-e :D :DJövő héten meg tudom nézni.
Jövő héten meg tudom nézni.Köszi. ☺
És még marad CPU idő a Commodore feliratot is görgetni! Próbáltam a WinTVC-vel is, de az minden áron magnóról akarna tovább tölteni, ahhoz nem értek.Én is csak az ep128emuval probaltam, mas TVC emu nincs feltéve a gépemre.
Facebookon nem vagy fent? Ott van a TVC-seknek csoportja, ott lehetne megmutatni nekik.
DAVEbasicTVC-t nem akarsz csinálni? A sztereó hangot nem is, talán a többit valamennyire vinné a TVC... vagy nem.
TVC verzióEnnek mi lesz majd a címe? Commodore-Videoton (CoVid!) Music Player?
Ennek mi lesz majd a címe? Commodore-Videoton (CoVid!) Music Player?Jó ötlet :D COVID20 :D
4 verzió van, ami valójában csak kettő, lemezes rendszeren 236-os errort (fájl vége utáni olvasás) kaptam, ezért megpecseltem a TVCTAPE által generált fájlban a hosszt , ami teljesen jónak tűnt, nem is értem miért panaszkodott a TVC.Igazi gépen is 236-os hiba az első kettővel, a pecseltek jók.
Nem tudom valakinek van-e real TVC-je, érdekelne, hogy azon megy-e :D :D
Igazi gépen is 236-os hiba az első kettővel, a pecseltek jók.Kúúúl, köszi szépen :)
És elég jól szólnak! :smt038
TVC-sek konvertáltak egy nagy adag M64 fájlt. (http://tvc.hu/cas/2020/HVSC72_M64.zip)Ez szuper, de ehhez már hely kellene az SD kártyán :) Tényleg, hol tart a FAT16-os EXDOS 3.0? :oops: