[asm]LEBEG1 LD A,(HL)
LEBEG2 CP (HL)
[/asm]
Nem errõl ismeri fel a fordító?
Quote from: "MrPrise"Nem errõl ismeri fel a fordító?
Az EP-s fordítók szerintem onnan ismerik fel, hogy a sor elsõ karakterén kezdõdõ szó :)
Meg is néztem most, Asmon, Fenas, Heass mind így kezeli. Heass-ben lehet kettõspont, de nem kötelezõ.
Az asmonban és a fenasban is lehet kettõspont, de nem kötelezõ. (mostanság fenas-t használok, de ha lenne heass-om romban, akkor azt használnám...). Az a baj, hogy a heass.ext-tel nem tudok fordítani. (nem tudom, miért)
Tehát hiába raksz utána :-ot, ha bentebb kezdõdik akkor nem címkeként értelmezi?
Quote from: "MrPrise"Tehát hiába raksz utána :-ot, ha bentebb kezdõdik akkor nem címkeként értelmezi?
Így van!
A rendszerszegmensen hol kezdõdik a karakterkészlet? Nem találom ez Enterpress-eimet.
Hogyan lehet azt megoldani, hogy saját programból, ha kiadom az exdos parancsot, és abból esc-kel visszatérek, ne tûnjöm el a fél képernyõ (amit az exdos kitakart).
Konkrétabban: az atomixben csináltam egy olyat, hogy ha megnyomom a kettõspontot, elõugorjon az exdos. Ha kilépek, tök jól folytatódik minden ott, ahol abbamaradt, leszámítva azt, hogy üres a képernyõ.
Peldaul az sdcc (sdcc.sf.net) olyasmiket hasznal hogy:
ADC A,#12
LD L,12(IX)
Szoval eleg nagy a kavar, sajnos ninvs olyan nagy foku egyettertes mint pl 65xx asm syntax eseten. Ezert szeretnem osszeszedni az osszes koztudatban levo szintaxist, hogy minnel tobb dologgal elboldoguljon. Ha valakinek ez ugyben van tehat megjegyzese, akkor irjon :)
...szeretnem osszeszedni az osszes koztudatban levo szintaxist
Quote from: "lgb"Peldaul az sdcc (sdcc.sf.net) olyasmiket hasznal hogy:
ADC A,#12
LD L,12(IX)
Ilyet most látok életemben elöször!QuoteSzoval eleg nagy a kavar, sajnos ninvs olyan nagy foku egyettertes mint pl 65xx asm syntax eseten. Ezert szeretnem osszeszedni az osszes koztudatban levo szintaxist, hogy minnel tobb dologgal elboldoguljon. Ha valakinek ez ugyben van tehat megjegyzese, akkor irjon :)
Szerintem egyetértés van, legalábbis én EP-n meg egyébként is csak egyfajtát láttam, azt amit a hivatalos Zilog leírásokban is látni. Éppen ezért döbbentem meg az extrém elvadult példádon, hogy ki lehet olyan örült, hogy ilyet kitalál :-)
Quote from: "lgb"...szeretnem osszeszedni az osszes koztudatban levo szintaxist
Ez nem ízlés kérdése.
http://www.z80.info/zip/z80cpu_um.pdf
Edit: Hmmm. Még mindig volt mit javítani benne :D
http://www.zilog.com/docs/z80/um0080.pdf
Quote from: "lgb"...szeretnem osszeszedni az osszes koztudatban levo szintaxist
Ez nem ízlés kérdése.
http://www.z80.info/zip/z80cpu_um.pdf
Edit: Hmmm. Még mindig volt mit javítani benne :D
http://www.zilog.com/docs/z80/um0080.pdf
Persze ez elvileg Z80 eseten is megvan, ahol ugye ilyesmire szokas hasznalni a (...) jeleket, viszont pl ezt se erzem mindenhol logikusnak.
Quote from: "lgb"
Persze ez elvileg Z80 eseten is megvan, ahol ugye ilyesmire szokas hasznalni a (...) jeleket, viszont pl ezt se erzem mindenhol logikusnak.
Hol nem logikus szerinted?
Én sem értem a hívás mûködését, pl. honna tudja a visszatérési címet, meg ilyesmi.
LD HL,RETC
JP rutin
RETC ...
rutin ...
JP (HL)
De úgy általában is érdekelne a Z80 gépi kód, azon belül az EP programozás. PC-n már assemblyztem, utoljára kb. 10 éve... Ha valakinek van türelme válaszolgatni, az Assembly topikban alkalomadtán kérdezgetnék, vagy ajánlhatnátok valami okítóanyagot.
A macro miatt nem lehet cimkét használni,
Én úgy emléxem, hogy volt rá valami megoldás...
Sajnos én sem találtam benne, tehát marad a dolláros kifejezés. Viszont akkor a GEN-bõl emlékeztem ilyenre.
Másik ötletem, hogy kéne egy kártyaismertetõ-sorozatot összehozni, pl. melyik kártya melyik porto(ka)t használja, az adott foglalat vagy ram melyik szegmense(ke)n látszik, stb. Itt elsõsorban a Mészáros-féle kártyákat értem... :)
Lebegõpontos rutinokat keresek Z80 assemblyre... (szorzás, összeadás).
Azok nem azok, amiket a BASIC is használ? Szerintem annál vannak gyorsabb rutinok is.
Viszont 286-oson láttam olyan pár száz bájtos .com file-t, amit kb. 1 mp alatt rajzolt
ugy emlékszam van olyan utasitás ami a port tartalmát közvetlenül a memoriába tölti vagy olvassa
valahogy igy IN (HL),(C) OUT (C),(HL) ?
Elvileg az ED 70 és ED 71 lehetne az in (hl), (c) és out (c), (hl), de ezek nem mûködnek.Azok az IN F,(C) OUT (C),F, mûködnek csak sok értelme nincs :-) (pl az IN-nél a két nem használt flag biten marad meg a beolvasott érték)
Elvileg az ED 70 és ED 71 lehetne az in (hl), (c) és out (c), (hl), de ezek nem mûködnek.Azok az IN F,(C) OUT (C),F, mûködnek csak sok értelme nincs :-) (pl az IN-nél a két nem használt flag biten marad meg a beolvasott érték)
Megjegyzem találkoztam már olyan Spectrum játékkal, ami használta az IN F,(C)-t billentyûfigyelésre... (gondolom a visszafejtés megnehezítésére) ezért az Spectrum emu programjába ezt is beletettem.
case 0x070:
{
_IN(R.TempByte);
ADD_PC(2);
R.Flags |= Z80_CHECK_INTERRUPT_FLAG;
}
break;
case 0x071:
{
_OUT(0);
ADD_PC(2);
R.Flags |= Z80_CHECK_INTERRUPT_FLAG;
}
break;
a 2-es fejlecu bovito ki is tud ugy takarodni a memoriabol, mintha ott sem lett volna ? Memoria felszabadul, :help listabol eltunik, stb. ? Mintha be sem toltottem volna ?A 2-es fejlécû igen, de az nem bõvítõ :-) Az áthelyezhetõ felhasználói program, igazából pont ez való arra amit te szeretnél.
Vagy hol van egy reerencia szintu hw leiras ep- rol ? Azt hittem az exos konyv szolgal erre a celra is ...Sok dokumentáció nem jutott el hozzánk, legalábbis a "nép" körébe...
Emellett a 44 "karakter" (exos terminologia: "slot") mellett meg jo, de ha ennel nagyobbra veszem pld. 46 (bal margo: 8, jobb margo: 54) vagy ennel nagyobb, akkor fellep a jelenseg! Leharapja a nick a kep ket szelet ?46-nál többet már a dokumentáció alapján se tud a Nick :-)
Van olyan monitorod amivel latszik a teljes szelesseg ? Ha van akkor este felrakom.Még sose próbáltam mit lehet betekerni :-)
Hol van info arrol, hogyan lehet ide feltolteni ?MrPrise, van az újoncoknak valami fórum használati tankönyv? :-)
Ki tudja hol talalhato informacio olyan dolgokrol mint pld. a ra midozitesek ? Tehat ha valami referenciaban azt olvasom hogy egy ld a,(hl) az pld 3 orajelciklusnyi ido(nem biztos hogy annyi csak valami iylesmi ertekek remlenek), akkor az egy elmeleti minimum ertek, ehhez hozza fog jonni a ramok kesleltetese miatt X orajelciklus, memoriatipusok (video,sima,rom) szerint kulonbozo merteku, de hogy igazabol ezek mekkorak ?
Es hogy meg mik befolyasolhatjak a futasi idot, pld. emlexem amigan az sem volt mindegy hogy milyen kepernyouzemmod volt bevaltva, ilyesmikre gondolok, hogy EP- n ezek mik ?
azaz nem lesz gyorsabb a gép (a video RAM hozzáférés sem) ha az egész képernyõn csak keret van.Hmm... az egyszerûség kedvéért a Nick akkor is olvas, amikor nem kell neki az adat?
És mi történik, ha a Nick 83H portjának nullázuk a 6-os bitjét? (b6 Set for normal operation. Clear to inhibit clocking of the line parameter counter.)
Azonkívûl, hogy ilyenkor nincs kép :-) vajon gyorsabb-e a video RAM?
na ki a nick guru?Tigrian! De õ sajnos mostanában nem jár erre :-(
Egyébként hogyan lehet, hogy a végén úgy indul újra az EP és jelenik meg a villogó ENTERPRISE felirat, hogy nincs elõtte memóriateszt :?: Vajon igazi EP-n is lehet ilyet?Ejnye, nem figyeltél az elmúlt években, amikor számtalanszor ajánlottam ezt a módszert gépi kódú programból való kilépésre... :-(
LD A,6
EX AF,AF'
LD A,1
LD HL,0C00DH
JP 0B217H
Természetesen ekkor a 2-es lapon a rendszerszegmensnek kell lenni.Ejnye, nem figyeltél az elmúlt években, amikor számtalanszor ajánlottam ezt a módszert gépi kódú programból való kilépésre... :-(Szerintem figyeltem én, csak amikor a valóságban is láttam ilyet, rendkívül meglepõdtem, mert ilyet még nem láttam. :D Elméletben nem döbbent le annyira. :D (Nem mintha értenék hozzá, hogy a kódban szereplõ hieroglifák mit jelentenek, leginkább talán pekingi boltok felirataira hasonlítanak.)
Akkor pl. basicbõl is ki lehetne adni ilyet, HEX és CALL USR utasítások segítségével? (Na jó, ALLOCATE is kell - ezzel ki is merült a gépi kód ismeretem.)Persze!
10 PROGRAM "EPLOGO.BAS"
100 ALLOCATE 11
110 CODE E=HEX$("3E,06,08,3E,01,21,0D,C0,C3,17,B2")
120 CALL USR(E,0)
Persze!Ez igen!10 PROGRAM "EPLOGO.BAS"
100 ALLOCATE 11
110 CODE E=HEX$("3E,06,08,3E,01,21,0D,C0,C3,17,B2")
120 CALL USR(E,0)
Ez igen!
Hogyan tudtad ilyen gyorsan megcsinálni? Kívülrõl tudod, hogy melyik utasításnak milyen hex kód felel meg, vagy valami más módszerrel?
(Egyébként azt hittem, véletlenül sikerült egyszer megjegyeznem, hogy a C3 = RET, de akkor ezek szerint nem az a RET, hanem valami JP?)
vagy valami más módszerrel?ASMON tud egybõl BASIC programnak fordítani, azt már csak ki kell egészíteni :-)
A EXOS által használt 0-ás szegmenst kilapozom, és helyére belapozok egy elõre kiválasztott memóriaszegmenst, amire felmásolom a 0-ás szegmens tartalmát 0-200H-ig, és átállítom, ha jó emlékszem a BFFCh memóriacímet a megfelelõ értékre. EP32 magnós konfig alatt nincsen semmi gondom a file betöltéssel, teljesen jól mûködik, de EP128 EXDOS-os config alatt CF-es hibaüzenetet ad vissza az EXOS1-es hívás.Ez izgi, mert ez én is csinálom a spectrum átiratos betöltõmben, EP64 esetére. Itt az FF szegmens lesz a nullás lap, betöltõ program, LPT és a rendszer szegmens egyben :-) és mûködik is az EXOS 1 magnóról, floppyról, vinyóról egyaránt! Annyi a fontos, hogyha te is FF szegmenst akarod erre használni, hogy az EXOS határt is be kell állítani, persze elötte kiutaltatni megosztott szegmensként.
A CF-rõl nem találtam semmit.A CF az számításaim szerint 207, az pedig File not found.
:?:
el tudnátok mondani pontosan mit csinál az lpt vsync része?Én már kezdem érteni, egyszerüség kedvéért nézzünk egy üres LPT-t, ez van alapból az IVIEW-ben:
sosem értettem miért kell ez a trükközés a végén, azaz miért ilyen bonyolult?
eltérõ módú sorok, különbözõ margókkal... ?
SYNC
DEFB 106,12H,63,0,0,0,0,0,0,0,0,0,0,0,0,0 ;150 sor
DEFB 106,12H,63,0,0,0,0,0,0,0,0,0,0,0,0,0 ;150 sor
DEFB 253,10H,63,0,0,0,0,0,0,0,0,0,0,0,0,0 ;3 sor, a szinkronizacio kikapcsolva
DEFB 252,10H,6,63,0,0,0,0,0,0,0,0,0,0,0,0 ;4 sor, a szinkronizacio bekapcsolva
DEFB 255,90H,63,32,0,0,0,0,0,0,0,0,0,0,0,0 ;1 sor, a szinkronizacio a sor felenel kikapcsol
DEFB 252,13H,6,63,0,0,0,0,0,0,0,0,0,0,0,0 ;4 ures sor
A 2 db 150 soros rész szabadon variálható képmegjelenítésre. Konkrétan az IVIEW esetén a kettõ közé jön a kép, ennek megfelelõen csökkentve ezeknek a hosszát. Ami megmarad ezekbõl a sorokból, az fogja a keretszínt megjeleníteni a kép alatt és felett.Ejnye, nem figyeltél az elmúlt években, amikor számtalanszor ajánlottam ezt a módszert gépi kódú programból való kilépésre... :-(
Az EXOS lapozórutinján keresztül kell meghívni az 1-es szegmenst, 6-os akciókóddal:Code: [Select]LD A,6
Természetesen ekkor a 2-es lapon a rendszerszegmensnek kell lenni.
EX AF,AF'
LD A,1
LD HL,0C00DH
JP 0B217H
1. a kisebbik: nem szabadítja fel a felhasználónak kiutalt szegmenseket, ezt meg kell tennünk magunknakTermészetesen!
2. a nagyobb probléma: nem mûködik EXOS 2.0-n. Ehhez módosítani kell az utolsó sort, JP 0B21C-re.Nem szép de mûködik :oops: igaz végrehajt pár fölös utasítást :oops:
Ha megírok egy programot az Asmon-ban, akkor hogy kell elmentenem ahhoz, hogy gép újraindítása után betöltéskor elinduljon?Monitor módban a Z billentyű lenyomása után az 'Object file name'-nél meg kell adni a file nevet, az 'EXOS module header'-t YES-re állítani, és az 'EXOS module type' 5 legyen. Utána az A billentyűvel lehet lefordítani a programot. Természetesen a forráskódot sem árt menteni kilépés előtt :)
Milyen org címre kell fordítanom, egyáltalán melyik lapra tölti be?100h címre, és a nullás lapra töltődik be a program eleje. Ha hosszabb, mint 15.75K, akkor az EXOS lefoglal legfeljebb két további szegmenst, és azokra töltődik a program többi része. Ezeknek a szegmenseknek a számát az FFh szegmensen a BFFDh és BFFEh címen lehet megtalálni (indításkor nincsenek belapozva). Ezt (http://www.ep128.hu/Ep_Konyv/Exos.htm#41) és ezt (http://www.ep128.hu/Ep_Konyv/Exos.htm#48) célszerű elolvasni.
gondolom, a túlcsordulást nem veszi figyelembe, és csak az alsó byte-ot használja felIgen, itt a bûnös:
Es valo igaz, kihagytam, hogy a felfele scrollt engedelyezi az ep hardware- e, a c64- e meg tulajdonkepp csak a vizszintest, ugyhogy 1-1.
Es most mikor +15 ev programozas utan ujra probaltam valamit, ujra ledobbentett, hogy milyen marha lassan lehet akar csak par pixelt is szoftverbol (nem nick trukkel) megmozgatni a kepen.
Amikor scanneltem a könyveket viszont pont az feltűnt, hogy a gépi kóddal foglalkozó könyvek megemlítik, hogy a rengeteg bitléptető-, rotáló utasítással nagyon hatékonyan lehet vízszintes scroll-t csinálni.
Pld. sztm az kielegito lehetne, ha mondjuk 4 szinu uzemmodban, 32*32 pixeles sprite- okbol ki lehetne tenni ugy 16 darabot 50Hz- el, ugy kb 50% cpu idovel...
szal nem a scroll gyors, az eppen lassu, hanem a modszer gyors= kis prociigeny.Végülis az EP 4MHz-es, a C64 1MHz-es, szóval ha pl. 2Mhz "elmegy" a scrollra, még mindig marad 2 MHz másra. :ds_icon_cheesygrin:
nem tudja valaki hogy milyen assemply mnemonikra fordul le az exos x hivas assemplyben ?
gyors alatt nem azt ertjuk hogy gyorsan megy, sot, epp az a jo, ha a legkisebb lepessel ( adott mod pixelmeret ) tud lepni, tehat epp lassan folyik, csak a gep kb zero prociidovel tudja csinalni ... szal nem a scroll gyors, az eppen lassu, hanem a modszer gyors= kis prociigeny.Volt egy ilyen megérzésem. :D Azért is jutott eszembe ez a demó, mert gyors a scroll, és ha az gyors, akkor gyanúsan a rutin is gyors, kevesebb prociidőt eszik, a léptetésre nem emlékszem, de csak nem karakteres. :D
nincs defb semAkkor kéne keresni egy normális assemblert :-)
ez jo ? :Nem jó mert hiányzik a RST 30 mögül a funkciót definiáló bájt.
hopsz... muxik...milyen assemblert használsz?
Nem jó mert hiányzik a RST 30 mögül a funkciót definiáló bájt.Megvan az, csak DEFB hiányában a program tölti fel, én is néztem egy darabig :D
a nop -ok helyere kerul az rst "parametere". hogy kell ide attacsolni ?Ha írsz egy hozzászólást, akkor nyisd le az additional optiont...
hat kene egy dupla sebesseg a ketszer ennyi csillaghoz, kene egy dupla hogy 50Hz -es legyen ne 25Hz -es, es kene egy dupla ahhoz, hogy ne kelljenek elore letarolt mintak, hanem valos idoben lehessen 3D forgatni.... az tehat nyolcszoros... 4 * 8 = 32Mhz- es z80- u EP- vel mar ki is bekulnek... :)Az emulátoron beállítható. :D Nyomtam már 64 Mhz-is. :D
Igazából a mai pc-k matematikai számolásai is brutális táblázatokat használnak a gyorsításhoz ha jól tudom...Pedig ott aztán szinte senki nem törekszik arra, hogy gyors kódot írjon. :D
Nemtom hogyan kell, endi... Futtathatot regen is csak 2X csinaltam osszesen ... SOMB1, SOMB2 :) Valahova masik cimre kellett forditani, es valamilyen fejlecet tett ele az EP fordito, es valami masik szegmenseket kellett lapozgatni, mar nem emlekszek, es annyit nem er az egesz, hogy igy vackoljak vele, csak egy effekt, annak is csak az alapja... neked nem lehet gond asmon- ban elinditani ... tenyleg csak annyi mint amit oda leirtam ... elindit asmon, megnyomkod amit odairtam, es kesz...nem nagy kunszt, a fejlécben is két hasznos infó van, én a következőképp oldottam meg, hogy PC-s assemblerrel is lehessen mókolni:
ORG 00f0H
db 00,05
dw fillen
db 00,00,00,00,00,00,00,00,00,00,00,00
startpr
...
fillen EQU $-startpr
Ahol a fillen a file hossza.
légyszi futtatható verziót...
ez egy inline assembler, nemtom h melyik, az SDCC nevu c forditoban van benne. lehet van defb, csak en nem talaltam, jo most az a hekk, majd megkeresem.
Pedig ott aztán szinte senki nem törekszik arra, hogy gyors kódot írjon. :D
IstvanV a nagy varazslo.... hat ezt meg hogy csinaltad ? Voltak a kodban abszolut ugrasok... meg minden ...van egy tippem, kimentette az emulátorral a 100h-a program végéig, és készült elé egy fejléc :)
De ha mar igy van, akkor azt tudod hogy esc utan miert nem jon vissza a rendszer ? ASMON- ban siman visszater. BASIC- ban miert nem ?
Nemtom hogyan kell, endi... Futtathatot regen is csak 2X csinaltam osszesen ... SOMB1, SOMB2 :) Valahova masik cimre kellett forditani, es valamilyen fejlecet tett ele az EP fordito, es valami masik szegmenseket kellett lapozgatni, mar nem emlekszek, es annyit nem er az egesz, hogy igy vackoljak vele, csak egy effekt, annak is csak az alapja... neked nem lehet gond asmon- ban elinditani ... tenyleg csak annyi mint amit oda leirtam ... elindit asmon, megnyomkod amit odairtam, es kesz...
van egy tippem, kimentette az emulátorral a 100h-a program végéig, és készült elé egy fejléc :)
Es ugy siman visszaterni a basic- be, vagy ahonnan elinditottuk a programot, ugyanugy mint asmonba, nem lehet, IstvanV ?
Ugye egy ret hatasara az asmon csilingel egyet, es visszater siman, es folytathatod vele a munkat, ha figyeltel hogy milyen szegmensekre pakoltal a programodban, akkor az asmon sertetlen marad visszateres utan.
Ezt nem lehet megcsinalni barmivel, csak asmonnal ? ( mer akko nekem asmon a baratom )
aham... valami ilyesmi remlett... es ennek szerinted mi lehet az oka... hogy nem csinaltak ilyen "low level call -t" szamitva arra, hogy a hivott program majd baratsagosan hasznalja a dolgokat, es ret- tel vissza akar terni... az asmon- ban ugye van ilyen... a "g" parancs. namost lenne az exosnak egy ilyen funkcioja, hogy exos 666, ami raugrana call- lal a de- be rakott cimre ... es kesz. es akkor ez a funkcio, akar egy fejlecet is kaphatott volna ( 666 fejlec ), es akkor betoltene a progit es raugrana ugyanugy mintha 5- os lenne, de "varna vissza" a vezerlest... es a basic (ha abbol hivtad) onnan folytatodna ahonnal meghivta a programot ... vagy ha exdos- bol is hasznalnak, akkor az exdos folytatodna... asmonban is mukodne ez is, nem csak a "g"... stb ...
me nincs ilyen ? :)
mint a dos- os progik... azok is visszatertek... a hivashoz ...
tehat akkor azt lazan meg lehet csinalni, hogy vmi elindul ilyen rendszerbovitokent, es akkor lefut, tezsi a dolgat es esc- re meg kiterminalja magat mint rendszerbovitot, es ha mondjuk ez basic- bol lett hivva, es mindenre vigyaztunk, akkor sertetlen basic jon vissza, programmal, mindennel ?
hat az ugy megint nem tetszik... azert nyomott esc- t mert ki akar lepni... nem akarja rezidens progikent ... de hat van ep- re cp/m, meg ilyesmi... abba tuti nem igy van... az exos fejlesztoi nem ismertek azt a szitut, hogy betolt/futtat/kilep ???Van egy másik megoldás, Basicben is meg lehet írni egy gépi kódú betöltőt, ami betölt egy fejléc nélküli file-t a megadott címre, majd betöltés után meghívni, ha ott térsz vissza RET-tel, akkor simán visszatér a Basic progidhoz
hat hiaba, en ezeket ma sosem fogom megerteni...
Van egy másik megoldás, Basicben is meg lehet írni egy gépi kódú betöltõt, ami betölt egy fejléc nélküli file-t a megadott címre, majd betöltés után meghívni, ha ott térsz vissza RET-tel, akkor simán visszatér a Basic progidhozEzzel viszont az a gond, hogy akkor csak BASIC-bõl fog mûködni a program, ill. elõfordulhat, hogy bizonyos gép verziókkal fog mûködni. (Sok gyári programmal is ez okozta az angol/német gép problémát!)
az exos fejlesztoi nem ismertek azt a szitut, hogy betolt/futtat/kilep ???Akkoriban a számítástechnika aktuális fejlettségi szintje ez volt: betölt, futtat, kikapcsol.
Ez már egy remélhetõleg jobb változat:A JP 1000H helyére kell CALL, és akkor ESC-re rámegy a kilépésre.
Nekem ez nagyon tetszik, abba ne hagyd!!! ;-)Egyetértek, nagyon jó!!!
Akkoriban a számítástechnika aktuális fejlettségi szintje ez volt: betölt, futtat, kikapcsol.Kapott is szegény kikapcsológombom a C64-esen rendesen :D, csoda, hogy nem az adta meg magát, hanem a táp. :D
Még reset sincsen a Spectrumon, C64-en és még egy csomó más gépen se. C64-en legalább kikapcsoló volt :-)
Kár, hogy az EP-re készült programok 99% nem használta ki ezeket a lehetõségeket, és csak hideg indítással lehetett kilépni belõlük. Ezért is készült az EXOS 2.3 ami jobban ragaszkodik az életéhez, és ha lehet, akkor hidegindítás helyett a bejelentkezõ képhez ugrik.
Ezzel viszont az a gond, hogy akkor csak BASIC-bõl fog mûködni a program, ill. elõfordulhat, hogy bizonyos gép verziókkal fog mûködni. (Sok gyári programmal is ez okozta az angol/német gép problémát!)
Lehetséges még a 2-es fejlécû felhasználói áthelyezhetõ modul, de olyat ember nem írt még a pár gyári programon kívül :-) és ezzel szintén a BASIC-hez láncoljuk magunkat.
A JP 1000H helyére kell CALL, és akkor ESC-re rámegy a kilépésre.
Volt már szó itt a fórumon arról, hogy bizonyos gépeken az IM2 megszakítás címének vétele hibás eredményt ad, mert az alsó byte-ban valami "zaj" van. (Ilyen volt az én gépem is, nem is futottak az im2-t használó játékok.)Az én gépem is ilyen volt, a BAM és janó féle átratokból elég sok nem is futott emiatt a gépemen.
Ezért is csináltam teljes 256 bájtos im2 táblát mindig. A profik által csinált spectrum programok is teljes tabellát csináltak, nem véletlenül.Vagy vissza kell rakni IM1-re, es megsporoljuk a tablat :-)
Vagy vissza kell rakni IM1-re, es megsporoljuk a tablat :-):smt045
Ez megválaszolta a következõnek szánt kérdésemet: mitõl lassul be brutálisan az LDIR, ha az utasítás kódja a videó memóriába kerül. Naivan eddig azt hittem, csak egyszer olvassa be a Z80 :oops: és így akkor megúszhatóak a várakozások.És van még egy módszer, ami memória takarékosabb, és még gyorsabb is mint az LDI-s, a POP-PUSH, itt egy félképernyõ (TEXT 80) scrollozásra van próbálkozás:
De így akkor egyértelmûen az jön ki, hogy minden esetben gyorsabb a kiírt LDI LDI LDI... sorozat, mint az LDIR. Persze bizonyos mennyiség felett elég memória pazarló ez a módszer :-)
És van még egy módszer, ami memória takarékosabb, és még gyorsabb is mint az LDI-s, a POP-PUSH, itt egy félképernyõ (TEXT 80) scrollozásra van próbálkozás:
És van még egy módszer, ami memória takarékosabb, és még gyorsabb is mint az LDI-s, a POP-PUSH, itt egy félképernyõ (TEXT 80) scrollozásra van próbálkozás:
Képernyõ scrollozására gyorsabb megoldás lehetne az LPT-ben átírni a video címet, és akkor csak a belépõ pixeleket kell a memóriába írni az egész mozgatása helyett.Ez kétségtelen, de nem véletlenül írtam félképernyõt :-)
Önmagában a POP-PUSH kb 2x gyorsabb mint az LDIR, viszont gyakran kell variálni az SP-el, ami elviszi a megtakarítás nagy részét :-( Nem tudom, lehetne-e ezen még optimalizálni valamit?
Egy keveset sikerült gyorsítani az utasítások sorrendjének a megváltoztatásával (a video RAM hozzáférés miatt ennek van jelentõsége):Ilyen esetben mire érdemes figyelni?
Az LDIR idõzítése azonos az LDI-vel, ha a végrehajtásával a BC értéke 0-ra csökken. Egyébként még a fent leírt 16 ciklus után van további 5 ciklus, ami gyakorlatilag relatív ugrást végez vissza az LDIR utasításra, amelyet aztán a Z80 újra beolvas a memóriából.Kipróbáltam, hogy mit csinál, ha az LDIR felülírja a saját utasítás kódját, és tényleg kiszabadul a ciklusból, amikor az EDH bájtja felülíródik. Ebbõl szerintem érdekes visszafejtés elleni trükköt lehetett volna csinálni anno :-)
Ez a folyamatos újbóli utasításkód beolvasás le van írva valamelyik Z80 doksiban (és csak nekem nem tûnt fel :oops: )?
A Z80 (http://z80.info/zip/z80cpu_um.pdf) dokumentációban ez olvasható:Majdnem csak a frisités nem a bájt másolása után hanem az utasítás beolvasásakor történik meg
(Attachment Link)
Ezt talán lehet úgy is értelmezni, hogy az utasítás újraolvasása a memóriából nem történik meg, de amit írnak, az alapján az tûnik ésszerûnek:
- minden byte másolása után a PC két byte-al csökken, és ilyenkor megszakítás is történhet (ami után természetesen folytatódik az LDIR)
- két memóriafrissítési (M1) ciklus történik minden byte másolása után
- az LDIR idõzítése ha van még újabb byte (4, 4, 3, 5, 5) csak annyiban tér el az LDI-tõl, hogy van még a végén 5 ciklus a PC csökkentésére
Majdnem csak a frisités nem a bájt másolása után hanem az utasítás beolvasásakor történik meg
(3T opcode0 + 1T RFSH)=4, (3T opcode1 + 1T RFSH)=4, (3T adat,(HL) )=3, (3T (DE),adat + 2T BC ell)=5, (5T PC=PC-2, HL=HL+1, DE=DE+1)
A HL és DE növelése nem az utolsó 5 ciklusban (ami LDI-nél, vagy ha nincs újabb byte, nincsen) történik, de ennek kevés jelentõsége van. Az M1 ciklusoknál nincs 3 ciklus az utasításkód olvasására; éppen azért is van olyan mód, amikor csak M1-hez generálódik várakozás, mert ott 2.5 helyett már 2 ciklus után megtörténik az olvasás a normál memóriamûveletekkel ellentétben, és a második 2 ciklus a frissítés.Részben igaz
Részben igaz
5, (5T PC=PC-2??????)
A másik M1 és M1 közöt mit értesz mert van *M1 CPU láb amihez igazitják a WAIT(várakozást) meg van blokdiagram M1 ciklus ami 4T alap esetben.
Olyan assembler/editor programokat keresek, amelyek nem ROM-ból futnak, hanem betölthetõ.És ez miért is jó? Ha emulátorhoz kell, ott gyorsan be tudod rakni a konfigurációba a szükséges ROM-okat. Igazi gép ROM bõvítése se megoldhatatlan :-)
Értem amit írsz, de eprom égetõm az bizony nincsHozol EPROM-ot és beégetem!
Hozol EPROM-ot és beégetem!
szerintem ide nem ennyi kell, de ennyit ír ki, gondolom Õ tudja jobban...Rosszul gondolod :-) írj be FFFF-t, és akkor jó lesz, a tényleges végét kiírja a töltés végén, az majd kelleni fog a mentésnél.
Rosszul gondolod :-) írj be FFFF-t, és akkor jó lesz, a tényleges végét kiírja a töltés végén, az majd kelleni fog a mentésnél.
FENAS.EXTEzt már programként töltötted be?
Ezt már programként töltötted be?
I/O módban közvetlen az ext fájl igenOtt a probléma, hogy a FENAS nem foglal szabályosan memóriát. Csak úgy puff bele módon rakja be az FA,FB,FC szegmenseket a memóriába. Ha 128-as gépen betölthetõ verziót használsz, akkor az a F9,FA-ra töltõdik be, vagyis amikor elkezdesz 4000-tõl tölteni felülírod a FENAS felét.
valakinek megvan ez nem ext verzióban hanem com?Az 1.0-ás verzió volt még COM-os.
mivel a programokat telefonról játszom le a gépemnek, felvenni nem tudok vele. jött a ramdisk ötlete. amit meg is találtam az ep128.hu programcsokorban.
Ha jól sejtem, te Alexander Gusev Ramdisk 0.1 programjára gondolsz.
Ennek semmi köze sincs az EXDOS-hoz. A RAMDISK méretét úgy állítja be, hogy mindig 64K szabad memóriát hagy (akkor is, ha memóriabővítést is emulálunk. Az EXDOS ramdisk funkciója lemez nélkül is szintén használható.
Kérdésem, ki mit használ eredeti gépen
IstvanV írt valami PC-s assemblerrõl. Néztem a z80.info-t, fogalmam nincs melyik lenne jó...
Linux alatt meg fõleg nem tudom, létezik-e ilyen ami jó ebben a helyzetben.
Ebben a ep128emu2-ben lesz a jövõben vajon assembler?
De tényleg nem látom hogy lehetne bin-t etetni vele.És miért akarsz bin-t etetni vele? A Konvertálás/Adatfájl betöltése nem jó?
Nekem az a menüpont nem reagál semmire, sem emuban, sem EP-on...Van megnyitott (vagy létrehozott) forrásfájlod a memóriában?
Én is probáltam a HEASS-t de nekemse sikerült .asm .txt fájlt csak a speciális .H?? engedte volnaBetöltésnél csak HEA. Minden egyebet Konvertálásnál, de ahhoz kell az, hogy legyen megnyitva a szerkesztõben egy HEASS dokumentum.
Betöltésnél csak HEA. Minden egyebet Konvertálásnál, de ahhoz kell az, hogy legyen megnyitva a szerkesztõben egy HEASS dokumentum.
Alakul...Helyes :-)
De a Heass ha jól tudom, csak asm forráskódot tud betölteni (nincs "Read BIN File"), lefordított programot (*.com; *.ext) azt nem.
Nem a státusz sor palettaszínei miatt? (az a színpár, ami a kijelzõre van definiálva fekete)
- miért nem mûködik az áthelyezett status sorban a kijelzõ?Azért mert a magnókezelõ közvetlenül az EXOS LPT elsõ sorába, azaz az eredeti status sor paletta színet piszkálva éri el a villogást. A saját LPT-nkben mutathat tetszõleges helyen a status sor videó memóriájára, a felíratok (SEARCHING, LOADING, stb) mûködni is fog, a töltésjelzõ téglalap is megjelenik, azonban nem fog villogni, mivel a magnó kezelõ nem a mi LPT-nkben, hanem az eredeti helyén váltogatja a színeket.
- hogyan lehet megoldani, hogy mûködjön?Úgy, hogy az LPT táblánkat az EXOS LPT helyére tesszük, az eredeti status sort leíró blokkot megtartva, és beépítve a miénkbe.
- melyik programban mûködik?Z&A Demo
Z&A Demo
Az ep128.hun igen szûkszavú a leírása, más apróbb trükkök se lettek észrevéve :-(
De ha leírod, mit kellene észrevenni egy laikusnak, szívesen kirakom! :oops:
Nem lehet, hanem biztos! :-)Az miért rontja el a programot, ha a maradék karaktereket egyszerûen kitörlöm onnan, és így pár bájttal rövidebb lesz a file?
A maradék karakterekkel ne foglalkozz, a hoszbájt (05) adja meg az EXOS-nak, hogy mennyit nézzen.
Nem tudom, ebbe a topikba illik-e leginkább:Az miért rontja el a programot, ha a maradék karaktereket egyszerûen kitörlöm onnan, és így pár bájttal rövidebb lesz a file?Azért mert a gépi kódú programban minden címkezelés (ugrás, eljáráshívás, "változók") közvetlenül direktben hivatkozik címekre.
Ha a forráskódban kicserélem a fix 1009h és 100Dh címre való hivatkozásokat VEGE+20Fh-ra illetve VEGE+213h-ra, akkor már jónak tûnik.Köszi! :smt038
Azért mert a gépi kódú programban minden címkezelés (ugrás, eljáráshívás, "változók") közvetlenül direktben hivatkozik címekre.
Hogy Basicesen mondjam: nincs Renumber :-)
Akkor csoda, hogy egyáltalán mûködött úgy is a program és csak hang nem volt, nem? :DIgen :ds_icon_cheesygrin:
VEGE+20Fh-ra illetve VEGE+213h-ra, akkor már jónak tûnik.Ahhoz, hogy azt megtudjuk, ezek mire is vonatkoznak, ismerni kéne az .SNG fájlok felépítését...
songdump/ Dump a music studio song, playing the notes as they occur.Belenézve (http://cd.textfiles.com/geminiatari/FILES/MUSIC/SONGDUMP/) ott egy leírás, amivel meg van fõnyeremény! :ds_icon_cheesygrin:
Song file structure
512 byte header structure:
10 byte header CD,'Mstudio',CD,02
15*10 byte atari instrument names (null terminated)
15*8 byte atari instrument settings
15*10 byte casio instrument names (null terminated)
15 bytes casio settings
15 bytes casio settings
5 pointers (file displacement) to lyric lines
32 byte null terminated title string
after the 512 byte header (hexadecimal unless noted):
track 1-4 bitmap (4 * 1 word)
instrument active, [15:14:13...2:1:track enable]
00:80:01:key
1= C G D A E B F# C# F Bb Eb Ab Db Gb Cb =15
83:time
1= 2/2 3/2 2/4 3/4 4/4 5/4 6/8 =7
81:tempo
quarternote = tempo, 57..200
84:01:volume
0F pianissimo .. fortissimo 7F
music, 00 delimits beginning of column data, 0xff marks end of music info
82
bar
85:number
repeat number of times
86
end repeat
note format
0 : tie start : tie end : rest(not note) : [instrument:4]
[0=inkey 1=nat 2=sharp 3=flat :2] : accent : [duration:5]
pitch in C major midi coding (18(24d)=C2)
duration: 12d = quarter note, (+2 for dotted(*3/2) , -2 for triplet (*2/3) )
9d = 1/8th , 6d = 1/16th 15d = half, 18d = whole, etc.
pitch is always the natural note, later adjusted for key, or explicit sharp,
natural, or flat.
d means decimal. all other numbers in hex.
Van-e valami megoldás, hogy az EXOS-t megkérdezzük, mi az alapértelmezett eszköz, és ha az nem TAPE:, akkor írjon?Lenne rá szép megoldás: 3-as EXOS változó értéke 1.
Van-e valami megoldás, hogy az EXOS-t megkérdezzük, mi az alapértelmezett eszköz, és ha az nem TAPE:, akkor írjon?
Viszont ezzel felfedeztem egy hibát a FILEIO.ROM-ban: nem fájl-orientált eszköznek mutatja magát. (Azaz marad a 3-as változó értéke 0 mint a TAPE esetén.)
Felfedeztem egy nagyobb problémát is a FILEIO-val :oops:
HEASS MERGE-jé nem fut le, *** Call not supported by this device hibával.
Pontosan milyen EXOS hívást hiányol ? A FILE: gyakorlatilag azokat a funkciókat tudja, amiket a TAPE:, csak gyorsabb :)EXOS 10-t használ a fájlméret beolvasásához:
Talán az aktuális file pozíció olvasása és állítása kellene, amit nem valósítottam meg, mert a leírás alapján nem voltam egészen biztos abban, hogy ennek pontosan hogyan kellene mûködnie (paraméterek, hibák, stb.) :oops:Próbálgattam a funkciót, hogy az EXDOS hogyan kezeli:
Az EXDOS-ban van ez a osztórutin. De hogy mûködik?
Mi értelme az ilyen programszerkezetnek? A példában kitalált címekkel, az elv a lényeg.
Helymegtakarítás ? A JR utasítás rövidebb, mint a JP, és ha sok egymáshoz közeli helyrõl kell ugyanarra a távoli címre ugrani (pl. hiba esetén), akkor elég csak egy JP, a többi ugrás pedig lehet JR a JP-re.Gyors megfejtés volt! :smt038
Ezek a trükkök a disassemblerek rémálmai :ds_icon_cheesygrin:
Tudtok spektrum vagy ep játék forrásokat? Nem visszafejtett kódra gondolok hanem eredetire. Kiváncsi lennék milyen stílusban programoztak a hivatalos gyártók, akár egy codemasters.Ilyenre én is kíváncsi lennék, de nem túl valószínû hogy lehet ilyet találni. Codemasters-tõl biztosan nem, az még 20+ éves játékaik közreadását is letiltotta a WOS-ról.
Persze lehet hogy valami rendes koder le tudna vezezni, hogy ezek a sebesseg es meret megtakaritasok mit tudnak jelenteni egy olyan komplex assembly rendszernel mint az exos ( pld. )Akkoriban még nem úgy ment a programozás, hogy semmi nem számít majd max rak még 2 giga ramot a felhasználó gépbe, meg 4 magos procit, és plusz 1 tera vinyót :lol:
Én elég gyakran használom :oops:Láttam is :), néztem jó nagyokat amikor először találkoztam vele ;)
néztem jó nagyokat amikor elõször találkoztam vele ;)Ezzel szerintem mindenki így van, amikor elõször látja, aztán csap a homlokára, hogy "ez nekem miért nem jutott eszembe" :-)
en meg a xor a -t is utaltam
Fu sosem szerettem oket ... en meg a xor a -t is utaltam.
Különösen igaz ez ROM programokra, ahol IC kapacitása külön extra korlátot szab a programozó fantáziájának. És vagy kevesebbet fog tudni a program, mint amit szeretne, vagy ügyesebb lesz, és addig faragja amíg befér.És jön az örökös dilemma: gyors kód legyen, vagy rövid? :) A kettő nem mindig megy egyszerre, a gyorsabb sokszor hosszabb kódot eredményez (kicsit ellentmondásos a dolog, de igaz).
És jön az örökös dilemma: gyors kód legyen, vagy rövid? :) A kettõ nem mindig megy egyszerre, a gyorsabb sokszor hosszabb kódot eredményez (kicsit ellentmondásos a dolog, de igaz).Ez így van! De mondjuk a XOR A az gyors és rövid is :-)
a DAVE programozása ?
valami ilyesmire gondoltam
mennyi lehet a legrövidebb hang hossz egység (xx milisec)?
Így a zenei hang idõzítése 1 ms egységekben mérhetõ az a +-0.5 ms csak nem zavaró annyira.
De kettõ megszakítást alkalmazható a programban egyszerre ? PL: 50Hz és 1kHz vagy 50Hz és 0.hangcsatorna
Erre valók IS-DOS-ban a tranziens programok, komoly munkára ezek lettek szánva.
Megoldható még a 2-es fejlécû áthelyezhetõ programmal is, a betöltõ programon múlik.
exos leirasbol angol verzio nincs keznel ? mert egyet nagy nehezen talaltam itt:Ne az oldal ezeréves címén nézd, hanem az aktuálison:
http://enterprise.8bit.hu/document/books/exos_2.1_technikal_information/index.html
de ebbol hianyzik a nick/dave leiras, meg ilyesmik ...
Ne az oldal ezeréves címén nézd, hanem az aktuálison:
A kurzor F1 -re alakitasa a konfigokban huzalozott ? tehat melyik bovito csinalja, es lehet-e opcionalis, vagy ha az a bovito benn van, akkor cursor = F1 ?EPDOS HFONT-ja csinálja.
Jol gondolom azt a 2 pontos feltetelt, Zozo ?Jól.
Olyat lehetne még csinálni, hogy az 5-ös fejléc nem használt bájtjait felhasználni, pl. mondjuk eltárolni egy indítási címet, ami ha 0, akkor tudhatja a RUN, hogy ez egy hagyományos 5-ös program, nem lesz kilépés, felesleges erõlködni. Ha pedig nem 0, akkor ezt a pontot hívja meg, nem a 100h-t, így a programokban egyszerûbben lenne megoldani a "hogyan lettem indítva" kérdést, 100h-n indulva hagyományos mûködés, és a végén kilépés az EXOS logóhoz ugrás módon, az új címen indítva pedig kell lapozás, SP mentés, végén pedig kilépés ezek visszaállításával, majd visszatéréssel.
EXOS logóhoz
Kerdes hogy az exos nem sipol- e be, ha nem nullakat teszunk a fejlecbe oda ...Kipróbáltam, nem.
Kicsit macerásan, de lehet az ASMON-nal relokálhatót, írtam errõl anno az Enterpressben. Meg talán még a GEN tud ilyet, de azt sose használtam :oops:A GEN az baromi jó!
Mondjuk ha elkészül, és jól mûködik, akkor ROM formában lesz a leghasználhatóbb, ha nem túl nagy, akkor esetleg hozzácsapva valamihez.
A GEN az baromi jó!
Én sokat használtam, rekolálhatót is csináltam vele.
Csupán szokás kérdése.
Z80 System!
Amit te akarsz csinálni, az már kicsit a multitaszkos operációs rendszer felé hajlik. Multitaszkos operációs rendszer esetén van az, hogy az aktuális rendszert megszakítja egy idôzítô, eltárolja a következô utasítás címét, a verem tartalmát és a regisztereket. Ezután kialakítja az új környezetet a korábbi (vagy újonnan induló) másik programnak, betölti a verem/regiszter/utasítást, majd megy a másik program.
Ehhez az x86-os rendszereknél a processzornak vannak speciális utasításai, amely gyorsítja a folyamatot.
Írja a NAP betöltésnél, hogy amikor a méret alapján foglal RAM-ot, felhasználja az elõzõleg esetleg foglalt User szegmenseket, így innentõl nem lehetséges vissza térni az elõzõ programhoz.
Azt tudja valaki, hogy vannak- e kialakult szokasok arra nezve, hogy egy rendszerbovitot konnyen lehessen rambol futonak es rombol futonak is forditani ?Mi ebben a nehéz?
Írja a NAP betöltésnél, hogy amikor a méret alapján foglal RAM-ot, felhasználja az elõzõleg esetleg foglalt User szegmenseket, így innentõl nem lehetséges vissza térni az elõzõ programhoz.
Mi ebben a nehéz?
Ha emulatorbol inditok heass- t akkor angol a menum, ha a bovitett gepemrol, akkor magyar. a setupjaban nem latok nyelvi opciot, ez valami ket kulon heass verzio lehet ?Igen, külön ROM fájlok.
Es ez mar eleg off, de van valami tool, ami kiirja az ep szinek kodjait ? Tehat hogy 0-255 szin kozul melyik meylik ? grafikusan ertem, hogy mittomen rajzol egy kockat es beleirja h az a 38- as szin.Van SZCLXCHR.ROM-ban benne van a színkódkeresõ.
Van SZCLXCHR.ROM-ban benne van a színkódkeresõ.
Es ilyen rom hol van ? :) Emuban nincs, kersesre nem talal ...ep28.hu Util programcsokor :-)
Viszont miért rendszerbővítőben gondolkozol?
Valaki dobjon mar meg egy peldaval, hogy kell az "alapertelmezett csatornara kiirni egy sor szoveget" ...
en a 29- es exos valtozobol visszakert csatornaszamra probalkoztamAz a EDITOR videó lapja, ha van olyan megnyitva. Az alapértelmezett csatorna száma a 4-es változóban van. De erre van kitalálva a 255-ös csatorna, hogy ne kelljen ezzel neked foglalkozni :-)
es mi az az EDITOR ? a WP ?Editor (http://gafz.enterpriseforever.com/Dokumentacio/Konyvek/EXOS_2.1_technikal_information/exos/editor/)
Az ilyen integer kodokat milyen formaban tartjuk nyilvan, mint pld. a user exos valtozok azonositoja, vagy a file modul azonositok ?
Tehat ha en holnap fel akarok venni egy exos valtozot vagy modul azonositot, nyilvan abban a range- ben amit az exos megenged, akkor vajon honnan tudhatom, hogy olyan azonosito mar nem foglalt masra ?
Az EP gépi kódú programokban láttatok-e már olyat, hogy a dinamikus változók tárolására a vermet használja, méghozzá oly módon, hogy az IX vagy IY regiszterek a báziscímek, és ahhoz képest helyezkednek el változók?
...stb...
LD SP,IX ; A hívás előtti stack visszaállítása
POP IX ; A hívás előtti referenciapont visszaállítása
Akkor beigazolódott a gyanum, miszerint ez annyira sok órajelet emészt fel, hogy EP-nél túlságosan lassan működne. Most éppen a C nyelv és Assembly utasítás közötti kapcsolatot vizsgálom, és végre meg tudom válaszolni a korábban már nem egyszer feltett kérdést, hogy a gépi kódban hogyan tároljuk a dinamikusan (futás közben) létrehozott változókat. Hát így.
es van benne EP supportNa ez meglepett! Vajon ki volt olyan elszánt, hogy ezt megcsinálta?
Na ez meglepett! Vajon ki volt olyan elszánt, hogy ezt megcsinálta?
Miért is kellene a C nyelv "nehézkes" zsákos adatátadási módszerét használni??
Szerintem a legszebb és leghatékonyabb, melyet a magasabb programnyelvek nem nagyon képesek használni, hogy írható/olvasható memóriában futtatjuk a programkódot és magával a programmal építjük fel a később végrehajtandó program kódját, amire programunk rálép. Ez ROM-ban nem megvalósítható.
imadom az onmodosito kodot, magas a "cool" faktor :)Én is! :-)
Én is! :-)Egyetértek. :)
Az ilyesmi az tényleg valóban igen számítás igényes, kell egy osztó rutin, és sorban osztogatni, pl 16 bitesnél elsőként 10000-el, a kapott értéket kiírni, aztán az érték x 10000-t levonni az eredetiből, ismételni 1000-el, stb.Szorzás valójában nem kell, mert az osztó rutin a maradékot is kiszámítja. Ráadásul használható egyszerű ciklusban kivonás az osztás megvalósítására, mert az eredmény nem lehet nagyobb, mint 9.
32 bitesnél ugyan ez, csak sokkal több értékkel.
ld a, 1ch
.l1: add hl, hl
rla
jr nc, .l1
ld c, 82h
out (c), h
out (83h), a
A két LPT-ben azonosnak kell lennie a VSYNC és RELOAD közötti távolságnak.Köszönöm szépen :) Ez mindent megmagyaráz :D az utolsó sor a vsyncben, ahol a RELOAD bit van, eltér, pont Státuss sorbeli különbség miatt :D, de akkor kiiktatom a státusz sort mikor a program elindul, és visszaállítom RELOAD-os sor értékét. Köszi szépen mégeccer :)
Koszi az infokat! Most eppen felre teve a nullas lap kerdeset, a kovetkezo a problemam: ha lehet elsore nem akarom megvaltani a vilagot, sajat LPT stb. Megoldhato-e ertelmesen, hogy EXOS-tol szepen kerek adott kello videomodot nekem (exos valtozok beallitasa, majd megnyitom a display channelt, aztan johet a 11-es spec 1-es funkcio, hogy mutassa is meg, ezzel nincs is gondom: mukodik), _AMDE_ azzal a csavarral h pl pixel modban en szeretnem megmondani hogy honnan jojjenek az adatok, magyaran a megfelelo LPB LD1 erteket szeretnem modositani (az nekem tok oke, hogy az LPT-t - a fenti LD1-en kivul - az EXOS-ra bizom). Ezt "kitalalos" alapon kicsit nehez, meg bezavarhat hogy most EXOS milyen verzio stb. Van otletetek, hogy lehetne szepen megcsinalni ezt? Kicsit nagy az overhead, hogy most csak 2 byte miatt (LD1) csinaljak sajat LPT-t, stb stb. Vagy ezt nem fogom tudni kikerulni? Mert a gondom az, hogy ahol maguk a pixel adatok vannak annak a helye kotott, amde ott LPT pl nem is ferne el (ezert is akartam elozo postomban valamire "ralsozni" az LPT-t egy masik szegmensbe).Módosítsd az LD1 értékeit, 0bff4h megadja az LPT címét, és ez egy fix EXOS változó, minden EXOS-ban ugyanott van.
Es az van, hogy az elmult evtizedekben baromira hozzaszoktam a magasabb szintu progrmnyelvekhez (C, C++, C#, java es az osszes tobbi),En pont forditva vagyok :) Az, hogy sokat kell munkam soran is foglalkoznom magasabb szintu nyelvekkel, csak megerosit abban, hogy hobbynak assembly az igazi, es akkor erzem igazan az elegedettseget, ha abban sikerult vmit megoldani :)
kiprobaltam az SDCC- t, ossze is hoztam hogy adjon nekem egy EP- n futathato binarist a vege, C- ben lehet fejleszteni, ami tokeletesen eleg, es a legalapvetobb assembly szenvedestol megszabadit, viszont a forditott kod az SDCC- vel szerintem marha nagy lesz, mikor float- okat szamolok, akkor pedig iszonyatosan nagy ...
szoval nem tetszett (megha a csillagos effekt framework kodjait abban is irtam).
Van egyebkent ep- re C fordito... ?IS-DOS-ra van HiSoft C, de szerintem azzal sokra nem jutunk :-(
IS-DOS-ra van HiSoft C, de szerintem azzal sokra nem jutunk :-(
SDCC -ben van inline assembly, igy meg tudod csinalni azt hogy C fuggvenyekbe irkalod az assembly kodot, akarhany file- ba, es a vegen osszelinkeli egy binarissa.
(Mellesleg ha nem sajnalod ra a memoriat/futasi idot, akkor C- ben is kodolhatsz vele)
es nyilt forrasu is.
Ez egyébként mért jó? Én annak örülök tökre, hogy nem kell linkerrel szenvedni, meg, hogy mindent bele lehet tenni egy fájlba, már include se kell :-)
Ez egyébként mért jó? Én annak örülök tökre, hogy nem kell linkerrel szenvedni, meg, hogy mindent bele lehet tenni egy fájlba, már include se kell :-)Fura, hogy ezt kerded, annyira trivialis, hogy nem ertem nalad hogyhogy maskepp van ...
Fura, hogy ezt kerded, annyira trivialis, hogy nem ertem nalad hogyhogy maskepp van ...
Ha nem tévedek nagyot, az is emulált karakteres állapot, valójában grafikus lpt-t használ. Legalábbis valami hasonló emlékeim vannak felőle.
Sztm atloghatnak szegmens hatarokon a videolap teruletek, es szerintem folyamatos a memoriakiosztas. Ha nem az lenne, akkor lenne olyan exos funkcio, amelyikkel soronkent lehet megkapni a cimet, vagy ilyesmi. Lekerdezesre meg tok jo az a funkcio amit mondtal, az a mindenkori csatarnanak megmondja a memoria kezdetet, onnantol az egyeb csatorna parameterek (video mod, szelesseg, mittudomenmivanmeg) alapjan lehet szamolni a video lapon (csatornan) valo cimeket.
Igen, 9 pixelenkent van az lpt blokkokra osztva, en anno utaltam, hogy nem 8 pixeles egy sor, milyen hulyeseg mar hogy egy karakter nem 8X8- as hanem 8X9- es, de sokan meg imadtak, de hat ugyis sajat lpt- t hasznaltam mindig, amint megertettem hogy az exos hivasokkal operalas meg nem a teljes sebessegu hasznalata a hardvernek az en celjaimra.
Amit pedig irsz a scrollozodasrol, az meg azt jelenti sztm hogy hardverbol scrolloz, tehat mikor scrollozni kell egy lapot, akkor az lpt (9 pixelenkenti, ami 1 karakter karakteres modban) blokkjaiban a memoria cimeket atirva scrolloz, nem a tenyleges lapmemoriaban masol.
Miért nem írod felül az LD1-es értékeit az EXOS LPT-nek? Kérsz egy videólapot, vagy egy user boundaryt az FF szegmensen, és annak megfelelően állítod be a magad kis videólapcímeit, akkor biztos folytonos lesz a címzés.
Ahogy nezem, amugy grafikus modban is 9 pixelenkent egy LPB alapu LPT-t allit elo az EXOS, karakteres modban meg nyilvan.Igen, mert a karakter méretnyi terület az alapegység az EXOS videólap kezelésénél.
nem teljesen vagyok kepben, hogy szokas "szepen" csinalni ezt.Leginkább saját videómemóriával és LPT-vel :-)
Ha az adott lap meg atlog 3 szegmensen, akkor atlog, a te feladatod hogy belapozd oket, es olyan z80 cimeket szamolj hozzajuk, ahova belapoztad.Így van. Annyit még hozzá tennék a dologhoz, hogy bizonyos EXOS műveleteknél el is mozdulhat az adott terület a videó memóriában! Az EXOS igyekszik a szabad területet összefüggően tárolni, így ha pl van két videólap, és a korábbit bezárod, akkor a másodikat felmozgatja, hogy egyben legyen a szabad terület. Ez BASIC-ben néha látható is, hogy egy picit villan a kép.
Leginkább saját videómemóriával és LPT-vel :-)
Pontosan! De ezert mondtam, hogy nem lehet arra szamitani - altalanos esetben - hogy a memoriaban direktbe elerve a "video RAM"-ot az folyamatos, mint mas gepnel. Mondjuk ez kevesbe zavar engem, mivel csak en irnek ra, igy az EXOS-nak nincs alkalma, hogy atrendezze pl scroll hatasara, alapbol a videolap letrehozasa utan meg amugy linearis szokott lenni (remelem legalabbis)Nem ertem a problemadat ezzel...
Kozben rajottem viszont hogy "hulye vagyok" a Z80 bit eltolas/forgatas opcode-okhoz mindig total keverem hogy melyik mit csinalHa jól tippelem ez kell neked:
LD HL,videocim
LD A,0FFH
PUSH HL
RL H
RLA
RL H
RLA
POP HL
OUT (0B2H),A
SET 7,H
RES 6,H
A videócím legfelső két bitjét átforgatjuk az A alsó két bitjére (Carry használatával), A többi bitje 1, így végül megkapjuk a videószegmens számát.Namost egy lapon belul ez a terulet folyamatos, es az is marad. Tehat mondjuk letrehozol egy video lapot, ami mondjuk karakteres es teljes szelessegu, es 3 kepernyo magas. Akkor te egy exos hivassal megmondhatod, hogy ennek a lapnak melyik soratol kezdve legyen a kepre rakva hany sor a lapbol.
Bár nem sok jelentősége van, ezt egyszerűbben is meg lehet oldani: :)Code: [Select]LD A,0FFH
PUSH HL
RL H
RLA
RL H
RLA
POP HL
LD A, H
RLCA
RLCA
OR 0FCH
Bár nem sok jelentősége van, ezt egyszerűbben is meg lehet oldani: :)Igaz :oops:
Szerintem nem marad folyamatos, ahogy ideztem is, leiras is irja, hogy valtozhat a sorrend pl scroll hatasara.Szerintem a scroll hatasara csak az lpt soraiban valtoznak a memoriacimek. Errol ir a doksi. Attol meg az adott video lap memoriaja (a mindenkori kezdocimehez kepest) folyamatos es teljes a lap teljes mereteben, szent es sertehetetlen.
Szerintem a scroll hatasara csak az lpt soraiban valtoznak a memoriacimek. Errol ir a doksi. Attol meg az adott video lap memoriaja (a mindenkori kezdocimehez kepest) folyamatos es teljes a lap teljes mereteben, szent es sertehetetlen.Így van. Elmozdulni elmozdulhat, de akkor is folyamatos marad.
Így van. Elmozdulni elmozdulhat, de akkor is folyamatos marad.
Bár nem sok jelentősége van, ezt egyszerűbben is meg lehet oldani: :)Code: [Select]LD A, H
RLCA
RLCA
OR 0FCH
Aha, koszi! Meg Zozonak is. Valami hasonloan egyszeru elegans peldat tudnal adni ennek forditottjara? Amikor tudom a szegmens szamot, azon belul az "offsetet" es abbol kell nekem nick cimet szamolni. Ezt is megoldottam, csak epp tartok tole, hogy joval bonyolultabb mint az idealis megoldas, orajelciklusokat es utasitasok szamat nezve :)and 03h
És akor a z80 -ban a megszakítások engedélyezettségének állapota a flag ragiszterben van tárolva ?Nem arra van külön belső flag (IFF1 és IFF2), csak ebben a speciális esetben másolódik az F-be, pont azért, hogy le lehessen kérdezni.
0BFED/Eh - USER_ISR Address of user's interrupt serviceJaj igaz :oops:
routine, must be in page 0 and can
be 0000h for no routine.
Ha az exos ránéz a 3ch -n lévő JP utasítás operanduszára, hogy az nulla- e, és csak akkor ugrik, ha nem nulla, akkor minek oda a 3ch -n lévő JP utasítás kód ?Mert így egy fix címet lehet hívni, azaz a 3Ch-t.
De a te rutinodból a megszakított programba tér már vissza a vezérlés.Ááááááá, mindíg van valami amit zsigerből másképp gondolnék ...
Miért ? Miért nem hív meg engem, aztán ha visszatértem, korrekt módon visszaadja a főprogramnak a kontrollt ?Ez korlátozná a lehetőségeket, nem lehetne a főprogram regisztereit piszkálni.
Hááát... imígyen elülső hallásra elég nagy kattyvassz ez néköm ...Játék/demóban úgyis teszel egy JP-t 38h-ra, és kész :-D
Ezzel az OUT 191,12 -vel mekkora sebességnövekedést lehet elérni assembly cucc esetén ?Függ az utasítások hosszától, rövideknél többet, átlag lehet egy 10-15%
Namost a megszakítás azt csinálná, hogy az adott (eppen megszakított) "szál" nyilvántartott memória struktúrájába lementené a regisztertartalmakat, mindent, árnyékot, stack -et, IP -t, és venne egy másik szál struktúrát amiből meg feltöltené a regisztereket, szintén mindet. Természetesen az SP/IP visszatoltéshez valami olyan trükköt alkalmazva, hogy a RETI kiadása előtt valami területre (pld. nulláslap első 100H -ján keresni valami használható helyet) lementene egy kis programocskát, ami feltölti SP -t és ráugrik az új IP -re. Aztán módosítaná a stack -en a megszakítás visszatérési címét ennek a kis programocskának a címére, és a RETI akkor oda "térne vissza", nem oda ahol megszakította az előző szálat, a kis programocskánk meg ugye beleugrana az új (nyilván korábban már megszakított) szálunkba.
Így akkor tehát párhuzamosan futnának a "szálak" olyan időosztással amit a megszakítással megadunk.
A kérdésem az lenne, hogy vajon milyen frekvenciával lennénk képesek ezt a szál váltogatást csinálni, hogy azért pár órajelciklus még a futó szálnak is maradjon, mielőtt jön az új szálváltó megszakítás ? Tehát egy olyan kód, ami összes regisztert lepakolja memóriába, aztan az összeset visszatolti egy másik memóriáról, és kiad még 1-2 utasítást, megfejelve mindezt a megszakítások esetleges késleltetéséhez (ha van a megszakításkezelésnek valami büntetése), vajon milyen frekivel lehetne ezt pörgetni ? Teszem azt 1KHz -es megszakításnál, mikor ugye egy szál az egy ezredmásodpercig futna, akkor az egy ezredmásodpercnek kb. hány % -a mehetne el fentebb cizellált szál váltó kód futtatására és mennyi maradna a tényleges szál futtatásra ?
Most nézem, hogy a megszakításkezelő függvényben (C függvény) nem állítottam naked -re a függvényt, vagyis a C generált oda normal RET utasítást a végére, mégis működik a kód ... Miért nem baj az, hogy a megszakítás végén sima RET van, nem pedig RETI ?EP-n nincs jelentősége, és a RET gyorsabb is. A RETI-nek csak akkor van jelentősége, ha a hardver felsmeri ezt az utasítást, és a megszakításkérés törlésére használja, de EP-n szoftveresen kell törölni a megszakítást a B4h porton.
di
push af
ld a,#0x30
out (0xb4),a
ld a,#1
ld (_g_WasIRQ),a
pop af
ei
még néhany utasítás, aztan
ret
Namost a megszak végén ugye megvolt már a b4 port írás, és ei is,Namost a megszak végén ugye megvolt már a b4 port írás, és ei is,Ez nem probléma, feltéve, hogy a megszakítások egymásba ágyazása nem végtelen. A Z80 nem kezeli speciális módon a RET utasítást a rutin végén, a megszakításkezelés ugyanolyan, mint egy egyszerű DI + RST 38H utasítás. Arra is lehetőség van, hogy a B4h port törlése és az EI utasÍtás azonnal a rutin elején történjen, így például egy lassú 50 Hz-es megszakítási rutint megszakíthat egy gyorsabb 1 kHz-es.
és van pár utasítás még a ret előtt.
Előfordulhat hogy a pár utasítás közben jön újra megszakítás igény, és rászakít a megszakításra ?
így például egy lassú 50 Hz-es megszakítási rutint megszakíthat egy gyorsabb 1 kHz-es.Hmmm ... na erre még sosem gondoltam ... a megszakításkezelés innentől kezdve tényleg nem más mint egy szubrutinhívás, ami abban különbözik csak a call -tól, hogy nem általunk meghatározott helyen történik a kódunkban, hanem bárhol, ahol a megszak történik.
a megszakításkezelés ugyanolyan, mint egy egyszerű DI + RST 38H utasításAkkor tök feleslegesen indul minden megszakítás kezelő kód ( amit csak láttam ) azzal hogy DI, mert mire megkapja a vezérlést a CPU által már rég le vannak tiltva ? :)
de igazából MEG NEM SZÜNTETJÜK a lehetőségét, elvileg lehetséges hogy az EI után de még a RET előtt megszakból megszakít újra.A Z80 érdekes tulajdonsága, hogy közvetlenül EI után nem fogad el megszakítást (még akkor sem, ha az EI előtt már engedélyezett volt, tehát például sok egymást követő EI futása közben átmenetileg tiltottak a megszakítások), tehát csak a RET után ugrik újra a megszakításkezelő rutinra.
Ebből viszont az is következik, hogy még csak nem is kötelező az előbb említett szál kezelő megszakításból előszor RET -et kiadva valami nulláslap szerű helyre rakott kódra ugrani, a stack megfelelő kezelése mellett akkor a megszakításkezelőből egyből ugorhatunk a kiválasztott új szálra ?Igen.
Akkor tök feleslegesen indul minden megszakítás kezelő kód ( amit csak láttam ) azzal hogy DI, mert mire megkapja a vezérlést a CPU által már rég le vannak tiltva ?A DI nem kell, igaz, nem is árt, csak elfogyaszt néhány ciklust.
A Z80 érdekes tulajdonsága, hogy közvetlenül EI után nem fogad el megszakítást (még akkor sem, ha az EI előtt már engedélyezett volt, tehát például sok egymást követő EI futása közben átmenetileg tiltottak a megszakítások), tehát csak a RET után ugrik újra a megszakításkezelő rutinra.Hát erre már csak azt tudom mondani, hogy: beszarás. :)
Egyébként letiltott megszakítások alatt (akkor előbbiek szerint az tökmindeggy, hogy főprogram vagy megszak "alatt" vannak letiltva) bekövetkező megszakok az engedélyezés után ( következő utasítás után ... :) ) egyből kiváltódnak z80 által, vagy pedig azokat a megszakokat már elbuktuk, és csak akkor váltódnak ki, ha a megszak pillanatában a z80 epp EI után van ? Ráadásul ha elbukós, akkor akár zsinórban többet is elbukhatunk ? Vagy nem elbukós, és kiváltódik, de csak 1X, pedig lehet hogy 10X volt már olyan megszak igény ?A megszakításkérést (külön az 1 Hz-es, hang, és video megszakítást) a DAVE tárolja a B4h porton, és a törléséig aktív marad. Tehát ha DI és EI között kér megszakítást egy eszköz, az nem veszik el, feltéve, hogy nem érkezik újabb, azonos típusú megszakításkérés az első kiszolgálása előtt, vagy a program nem törli a B4h portot a megszakítás kiszolgálása nélkül.
Kérdés hogy F -en keresztül is mozog az adat módosítás nélkül, ha nem teszek a pop és push közé olyan utasítást, ami flag -et állít ?Igen, az F is használható másolásra, illetve valószínűleg használni is kell (és az AF'-et is) ahhoz, hogy valóban gyorsabb legyen az LDI utasításoknál. A Z80 F regiszterében nincs olyan bit, amelynek az értéke nem változtatható, és egyiket sem használja speciális célra (pl. megszakítások engedélyezésére).
jól emlészem hogy vannak valami atombiztosan működő "titkos" z80 opcode -ok, amivel lehet IX és/vagy IY regisztert 8 bitesként kezelni ? van ezekről valahol leírás ?Ha az assembler támogatja, akkor egyszerűen IXL, IXH, IYL, és IYH regisztereket kell használni (egyes assemblereknél I nélkül). Ezek gyakorlatilag az L-t és a H-t helyettesítik. Nem lehet azonban egy utasításban IXL/H és IYL/H is, és az L, H, és HL regiszterekkel sem használhatók együtt, illetve a CBh prefixes utasításoknál sem működnek (ott a DDh/FDh prefixnek más hatása van). Tehát ezek az utasítások hibásak:
LD IXL, IYL
LD IYH, (HL)
LD IYL, H
SLA IXH
Ez viszont jó (LD L, H + DDh prefix): LD IXL, IXH
Mi a mák az "M Cycle" meg a "T State" ?
jól emlészem hogy vannak valami atombiztosan működő "titkos" z80 opcode -ok, amivel lehet IX és/vagy IY regisztert 8 bitesként kezelni ? van ezekről valahol leírás ?
Van mondjuk kb. 2000H üres terület az FF szegmens alsó végén ?Nincs.
Alapból kb. mennyi hely van szabadon hagyva az FF szegmensből aza exdos által ? Tehát ha nem nyitottunk meg különösebben semmit, csak úgy elindult a gép, esetleg egy exdos vagy epdos épp fut ?Van mondjuk kb. 2000H üres terület az FF szegmens alsó végén ?
Komoly overhead lehet a video memória lassítása ... ? Az csak ilyen 10%, vagy pedig videó memóriából fele sebességgel olvas, mint sima memóriából ?Több egymást követő LDI utasítás átlagos sebessége:
Az az okkeros, sárgás szín meg a billentyűzetbeolvasás 10 port irása/olvasása ... :) Szánalom, komolyan mondom ...A sprite kirakásos kék sáv jónak tűnik nagyon, a billentyűolvasásos sárga egy picit soknak.
Fel kell írni egy darab papírra, akkor vissza lehet nézni :-)Én így a XXI. században papír helyett Printscreen-t használtam. :ds_icon_cheesygrin:
Hát a kérdésem alig assembly jellegű, de azért ide írom.
Én ugye most PC -n fejlesztek (imitálom), és egy PC fordítóval fordítok EP binárist, majd azt az emulátorba töltve tesztelem.
Namost a fordítóm egy C fordító, ami tud inline assebly -t ugyan, és a kód nagyja abban fog készülni, de a C -t is használnám, a nem sebesség kritikus részekhez.
Csakhogy mintha valami baromi nagy lenne a fordított kód méretet tekintve.
Tud esetleg valaki valami jó kis C->z80 tárgykód fordítót ?
Ja sdcc -vel tolom, de tudni tudok még a z88dk -ról is (bár valamiért az sdcc -t tudtam összelőni, a másikat meg hagytam, pedig abban sokkal jobban hasonlít az assembly mnemonik -ok formája az eredetihez), és igen, ha lehagyom a float -os számításokat (mást nem használok a könyvtár kódjából), akkor nem linkel hozzá egy vagon kódot, de azután sem tetszik a méret ... ahogy a síma kódot írom, pár forciklust bedobok és 100H -kkal nő a kód ... most nem emlékszem a konkrétumokra, de valahogy úgy emlékszem, hogy attól kellett tartsak, hogy írok kis kódot és kicsúszok a 16K -s lapomról ...
Hat nem tudom ... Esetleg nezd meg amit assembly-be lenyom (vagy -S kapcsoloval, akarmi), es hasonlitsd ossze egy ilyen "novekedes" utan hogy mi valtozott az asm file-ban az elozohoz kepest. Amikor en jatszottam sdcc/EP ugyben akkor belefutottam egy sdcc bug-ba, amit jelentettem is nekik (https://sourceforge.net/p/sdcc/bugs/2089/) (ez is meretnovekedest okoz).Hát köszi, de elég gáz nekem az EP is, nem akarnék most fordítót analizálgatni PC -n ...
Van egy olyan gyanúm, hogy ami témában te nyomulni szeretnél ott el kell felejteni a magas szintű nyelveket, méret és sebesség okán. Assembly és kész (http://enterpriseforever.com/Smileys/phpbb/ds_icon_redface.gif)Hát ja, és ennek okán akkor simán el lehetne felejteni a PC -t is akár (bár elég barátságtalannak éltem meg még a HEASS -t is a múltkor, miker ezzel próbálkoztam, pedig mennyivel jobb mint egy sima ASMON), hiszen ha csak assembly, akkor mér ne lehetne egyből EP -n,
A mindenféle táblákat adatokat lehetne esetleg úgy, hogy a C program adatfájlba írja ki, amit majd betölt a program.Hát persze ... és akkor már nem is kellene EP -re fordítani, hanem futhatna PC -n az adat file kimentő ...
A legjobb az lenne, ha valahogy rá lehetne bírni a C fordítót, hogy tudjon lapozni futás közben ...Elvileg létezik ilyen. (http://www.softools.com/scz180.htm) Csak sok pénzért adják :-(
Hát persze ... és akkor már nem is kellene EP -re fordítani, hanem futhatna PC -n az adat file kimentő ...
Csak akkor kell annak is egy külön projekt és mindíg végig kell gondoljam mit kell kimentsek/töltsek, így meg lefut ugye az EP program futtatásakor ...
Mondjuk lehet jobban járok vele ha mentek töltök már az elejétől, mert eszetlen lassan számol színuszt az EP ... :) Nem ilyenre van ez kitalálva ...
csakhat kell hozza basic, ami ep-n nem 100% h mindig vanA matekrutinok ha minden igaz pont az 1-es szegmensben maradtak.
Elvileg létezik ilyen. (http://www.softools.com/scz180.htm) Csak sok pénzért adják (http://enterpriseforever.com/Smileys/phpbb/ds_icon_sad.gif)Próbaverziójának nekiugrottam anno, mikor mondtad, de már nem emlékszem hogyan, de rosszabb eredményeket sikerült elérnem vele mint az SDCC -vel.
Sinus-ra meg rengeteg optimalizalt megoldas is van (kozelitessel viszonylag kis hiba nelkul minden float/akarmi hasznalata nelkul is - igaz erre 65xx-re tudok hirtelen csak linket (https://plus.google.com/108984290462000253857/posts/X2mzfRHAemP), z80-ra nem), vHát ez marha jó ... Ilyeneket miért most kell megtudjak ...
Hát ez marha jó ... Ilyeneket miért most kell megtudjak ...
Én már addigra csináltam egy alap pályaeditort (delphi+asm), régebbi munkáimra alapozva. Mondtam neki hogy azt folytassa inkább. Főnök is mondta neki. De ráhagytuk.Szerintem nagyon nagy meló lehet egy olyan programot írni tovább, amit más kezdett el. Egyszerűbb, ha az folytatja, aki elkezdte. Átnézni, "visszafejteni", ráhangolódni külön idő. Én a basic programokkal mindig így voltam.
Szerintem nagyon nagy meló lehet egy olyan programot írni tovább, amit más kezdett el. Egyszerűbb, ha az folytatja, aki elkezdte.Igen, sajnos a 2 dolog eléggé különbözik, mikor te írod a kódot, akkor az egész felől haladsz a részletek felé, míg mikor más kódját érted meg, akkor a részletekből haladunk ugye az egész fele, a részletekből kell összeálljon az egész ...
Szerintem nagyon nagy meló lehet egy olyan programot írni tovább, amit más kezdett el. Egyszerűbb, ha az folytatja, aki elkezdte. Átnézni, "visszafejteni", ráhangolódni külön idő. Én a basic programokkal mindig így voltam.Persze, viszont ahogy emlékszem a srác kb semmit se kérdezett, értette a kódomat magától is. Pedig csak alap szinten volt felkommentezve.
Aztán biztos vannak nagyon penge elméjű emberek, akik csak ránéznek az addig elkészült kódra, mindent átlátnak benne és továbbírják, mintha ők kezdtél volna.
ha jól emlékszem vannak táblázatok amikben egzaktul le van írva minde z80 utasítás idejeJól emlékszel, ezektől a táblázatokról szólnak a kérdéseim.
megszakításról: ilyenkor a visszatérési cím SP-n tárolódik?ja.
tehát nem lehet olyan megszakítást írni amiben nincs SP használat?Zozo válasza alapján: ja.
már nem emlékszem (http://enterpriseforever.com/Smileys/phpbb/smiley.gif) bár azt nem tudom miért akarok emlékezni (http://enterpriseforever.com/Smileys/phpbb/ds_icon_biggrin.gif)Mert ha nem próbálnál meg visszaemlékezni, akkor nem éreznéd alapját annak, hogy alig vonatkozó butuskásokat kotyoghass ... :)
Normál (nem video) RAM és ROM között szerintem nincs különbség, és az ezekhez való minden hozzáférésnél 0 vagy 1 Z80 ciklus késleltetés van a 0bfh I/O port beállításaitól függően. Az utasítás első (vagy ha van CB, DD, ED, vagy FD prefix, akkor az első két) byte-jának az olvasása "M1" hozzáférés, aminél a késleltetést külön lehet szabályozni. Az "ld a, (hl)" normál RAM-ban futva és az alapértelmezett késleltetésekkel 8 ciklus, mert 4+1 az utasítás, és 3 az adatbyte olvasása. A video memória és a NICK I/O portok (080h-08fh) elérésekor a NICK busz órajeléhez kell szinkronizálni (~890 kHz), és ez 1 és 5 Z80 ciklus közötti késleltetést jelenthet; a 0bfh portnak ilyenkor nincs jelentősége.
De ha azt is összehasonlítaná valaki, lehet hogy a két válaszból már sikerülne leszűrnöm a szabályosságokat, hogy hogyan tudom megállapítani, hogy kb. akkor X utasítás, amire azt írjak, hogy 1.75 ciklus, az akkor mégis miért lesz 8 ciklus ...Az "1.75 ciklus" az valószínűleg 1.75 us, azaz 7 ciklus (T-state) 4 Mhz-es órajelen.
Az "1.75 ciklus" az valószínűleg 1.75 us, azaz 7 ciklus (T-state) 4 Mhz-es órajelen.Oks, lehet marhaságokat irkálok össze, akkor vegyünk konkrétan egy 1.75 -öst:
Mert ha csak az E.T. értékkel simán összehasonlítom őket, akkor abból az jön ki, amit előbb írtam: az EXX+ld a,b az hosszabb idő, mint az ld a,(hl). Márpedig gyanús, hogy ez durván nem így van ...Miért ne lenne így ? Az EXX + LD A, B 2 utasítás olvasás (2 * 4 ciklus = 8 ciklus), az LD A, (HL) pedig egy utasítás és egy adat olvasás (4 + 3 = 7 ciklus). Az EP az alapértelmezett beállításokkal az utasítás olvasási (M1) műveleteknél vár 1 ciklust, ezért így az utasítások időtartama 10 (2 * 5), illetve 8 (5 + 3) ciklus lesz; a várakozás azonban letiltható. Video RAM-ban pedig átlagosan ~18 (2 * ~9) és ~13.5 (~9 + ~4.5) ciklus alatt futnak le ezek az utasítások.
Miért ne lenne így ? Az EXX + LD A, B 2 utasítás olvasás (2 * 4 ciklus = 8 ciklus), az LD A, (HL) pedig egy utasítás és egy adat olvasás (4 + 3 = 7 ciklus). Az EP az alapértelmezett beállításokkal az otasítás olvasási (M1) műveleteknél vár 1 ciklust, ezért így az utasítások időtartama 10 (2 * 5), illetve 8 (5 + 3) ciklus lesz; a várakozás azonban letiltható. Video RAM-ban pedig ~18 (2 * ~9) és ~13.5 (~9 + ~4.5) ciklus.Oks, akkor tehát egyrészt szerinted a megadott "4 MHz E.T." értékeimmel igenis összehasonlíthatom az utasításaimat, és azok az EP kiépítésében is viszonylag jól tükrözik az utasítások abszolút idejeit ha nem video ramban fut a kód (és persze hogy nem), pláne ha még az EP "direkt" lassító várakoztatásait is kikapcsoljuk?
A legegyszerűbb, ha letiltod a várakozást (OUT 191, 12), és kerülöd a video RAM használatát, ha lehetséges. Ilyenkor az utasítások a Z80 dokumentációban megadott "T states" ciklus alatt futnak le (NOP = 4 ciklus, JP = 10 ciklus, stb.).
Az 1Hz-es az órához kell, ha jól emléx.Tehát van még egy külön egy herces megszakítás, ami párhuzamosan tud jönni a hang megszakkal ? Tehát az 1Hz -es hang megszak mellett van még egy külön "nem hang" megszak 1 Hz ?
Beállítod az A7-es portot, 40-re, vagy 60h-ra, attól függően, hogy melyik hanngenerátort szeretnéd időzítésre használni , utána a kiválasztott hanggenerátor két frekiportjban megadod a megfelelő értéket, és tolhatod az a8, ac porton a digi értékeket megszakból (frekvencia = 250,000/(n+1) ) , és a végénTanx, kipróba.
ld a,03h
out (0b4h),a
-val aktiválod a hanggenerátor által gerjesztett megszakítást,
ezekről megint előjönnek az emlékek :)Hát igen, de valahol még ilyen lehetőséged sincs, mert van a videjó, oszt gatter :D
emlékszem, az marhára csalódás volt nekem hogy a megszakítás típusokat is nekem kellett lekezelni kódból
plusz a verem használata...
berak az ember 2 féle megszakítást amik semmit se csinálnak, és elég nagy frekin mennek, máris a proci idő nagy % elveszett
totál gáz :(
Tehát van még egy külön egy herces megszakítás, ami párhuzamosan tud jönni a hang megszakkal ? Tehát az 1Hz -es hang megszak mellett van még egy külön "nem hang" megszak 1 Hz ?Az a hang 1 Hz valójában 1 Khz :D , de ha akarod, akkor pl van a videó 50 Hz -ed mellett egy Dave által generált 50 Hz is, a Net megszakítás nem tudom milyen sűrűn érkezik.
Tanx, kipróba.No para :)
Az a hang 1 Hz valójában 1 Khz (http://enterpriseforever.com/Smileys/phpbb/ds_icon_biggrin.gif) ,De nézdcsaknézdcsak, ez a Dave leírásból van:
De nézdcsaknézdcsak, ez a Dave leírásból van:Sztem igen.
"Four latched interrupts are provided, a 1Hz interrupt for time clock applications, an interrupt switchable between 50Hz, 1KHz or the outputs of tone generators 0 or 1"
Vagy ez tulképpen 2 interrupt, csak mindkettőt a Dave generálja, viszont külön forrásnak számít,
és a másik meg, a komplex az csak három féle lehet: 50Hz,1KHz,és beállított ? És akkor a beállított az olyankor tényleg nem tud szólni, mert le van ezzel foglalva ?
Leteszteltem, szól a hang is, bár nem tudom mit lehetne kezdeni egy állandó hanggal, vagy egy változó sebességű megszakítással, lehet ezekből is ki lehetne hozni valamit.
De mi van a magát módosító kóddal. Amennyire tudom, síma z80 alatt az nem igazán probléma, de az újakkal mi a pálya ?Nincs vele gond.
void IRQ() __naked
{
__asm
di
ex af, af ;csak árnyékregisztereket használunk
in a, (0xb4) ;megnézzük, hogy hang megszak jött -e
and #0x2
jr z, IRQ_NoAudio ;ha nem hang elugrunk oda, ezzel kizártunk minden zavaró tényezőt a lehető leggyorsabb hang megszakhoz,
;vagyis a video vackai nem lassítják tovább a hangot
ld a, #D_Ints+ 0x2 ;tehát akkor hangmegszakunk van itt már
out (0xb4), a ;ha már itt van A regiszterben, ilintézzük a 0xb4 sorsát
exx ;még mindíg csak árnyékot használunk, melyben elő van készítve főprogram által:
;DE= egyik minta
;HL= másik minta
;b= egyik minta vége után lévő cím felső bájtja
;c= másik minta vége után lévő cím felső bájtja
;tehát a hangminták csak 256 -os igazításon és hosszon vannak
ld a, #0xf9
out (D_Page1), a ;belapozzuk a hangminta szegmenst
ld a, d
cp b ;ellenőrizzuk, hogy elértük -e már a hangminta végét
jr nc, IRQ_AudioEnd0 ;ha elértük átugorjuk a minta kezelését
ld a, (de) ;betöltjük a mintát
out (0xa8), a ;kiirjuk a mintát
inc de ;növeljük a minta címét
IRQ_AudioEnd0:
ld a, h
cp c ;ellenőrizzuk, hogy elértük -e már a másik hangminta végét
jr nc, IRQ_AudioEnd1 ;ha elértük átugorjuk a minta kezelését
ld a, (hl) ;betöltjük a másik mintát
out (0xac), a ;kiirjuk a mintát
inc hl ;növeljük a minta címét
IRQ_AudioEnd1:
ld a, #0xfc
out (D_Page1), a ;visszatesszük az ellapozott lapunkat
exx
ex af, af
ei
ret ;ez egy audio megszak volt, visszatérünk. azt remélem, hogy ha itt volt video megszak IS az audio mellett,
;akkor az a visszatérés után újra kiváltódik majd egyedül, hang megszak nélkül
IRQ_NoAudio:
ld a, #D_Ints+ 0x20 ;ha ide eljöttünk, akkor ez egy video megszak, és ez már nem számít, mert ez sokkal kevesebbszer fut csak le
out (0xb4), a
ld a, #1
ld (_g_WasIRQ), a
ex af, af
ei
ret
__endasm;
}
Szóval ha van tipp, hogy hogyan lehetne felgyorsítani, az nem volna rossz.Hmmm ... lehet, hogy eszembe jutott egy jó ötlet ...
Segíteni sajnos nem tudok, csak imádkozni érted, hogy Zozo meg ne lássa a fix szegmenscímeket. (http://enterpriseforever.com/Smileys/phpbb/ds_icon_cheesygrin.gif)Ja, de ha lesz ebből bármi is, akkor a fix címeket simán át lehet írni önmódosító kóddal, mikor EXOS -osítani akarja valaki. Kb. 3 helyen lesz benne lapozás, és forrásállományban rendelkezésre fog állni az egész.
Segíteni sajnos nem tudok, csak imádkozni érted, hogy Zozo meg ne lássa a fix szegmenscímeket. :ds_icon_cheesygrin:Készültem szóvá tenni :-)
void IRQ() __naked
{
__asm
di
ex af, af
in a, (0xb4)
and #0x2
jr z, IRQ_NoAudio
ld a, #D_Ints+ 0x2
out (0xb4), a
exx
ld a, #0xf9
out (D_Page1), a
ld a, (de)
out (0xa8), a
inc de
ld a, (hl)
out (0xac), a
inc hl
ld a, #0xfc
out (D_Page1), a
exx
ex af, af
ei
ret
IRQ_NoAudio:
ld a, #D_Ints+ 0x20
out (0xb4), a
ld a, #1
ld (_g_WasIRQ), a
ex af, af
ei
ret
__endasm;
}
És igazából ugyanennek akkor lehet készíteni egy ilyen verziót is, ami talán egyetlen hajszálnyival gyorsabb mint az előző:void IRQ() __naked
{
__asm
di
ex af, af
in a, (0xb4)
and #0x2
jr z, IRQ_NoAudio
ld a, #D_Ints+ 0x2
out (0xb4), a
exx
ld a, #0xf9
out (D_Page1), a
ld c, #0xa8
outi
ex de, hl
ld c, #0xac
outi
ex de, hl
ld a, #0xfc
out (D_Page1), a
exx
ex af, af
ei
ret
IRQ_NoAudio:
ld a, #D_Ints+ 0x20
out (0xb4), a
ld a, #1
ld (_g_WasIRQ), a
ex af, af
ei
ret
__endasm;
}
De ami viszont nagyon érdekes. Mindkét verzióra igaz, hogy mégha egymáshoz képest nincs is nagy különbség, de az előzőhöz képest azért komoly különbséget vártam ...Mit szólsz ahhoz, ha a videó megszakítást el is hagyod?, akkor nem kell figyelgetni, és egy csomó időt megspórolsz, mivel 50 FPS-es játékot szeretnél, a videó megszakítás részt tedd a főprogramba, pont az 50 Hz-es várakozás után.A hangmegszakítás 4KHz -el pörög a digi hanghoz ... Nem értem milyen 50 Hz -es dologra gondolsz, ami nem video ... És milyen 50 Hz -es várakozás ...
w50 in a,(b4h)
bit 4,a
jr z,w50
call eredetilegmegszakításbanlévő50Hzrutin
.
.
.
a főprogram további része
Így csak a progamozható megszakításod lesz, és nem kell csekkolni semmit, csak egy 03h-t küldeni a b4h portra.
Ne legyen videó megszakításod, csak a programozható, ami most videó megszakításos rész, legyen a főprogramban.Aham ... tehát azt állítod, hogy a video megszak bit akkor is beállítódik az LPT által, ha a video megszakítás a b4 -en valójában tiltva van,
főprogram 50Hz -re való várakozás:
én továbbra se értem minek bele a lapozásPedig 1Xű. B0 -án van a program (C is) kód, meg a mozgás adatok, főleg utóbbi miatt még szűk is lehet, másik három lapon meg a video ram van, screen meg sprite adatok.
Pedig 1Xű. B0 -án van a program (C is) kód, meg a mozgás adatok, főleg utóbbi miatt még szűk is lehet, másik három lapon meg a video ram van, screen meg sprite adatok.jó értem én. tehát giga mennyiségű és minőségű grafika és effekt lesz benne
Ezzel kész is. Máris 64K. Ha digi hangot akarok, akkor már mér ne sokat, ami mutat is valamit ? És van még másik 64K kihasználatlanul a legalapabb EP -ben is.
Ha digi hangot akarok, akkor már mér ne sokat,Még az is lehet, hogy teljes digi zenét le stream -elek alá az egyik oldalon ... vagy legalább ambienteket ...
Még az is lehet, hogy teljes digi zenét le stream -elek alá az egyik oldalon ...Kis Metallica -t alá ... :)
És van még másik 64K kihasználatlanul a legalapabb EP -ben is.Persze a 64K gépek buktak ...
Az in és out utasítás mechanizmusában nincs ilyen külső hardvertől függő lefutási idő ?Ilyet tud a Z80-as rendszer, de az EP-ben nincs használva.
Tehát in/out -nál a proci kiteszi az értéket az adatbuszra, vár egy kicsit, a külső eszköz meg vagy lekapta onnan, vagy nem,
vagy pedig kirakja, és ott vár mindaddig, míg a külső eszköz nem jelez, hogy levette az anyagot ?
Úgy vettem észre, hogy a 4. bit 1-be billen, amikor eléri a megszakításbájtot tartalmazó LPB-t a NICK, és törlődik, amikor áttér a következő LPB-re.
Én is ezt használom időzítésre, csak tiltott megszakítás mellett.Hát a videot akkor én is tiltanám. Arra gondolsz, hogy neked egyáltalán nincs semmilyen megszak, hang sem, és az hátha bekavar ?
tehát giga mennyiségű és minőségű grafika és effekt lesz benneHat 150X150 -es képernyőfelbontásnál nehéz giga mennyiségről beszélni ... de amit találok belekonvertálom. Mit veszíthetek vele.
giga mennyiségű és minőségűMinőség ... 4KHz hang ... :)
Ennek ellenére lehet hogy mégis alkalmazni fogom. Megnézem mennyit gyorsít a hangképzésen, és ha eleget, akkor hozok egy olyan kompromisszumot, hoÁáááá mégsem ... :(
Egyszerű a megoldás (nem tökélestes), ha 25fps-t akarsz, akkor két helyre teszel wait50hz-et, csak jól kell kiválasztani a második helyét, ha meg át akarsz térni 50-re, akkor önmódosító kóddal törlöd a 2-dikat.Nem én 1-5, vagy még jobb lenne 1-10 frame között tetszőlegesen beállíthatót akarok. Úgyhogy ez nem lesz így esetenként megcsinálva. Általános kód lesz, max kisebb kompromisszumokkal ...
in a, (0xb4)
and #0x2
jr z, IRQ_NoAudio
Valszeg nem éri meg ...
ld b,0ffh
w50a in a,(0b4h)
bit 4,a
jr z,w50a
di
w50b in a,(0b4h)
bit 4,a
jr nz,w50b
ei
djnz w50a
Igazából ezt a három utasítást spórolná meg ...Elméletileg ez 500 NOP lenne 1 frame-ben.
Code: [Select]in a, (0xb4)
Valszeg nem éri meg ...
and #0x2
jr z, IRQ_NoAudio
Elméletileg ez 500 NOP lenne 1 frame-ben.Ebben biztos vagy ? Az valami 6-8 rasztersor, nem ? És a 60-80 raszterhez képest amit vinne ez egy egész frame esetén az olyan 10 % lenne akkor ...
Ha jól számoltam, akkor több, mint 7.Ja, én is így számoltam. Csak én már a te 500 NOP -odból indulva.
Még ezzel a gyorsulással is vagy 60 raszterbe kerül a digi hang ... elég súlyos ... lehet még kaparhatnám lefele 3KHz -re, és lehetne inkább csak egy csatorna monóban ...Sztem tök jó a 60 raszter, még marad egy csomó időd, most járok 60 raszternél, és 5 ojjektum mozog a képen, és amilyen ámátőr vagyok, tutter lehetne ezt gyorsabban is, szebben meg mega 1000% :lol:
Endinek igaza van, legalább az egyik lapozást meg lehetne spórolni a megszakításban, kevesebb lassulást okoz ha a 3 videólapot lapozgatod két szegmensen, mikor mi kell, az egyik szegmens lehetne fixen a digi hangé, az is kb 300 nopot jelentene.
Sztem tök jó a 60 raszter,
most járok 60 raszternél, és 5 ojjektum mozog a képen ...
Hogy csináltad a sorduplázást? Ha jól értem, akkor 2 LPB a két sorra, mert ha jól emléxem, akkor 1 LPB-vel is megoldható a duplázás.Nem, két raszterenként van 1 LPB, tehát a szinkronizált raszter soraim száma 272 de csak ennek fele az LPB -k száma (a szinkronokon kívül), meg hát a játékomban is csak a fél felbontás van. :)
A Gnashernek álltam neki, az olyan kis eccerű,Ja, én is akarok olyasmiket is, ha ki van dolgozva jól, akkor frankó az.
mégis akadtak, és tuti akadnak problémáim (http://enterpriseforever.com/Smileys/phpbb/ds_icon_lol.gif) ,Ja én technikailag hasonlóba az exorcist -be akarok majd belefogni, de már gondolkodtam rajta, hogy mondtam, hogy így ziccer meg úgy ziccer, oszt mikor belegondoltam rájöttem hogy mégsem lehet pixelművelet nélkül megúszni, mert pikkpakk elfogynak a karakterek amibe a szkrollozott fazisokat tarolna az ember
egy galagába lehet bele is fulladnék (http://enterpriseforever.com/Smileys/phpbb/ds_icon_biggrin.gif)Fuldoklás ez mindig ... de egyszer csak átérünk a túlpartra.
Nem, két raszterenként van 1 LPB, tehát a szinkronizált raszter soraim száma 272 de csak ennek fele az LPB -k száma (a szinkronokon kívül), meg hát a játékomban is csak a fél felbontás van. :)Hát, akár meg is érhetné levágni azt a 16-ot a spórolás miatt, emléxem, hogy volt olyan tv-nk, amin a 27 magas basicben nyitott videó lap majdnem kilógott :D (3-4 karakternyi hely volt felül, a 256 magas kép nem jelent volna meg :D )
Ja én technikailag hasonlóba az exorcist -be akarok majd belefogni, de már gondolkodtam rajta, hogy mondtam, hogy így ziccer meg úgy ziccer, oszt mikor belegondoltam rájöttem hogy mégsem lehet pixelművelet nélkül megúszni, mert pikkpakk elfogynak a karakterek amibe a szkrollozott fazisokat tarolna az emberHát igen, 256 karakterbe belefértem volna, de akkor hol vannak a színek ??? Azok meg kellenek, így maradt a többször használatos karakter :D , így jól állok, maradt 8 szabad a 64-ből :D
Fuldoklás ez mindig ... de egyszer csak átérünk a túlpartra.vagy nem, de az biztos :lol:
A Gnashernek álltam neki,És hogy csinálod ? Vason ? Emuban ? ASM, vagy PC -n valami crosscompile ?
Hát, akár meg is érhetné levágni azt a 16-ot a spórolás miatt, emléxem, hogy volt olyan tv-nk, amin a 27 magas basicben nyitott videó lap majdnem kilógott (http://enterpriseforever.com/Smileys/phpbb/ds_icon_biggrin.gif) (3-4 karakternyi hely volt felül, a 256 magas kép nem jelent volna meg (http://enterpriseforever.com/Smileys/phpbb/ds_icon_biggrin.gif) )Francba, én úgy emlékeztem ezt a 272 -t úgy választottam ki, hogy az lett mondva, hogy átlag TV -n az még latszik. Nem minden, nyilván, de a legtöbbet úgy lehet állítani, hogy latsszon ...
És hogy csinálod ? Vason ? Emuban ? ASM, vagy PC -n valami crosscompile ?Emuban, annyit megy a debugger, hogy beégett már a kijelzőbe :D Asm Sjasm-mal fordítva.
Francba, én úgy emlékeztem ezt a 272 -t úgy választottam ki, hogy az lett mondva, hogy átlag TV -n az még latszik. Nem minden, nyilván, de a legtöbbet úgy lehet állítani, hogy latsszon ...Lehet, nem emléxem mi volt a határ, meg azt a tévét, amiről beszéltem, 85-ben vettük :D
Asm Sjasm-mal fordítva.Egy ilyen assembler támogat már mondjuk lokális változókat, vagy ilyesmiket ?
void IRQ() __naked
{
__asm
exx
ld c, #0xb4
ld b, #D_Ints+ 0x2
out (c), b
ld c, #0xa8
outi
ex de, hl
ld c, #0xac
outi
ex de, hl
exx
ei
ret
__endasm;
}
leteszteltem, hacsak nem írtam el valamit, akkor végtelen ciklus lesz.
Ez jó, legalább szabadon lehet használni az af'-t, így mennyi az annyi raszterban?Ja, bár nem tudom mire kellhetne ...
Lehet, ezért tették kiolvashatóvá a Dave INT bemeneteit.Kicsit akkor még általánosabban:
Bit4 (16) jelenti azt, hogy a Nick éppen megszakítás jelet ad.
Bit5 (32) azt jelenti, hogy van eltárolt videó megszakítás, ez csak akkor állítódik, ha engedélyeztük azt a B4 porton. Erre figyelni csak folyamatos DI mellett érdemes, mert egyébként úgyis IRQ lesz, amikor beáll.
DI
CIKLUS IN A,(0B4H)
AND 10H
OUT (81H),A
JR CIKLUS
Fenasban futtatva az utolsó sor alatt zöld lesz a keret.
void IRQ() __naked
{
__asm
exx
ld c, #0xb4
ld b, #0x1+ 0x2
out (c), b
ld c, #0xa8
outi
ex de, hl
ld c, #0xac
outi
ex de, hl
exx
ei
ret
__endasm;
}
Ez így szerintem rossz, mert elrontja a jelzőbiteket. Kellene EX AF, AF' is.Fú, az simán lehet, mert azokat a legutolsó optimalizálási lépcsőben "optimalizáltam" ki ... :)
Fú, az simán lehet, mert azokat a legutolsó optimalizálási lépcsőben "optimalizáltam" ki ... :)Valójában nem veszítenél vele időt, mert a kód elején az OUT (C), B helyére egyszerűbb és gyorsabb OUT (0B4H), A kerülhetne.
Valójában nem veszítenél vele időt, mert a kód elején az OUT (C), B helyére egyszerűbb és gyorsabb OUT (0B4H), A kerülhetne.Hát pedig pont a 2 ex af, af -et optimalizáltam ki, előtte az volt ... :)
ld c, #0xa8
outi
ex de, hl
ld c, #0xac
outi
ex de, hl
ennél: ld a, (de)
out (0xa8), a
inc de
ld a, (hl)
out (0xac), a
inc hl
A második megoldás jobb, mert kis mértékben gyorsabb, és kevesebb regisztert használ. A háttér regiszterek hasznosak lehetnének a főprogramban a grafikai és egyéb rutinokban. (http://enterpriseforever.com/Smileys/phpbb/smiley.gif)Szuper ... na befejeztem a fejből optimalizálást. Így visszafele haladok ... :)
A másik megszak javaslatodat visszavontad ?Igen, mert tévedésből sztereó hangot játszott le két független mono csatorna helyett.
másrészt meg a többi is túl nagy megkötésnek tűnik nekem, hogy a max 256 byte lehet a sample, meg ilyenek ...Ez nem igaz, csak 256 byte-os határon érhetne véget (de tetszőleges címen kezdődhetne), és általában +5 ciklust fogyasztana csatornánként (többet a 256 byte-os határok elérésekor, de ez statisztikailag csak ritkán fordul elő). Az előnye az lenne, hogy a megszakítás automatikusan kezelné a lejátszás megállítását, és végtelenített lejátszást is lehetővé tenne.
Még egy probléma: a lejátszás így nem tud megállni, legalábbis automatikusan (megszakításból vezérelve) nem. Azaz a hangminták végén megfelelő hosszúságú (legalább 1/50 másodperc) üres helyet kell hagyni, és a főprogramban minden video megszakításnál ellenőrizni, hogy a lejátszás lefutott-e már.Igen, ez by design van így, pont az optimalizálás jegyében, csak gondolom addig már nem olvastad vissza. Sőt a helyzetet tovább bonyolítja hogy a cuccból most vettem ki a video megszakot, vagyis nem is lesz fix 50 Hz megszak, hanem csak a főprogram tudja majd kezelni ezt körönként, de a főprogramot pedig valójában szabadon lehet majd állítani 1-10 FPS között ...
A hang szüneteltetéséhez egy csatornán pedig a megfelelő regisztert úgy állítani, hogy 0 (azaz valójában 20h) értékű hangmintára mutasson, és az INC utasítást NOP-al felülírni.Nem így akarom, mindíg menni fog a hang, folyamatosan, és lesz egy csend hangom, amire mindíg rá lesz váltva, amikor nincs értelmes hang beváltva. Hát ez végülis az amit mondasz, csak az inc -et nem kell piszkálni.
Ez nem igaz, csak 256 byte-os határon érhetne véget (de tetszőleges címen kezdődhetne),Ezt nem értem ... csak inc c van benne ... az sosem fog kimenni 256 byte -os range -ből. Igen kezdődhetne akárhol, de nem lehetne a hang hosszabb, mint 256 byte. Hisz mikor előszor 0 lenne a c, akkor vége lenne a lejátszásnak. Vagy mit nem értek ?
Sőt a helyzetet tovább bonyolítja hogy a cuccból most vettem ki a video megszakot,Hoppá ... most esett le ... mivel a sebességem úgyis meglesz 50 FPS -el, ezért mikor majd épp 10 FPS -sel megyek, nem kell nekem a főprogram loop -ját olyan hosszan befognom, csak arra kell megtanítsam, hogy miután az első frame -ben kész vagyok, a többi frame- ben csak olyanokat csináljon ami nem mozgás ... tehát a hangot nyugodtan tudom még attól kezelni, meg még a színkeverő villogtatást is ...
void IRQ() __naked
{
__asm
ex af, af
exx
ld a, #D_Ints+ 0x2
out (0xb4), a
ld a, (de)
out (0xa8), a
inc de
ld a, (hl)
out (0xac), a
inc hl
exx
ex af, af
ei
ret
__endasm;
}
Ezt nem értem ... csak inc c van benne ... az sosem fog kimenni 256 byte -os range -ből. Igen kezdődhetne akárhol, de nem lehetne a hang hosszabb, mint 256 byte. Hisz mikor előszor 0 lenne a c, akkor vége lenne a lejátszásnak. Vagy mit nem értek ?Az INC C után feltételes elágazás következik, és ha a C 0, akkor INC B történhet, illetve a B értékének a tesztelése.
Na, ha jól értem, akkor ez nyert mint leggyorsabb még működő verzio, ha 2 hangot akarok lejátszani, és ráérek a főprogramból lekapcsolni ?Még egy keveset lehetne gyorsítani a megszakítást OUT (C), B utasítással törölve (BC' = 03B4h fixen), de egy regiszterpár elvesztése talán túl nagy ár lenne a 6 ciklus gyorsulásért.
Az INC C után feltételes elágazás következik, és ha a C 0, akkor INC B történhet, illetve a B értékének a tesztelése.Fárasztó lehet elmagyarázni ezeket a trivialitásokat ... Kösz ... :)
Még egy keveset lehetne gyorsítani a megszakítást OUT (C), B utasítással törölve (BC' = 03B4h fixen), de egy regiszterpár elvesztése talán túl nagy ár lenne a 6 ciklus gyorsulásért.Oks, egyenlőre nem használom a főprogramban az árnyékot semmire, de majd a végén beleírom, ha így is marad.
Most akkor az lehet még kérdés hogy az inc r + jr cc az nem gyorsabb -e mint az inc hl/inc de, amire érzésre megint azt mondanám, hogy nem, de mostmár megnézem majd az órajeleket ...Az INC HL természetesen gyorsabb, mint az INC L + JR Z, de ezt már említettem is.
Eszembe jutott még egy gyorsítási lehetőség, nem jelent túl sokat, de mégis valami: az inc de-t, és inc hl-t le lehetne cserélni inc e-re, és inc l-re, és a videó megszakítás után csekkolod, hogy elért-e 0f0h közelébe, ha igen, akkor következő 256-os tartományra ugrás, igaz, egy picit helypazarló.Ez szerintem nem lenne jó, mert a főprogram nem tudná elég pontos időzítéssel tesztelni a lejátszási pozíciót, ezért akadozna a hang.
Viszont egy dolog foglalkoztat, hogy lehet az alul/felüláteresztő szűrőt, és a ring modot leprogramozni?Ezt nem egészen értem, pontosan mit is kellene elmagyarázni ? :oops:
Ezt nem egészen értem, pontosan mit is kellene elmagyarázni ? :oops:Hát mivel a működésüket nem bírtam felfogni :lol:, így a megvalósítása is elég távol áll tőlem, ha nem hosszú kód/bonyolult, akkor azt szeretném, hátha abból felfogom, hogy hogy is műxik ez digi hangok esetén.
Engem olyan Link érdekelne ahol Z80 rutinok forrás kódjai található. Pl sorrendbe rendező; Hex2Dec; hex2ASCII; (nn)=HL*DE....http://baze.au.com/misc/z80bits.html (http://baze.au.com/misc/z80bits.html)
A hálón nem találom de lehet rosszul keresem. Emlékszem volt ilyen.
Nekem elveszett
Esetleg a linkekhez is belehetne tenni. Vagy valahol az oldalon is lehetne gyűjteni a legjobbakat.
Előre is köszönöm
Viszont az bíztató, hogy +4-en valamire sikerült jutni, igaz a processzora nem lassabb, mint az EP-é, de talán a z80 utasításkészletével, + a Dave adottságaival jobb minőséget lehetne kihozni.Valahol valakik egyszer nagyjából konszenzusra jutottak hogy a Z80 2,2-szeres órajel mellett képes a 65XX-szel egyenlő teljesítményt leadni általános feladatok alatt. !!Nem én állítom, nem is óhajtok vitatkozni rajta, csak munkahipotézis!! Ezt és a +4 órajelét figyelembe véve, az EP még előnyben kellene hogy legyen.
A különbség attól is függ, hogy Plus/4-en engedélyezett-e a képernyő. Ha nem (az egész kép keret), akkor a fenti 2.2-es "Z80 lassulást" feltételezve 3.73 MHz-es (várakozás nélküli) Z80-nak felel meg, egyébként csak 2.51 MHz-esnek.Hát, ez az itteni úri közönséget valószínűleg meglehetősen kevéssé érdekli, én meg ismerem ezeket a lehetőségeket. Én csak annyit próbáltam volna kihozni a dologból, hogy ha valakinek van hozzá energiája, akkor szabványos konfiguráció mellett is feltehetően megoldható a "wave converter" stílusú hangkeltés EP-on.
Egyes programok gyorsulást érnek el azzal, hogy a gépet NTSC módba kapcsolják, amivel 5 / 4 arányú "overclock" lehetséges. Így azonban nincs használható video kimenet, és a szabálytalan órajelet valószínűleg nem célszerű hosszabb ideig használni.
Létezik azonban "lassú" mód is, amelyben a CPU mindig egyszeres sebességgel fut (886723.75 Hz = ~1.95 MHz-es Z80). Ennek kikapcsolt képernyőnél lehet értelme, ha konstans sebességre és pontos időzítésre van szükség (például 1541 "turbó" töltőknél).
Hát, ez az itteni úri közönséget valószínűleg meglehetősen kevéssé érdekliEngem érdekelnek a szomszéd tábor érdekességei is. Pl. izgi ez a képkikapcsolás, ilyenről eddig csak ZX81-en hallottam.
Hát valójában csak azt teszteltem, hogy milyen frekin kell tolni a hangot, hogy ne torzítson, ez lett 20Khz, a gyűrűmodot nem néztem, igaz nem is tudtam volna :D Alacsonyabb sebességű playbacknél egyre rosszabb.Az ideális megoldás talán a SID órajelének a 64-ed része lenne, azaz C64 esetén 15394.51 Hz (250000 / 16 = 15625 Hz-es DAVE megszakítás, vagy 259 4 MHz-es Z80 ciklus / hangminta), Plus/4-nél pedig 13855.06 Hz (250000 / 18 = 13889 Hz-es DAVE megszakítás, vagy 288 4 MHz-es Z80 ciklus / hangminta). De ehhez nagyon kevés az idő, ha nem csak nagyon egyszerű emuláció kellene, akkor célszerűbb lenne ennek a felével próbálkozni.
Engem érdekelnek a szomszéd tábor érdekességei is. Pl. izgi ez a képkikapcsolás, ilyenről eddig csak ZX81-en hallottam.
arra gondoltam még, hogy mind a 15 hangmagassághoz lenne alap háromszög, és fűrészjel is eltárolvaA 15 hangmagasság itt pontosan mit is jelent ? :oops: A hangmintákat több változatban tárolni anti-aliasing céljából van például értelme, de elsősorban csak PC-n, egy 8 bites lejátszón a "tökéletes" minőség kevésbé lényeges.
a négyszögjelen még nem gondolkoztam :lol:Négyszögjelnél a kitöltési tényező módosításához (PWM) hasznos lenne több hangmintát tárolni. Például 32 lehetséges értékhez 8 KB területen (a SID ugyan ennél nagyobb felbontást tud, de a 32 is jobb a semminél). Ez a megoldás pazarolja a memóriát, viszont CPU időt takarít meg, amiből meglehetősen kevés van.
Plus 4 eseten nem tudom pontosan hogy van ez a TED-del (ott imho nincs kulon colour SRAM) de talan pont ezert ott meg az orajellel is faragni kell, hogy beleferjen? Vagy hasonlo ...A Plus/4 valamivel bonyolultabb:
... Plus 4 eseten nem tudom pontosan hogy van ez a TED-del (ott imho nincs kulon colour SRAM) de talan pont ezert ott meg az orajellel is faragni kell, hogy beleferjen? Vagy hasonlo ...Nos ott tényleg nincs külön színmemória, ezért a képernyőmemória mellé direktben van egy dinamikus színmemória rendelve (pl.: default képernyő kezdőcím $0C00 és az ehhez a karakterhez tartozó szín a $0800 címen van). Ennek hála a 8 bites adatbuszán kétszer annyi adatot kell karaktersoronként átrángatni, mint 64-en. Plusz bónusz a rasztersoronként 57(*2) ciklus a 63-mal szemben. Természetesen a TED ugyan úgy lopogatja a ciklusokat, mint a VIC, cak itt két badline van de legalább a sprite-ok nem zavarnak a képbe. Egyébként szerintem nincs két órajel frekvencia, csak a processzor a kereten sokkal kevesebbet van várakoztatva, mint a látható területen. De ezt IstvanV valószínűleg pontosabban tudja.
(persze a konkret implementacio mas, C64-en orajel ciklusokat "lophat" el a VIC, +4-nel - afaik - viszont az orajel frekvencia van valtoztatva, EP-nel pedig ugye az orajellel jatszanak ismet, csak kisse maskeppen, de ezt Zozo ugyis jobban tudja)
+4-en a négyszögjel kitöltési tényezőjét azt hiszem úgy modulálták, hogy a szokásos számú minta helyett másfélszer akkora terület volt foglalva és a kitöltési tényezőtől függően máshol (később) kezdték a kiolvasást.Ez valóban kevésbé pazarló megoldás, de Z80 CPU-n valamivel lassabb, mert nem áll rendelkezésre a 6502 hatékony indexelt címzése. Azaz nem lehet egyszerűen csak a H regiszterbe írni a táblázat kezdőcímét, az L-be pedig az aktuális fázist, hanem aritmetikai műveletre lenne szükség. De ha ez a (nem nagy mértékű) lassulás nem probléma, akkor így memória takarítható meg, és az effektus felbontása is nagyobb lehet.
A 15 hangmagasság itt pontosan mit is jelent ? :oops: A hangmintákat több változatban tárolni anti-aliasing céljából van például értelme, de elsősorban csak PC-n, egy 8 bites lejátszón a "tökéletes" minőség kevésbé lényeges.Bocs, a hangmagasság, a hangerőt akarta jelenteni :lol:
Négyszögjelnél a kitöltési tényező módosításához (PWM) hasznos lenne több hangmintát tárolni. Például 32 lehetséges értékhez 8 KB területen (a SID ugyan ennél nagyobb felbontást tud, de a 32 is jobb a semminél). Ez a megoldás pazarolja a memóriát, viszont CPU időt takarít meg, amiből meglehetősen kevés van.A 32 sztem egész jó is lenne, ugyan nem tudom, hogy a white-fülűeknek mennyire lehet feltűnő a hiány, de a hozzám hasonló botfülűeknek sztem nem nagyon :D
Ez valóban kevésbé pazarló megoldás, de Z80 CPU-n valamivel lassabb, mert nem áll rendelkezésre a 6502 hatékony indexelt címzése. Azaz nem lehet egyszerűen csak a H regiszterbe írni a táblázat kezdőcímét, az L-be pedig az aktuális fázist, hanem aritmetikai műveletre lenne szükség. De ha ez a (nem nagy mértékű) lassulás nem probléma, akkor így memória takarítható meg, és az effektus felbontása is nagyobb lehet.
Bocs, a hangmagasság, a hangerőt akarta jelenteni :lol:Én erre külön táblázatot használtam, ami hanggenerátoronként elfogyaszt 14 ciklust. :oops: Viszont kevesebb memória használatával lehet 15-nél több szint (ami a burkológörbe generátorral előfordulhat), és a sok táblázatos PWM emulációval kombinálva nem lesz elfogadhatatlanul nagy a memória igény. Azaz valami ilyesmire gondoltam:
Úgy gondoltam, hogy miden hangerőhöz letárolok 1 3szög, egy fűrészjelsort, ami kitölti 256 byte-ot, és az 50Hz-es megszak állítja, hogy melyiket olvassa, a beolvasott hangerő függvényében. A frekvenciát, meg ugyanolyan addolós módón, mint a DTM playerben.
Na ebbe pont beleutkoztem. Mint "gyakorlott" (Z80-hoz kepest legalabbis!) 65xx programozo, hirtelen gondolkodoba is estem a minap, amikor az kellett, hogy egy egy memoriaban tarolt tablazatbol egy register altal (amugy egy byte-ba belefer, sot 128 byte-ba is ...) megadott elemet toltsek be. Ez 65xx-n az indexelt cimzes mellett igen egyszeru, Z80-nal viszont eleg kenyelmetlen es lassu, mert csak ugy lehet megoldani, hogy pl 16 bites osszeadassal hozzaadom a tablazat kezdocimet es akkor ugy kiolvasom. Ennel tenyleg nincs jobb/gyorsabb megoldas? :(A leggyorsabb az, amit már említettem: 256 byte-os határra kell igazítani a táblázatot, és akkor egyszerűen egy regiszterpár alsó regiszterébe kell tölteni az indexet, a felsőbe pedig a táblázat kezdőcímének a felső byte-ját. Kisebb táblázatokat elég a méretüknek megfelelően igazítani, a lényeg, hogy elkerülhető legyen a 16 bites aritmetika, azaz ne keresztezzenek 256 byte-os határt.
A leggyorsabb az, amit már említettem: 256 byte-os határra kell igazítani a táblázatot, és akkor egyszerűen egy regiszterpár alsó regiszterébe kell tölteni az indexet, a felsőbe pedig a táblázat kezdőcímének a felső byte-ját. Kisebb táblázatokat elég a méretüknek megfelelően igazítani, a lényeg, hogy elkerülhető legyen a 16 bites aritmetika, azaz ne keresztezzenek 256 byte-os határt.
http://baze.au.com/misc/z80bits.html (http://baze.au.com/misc/z80bits.html)itt is van egy pár jó rutin:
Én erre külön táblázatot használtam, ami hanggenerátoronként elfogyaszt 14 ciklust. :oops: Viszont kevesebb memória használatával lehet 15-nél több szint (ami a burkológörbe generátorral előfordulhat), és a sok táblázatos PWM emulációval kombinálva nem lesz elfogadhatatlanul nagy a memória igény. Azaz valami ilyesmire gondoltam:Na, én ezt a 15 - nél több hangerő szintet nem vettem figyelembe, mondjuk ami adatot ki tudok nyerni, az csak 15 szintű.
- 2 * 256 byte táblázat a fűrészjelhez és háromszögjelhez
- 1 * 256 byte táblázat rossz minőségű (rövid ciklusban ismétlődő) "zaj" emulációhoz; a másik megoldás a DAVE 17 bites polinom számlálójának a használata
- 16384 byte táblázat 6 bites hangerőhöz (ha az előző táblázatok csak 6 bites értékeket tartalmaznak, akkor valójában 256 byte-onként 192 byte-os "lyukakat" tartalmazna, amelyeket egyéb célra is fel lehetne használni)
- 8192 byte táblázat 5 bites PWM emulációhoz (tulajdonképpen 8448 byte kellene ahhoz, hogy 0 és 1 között 1/32 lépésekben lehessen állítani a kitöltési tényezőt)
- 32 KB területen még marad 7 KB szabad memória további táblázatokhoz
2 belapozott szegmensen a különböző táblázatok lennének, egyen a kód és egyéb adatok/változók, egyen pedig a lejátszandó zene.
Először én is a kinyert zaj sample alkalmazására gondoltam, de aztán arra hutottam, hogy a zajt tök jól le tudnánk játszani a 17 bites polinom számláló beállításával, csak akkor kell egy nagyobb frekvencia konverziós tábla is, vagy eleve a zajnál a konvertált regiszter tartalmat kimenteni, és nem a SID regiszter értékeket.A táblázatos zaj generálás egyszerűbb, mert csak 256 véletlenszerű (a négyszögjel alacsony és magas értéke közötti tartományban) byte-ot kell írni a táblázatba, és a frekvenciát 16-al osztani, illetve az eredeti SID frekvenciához képest 4 helyett 64-el. Azonban az így lejátszott "zaj" zavaróan ismétlődik, és a Plus/4 zajgenerátorához (ami egy 8 bites polinom számláló) hasonló, ha nem is használhatatlanul rossz. Ezt javítaná a DAVE polinom számláló használata, bár annak csak 2 értékű kimenete van, és bonyolultabb a konverzió: fDAVE = 250000 / (fSID * 0.939606) - 1, ha a SID órajele 985249 Hz (PAL C64); a hangerőt is csökkenteni kell, de ez egyszerűen megoldható a "hullámforma" táblázatba 256 fix értéket írva, ami beállítja a helyes hangerőt. Nagy méretű táblázat is jó megoldás lenne, csak túl lassú.
Ezt a 16k-s hangerő táblázatot nem értem, azt hittem, hogy csak 256 byte-nyi az isA táblázat címzése két értékkel történik: az eredeti hangmintával, és a hangerővel. A mérete tehát ezek lehetséges értékei számának a szorzata (pl. 64 * 64, de a 64 * 256 címzése gyorsabb).
Ezt javítaná a DAVE polinom számláló használata, bár annak csak 2 értékű kimenete van, és bonyolultabb a konverzió: fDAVE = 250000 / (fSID * 0.939606) - 1, ha a SID órajele 985249 Hz (PAL C64); a hangerőt is csökkenteni kell, de ez egyszerűen megoldható a "hullámforma" táblázatba 256 fix értéket írva, ami beállítja a helyes hangerőt. Nagy méretű táblázat is jó megoldás lenne, csak túl lassú.A sid playerben van egy 4096 elemű konverziós táblázat, ha a zajhoz azokat az értékeket mentenénk le, akkor csak be kell tolni a Dave-nek, erre gondoltam, Meg az egészet úgy, hogy van két verzióm, az egyik sid player a SID regisztereket menti, a másik meg a Dave ragisztereket lejátszás közben, minden megszakításban, a kettőt összegyúrva, miből mi kell, lehetne talán a legkevesebb lejátszás közbeni adatátalakítással megúszni az egészet. ( a freki, és a hullámforma értékeket a SID regisztereket mentő változatból, a zaj freki, és a hangerő értékeket meg a Dave regisztereket mentő változatból, vagy esetleg csinálni egy 3. verziót, ami azt menti le, amit kell :D ) Ezt összenyomni egy egyszerű, és gyors tömörítéssel, hogy ne legyen nagy a file, az eddigi pár zenénél ezt manuálisan csináltam :D
A táblázat címzése két értékkel történik: az eredeti hangmintával, és a hangerővel. A mérete tehát ezek lehetséges értékei számának a szorzata (pl. 64 * 64, de a 64 * 256 címzése gyorsabb).Akkor nem egyszerűbb a 2 hullámformára megcsinálni a 15 volume változatot, ami kevesebb, mint 8k, és azt változó frekivel lejátszani? :ooops:
ohohóóó, látom fertőző Z80System betegsége, már mindenki komondort akar faragni az EP-ből
:twisted:
fölrakhatom az EP-WIKI-re, hogy nem merüljön el a fórumok mélyén?Nyugodtan!
tudom, hogy az LPT-t kell birizgálni hozzá, de bevallom férfiasan, hogy nem nagyon értem...Egyébként emlékszem, hogy sok évig nekem is "mumus" volt ez a LPT téma, meg a Z80/videó címek különbözősége. Aztán egyszer beugrik az embernek, és rájön, hogy tök egyszerű :-)
A négyszögjelnél meg az említett 32-t, és azt a megfelelő volume értékkel lejátszani?Az is egy lehetséges megoldás, de akkor a lejátszó kódban kell megvalósítani a hangerő szabályozását. Ez lehet egy egyszerű AND utasítás (7 ciklus a hangerű táblázat 14 ciklusa helyett), de akkor kis hangerőnél "kattog" a négyszögjel az indításakor és a kikapcsolásakor (mert például 48 és 16 helyett 32 és 0 értéke lehet fél hangerőnél). Vagy egy kis méretű táblázat csak négyszögjelhez (a többi hullámformánál letiltva), ami helyet takarítana meg (illetve valójában nem, csak nem lenne "szétszórva" a szabad terület, mint a 16K-s táblázatnál, amiből csak 4K ténylegesen használt) a hangerőszabályozás kisebb felbontása árán. Egyébként 16 hangerő szintnél a külön táblázat foglalna kevesebb helyet, és még 32-nél is csak kb. hasonló memória igénye lenne. :)
Grafikus képernyő kezelésére az itt (http://enterpriseforever.com/programozas/fraktalok-assemblyben/msg35541/#msg35541) található programokban is van néhány egyszerű példa:igen, nézegettem azokat is, nekem főleg az LPT-vel voltak gondok, a szabályos szegmensigénylés eddig is ment :-) meg a rajzoló rutinokra gondoltam, hogy föl kéne használni Pascal-ban, és lenne egy übergyors pitpixel, lineto, moveto és floodfill rutin :-)
- video szegmensek foglalása és a nem használt szegmensek felszabadítása
- egyszerű LPT (az egész aktív képterület egy LPB) létrehozása és a cím beállítása
- BORDER és BIAS állítása EXOS hívással
- vonal rajzolása és terület feltöltése (FILL) 2 színű módban (graph.s)
- 16 színű pixel rajzolás dither használatával (mandel.s)
a polinom számlálós verzió egész jó, alacsony frekin hallottam különbséget.Egy probléma azért még van a polinom számlálóval: ez sem kompatibilis azzal, ha 20h a kimenet, amikor nincs hang. Tehát ez is "kattogna" alacsony hangerőnél. Ha minden hullámformánál 00h lenne a kikapcsolt hang, akkor legalább következetesen fordulna elő ez a "hiba". :) Így azonban már lehetséges lenne a hangerő táblázat elkerülése, és AND utasítás használata a négyszögjel és zaj 6 bites hangerő szabályozásához. A fűrészjelnél és a háromszögjelnél külön táblázatokat készítve minden hangerőhoz az 5 bites felbontás még elfogadható memória igényű (2 * 8 KB), és a táblázatokban nem csak lineárisan növekvő hangerő lehet - a logaritmikus jobban kihasználja a korlátozott felbontást. További előny, hogy pont marad még idő gyűrűmodulációra is:
Éredekes lenne még egy nagyobb tudású, de lassabb emulátort készíteni, ami turbós gépeken a lehető legjobb minőséget próbálná elérniEzt már én is akartam javasolni!
Tehát a kérdés csak valami olyasmi, hogy van -e a "megszakítás ütemezőjének" az EP harverében valami olyan pontatlansága, ami miatt nem tudom teljesen kitölteni az 1/4KHz időt, és valami "nagyobb" idő ráhagyással kell majd dolgozzak, hogy véletlen ki ne csússzak a megszak időből (nem akarok kimaradt hangot), és az X darab megszakítás ezért egy komolyabb overhead -et tesz majd a csillagmozgatásom kódjára ahhoz képest, mintha a főprogramban futna ?Igazából nem pont a "megszakítás ütemezője" miatt, de természetesen bizonyos időzítési pontatlanságra számítanod kell mindenképp. Legalábbis szerintem. Nem tudod semmilyen módon garantálni, hogy a megszakításkezelő órajelre pontosan mikor induljon el, mivel nem fogod tudni, hogy éppen milyen utasítást hajt végre a Z80. Ezen felül mivel a videomemóriát írod, számolnod kell a Nick által lefoglalt buszciklusokkal is. Bár ez utóbbira IstvanV vagy Zozo lehet, hogy tudna rajzolni neked egy táblázatot az egyes rasztersorokban a processzor számára elérhető szabad ciklusokról. A legegyszerűbb valószínűleg az lenne, ha elméleti számítások helyett írnál egy tesztprogramot, és tesztelnéd mennyi idő áll rendelkezésre biztonságosan.
A legegyszerűbb valószínűleg az lenne, ha elméleti számítások helyett írnál egy tesztprogramot, és tesztelnéd mennyi idő áll rendelkezésre biztonságosan.Hát pont ez az, amit meg akarnék úszni a kérdezgetéssel ... Nyilván ha ilyen megoldás mellett döntök, akkor annak kikísérletezésétől, hogy mekkora chunk -okban tudom a csillagaimat kirajzolni, nem ment meg senki.
Tehát feltételezve, hogy a csillagrajzolás kód szinte semilyen feltételes utasítást nem fog végrehajtani, tehát nagyjából konstans ideje lesz, mondjuk elvben mintha csak NOP -okat tartalmazna,
akkor lehet -e ezt olyan jól kiidőzíteni, hogy kihasználja a 4KHz megszak teljes idejét, majd visszamenjen a főprogramba, gyakorlatilag csak azért, hogy újra hívódhasson a megszakítás ?
Tehát a kérdés csak valami olyasmi, hogy van -e a "megszakítás ütemezőjének" az EP harverében valami olyan pontatlansága, ami miatt nem tudom teljesen kitölteni az 1/4KHz időt, és valami "nagyobb" idő ráhagyással kell majd dolgozzak, hogy véletlen ki ne csússzak a megszak időből (nem akarok kimaradt hangot), és az X darab megszakítás ezért egy komolyabb overhead -et tesz majd a csillagmozgatásom kódjára ahhoz képest, mintha a főprogramban futna ?
Viszont nem teljesen ertem ez mire jo, ilyen elven ne is terj vissza az interrupt-bol amig a foprogramnak ugysem kell futnia, minek is akkor?Hát pont azért amit írtál ... mert akkor turbós gépen is jó lesz.
Hát pont ez az, amit meg akarnék úszni a kérdezgetéssel ... Nyilván ha ilyen megoldás mellett döntök, akkor annak kikísérletezésétől, hogy mekkora chunk -okban tudom a csillagaimat kirajzolni, nem ment meg senki.De most komolyan! Tényleg azt várod, hogy valami nem létező kódról itt bárki megmondja neked, hogy tudja teljesíteni a kritériumaidat vagy sem?!
De ha már most eltántorít valaki attól, hogy az 1/4KHz -es időintervallum méretéhez képest egy komoly méretű lehet az ilyen bizonytalanság miatti ráhagyás vesztesége, akkor megúszok egy csomó felesleges kísérletezést.
De most komolyan! Tényleg azt várod, hogy valami nem létező kódról itt bárki megmondja neked, hogy tudja teljesíteni a kritériumaidat vagy sem?!írottam vagyon:
Egyébként tegyük fel egy pillanatra a gondolkodó sapkát!Csak előtte mindenképp olvasd el amit írok.
4kHz-es megszakításnál van 1000 órajelciklusod két megszakításkérés között. Ebből ha levonod a használni tervezett leghosszabb Z80 utasítás órajelciklusainak kétszeresét, akkor nagyjából meg van az az érték, ami garantáltan rendelkezésedre fog állni. 312 soros LPT esetén nagyjából 3,9 soronként fog bekövetkezni megszakítás. Ha lenne információ arról, hogy rasztersoronként mennyi órajel szabad a videomemória írására illetve tudnád, hogy hány ciklusonként akarod írni, akkor valszeg tudnál egy becslést adni arra, hogy átlagosan mennyi késleltetést fog összeszedni a kódod a Nick buszfoglalása miatt a megjelenített képernyő sorokban.Most nem idézgetek be magamtól mindent, amitől azt hinni, hogy ezt hiszem, nem állja meg a helyét.
De gondolom te nem ezt szeretted volna itt olvasni, hanem valami "Igen, 332." szerű választ. Félek, ez nem fog menni. Senkinek.
Nézd, én nem akarom azt állítani, hogy te hülye lennél, csak én vagyok helikopter,Hát ez szép tőled ...
de még ha nem is olvastam végig és elemeztem részletesen az összes rögzített állításodat, az olvasmány élményeim és más gépen összegereblyézett ismereteim alapján próbáltam felhívni a figyelmed a tényleges gyakorlati megvalósítás során előtted álló problémákra,Hát mégis úgy éreztem, hogy túl nagy az a gondolkodó sapi, és a szemed elé csúszott egy pillanatra.
illetve arra hogy valós tesztekkel gyorsabban eljuthatsz a szükséges tudás megszerzéséig, mintha próbálnál elméleti konstrukciókat gyártani jelenleg nem pontosan ismert bizonytalanságok figyelmen kívül hagyásával.Ijesztő számomra, de kezdek hajlani eme igazságra, de azért még van bennem remény, hogy valaki másképp idomul a kérdéshez, és mégis tud valami ennél ügyesebb közelítést ismerni fel és adni, megmentve engem a dolog potyára kipróbálásától.
Megszakítási rendszer bizonytalankodása: igen van, attól függően, hogy milyen utasítás fut éppen és az hol tart, változó számú ciklust késhet a kezelő indulása.Hát igen, de azt gondolnám, hogy mondjuk 1-20 BIZONYTALAN ciklus ideje az 1/4KHz -es időhöz képest nem egy nagy eresztes, elhanyagolható ... ennyi jöhetne kb. egy utasításból, gondolom ... ezt sztm be lehetne áldozni. De vajon milyen BIZONYTALAN késlekedések lehetnek még ...
[ul](Hát még persze, hogy) nem.[/ul]
- videoszegmensben fut a kódod?
csak írja a videószegmenst vagy olvassa is?
[ul]Hát eddig nem akartam ezzel vacakolni, de ha ettől lenne stabil, beküzdhetem a keretre.[/ul]
- mindig csak kereten fut a kódod, vagy a képernyő aktív területén is?
Ijesztő számomra, de kezdek hajlani eme igazságra, de azért még van bennem remény, hogy valaki másképp idomul a kérdéshez, és mégis tud valami ennél ügyesebb közelítést ismerni fel és adni, megmentve engem a dolog potyára kipróbálásától.Bárminek a kipróbálása soha sem számít potyára dolgozásnak. Szerintem. Még akkor sem, ha valaki már kipróbálta előtted és bebizonyította hogy működik vagy nem. Mert mi van, ha te még észreveszel valamit, ami vagy jobbá vagy egyáltalán lehetővé teszi a próba tárgyát?
Egyébként gondolod, hogy IstvanV amikor írta az ep128emu-t csak úgy ült és elmélkedett magában, vagy írta az egyre trükkösebb és optimalizáltabb teszt programokat, és időnként meglepődött?Ezért is IstvanV egy megaguru aki rúlz, én meg egy szimmepla alkalmazás programozó, aki küzd ...
Különben ő lenne a legjobb ember erre a feladatra (ahogyan látom),Vagy Zozo, vagy geco, vagy te, vagy akárki aki ért hozzá ... (kivéve endit persze :))
de nem vagyok benne biztos hogy meg akarná írni helyetted a programod legtrükkösebb részeit. (http://enterpriseforever.com/Smileys/phpbb/smiley.gif)Hát sajnos ... pedig az lenne a legegyszerűbb. De hát ez a fránya teremtő kitalálta ezt a szabad akarat dolgot ... lennék csak én a helyébe, minden EP guru játékot kódolna ... vagy pedig lenne az EP -be szprá ...
Vagy Zozo, vagy geco, vagy te, vagy akárki aki ért hozzá ... (kivéve endit persze :))Én is meg tudnám csinálni, de csak BASIC-ben, sok IF-fel, ami kicsit lassú lenne, de nem baj, mert ott a Zzzzzzzzip! :D
Itt már megint nem az assembly programozásról van szó lassan, de sebaj. (http://enterpriseforever.com/Smileys/phpbb/ds_icon_biggrin.gif)Azért a célt sem veszítjük szem elől.
Aham ... hát ilyet még nem csináltam emuban. Simán lehet hogy nem is tud ilyet. De sajnos nem ismerek direkt PC disassemblert.Az emulátor disassemblere file-ba is tud írni, például d "" 100 3fff. Azonban ha fordítható assembler kód kell címkékkel, akkor érdemesebb erre a célra készült külső disassemblert használni.
ööö... én olyat keresek, amibe betöltök egy fájlt, megmondom a kezdőcímet (hogy hova dissassemblálja), majd kiírja nekem txt fájlbaAz ilyen fajta disassemblerrel nem mész sokra, max nagyon egyszerű programok esetén. Mindenesetre ilyen a DZ80
kösziEhhez csináltam EXOS hívás felismerőt.
közben találtam ezt: dZ80
Ehhez csináltam EXOS hívás felismerőt.de jó, köszi! :-)
Az ilyen fajta disassemblerrel nem mész sokra, max nagyon egyszerű programok esetén. Mindenesetre ilyen a DZ80
IDA-val lehet jobban boldogulni, azzal meg csak az a baj, hogy pl az EXOS hívásokat nem ismeri, kézzel kell mindet szerkeszteni, hogy az RST után DB legyen.
Beszéltünk már sokat arról, hogy kéne egy jó, EP-t ismerő disassembler, de eddig még nincs ilyen :-(
jó lesz ha abbahagyjátok ezeket a tool fejlesztéseket mert a végén még én is elkezdek megint ep-re programozni :)Ejnye, mivel te nem programozol EP-re, más se tegye? Miféle sabotage ez? :D
Miféle sabotage ez? (http://enterpriseforever.com/Smileys/phpbb/ds_icon_biggrin.gif)Saboteur.
Saboteur.Igen. Megtalálja a lemezt tele EP programokkal, majd egy helikopterrel lelép a cuccal. :D
PC regiszter valami általánosabb regiszterbe töltésére van valami szép módszer ? Szebb mondjuk ennél :
call addr
addr:
pop hl
00000000 <__x86.get_pc_thunk.cx>:
0: 8b 0c 24 mov ecx,DWORD PTR [esp]
3: c3 ret
A 64 bites x86 már támogatja az RIP relatív címzést, így ott nincs szükség ilyen trükkre.
Jól értem, hogy a sprite adatokat a videoszegmensekben akarod tárolni?Hát sajnos jól ... :(
Szóval egyrészt nem tudom mennyi lesz ez a lassulás a video RAM olvasásból,De ha tényleg komolyat szakít a sprite kirakásban, ha a forrás a video RAM, akkor most még egy olyan dolog felötlött bennem, hogy oly módon, ahogy a csillagmozgás is külön, saját szegmensre került és a nullás lap át van rá lapozva,
Tehát az LDI utasítások átlagosan 16 + 5 + 1.5 = 22.5 ciklus alatt futnak le (közelítően).És ha a forrás és a cél is "fast" RAM, akkor meg hozza a megadott (4, 4, 3, 5) = 16 ciklust ?
IstvanV és Zozo, a segítségeteket kérném! Próbáltam elméletben számolgatni a videoszegmensek elérésével kapcsolatban egy kicsit, de mivel tudásom parányi, eléggé hihetetlen érték jött ki. Egy videosor 57(*2 - órajel két fázisa) Nick buszciklusig tart. Ebből 8(*2) az LPB beolvasása, 3 memória frissítés vagyis marad 95. Ebből jön le a tényleges képernyőtartalom elérése, ami (RMARGIN-LMARGIN)*[1|2]. 40 oszlopos kép esetében ez lehet 40 vagy 80 félciklus, mely utóbbi esetében csak 15 hozzáférési lehetőség jutna a Z80-nak 256 T ciklusonként (4MHz-es processzor) , ami szerintem elképesztően kevés. Hol a hiba a számolásomban?Egy karakteren belül valójában 3 video RAM művelet lehetséges (ellentétben például a Plus/4-el, ahol csak 2, de ezt a TED kevésbé "pazarlóan" használja fel), ebből 2 mindig a NICK számára fenntartott, egy pedig szabad a Z80 számára. Ez teljesen független attól, hogy a képernyőn éppen mi történik, a keretszínű sorokban is lassú a video RAM. A Z80-nak mindig meg kell várnia a következő karaktert (~889846 Hz-es frekvencia), és még el is kell végeznie a memória műveletet, ami így akár 5.5 ciklus várakozást is eredményezhet a legrosszabb esetben. A Z80 várakoztatása 0.5 ciklus (125 ns 4 MHz-es gépen) egységekben történik.
És ha a forrás és a cél is "fast" RAM, akkor meg hozza a megadott (4, 4, 3, 5) = 16 ciklust ?Igen, feltéve, hogy a BFh porton nincs várakozás beállítva.
ha disassembláltok, akkor milyen címkéket használtok?Hát én még sosem csináltam ilyet, hogy dissass -al nagyobb kódot hozok fordítható formába, de miért nem jó akkor mindkettő ? :
Egyébként te mit csinálsz, milyen feladat megoldásához fordítasz vissza ?A HiSoft Pascal-t fordítom vissza. Értelme nulla, de jól szórakozok vele :-) De izgalmas dolog felfedezni egy fordító működését.
Eredetileg úgy gondoltam (én naiv), hogy majd kibővítem egy STRING típussal. Nem biztos, hogy olyan egyszerű lesz... :-)Nincs mondjuk Spectrumra olyan, amiben már benne van? Akkor csak azzal kéne összevetni, hogy ott mit fejlesztettek.
Én ilyenkor kommentben írom oda, amikor meg van valami, akkor az egyből az összes előfordulásához.Lehet, hogy van már az EXOS/EXDOS kódokból visszafordított, fordítható állomány, csak én még nem hallottam róla ?
Lehet, hogy van már az EXOS/EXDOS kódokból visszafordított, fordítható állomány, csak én még nem hallottam róla ?Nincs. Ill. az EXDOS már lefordul, de valahol vannak még benne kód relatív címzések, mert ha bele van írva, akkor már nem működik :oops:
Nincs.Pedig ha lenne, akkor sokkal több lehetőség közül választva tudnád hekkelni, nem ? Mikor helyet kell csinálni valaminek, vagy ilyesmi ...
de valahol vannak még benne kód relatív címzésekAz mi is ? Valami kódból számolt címzésre gondolsz ?
Pedig ha lenne, akkor sokkal több lehetőség közül választva tudnád hekkelni, nem ?Igen, ezért is ez a célkitűzés.
Az mi is ? Valami kódból számolt címzésre gondolsz ?Igen, pl amikor mondjuk egy LD HL, szám esetén a szám az nem érték, hanem valaminek a címe a kódban. Ezeket mind meg kell találni és becimkézni, ahogy az a eredeti forrásban lehetett.
Nincs mondjuk Spectrumra olyan, amiben már benne van? Akkor csak azzal kéne összevetni, hogy ott mit fejlesztettek.ááá, még a CP/M-es változatban sincs olyan... :-)
Igen, ezért is ez a célkitűzés.
Igen, pl amikor mondjuk egy LD HL, szám esetén a szám az nem érték, hanem valaminek a címe a kódban. Ezeket mind meg kell találni és becimkézni, ahogy az a eredeti forrásban lehetett.
IDA nem tud ilyet?Leginkább ott is kézzel megadni az ilyeneket.
van egy darab nyitott video-csatornánk, és létrehozunk egy saját lpt-ta BFF4h címen (vagyis az FFh szegmens 3ff4h címén) lakozik az LPT címe 4000h-t hozzá kell adni, és ki kell számolni belőle 82-83h portoknak megfelelő értéket.
miután már nem használjuk saját lpt-t, vissza is adtuk az exos-nak a lefoglalt video-szegmensüket, hogyan tudom visszaállítani láthatóvá a még mindig nyitott video-csatornát? gondolom előtte el kellett volna menteni a video lap lpt címét? és azt kell megmondani a Nick-nek, ugye? na de hogyan?
a BFF4h címen (vagyis az FFh szegmens 3ff4h címén) lakozik az LPT címe 4000h-t hozzá kell adni, és ki kell számolni belőle 82-83h portoknak megfelelő értéket.köszi, működik
ezt megszakításból fölülírja-e az EXOS (úgy mint a 81h-t)?Igen, tehát célszerű EXOS változóval állítani, hacsak nem valami demó trükk, de akkor ott úgy sincs EXOS megszakítás :-)
Igen, tehát célszerű EXOS változóval állítani, hacsak nem valami demó trükk, de akkor ott úgy sincs EXOS megszakítás :-)ööö, tényleg, 28-as változó... kicsit szét vagyok esve ma :-)
valahonnét (az újabb EXOS-ok esetében) ki lehet olvasni, hány MHz-es a gép? Ha nem, hogyan lehet megállapítani viszonylag egyszerűen?
LPT táblát hogy kell módosítani, hogy legyen még egy 36 pixelsor magas szöveges lapom, a grafikus rész alatt, hasonlóan a BASIC graphics parancsához?A legegyszerűbb az EXOS státusz sor LPB-jét (BFF4h-ról olvasható a címe a 2. lapon) másolni, ez már tartalmazza a karakterkészlet kezdőcímét, és beállítani az LD1 címet, margókat (figyelve az ALTIND0/1 bitekre), és palettát. Természetesen az alsó és felső keretet is rövidíteni kell összesen 36 sorral.
valahonnét (az újabb EXOS-ok esetében) ki lehet olvasni, hány MHz-es a gép? Ha nem, hogyan lehet megállapítani viszonylag egyszerűen?Valamelyik Spectrum Világ mellékletében volt egy példaprogram, ami kiírja az órajelet. A 12-16. számok között lehetett az egyikben.
Van olyan z80 utasítás (nem dokumentált) amivel megtudhatjuk, hogy milyen megszakítási mód van beállítva?Nincs. Az emuba azt csináltam, hogy az I alapból a ROM-ba mutat értelmetlen helyre (tehát nem az FF-ekre), és ha megváltozik, akkor azt IM2-re áttérésnek veszi. Nem tökéletes módszer, de nagy rakás játék működövé vált így.
Nincs. Az emuba azt csináltam, hogy az I alapból a ROM-ba mutat értelmetlen helyre (tehát nem az FF-ekre), és ha megváltozik, akkor azt IM2-re áttérésnek veszi. Nem tökéletes módszer, de nagy rakás játék működövé vált így.A TAP-ok betöltése miatt kérdeztem, mert van olyan program, ami beállítja az IM2-t, és elkezd tölteni, na nálam ez egy hatalmas fagyi lett :lol: , most le van tiltva az összes megszakítás a TAP egy-egy részének töltése végéig, ezt akartam valahogy elkerülni.
A snapshot mentésnél van egy ilyen lekérdezés az emu-ban:Na erre nem gondoltam, hogy a 0-ás lapra is csináljak egy saját IM 2 rutint :), ez sokkal jobb, mint amit én csináltam ideiglenesen, a speccy ROM-ban elhelyezett IM 2-mben állítottam :lol:Code: [Select]IMKERD LD A,30H
Itt már a 0-ás lap van belapozva, az azon futó IM2 rutinban egy INC A van.
OUT (0B4H),A
LD A,3DH
LD I,A
XOR A
EI
HALT
DI
IM 1
PUSH AF
LD A,3FH
LD I,A
POP AF
RET
Normális programozási elv mentén szerintem kb. 8 körül mozoghat az érték, míg IX és egyéb hosszú utasítások alkalmazásánál 12-14 körül lehet.Na, hát pont én is erre lennék kíváncsi... :-)
Az szerintem csak max reklamfaktor, hogy a MIPS az "million instruction per second", attol, hogy tobb utasitast hajtasz vegre 1 masodperc alatt egy masik megoldashoz kepest, nem biztos, hogy az lesz a gyorsabb, mert egyes utasitasok vegrehajtasi ideje nem ugyanaz.És tényleg, most olvasom, hogy tréfásan "Meaningless Information on Performance for Salespeople" (értelmetlen teljesítményinformáció kereskedőknek) is értelmezik a rövidítést... :-)
"jól megizzasztom a procit"?Pl. arra kényszerítjük, hogy ha döcögve is és nagyon akadozva, de játsszon le DTM zenét, miközben Iview formátumú videót játszik le, nem?
Más téma, ami eszembe jutott:
Van-e értelme annak a kifejezésnek, hogy "jól megizzasztom a procit"? Pl. Mandelbrot-halmaz számítással, vagy Small Demo futtatásával... :-)
Bele építhették volna anno és inverz kiírással LIST-ázhatták volna.Mivel nem voltak dokumentálva, honnan tudhatták volna? :oops:
Pontosabban: CALL M, xxxxMi a különbség a kettő között, mármint működésügyileg?
Mi a különbség a kettő között, mármint működésügyileg?A CALL M feltétele akkor teljesül, ha az eredmény negatív (a 7. bit 1), ami azonos az eredeti BIT 7, A-t használó kóddal.
Emun teszteltem PE-vel működött, igaz a 00h-s, és a 80h-s összeggel nem teszteltem.
amatőr kérdés, tudom, de nem találom sehol, hogy az SP regiszter értékét ki tudom-e nyerni valahogy?LD (nnnn),SP :-)
kösziHa nem akarod, hogy a megszakítás bepiszkítson a verem területedre, akkor nem árt, ha biztos vagy benne, hogy nem lesz megszakítás ott, akkor nem kell.
az LD SP,HL utasitás előtt kell DI, vagy nem?
kilepes: DI
LD SP,100H
LD C,40H
EXOS 0
INC A
OUT (0B3H),A
LD A,6
JP 0C00DH
miért nem működik normálisan? ugyan az EP logóhoz jutok, de onnantól szép fagyásokat produkálÉs nálam van benne:ez hiányzott... :oops:
LD A,255
OUT (0B2H),A
is :-)
és azt tapasztalom 128K gépen, hogy nincs üres szegmens az asmon 1.3 szerint egyáltalan,Nem fordítva?
az asmon 1.5 szerint meg 1 üres szegmens van ...
És ez fura, mert a basic ugye alig foglal le memóriát ... mire foglal le az asmon az 1-2 szegmensén kívül ?Nullás lap, rendszerszegmens, két szegmens a az Asmon-nak mint rendszerbővítő, 2-t belapoz, ez eddig 6... És akkor még videó lap, stb
Nem egyszerű dolog egy asmon -ba Zozo féle gyorstesztet rakni ?Nem.
Van olyan asmon.rom amiben egyáltalán nincs semmilyen gyorsteszt, és ezért nem bírálja felül az esetleges (már csippelt) exos rom -ban lévőt ?EXOS 2.2-től kezdve nem fut automatikusan a TEST_ROM, csak ha T-t nyomsz.
Nem fordítva?
Én hamar átszoktam a Fenass-ra, ami brutálisan gyors editor és fordító volt a többihez képest. :)A HEASS meg még brutálisabb, ráadásul az összes RAM-ot tudja használni, nem kell INCLUDE fájlokkal szórakozni :-)
A HEASS meg még brutálisabb, ráadásul az összes RAM-ot tudja használni, nem kell INCLUDE fájlokkal szórakozni :-)
Pl a Zozotools 126K .HEA formában, 247K normál TXT-ben.
A HEASS nagy hiányossága, hogy nincs benne monitor. Valahogy kombinálni kéne az ASMON-t a HEASS-szal :-)Fordítod binárisnak, és betöltöd ASMON-ba :-)
A HEASS sajnos emulátoron nem hajlandó együtt működni a :FILE eszközzel (nem lehet onnét bináris fájlokat include-olni.Ez a FILE: eszköz hibája, mert nem fájlkezelő eszköz :-(
Én a héten szoktam át erre:Ez miben jobb mint az sjasm?
http://www.nongnu.org/z80asm/
Igaz, ez nem EP program, de nagyon tetszik.
Ez miben jobb mint az sjasm?Nem tudom, azt nem ismerem. Lehet, hogy az sjasm jobb.
Igen. Mi lesz ebből? :-)Egy 8 bites wav lejátszóra gondoltam, tudom ott az SNDPLAY, de úgy emléxem az 7 bites.
betöltöttem a hangot goldwave-be és tényleg 8 bitesTudom, én konvertáltam mp3-ból ;)
de ezt 8 bitesként is játszod le EP-n, valami trükkel? több csatorna együtt? nagyon jó minőségű (jó, persze pc-n a 8 bites lejátszás is minőségjavított)
de amúgy szerintem valami tömörítéssel is lehetne próbálkozni, amit realtime le lehet játszani. pl asszem van olyan ami nem az abszolút, hanem relatív amplitudót tárolja és kevesebb biten. ilyesmit szerintem az EP is le tudna realtime
de hogy tolod ki 4 csatira a 8 bitet? arra gondolok hogy ez ügye több out utasítás, és nem egyszerre történik ügyebár. ez nem okoz gondot? így hallásra persze nem77 órajelciklus alatt történik meg a 4 out utasítás.
ld c,(hl) ;sample érték
inc hl
ld b,high regval0
ld a,(bc)
out (0a9h),a
inc b
ld a,(bc)
out (0aah),a
inc b
ld a,(bc)
out (0adh),a
inc b
ld a,(bc)
out (0aeh),a
hát ezt nem teljesen értemMinden regiszternek megvan a maga 256-os (0-3fh értékkel feltöltve, az egyes táblázatok el vannak tolva egymástól 1-gyel) táblázata egymás után tárolva, és a sample 0-ffh értékének megfelően onnan veszi ki a megfelelő értéket, ami a portra kerül.
mi az a high regval és mi van a (bc)-n?
Sample érték: 01 03 08 15 81 port1 01 01 02 04 21 port2 00 01 02 04 20 port3 00 01 02 04 20 port4 00 00 02 03 20 |
Jó lenne valami tömörítés, és az az eltolásos dolog lehet hatékonyabb is lenne, mint más, zip-et néztem, nagyon minimálisan tömörített, 16KHz-en talán még menne is a kitömörítése on the fly, bár nem ismerem az eljárást.
de amúgy szerintem valami tömörítéssel is lehetne próbálkozni, amit realtime le lehet játszani. pl asszem van olyan ami nem az abszolút, hanem relatív amplitudót tárolja és kevesebb biten. ilyesmit szerintem az EP is le tudna realtime
Egy 8 bites wav lejátszóra gondoltam, tudom ott az SNDPLAY, de úgy emléxem az 7 bites.
Olyat nem lenne érdemes csinálni, hogy a megszak rutinban csak egy egyszerű lejátszás megy egy kis bufferből
A zip (deflate) tömörítése hasonló az epcompress -m0 algoritmushoz, és EP-n hang lejátszáshoz valószínűleg túl lassú lenne.Csak lustaságom miatt néztem a ZIP-et, azt a leggyorsabb letesztelni, hogy mennyit tömörítene az adaton , hát láttam, szinte semmit :)
Az sndplay csak 7 bites, mert nem használ mono lejátszáshoz két csatornát (illetve mindkét oldalon pontosan ugyanaz a kimenet), és a gyakorlatban elsősorban a kezdetleges veszteséges tömörítés, az alacsony mintavételezési frekvencia, és az EP rossz minőségű analóg kimenete korlátozza a minőséget. Az IRQ rutin így néz ki egy és két csatornás lejátszáshoz:Akkor szerinted nem is érdemes a 8 bites lejátszást erőltetni?
A Dave-ből mindenképpen 2x6 bit jön ki, és megy a D/A ellenállásokra :oops:De ez csak akkor igaz, ha D/A módban használjuk a 0-ás csatornát , nem?
Akkor szerinted nem is érdemes a 8 bites lejátszást erőltetni?
Nem, fizikailag jön ki ennyi, lásd bal felső sarok a rajzon. (http://enterprise.iko.hu/schematics/EP64-2~1.jpg)Akkor parasztvakítás a 2x4 6bites hangerő, mert ha az egyik oldalon van 10, 10, 30, 63 hangerő beállítva, akkor a Dave-ből nagyjából 28-as hangerő jön ki, vagy ki tudja hogy számol pontosan, de ez a lényege, nem?
Belsőleg mixelheti le 6 bitre.
Annak is van értelme, csak én az SNDPLAY-ben nem próbálkoztam vele, mert elsősorban az volt a cél, hogy alapkiépítésű (128K-s) gépen viszonylag hosszú hangot lehessen lejátszani többé-kevésbé elfogadható minőségen.Ezt teljes sikerrel , de szerintem a viszonylag elfogadhatót is embere válogatja, én úgy emléxem, hogy teljesen jó minőségű volt, amikor teszteltem, ez a nagyfrekvenciás 8bites memóriazabáló lejátszás akkor ötlött fejembe, amikor elkezdtem szórakozni egy speccy program átírásával (le is akadtam a zenénél :D ), és a beeperes zenét akartam Dave-esíteni, ez meg is történt, aztán meg arra gondoltam, hogy Samplékat játszok le a zene alapján, akkor jött ez a 8bites ötlet.
Akkor parasztvakítás a 2x4 6bites hangerő
Lehetne egyébként olyan módosított/továbbfejlesztett epsndconv és sndplay verziót készíteni, ami a tömörített formátumot 7 helyett 8 bitre dekódolja. Ez a halkabb részeknél javíthatna a minőségen.Én támogatom :) Sőt, esetleg akkor meg lehetne csinálni azt is, hogy támogassa a tömörítetlen Wav fájlok lejátszását is?
Nem, mert igaz ugyan, hogy a fizikai kimenet csak 6 bites, de a 4 csatorna időosztásos rendszerben működik, így több csatorna használatával lehetséges 6 bitnél nagyobb felbontást elérni. Azonban valódi gépen az analóg kimenetet megvalósító ellenállás hálózat meglehetősen rossz minőségű (pontatlan), ami jelentős torzítást eredményezhet, például előfordulhat, hogy az 1Fh szint magasabb, mint a 20h.értem, köszi a leírást, akkor tényleg van értelme a 8bites próbálkozásnak, csak vason nem szól olyan jól ,mint emulátoron, azért kíváncsi lennék, hogy EP-n hogy szól, sajnos lusta vagyok összeszerelni a jó öreg EP konfigom :oops:
Én támogatom :) Sőt, esetleg akkor meg lehetne csinálni azt is, hogy támogassa a tömörítetlen Wav fájlok lejátszását is?
A kicsomagolás mennyi időt vesz igénybe ?
4bites esetén 2 bájt kicsomagolása kb 51 órajelciklus , és ezzel majd feleződik a fájl mérete?
Nem, mert igaz ugyan, hogy a fizikai kimenet csak 6 bites, de a 4 csatorna időosztásos rendszerben működik, így több csatorna használatával lehetséges 6 bitnél nagyobb felbontást elérni.Trükkös! És ez milyen frekvenciával történik, Dave órajellel?
Azonban valódi gépen az analóg kimenetet megvalósító ellenállás hálózat meglehetősen rossz minőségű (pontatlan), ami jelentős torzítást eredményezhet, például előfordulhat, hogy az 1Fh szint magasabb, mint a 20h.Elvileg ide lehetne valami jobb D/A-t berakni, meg esetleg az analóg erősítőrészt is felújítani.
Trükkös! És ez milyen frekvenciával történik, Dave órajellel?
Tehát ha a pl az összes hangcsatornának a frekvenciáját 0001h-ra állítjuk, akkor egy oldalra már 3x6, és a másik oldalra már 3x6 bit megy, és egy kis trükközéssel, a zajcstorna bevonásával már 2x4x6, nem?
A zajcsatornán nehéz folyamatosan magas (nem zaj) kimenetet elérni, nekem ez csak másik csatorna "feláldozásával" sikerült, de akkor már nincs értelme, ha a felhasználható csatornák számának a növelése a cél.Felüláteresztő szűrő a zajral a 0-ás csatornával, nem jó, vagy akkor is bukjuk a 0-ás csatornát?
Felüláteresztő szűrő a zajral a 0-ás csatornával, nem jó, vagy akkor is bukjuk a 0-ás csatornát?
A szűrés nem szünteti meg a hallható zajt, csak halkabb lesz, de a lejátszott digitális hang is.Szuper, ebből is látszik mennyire értek hozzá :D
Ezt nem említi a dokumentáció, de például oszcilloszkóppal talán mérhető lenne.Igen, pont ilyen mérésre gondoltam.
off, annak idején egy rövid ideig programoztam amigát asm-ban, írtam rá egy kis demót (sajnos elveszett)
de egyvalamit nem értettem az amigában. attól lefagyott, hogy memóriát olvastam. miért lehetett ez?
62.5 kHz-es sztereó lejátszó 4 MHz-es gépre:Nem baj, hogy sok értelme nincs, a lényeg (legalábbis az én szemszögemből), hogy mit lehet :D
(Attachment Link)
Sok értelme ugyan nincsen, mert még 4 MB-os gépen is csak kb. fél percet tud lejátszani, és a bemeneti formátum (sndp625.bin file) fejléc nélküli 6 bites hangminta pazarló módon 8 biten tárolva. :oops: A file betöltése hosszabb ideig tart, mint a lejátszás. De megfelelően konvertálva (noise shaping használatával) jó minőségű, legalábbis emulátoron, igazi gépen valószínűleg problémát okozna a D/A konverzió torzítása.
Nem baj, hogy sok értelme nincs, a lényeg (legalábbis az én szemszögemből), hogy mit lehet :D
Ha valakinek van jó minőségű konvertálható 29-30 másodperces hangmintája, azzal ki lehetne próbálni, milyen az EP-s "hifi" hang, legalábbis emulált "ideális" hardveren. Esetleg még módosítani lehetne a lejátszót 7 bites 41667 Hz-es formátum használatára, ami másfélszer kisebb file méretet tesz lehetővé, de ehhez még optimalizálni kellene.Sztem kipróbálom valami MP3 átalakításával, majd feltöltöm.
olyat nem lehet hogy pl 5 bites, szoftveresen feljavítjuk realtime? :)
A 6 bites 62500 Hz-es hang már "feljavított" lehet, mert olyan dither (noise shaping) használatát teszi lehetővé, ahol a zaj nagy része a nem hallható 20000-31250 Hz tartományba kerül, és a hallható zaj alacsonyabb, mint az egyszerű 6 (vagy akár 7-8) bites konverziónál. A legtöbb modern DAC hasonló trükkel ér el akár 20-21 bites minőséget úgy, hogy az analóg kimenet ténylegesen csak néhány bites felbontású, de több MHz-es frekvenciát használ.
Rosszul gondolom, hogy pl egy egybites lejátszásnál (pl Speccy) el lehet érni úgy, vagy hasonlóan 8 bites lejátszást, hogy mondjuk a 8bites 20KHz-es samplét 160 KHz-en játszuk le, és minden sampléban lévő bájtot 8 1 bitesként kezelünk?
pl FFh-t 11111111 ként toljuk ki a beeperre, 8fh.t 10001111-ként, vagy 256 bit kellene hozzá még nagyobb sebességen, vagy ettől azért bonyolultabb?
8-nál több, de 256-nál kevesebb kellene hozzá. Mindenesetre 4 MHz-es CPU-n már a 160 kHz-es lejátszásnál is csak 25 ciklus idő lenne egy hangmintára.Naja, ezt nem számoltam, ez csak arra lenne elég, hogy toljuk az adatokat ki egy hangcsatornára, lapozás már felejtős is :lol:
Lustábbak kedvéért egy snapshot is :DEz nagyon jó!
play625.ep128s (3809.21 kB - letöltve 254346 alkalommal.)
Első.
Mondjuk nem is értem, hogy letiltott megszakítás esetén miért kéne megszakításnak bármit csinálni :oops:
Mondjuk nem is értem, hogy letiltott megszakítás esetén miért kéne megszakításnak bármit csinálni :oops:
Gondolom a letiltás alatt a CPU IRQ elfogadás tiltás van értve (DI), a hardver az ettől függetlenül birizgálja a processzor megszakítás bemenetét. Ebben az esetben a "várt" viselkedés az, hogy a HALT esetén a CPU megáll, ezután valamikor jön egy IRQ kérelem a hardver felől, akkor meg a CPU csak simán kilép a HALT állapotból, de nem kezdi el a megszakítási rutint, hanem folytatja a HALT utáni utasítással. Legalábbis ez a tipp. :) Ez szerintem kéne hogy menjen Z80 esetén. Persze a tuti a doksiban lesz.
Doksi meg hosszu, RTFM-hez kell egy rakas vallalkozokedv - mint mindig :)
Na, kerestem FM-et. A zilog Z80 CPU User Manual 2014-es kiadását (http://www.zilog.com/appnotes_download.php?FromPage=DirectLink&dn=UM0080&ft=User%20Manual&f=YUhSMGNEb3ZMM2QzZHk1NmFXeHZaeTVqYjIwdlpHOWpjeTk2T0RBdmRXMHdNRGd3TG5Ca1pnPT0=) dobta ki elsőnek az internet. A pdf 28. oldalán (is) van erről szó. Egyrészt azt írja, hogy HALT alatt NOP-okat hajt végre a CPU, ami meg nem egy órajel, tehát 1 ciklus pontossággal nem fog tudni ebből az állapotból kilépni.
Aztán meg azt is írja, hogy a kilépéshez NMI kell, vagy INT és engedélyezett interrupt.
az a baj ezekről csak igazi ep-n lehetne eldönteni a minőséget
pc-n ügye a hangkártya feljavítja
Az EP hangkimenetének a torzítása miatt a zaj egy része a jól hallható tartományba kerülhet.Magyarán az a kérdés, hogy van-e valami jól hallható minőségromlás?
Magyarán az a kérdés, hogy van-e valami jól hallható minőségromlás?Sztem igen, bár én arra tippelek, hogy a hozzánk hasonló botfülűek nem nagyon vesznek észre semmit :D
a hozzánk hasonló botfülűek nem nagyon vesznek észre semmit :DÉn is ettől tartok :oops:
Csak azt kell megnézni, hogy EXOS 2.0 vagy 2.1+
2.0-ban B680h, 2.1-től B480h a kezdete (ha a rendszerszegmens a 2. lapon van).
Van-e vmi "egyszeru" mod arra, hogy "kinyerjem" az EXOS (sw text80 mode) es Nick (hw text40) mod altal hasznalt karakterkeszletet, es sajat celjaimra hasznaljam egy programban?Itt a wikin (http://wiki.enterpriseforever.com/index.php/IS-BASIC_tr%C3%BCkk%C3%B6k) alul van erre egy basic program. Assemblyben is biztos valahogy így kell, csak kicsit másképp. :D
Hat ez szuper, koszi. Csak ugye en mindig aggodom, ha EP-n fix cimeket akar az ember hasznalni (volt erre rossz pelda mar ...)
Csak dokumentált fix címet használó, de kevésbé egyszerű megoldás: a BFF4h címről olvasható az EXOS LPT kezdőcíme a 2. lapon, az első LPB pedig mindig a státuszsor 128 karakteres módban:
Na igen. Amugy Z80-ra is van hasonlo trukk, hogy legalabb ne teljesen off-topic legyen. Ha csak ritkan kell veletlenszam,akkor az R regiszter segithet tovabb randomizalni, mivel azt azert nehez megjosolni, hogy mi lesz benne, ha kozben lefut a fel vilagegyetem cimu kodreszlet, meg feltetelek stb vannak benne ... Nyilvan ha mondjuk minden masodik utasitasnal kell veletlenszam akkor az R egesz jol kiszamithato :)
Ja, én a Spectris-ben (spectrumról átírt 1kB-os Tetris klón) használtam az R-regisztert véletlenszám-generátorként, nem is jött be... :-) Ugye 7 különböző alakzat van, fogtam az R értékét, kinulláztam a felső 5 bitet, és ha nulla volt az eredmény, akkor újra vettem az R-t. Így volt egy "véletlen számom" 1-7 között. Meg is látszik a játékban, hogy baromira nem lett jó így, mert sokkal gyakrabban kapok "Z" formát, aminek 1 a kódja, mint a többi elemet. :-)
az LDIR utasításra azt írják, hogy 21 / 16 ciklus a végrehajtási ideje. Gondolom a 21 ciklus egy bájtra vonatkozik, a 16 pedig arra, ha BC == 0?
Logikusabb lenne _szerintem_ ha az LDI beken hagyna a BC-t, mert pl sok LDI egymas utan trukknel nem rontana el a BC-t. Az LDIR meg megfelelne egy LDI + looping-nak, ahol a looping resz intezne a BC-s dolgot. Ilyesforman lehet, egy sima LDI meg gyorsabb is lenne, mint most. Ehelyett, most maskepp van "felosztva", LDI magaban is butykoli a BC-t.
Az mondjuk nem vilagos amit irtal, oke, hogy a DE, HL is modositando az LDI altal, de ha kimaradna a BC nem lenne gyorsabb a csak LDI-t hasznalok jellegu felhasznalasnal?
Úgy értettem, hogy az LDI nem feltétlenül lenne gyorsabb, mint 16 ciklus, mert a +2 ciklus idő az utasítás végén valószínűleg a DE növelése miatt nem volt elkerülhető. A BC csökkentését pedig más műveletekkel párhuzamosan (pl. (HL) olvasása közben) is el lehet végezni.
Ez igaz, de a helyettesítés esetén kell egy push, ami előtt még a visszatérési címet is számolni kell.
A nem hivatalos utasítás készletben nincs jelen?Nincs. Újabb (Z80 kompatibilis) prociban sem.
egyébként milyen környezetbe,rutinba kellene a CALL HL, CALL IX, CALL IY?
valami generál egy HL értéket és azt hívja meg PL.:?
Tegyünk egy gondolatkirándulást:
Vegyünk egy multitaszkos OP rendszert, mint a sokat emlegetett SymbOS.
Mondjuk szeretnék futtatni egyszerre több pici programot, amik csak 300 Byte-osak, de nagyon sokan vannak.
Mindegyik relatív ugrásokkal bír belül. A karakteres kiíráshoz, vagy bill. bekéréshez pedig az OP rendszert hívja RST rutinnal. Tehát semmi abszolut címzés nincsen benne.
Ugye ilyenkor betöltöm a lemezről a programokat valahova. Meg a másikat megint máshova, míg a végén van 30 segédprogramom a memóriámban. Minden segédprogram helyét eltároltam egy tömbbe.
Hogy hívjam meg őket gyorsan, és kapjak visszatérési értéket, ha nincs CALL HL utasításom?
Természetesen újra hallom Zozo hangját, ahogyan javasolja a JR utasítást. De azért vegyük le a kalapunkat, és valljuk be, ez nem az igazi.
a betoltheto programokban van egy relokacios tabla, ami alapjan az OS at tudja irni a nem relativ cimzeshez kapcsolodo byte-okatErre egyébként az EXOS-nak van egy elegánsabb megoldása (relokálható fájlformátum).
Erre egyébként az EXOS-nak van egy elegánsabb megoldása (relokálható fájlformátum).
Ha jól emlékszem ezeket nem assembler módon oldották meg, még x86-on sem.
A probléma szerintem ott van elásva, hogy míg az x86-nál 16 Bájtos lapok voltak,vannak addig az EP-nél 16384 Bájt.
Mert a kis rutinokat "org 4000h" kezdéssel lehet fordítani és csak be kellene lapozni esetünkben az 1. lapra.
Mint ahogy használja is a 3. lapon az ~össze ROM C000h indítási, fordítási ponttal.
Csak a rutinok 16384 Bájt helyet foglalnak nem pedig 300 Bájtot.
nem hinnem hogy azon aggodtak volna, hogy pazarolunk-e egy lapot ROM-ra akkor is ha csak 300 byte kell neki abbol,ROM-nál nem, de RAM-nál igen, erre szolgál az említett 7-es fejlécű áthelyezhető rendszerbővítő, ill (a fájl formátum szinten azonos) 2-es fejlécű felhasználói áthelyezhető modul, amit pl. betölthető a BASIC bővítések használnak.
Na de mit csinál? Átír minden JP és CALL utasítás után található számot?Így is lehet mondani... lényegében igen, de nem csak ilyen utasításoknál lehet áthelyezhető cím.
Na de mit csinál? Átír minden JP és CALL utasítás után található számot?
geco, ez az az oldal, ahol az integer to ASCII konverziós rutin (is) van, erről beszéltem neked a találkozón:
http://map.grauw.nl/sources/external/z80bits.html#5.1
geco, ez az az oldal, ahol az integer to ASCII konverziós rutin (is) van, erről beszéltem neked a találkozón:Köszi szépen el is tárolom :)
http://map.grauw.nl/sources/external/z80bits.html#5.1
;WRITE(e)
;writes an INTEGER number
;input: e in HL
l05e5: bit 7,h
jr z,l05f5 ;jump, if HL>0
ld a,"-"
call WriteChar_L0112
or a
ex de,hl
ld hl,0
sbc hl,de
l05f5: ld iy,l061f
ld bc,0530h ;B=5 C="0"
l05fc: ld a,"0"
ld e,(iy+00h)
ld d,(iy+01h)
l0604: or a
sbc hl,de
jr c,l060c
inc a
jr l0604
l060c: add hl,de
cp c
jr z,l0614
call WriteChar_L0112
dec c
l0614: inc iy
inc iy
djnz l05fc
cp c
ret nz
jp WriteChar_L0112
l061f: dw 10000
dw 1000
dw 100
dw 10
dw 1
Ilyesmire egyébként ott van a Hsoft féle full extrás NUMSTR rutin gyűjtemény is.
Nem akarok teljesen hulyenek tunni, de milyen eletkepes alternativa van meg a 10-es kivonogatason kivul?
Ez meg az EXDOS-é:
Zozo, ezt te disassembláltad és kommentezted fől, vagy ez az eredeti IS kód?Ez az eredeti.
flag bitekkel kapcsolatban kérdeznék
a CP és SUB utasításoknál a Sign bit ugyanúgy lesz mindig beállítva (vagy törölve), hogy a Carry is, ugye?
Ez milyen assembler?
A simában nincs osztás, szorzás, "if then", legfeljebb makrózva.
Ez már egy magasabb szint.
A HL=HL-DE megfelelője is: sbc hl,de.
Csináltam egy érdekes statisztikát, hogy melyek a leggyakrabban használt utasítások.
Szerintem ez kb "pseudo-kod" akart lenni, azaz kozvetlenul persze nem fordithato igy le, ilyet csinal az ember, ha pl csak fejben kepzeli el elso lepesben, es meg ki sem probalta :) Gondolom en ....Értem.:)
Ez milyen assembler?Nem is kezdtem ORG -al
A simában nincs osztás, szorzás, "if then", legfeljebb makrózva.
Ez már egy magasabb szint.
A HL=HL-DE megfelelője is: sbc hl,de.
Gépi kódban, hogy tudok a 254-es szegmensre írni?Pl:
spoke 254,n,255 - ezt hogy lehet megoldani?
XI. rész: A DAVE-chip programozása (http://www.ep128.hu/Ep_Konyv/Exos.htm#240)
Feltételezem a Z80 assembly megy.
XI. rész: A DAVE-chip programozása (http://www.ep128.hu/Ep_Konyv/Exos.htm#240)
Egyéni szoc probléma, de vércikinek találom amikor olyat kérdezek amit saját magam is kideríthettem volna.[/s] Bocsi!
Pl:
code=z80
Szerintem egy fórumon nem "vérciki" kérdezniSzerintem sem. Én még emlékszem milyen volt kezdőnek lenni.
Szerintem egy fórumon nem "vérciki" kérdezni, de igazad van; ez az én szoc problémám...
Ebből sikerült arra az utólag tévesnek bizonyult következtetésre jutnom hogy megint valaki túl lusta.
... Én azt mondom, nem isznak a népek rendesen ! :)
Az EP emu-ba érdekes lenne egy ilyen statisztikát számoló részt belerakni...
(Attachment Link)
A debuggerben "Run" és aztán "Step" futtatja, minden 1000000. utasításnál kiírja a 10 leggyakoribb utasítás kódját, és hogy hányszor fordult elő.
Miféle "perverzióra" készülsz
Tegyél pontot a functionx alatti címkék elé, és a jr utasításban is a .-tal kiegészített címkét használd.
a 3 pont csak a ... akart lenni :ds_icon_cheesygrin:
Egyszerűen keresném a megoldást a kényelmes névválasztásra. Szeretnék valami ilyet:Ebben a konstrukcióban pontosan mi a probléma? Az hogy ütköznek a két függvényben a címkék nevei, vagy az hogy nem lehet rájuk pl.: Function0.LoopExt.LoopInt.LoopIntInt-ként hivatkozni?
Function0:
LoopExt:
LoopInt:
LoopIntInt:
jr LoopIntInt
jr LoopInt
jr LoopExt
ret
Function1:
LoopExt:
LoopInt:
LoopIntInt:
jr LoopIntInt
jr LoopInt
jr LoopExt
ret
Nem geco, nem gondoltam, hogy a három egymás alá írt pontod jelent bármit is.Bocs, nem vettem észre az egyik hozzászólásod, az miért fontos, hogy egy relatív címke az előtte lévő relatív címkéhez képest legyen relatív?
Értem, hogy mit mondtál a . -tal kapcsolatban,
és vagy nem igaz amit írok, vagy te nem értetted meg amit válaszként írtam.
Ebben a konstrukcióban pontosan mi a probléma? Az hogy ütköznek a két függvényben a címkék nevei, vagy az hogy nem lehet rájuk pl.: Function0.LoopExt.LoopInt.LoopIntInt-ként hivatkozni?
A példádból indultam ki, azt pedig jól lefedi a szimpla relatív címkés megoldás.
Egyszerűen keresném a megoldást a kényelmes névválasztásra. Szeretnék valami ilyet:
Function0:
LoopExt:
LoopInt:
LoopIntInt:
jr LoopIntInt
jr LoopInt
jr LoopExt
ret
Function1:
LoopExt:
LoopInt:
LoopIntInt:
jr LoopIntInt
jr LoopInt
jr LoopExt
ret
Ezt most nem ertem. Function0 es Function1 legyen ilyen label, a tobbi ponttal kezdodo.
Reusable labels
Itt idegesito, hogy emiatt cimket kell bevezetni
De ha beírhatnád ott lokálisan 600adikra is hogy "loop:" meg "jumpto:" vagy akármi, az ott helyileg tök értelmes, kifejező és frappáns lenne ... csupán végtelenségig ágyazható relatív cimke névfeloldás kellene ... akár mint a C++ névterek ...Akkor neked az LGB által említett "unnamed labels" lenne a megoldás, és láttam is ilyen megoldást egy z80 disassembly listában, úgyhogy biztos van assembler is ilyen.
Akkor neked az LGB által említett "unnamed labels" lenne a megoldás,
module function0
{
entry:
module loop
{
loop:
module loop
{
loop:
module loop
{
loop:
jr loop
}
jr loop
}
jr loop
}
ret
}
module function1
{
entry:
module loop
{
loop:
module loop
{
loop:
module loop
{
loop:
jr loop
}
jr loop
}
jr loop
}
ret
}
Mindennek szép formáját már említeni se merném :) :Code: [Select]module function0
{
entry:
module loop
{
...
Ehhez hasonlo cucc kene?
A "module" szerintem nem illik ide, az nem erre valo mar "filozofiaban" sem igazan.
Azt csak én nem értem, hogy minek kell ezt így túl bonyolítani? :oops:Nem. :)
Akkor neked inkább valami Z80-as C fordító kellene ami tud inline assembly-t fordítani.
Azt csak én nem értem, hogy minek kell ezt így túl bonyolítani? :oops:
Azt csak én nem értem, hogy minek kell ezt így túl bonyolítani? :oops:
Nem minden ember zseni.
Mi a filozófiájuk egyébként ?
Szerintem a page-eknek tobb ertelme van,
:) Ez tipikus minden relativ dolog. Nekem a te peldaid alapjan tunik ugy, hogy azt atlatni ahhoz zseninek kell lenni, nekem a namespace ilyen hasznalata tunik eroltetettnek es tulbonyolitottnak, amit en nehezen tudnek kezelni a csopp eszemmel. Erdekes modon ezek szerint te pont forditva vagy ezzel, van ilyen :)
Teljesen egyetértek! :-)
Tehat filozofiai szempontbol
Mert pont nem érdekel a filozófia.
Játékot akarok (nó filó), leggyorsabban futót, legkisebb méretűt -> KÉNYTELEN vagyok assembly -ben lekódolni, leggyorsabban elkészülőt (zeró idő alatt) ->nem érek rá címkeneveket kitalálgatni és nem vagyok ufó, hogy a visz435435 címkéből egyből értsem hol vagyok és mi az, közben pont letojom mi a gépközeli mi sem ... :)
Pedig a C++ izgalmas dolog. Főleg amikor találgatod mit sikerült ilyen szépen elcseszni, hogy teljesen jónak néz ki, de a fordító meg ordít hogy na ezt ő aztán nem. A legizgibb dolog a template, főleg amikor valamilyen könyvtárat használsz, és a fordító dob a legjobb ötleteidre 3-4 soros hibaüzenetet, de olyat hogy a hivatkozott objektumokat sem bírod elkülöníteni csak 10 perces szemgúvasztással. :)
Aha. Akkor lehet neked nem is assembly kene.
saját oprendszert kell írni, csak azon lehet profin fejleszteni
sőt, saját hardvert
mert különben sose lesz játék
XD
azert fura valakinek
egy 'atlag' assembler tudasa
ahol fura=gyík.
egy átlag assembler -ben vannak relatív cimkék ?
label1: NOP
label2: NOP
labelREL = label2 - label1
Mi az a gyík?
az csak annak valo aki a CPU "fejevel" akar gondolkodni
kozvetlenul akarod hw szinten "uralni" a dolgokat
Ezt a fogalmat tovabbra se ertem igazan ... A relativ cimke defincio szerint azt jelentene, hogy a cim relativ? Ilyesmi?
ha hajlando lennel elfogadni, hogy az assemblerek ilyenek,
es megprobalni megszokni.
Lehet az is megoldás lenne egyébként a problémájára ha egymásba ágyazott makrókat használna a kódjában, mert akkor talán körbe tudná manőverezni a "relatív címkék" problémáját.
acsak megeshet az is, hogyl lehet namespace-be namespace-t ágyazni, mert ebben itt a kánaánod ;)
Én ezt nem értem ... miért pont 3 ? ? ? Kell itt lennie valami okosságnak ...
Mit akarsz mondani ? Szavadat nem értem ...ha namespace -be lehet namespace definíciót ágyazni, akkor megoldódott a problémád, de rosszul értelmeztem első átfutásra a leírást, szerintem egy fikarcnyival se vagy előrébb itt, mint a SJASM module, globális címke +lokális címke megoldásával.
Brass extends the module idea significantly. Rather than a simple bunch of root-level modules, Brass allows you to nest modules inside eachother.
This defines a local scope for normal label definitions. This way you can safely use 'standard' names for jump targets in included files without worrying about name collissions.
#local contexts can be nested.
Note: used but locally undefined labels are automatically pushed to the surrounding scope by
#endlocal and will finally reach the global scope, if they were not defined in an intermediate surrounding #local scope. There they can be picked up and resolved by the #include library directive.
Amiket írsz, abból már csak a kötőszavakat értem :oops:
Amiket írsz, abból már csak a kötőszavakat értem :oops:
Még nem jöttem rá, hogy a paletta 2. nyolc színét, hogy kell beállítani, ezért hiányzik egy szín a ruházatból :-)
A C fordítók egy áldás, a C++ meg az isten ... :)"This is why IMHO handing C++ to the average programmer seems roughly comparable to handing a loaded .45 to a chimpanzee."
Az a FIXBIAS. 0x80 port also 5 bit adja a felso 5 bitjet a masodik 8 szinnek a palettabol. Sajna csak igy "egyben" allithato ez.De célszerűbb az EXOS BIAS változóját használni:
Sajna csak igy "egyben" allithato ez.
Tehát ha jól értelmezem; színenként nem lehet csak 8-as fix színcsoportonként?
256/8 = 32 variáció ...?
Hello,Nem valami szép, és nincs agyonkommentelve :D
A forrást feltennéd valahova?
Akit érdekel, egy kis program,
ld bc, 0x8000
add hl, bc
Nem tudom, milyen topikba illik ez...
Ilyen játékot (https://www.youtube.com/watch?v=O_U65QkH_EU) biztos könnyen lehetne írni EP-ra is. Nagyon egyszerű a grafika.
de átírni is lehetne, ugyanis van specyre isÉrdemesebb lenne egyből EP-ra írni, így az EP képességeihez alkalmazkodna. Olyan veszettül bonyolult nem lehet az a pár scrollozó cucc megvalósítása, már amennyire értek én hozzá. :D
Érdemesebb lenne egyből EP-ra írni, így az EP képességeihez alkalmazkodna. Olyan veszettül bonyolult nem lehet az a pár scrollozó cucc megvalósítása, már amennyire értek én hozzá. :D
Nem tudom, milyen topikba illik ez...A régi munkakerülő blogon ezt a szemétparaszt kategóriába sorolták volna be.
Ilyen játékot (https://www.youtube.com/watch?v=O_U65QkH_EU) biztos könnyen lehetne írni EP-ra is. Nagyon egyszerű a grafika.
jaja, sokkal szebbet ki lehetne hozni, és mehetne 60 fps-el is:shock: 60? Hogyan?
:shock: 60? Hogyan?
van valakinek ötlete osztó rutinra?Úgy kell csinálni mint ahogyan mindig. Az előjelek alapján meghatározod az eredmény előjelét, veszed a számok abszolút értékét, az osztót fellépteted addig amíg még kisebb az osztandónál, aztán összehasonlítgatod és szükség szerint kivonogatod a visszaléptetgetett osztót, az elvégzett kivonásokat a hányadosban 1-es bittel jelzed, és minden léptetésnél lépteted a hányados bitjeit is. Amikor visszaállt az eredeti osztó és azzal is elvégezted a kivonást (ha kell), megkaptad a maradékot is. Annyi a kihívás, hogy nem tudod úgy tárolni, hogy a CPU egy utasítással tudja kezelni a 32 bites számodat, ezért az összehasonlításokat az alsó és felső szóra is el kell végezni az eredményük összegzésével, illetve a léptetéseknél a kicsúszó biteket át kell vinni az osztó kiterjesztett dupla szavának alsó és felső fele között.
32 bites előjeles egészt kell oszatni 16 bites előjeles egésszel
az eredmény 16 bites előjeles (ha nem fér bele, az nem baj)
meg persze kéne a maradék is 16 bites előjelesként
Ugy emlexem igy muxik, hasznaltam ma r parszor, de csak 99%-ra mondom.ja, úgy tűnik, működik, kipróbáltam... :-)
Nekem a DAA "trukkos" felhasznalasa kapcsan ez tetszett (0-15 konvertalasa hex ertekre ami kirakhato mint ascii karakter):Code: ZiLOG Z80 Assembler
AND $0F ADD $90 DAA ADC $40 DAA
Remelem jol emlekeztem ra fejbol :)
Ami már kezdetnél is nagy könnyebbség: nem ész nélkül disassemblál mindent, hanem megadsz egy belépési pontot, és onnantól "lefuttatja" a kódot, végig menve minden híváson, ugráson. Így már az elején elég jól elválik egymástól, hogy mi kód, mi adat.Na, ez nekem nem tetszett annyira, 6510-es forrást próbáltam megetetni vele, és egy csomó kódot nem talált meg, és a data részt is hiányosnak eléggé véltem :D , és megpróbáltam az adatokat 8-asával grouposítani, nem ment :( Nem tudom z80-ra mennyivel jobb, azt nem próbáltam.
Nemrég belenézegettem a Cyclone-ba és az Exolon-ba, és megtaláltam, hol vannak bennük a sprite-ok, illetve a pályák eltárolva. Ezen sikeremen felbuzdulva szeretném az Exolon-t felderíteni, hogy is működik az egész játék, esetleg módosítgatni ezt-azt. Z80 gépi kódban elég alap szinten vagyok, de nagyon érdekelni kezdett. Milyen segédprogikat ajánlotok ilyesmihez? Spekihez van a Skoolkit, de azzal nem sikerült még boldogulnom. Egyáltalán a Speki vagy az EP változatokat érdemesebb piszkálni?Talán megfelel az elvárásoknak.
org 1000h
DEC L
JR C,NULLAS
DEC L
LD E,H
LD BC,500H
JR C,EGYES
KETTES
LD E,5
EGYES
LD A,E
INC E
OUT (0B5H),A
IN A,(0B6H)
RRCA
RL C
DJNZ EGYES
JR VISSZA
NULLAS
LD A,8
OUT (0B5H),A
IN A,(0B5H)
BIT 6,A
JR NZ,UG
SET 4,C
UG
LD A,7
OUT (0B5H),A
IN A,(0B5H)
BIT 3,A
JR NZ,UG1
SET 3,C
UG1
BIT 1,A
JR NZ,UG2
SET 2,C
UG2
BIT 5,A
JR NZ,UG3
SET 1,C
UG3
BIT 2,A
JR NZ,UG4
SET 0,C
UG4
LD L,C
RET
Ezt BASIC ALLOCATE építeném. org 1000h
DEC L
INC L
JR Z,NULLAS
DEC L
LD E,H
LD BC,500H
JR Z,EGYES
.
.
.
KETTES
LD E,5
EGYES
LD A,E
INC E
OUT (0B5H),A
IN A,(0B6H)
RRCA
RL C
DJNZ EGYES
JR VISSZA
NULLAS
KETTES
LD E,5
EGYES
LD A,E
INC E
OUT (0B5H),A
IN A,(0B6H)
RRCA
RL C
DJNZ EGYES
LD A,C
CPL
AND 1FH
LD L,A
RET
NULLAS
Asmon ban jóAz INC E rossz helyen van az OUT után kéne lennie, vagy ha előtte van ,akkor az E bemeneti értéke 0ffh, vagy 04h kellene legyen.Miért?
Miért?ja, bocs, nincs rossz helyen :D, a növelés előtt már beteszed A-ba :D
a DEC L nem állítja a C flaget, helyette használhatod aEz viszont nem volt rossz ötlet.Code: [Select]org 1000h
DEC L
INC L
JR Z,NULLAS
DEC L
LD E,H
LD BC,500H
JR Z,EGYES
.
.
.
ugy emlexem itt a forumon van ep verzio futtathato, de ha nem talalod meg, tudok kuldeni. A label problema meg azert van, mert minden az elso oszloban kezdodik, ami nem label, told be legalabb egy space-szel.Kösz, így már működik!
exos 5 esetében a 0100h alatti területre meddig nyújtózkódhatok?005Bh
exos 5 esetében a 0100h alatti területre meddig nyújtózkódhatok?
Ez így nem igaz.Ez így nem teljesen igaz.
ha di mellett fut a minden is,akkor a full memoriat lehet :-D , de ugyi akkor a soft reset is buko,Mivel az EXOS-t kiiktatod.
{
char x=4; // ezek csak a tömb mérete miatt vannak deklarálva
char y=4; // ezek csak a tömb mérete miatt vannak deklarálva
char tomb[4][4]; // nem inicializált
char i;
char j:
for (i=0;i<x;i=i+2)
{
for (j=0;j<y;j++)
{ tomb[i][j]=255;}
}
}
IndexRegiszter kezdőcím +
0. char x
1. char y
2. base address LOBYTE : char TOMB[i][j] - vegyük úgy, hogy a végrehajtáskor már valahova mutat
3. base address HIBYTE : char TOMB[i][j]
4. char i
5. char j
INIC_FOR_i:
LD(IX+4),0 ; for(i=0;.....)
FOR_i:
LD A,(IX+4) ;A <- char i
LD L,(IX+0) ;L <- char x
CMP L ;for(...;i<x;...)
JR C, END_FOR_i ; elöl tesztelt for_i addig hajtjuk végre a ciklust amíg igaz: i<x
INIC_FOR_j:
LD (IX+5),0 ;for(j=0;.....)
FOR_j:
LD a,(IX+5) ;A <- char j
LD L,(IX+0) ;L <- char y
CMP L ;for(...;j<y;...)
JR C, END_FOR_j ; elöl tesztelt for_j addig hajtjuk végre a ciklust amíg igaz: j<y
LD L,(IX+2)
LD H,(IX+3) ; HL <- base address of char tomb[][]
LD BC,HL ; BC <- base address of char tomb[][]
; most jön a tömb indexelt címének meghatározása: BASE_ADDR + 4*i + j
; elöször 4*i kiszámolása
LD A,(IX+4) ; A <- char i
SLA A
SLA A ; 2x szorzás 2-vel a tömb 2. dimenziója miatt, itt kicsit megdöbbentem, hogy a Z80 nem kérdi, hányszor akarok léptetni
LD DE,0
LD E,A ; DE <- 4*i
LD HL,0
LD L,(IX+5) ; HL <- char j
ADD HL,DE ; 4*i + j
ADD HL,BC ; BASE_ADDR + (4*i+j)
LD (HL),255 ; tomb[i][j]=255;
LD A,(IX+5) ; A <- char j
INC A ; A++
LD (IX+5),A ; for(........;j++)
JR FOR_j ; for(j... a növelés után visszaugrik elöltesztelésre
END_FOR_j: ; ciklus vége
LD A,(IX+4) ; A <- char i
ADD A,2 ; A=A+2
LD (IX+5),A ; for(........;i=i+2)
JR FOR_i ; for(i... a növelés után visszaugrik elöltesztelésre
END_FOR_i: ; ciklus vége
RET
Valaki meg tudná nekem mondani, hogy az Indexregiszteres címzés az összeadással mire jó?Nem tudom megmondani, de nekem úgy tűnik, mintha kifejezetten jól használható lenne felhasználó által definiált, összetett típusok kezelésénél. struct { típus1 mező1; ... };
PL: LD A, (IX+d)
tomby db 04h ;i
tombx db 04h ;j
tombstr defs tombx*tomby
ld hl,tombstr
ld bc,(tomby) ;i=4,j=4
ld e,b ;tombx
ld d,00h
ld a,255
fori push bc
forj ld (hl),a
inc hl
djnz forj ;j--
pop bc
add hl,de ;minden páratlan sort átugorjuk
dec c ;i=i-2
dec c
jr nz,fori
Most hogy írod LD BC,HL utasításon megint meglepődtem, mint amikor kiderült, hogy bit rotáló útasításnál nem lehet megadni, hogy hányszor végezze el.
Azt olvastam, hogy a HL regiszter, az a 16 bites akkumulátor. Erre kiderül, hogy nincs lehetőség ebből a regiszterből 16 bites értéket másikba tölteni?
Most látom, hogy csak a következő HL utasítások validak:
LD HL,nn
LD HL,(nn)
LD SP,HL
LD (nn),HL
Most ha kiszámolok egy memóriacímet, és LDIR-t akkarok használni, akkor nem tudom áttölteni a BC és DE regiszterekbe az eredményt?
De át tudom, csak 8 bitenként:
LD B,H (opcode 0x44)
LD C,L (opcode 0x4D)
Gondolkodtam, hogy ha a verem a cache-ben lenne akkor mennyivel gyorsulnának fel a dolgok.
Az a baj, hogy a Z80 verem utasításai a 16 bites mozgatásban kimerülnek. Nem lehet a veremből kivenni a 4. elemet hogy feldolgozzuk, aztán visszategyük. Emiatt az az érzésem, hogy rengeteg globális változó esetén inkàbb az indexregiszterek lesznek jól használhatók. Főleg azért mert az indexregiszterek által címzett memória közvetlenül is manipulálható. Pl matematikai utasítások végezhetőek el az ix által címzett memórián lévő érték és az akkuval. Tölthető a címzett memória bármelyik regiszterbe majd onnan vissza. Stb.
Persze lassú a jelenlegi állapotában, de ha kicserélem a Z80-at egy fpga-ra, akkor a cache-be töltöm az indexregiszter által címzett memóriát, és máris minden utasítás csak 2-4 ciklus lesz.
De mi volt pontosan. Emlékszel még?
org 1000h
...
...
DB 0EDh,xx
RET
RET
RET
RET
END
lefordítod ld hl,0 ;const
add hl,sp
inc (hl)
.i_63
ld h,0
ld a,2
sub l
ccf
jp nc,i_62 ;
ld hl,(_Control)
ld h,0
ex de,hl
ld h,0
call l_eq
jp c,i_65 ;
ld hl,(_Control+1)
ld h,0
ex de,hl
ld h,0
call l_eq
jp nc,i_64 ;
.i_65
ld de,_Joy
ld h,0
add hl,de
push hl
ld hl,105 ;const
push hl
ld l,4
add hl,sp
ld l,(hl)
ld h,0
push hl
call _Get_Joy
pop bc
pop bc
pop de
ld a,l
ld (de),a
jp i_61 ;EOS
.i_62
inc sp
ret
z88dk a következő assembly kódot generáltaA CCF nem clear carry flag, hanem COMPLEMENT carry flag.
Amit nem értek, a ".i_63" alatt 4 sorral a CCF utasítás. Elvégzi a kivonást, majd törli a flaget, végül ugrik, ha Carry=0. Márpedig a Carry a CCF után nulla lesz.
ne kelljen abszolút ugrást használnia, hanem elég legyen a relatív?A JP az abszolút ugrás, a JR lenne a relatív. (Jump Relative)
ORG 1000H
;open file for read
LD DE,fname
LD A,10 ; channel NR 10
EXOS 1
;page segment F4 to 1.page
LD A,0F4h ; first segment
chpage PUSH AF
LD c,0B1h
OUT (c),A ; page segments F4..F5..F6.. etc to 1.page
;load file to the selected segment
LD DE,04000H
LD BC,04000H
LD A,10
EXOS 6
POP AF
INC A
CP 0F9h ; until F8
JR C,chpage
LD A,10 ; close channel
EXOS 3
RET
NOP
NOP
fname DEFB 11,"TST4_EP.BMP" ; file name with lenght
NOP
NOP
LD c,0B1hÍgy egyszerűbb, és két bájttal rövidebb:
OUT (c),A ; page segments F4..F5..F6.. etc to 1.page
Nem is gondoltam volna, hogy 0-ás csatorna van. Basicben is megadhatom?Már maga a BASIC használja, az EDITOR van 0-ásnak nyitva.
A 17. és a 18. sor közé nem hiányzik egy LD A,L ?Code: ZiLOG Z80 Assembler
LD DE,fname XOR A ; channel NR 0 EXOS 1 ;page segment F4 to 1.page LD L,0F4h ; first segment chpage LD A,L OUT (0B1h),A ; page segments F4..F5..F6.. etc to 1.page ;load file to the selected segment LD DE,04000H LD BC,04000H XOR A EXOS 6 INC L CP 0F9h ; until F8 JR C,chpage XOR A ; close channel EXOS 3 RET
Összesen 6 bájt megspórolva. Nyilván jelen esetben tök mindegy :lol: de jobb már ez elején rászokni rövidebb és gyorsabb kód írására!
A 17. és a 18. sor közé nem hiányzik egy LD A,L ?Nyertél :oops:
Úgy emlékszem a CP 0F9h C flag=A-0F9h A változatlan.
Ha lemezre írni akarok, akkor EXOS 1 vagy EXOS 2 kell? Mi van ha a lemezen a fájl név már létezik?Exos 2
A 19. sor JR NZ,chpage esetleg ?Jó a jr c,chpage, ha a számláló eléri az 0f9h-t akkor nem lesz carry, előtte meg de,így az utolsó futás 0f8h-nál lesz.
Még egy kérdés. Kicsit hiányosnak érzem a Z80 utasításkészletet. Ha el akarok számolni 1-től 2115-ig, és közben valamit csinálni, akkor hogyan tudom leellenőrizni, hogy elértem az 2115-öt?Nem hiányos, ha a z80 utasításkészletét érzed hiányosnak, akkor vess egy pillantást a 6502-ére, de akár a 6809-ére is.
CMP (vagy SUB) utasítást használnék alapból, de ahogy látom ezek csak 8 bitre érvényesek.
ld bc,2115
loop push bc
futtatandó kód
pop bc
dec bc
ld a,c
or b
jr nz,loop
Nem hiányos, ha a z80 utasításkészletét érzed hiányosnak, akkor vess egy pillantást a 6502-ére, de akár a 6809-ére is.
egy lehetséges megoldás:Code: [Select]ld bc,2115
loop push bc
futtatandó kód
pop bc
dec bc
ld a,c
or b
jr nz,loop
ld bc,0
loop push bc
futtatandó kód
pop bc
inc bc
ld hl,2115
or a ; Clear carry because there isn't SUB HL,rr
sbc hl,bc
jr nz,loop
Még egy kérdés. Kicsit hiányosnak érzem a Z80 utasításkészletet. Ha el akarok számolni 1-től 2115-ig, és közben valamit csinálni, akkor hogyan tudom leellenőrizni, hogy elértem az 2115-öt?Vagy csinálsz egy CompareHLBC rutint:
CMP (vagy SUB) utasítást használnék alapból, de ahogy látom ezek csak 8 bitre érvényesek.
CompareHLBC:
ld a, h
sub b
ret nz
ld a, l
sub c
ret
CCF (Change Carry Flag?) does not clear, it inverts the CarryCCF = Complement Carry Flag
ld bc,0000h
loop push bc
futtatandó kód
pop bc
inc bc
ld a,c
cp 43h
jr nz,loop
ld a,b
cp 08h ;2115 = 0843h
jr nz,loop
Geco ez akkor azt jelenti, hogy 0 tól x-ig felejtsem el a számolgatást, és szokjam meg hogy x-től 0-ig kell visszafelé számolni?Nem a BC az csak a progidat futtatja annyiszor amennyiszer akarod