Enterprise Forever
:HUN => Programozás => Topic started by: lgb on 2013.March.22. 20:05:30
-
Pontosan mit is szeretnél (Milyen méretű, felbontású kép?)
Azt amit csattoltam :) Mondjuk meg bugzik rendesen, kbd mappingban csomo hiba, nincs file I/O stb, de legalabb mar csinal valamit. Vagy irt mar vki ilyet? Na akkor sem baj, max gyakoroltam, ugy is eleg kezdo vagyok meg EP programozasban ... Koszi az eddigi segitseget is mindenkinek.
-
Izgalmas! :smt038
-
Nagyon jóóó :)
Hány KB memóriával emulál majd?
-
Nagyon jóóó :)
Hány KB memóriával emulál majd?
Marmint hogy milyen primot? Most eppen csak 32-est (azaz 16K RAM + 16K ROM), 48-as az mehetne, a 64-es komolyabb restrukturalassal esetleg (a patchelt primo romnak kene maga alol kilapoznia a dolgokat, ha kell vmi extra, most ez a 3-as lapon van allandoan az emulacio kozben, igy viszont az nem szabad). Vagy az EP-n kerdezed a memoriaigenyet? primo ossz memoria (RAM+ROM) + 16K. Ez utobbi szegemens ahol az en kodom van, nyilvan nincs "tele" az a 16K, erosen nincs.
-
A Primo memóriát kérdeztem, köfi :)
-
Nem is tudom, létezik-e még egy olyan 8 bites gép, ami ennyi másik gépet tud emulálni :-)
-
Nem is tudom, létezik-e még egy olyan 8 bites gép, ami ennyi másik gépet tud emulálni :-)
Azon gondolkodtam eppen, hogy C64-hez volt Z80 cartridge (C128-ban meg eleve volt Z80 built-in). Ilyen elven az lenne a fair, ha EP-hez pl lenne hw-es 6510 kulon :D Bar azert sok komoly ertelme nincs ... A Z80 cart C64-re is a CP/M miatt volt ugye, nem masert (pedig elgondolkoztam - van egy ilyenem amugy - hogy nemi plusz logikaval spectrum emunak is lehetne hasznalni C64-en, de mind1).
Viszont, hogy legyek off-topic teljesen: meg Jupiter ACE emulatort irnek EP-re, ami erdekelne.
-
A Primo memóriát kérdeztem, köfi :)
Ok, hirtelen azt hittem, hogy EP mem igeny a kerdes, hogy pl EP64-en menne-e. Amugy te ismered Primot kozelebbrol? En kevesbe, csak emulatort irok hozza, de sose hasznaltam primot amugy, csupan disassembleremmel :) ramasztam a rom-jara, es probaltam kitalalni h mit hol kene modositani benne hogy nemi trukkozes utan EP-n "fusson". Viszont egy primos velemenye azert erdekelne, mert van egy rakas dolog (amit kulon nem reszleteznek ebben a topic-ban, lehet uj topic kene?!) ami nem teljesen vilagos meg nekem ...
(Azert ez vicces mivel van egy Primo B32-esem amugy, csak epp sose hasznaltam meg, nem is biztos h mukodik).
-
Sajnos nem ismerem, utoljára általánosban volt a kezeim között, nem szerettette meg magát, minden egyes billentyűlenyomással megszenvedtem :D
Nézz körül itt, hátha van doksi: Primo (http://primo.homeserver.hu/)
Van is, a könyvek közözz hardver leírás :D
-
Sajnos nem ismerem, utoljára általánosban volt a kezeim között, nem szerettette meg magát, minden egyes billentyűlenyomással megszenvedtem :D
Nézz körül itt, hátha van doksi: Primo (http://primo.homeserver.hu/)
Van is, a könyvek közözz hardver leírás :D
Thx, ismerem az oldalt, meg nyilvan azert elolvastam vmit rola legalabb ... de igy is van par erdekes reszlet. Nem baj, majd beleaasom magam, elvegre EP-vel is ezt teszem/tettem, anno nem volt EP-m.
-
A hardver könyv 55. oldalán vannak a portkiosztások, szerintem csináld azt, amit én is a CPC emuban a file műveletes ROM résznél, hogy az egészet kitörlöd, helyette EXOS-ra bízol mindent.
-
Csináltam neki új topicot :-)
-
A hardver könyv 55. oldalán vannak a portkiosztások, szerintem csináld azt, amit én is a CPC emuban a file műveletes ROM résznél, hogy az egészet kitörlöd, helyette EXOS-ra bízol mindent.
WOW. Most nezem a reszleteket, egesz jo doksi (en csak feluletesen olvastam at) ROM belepesi pontok leirasa, disasm listingek stb. Erdekes, "nyugatabbra" gyartott gepeknel nem volt divat ennyire beavatni a usert a gep lelkivilagaba! En meg eddig szenvedtem es sajat magam disassemblaltam a primo ROM-ot, hogy legalabb annyira menjen mint most (billentyuzet pl). Igy azert egyszerubb nemileg.
-
Egy dolgot nem találtam benne, pedig fontos lenne, a billentyűzet ábrát, melyik sorban, hanyadik bit melyik billentyűt azonosítja. Nekem túl sok a hardver leírás benne :D
-
Egy dolgot nem találtam benne, pedig fontos lenne, a billentyűzet ábrát, melyik sorban, hanyadik bit melyik billentyűt azonosítja. Nekem túl sok a hardver leírás benne :D
00-3F I/O cimeknel az IN mindig ugyanazt adja mind a 64db portra funkciok tekinteteben, _kiveve_, hogy a legalso bitnek kulon jelentese van az I/O cimtol fuggoen: igy az adott sorszamu billentyu allapotat adja vissza. Azaz voltakeppen nincs keyboard matrix mint EP-nel, vagy ha van akkor az egyik dimenzioja 1 legalabbis :) A primo ROM pl szepen sorban lekerdezi mindegyik billentyu allapotat (na ezis meger egy miset, mire disasm alapjan rajottem mi a halalt csinal: arra jutottam h valoszinuleg a "vacak" kapacitiv jellegu mukodese miatt "tuskek" lehetnek, ezert minen billentyure egy allat ciklus van benne delay, meg szamlalo, hogy hanyszor erzekelt mit, stb ... brrrrrr, de azert az emumban ugy-ahogy csak mux mar!). Az emulatormban a 64db lehetseges "poziciora" van egy-egy byte (primo-to-ep keyboard mapping), aminek az also fele adja, hogy az EP B5-os portjara mit kell kiadni, a felso fele pedig azt, hogy hanyadik bitet kell figyelembe venni a B5-rol olvasva. Ez alapjan lesz beallitva az adott I/O porton a bit0, amihez a Primo ROM-ot meg-patch-eltem ertelemszeruen. Valoszinuleg emiatt lassu (bar valodi Primoval nem tudtam osszehasonlitani): ha az ember gyorsan gepel siman kimarad par leutes. Bar ezen nem is csodalkozom, elnezve a ROM disasm-ot, hogy mennyi ideig szenved mire egyenkent lekerdez minden gombot, minegyiknel delay, es egyenkent 128-szor ismetelve minden gombra ...
Otthon megkeresem, valahonnan kiolloztam a billentyu-I/O port megfeleltetest, amugy vmelyik primo fuzetekben volt. Csak epp nem tudom melyikben most hirtelen, megvan png-be lementve, hogy keznel legyen. Persze most epp nincs keznel :)
Btw, ha vkit erdekel, most epp ez van, innen le is toltheto amin eddig dolgoztam: http://eprimo.lgb.hu/ (http://eprimo.lgb.hu/)
Az erdekelne amugy, hogy ez megy-e igazi EP-n, csak emulatoron tudom tesztelni. Mivel egy alap EXOS LPT-t patchelgetek at, az adott LPB-re beallitott scanline szamokat valtoztatva, ezert nem lehetetlen h elszurtam, es futna a kep egy normal TV-n, bar igyekeztem jol osszeszamolni h korrekt legyen. Ahogy lattam ep128emu is korrekt ha nem stimmel, ott is fut a kep :) Kerdes, hogy mennyire felel meg annak, ha egy valodi TV-n nezne az ember ...
A hatter direkt kek :) Sajna A48 emu meg vmiert nem megy, pedig elvileg ebben a verzioban is menne, de valamiert nem jon ossze, ezert atugrom a kodreszletet jelenleg, ami alapbol A48-at emulalna, es csak akkor A32-ot, ha csak 1 szegemenst tudtam foglalni pluszban, es kettot mar nem.
A file I/O-nak meg nekiallok mostmar nem sokara vegre (hacsak meg nem szuletik a kisfiam kozben, ugyanis mar barmikor erkezhet lassan ...).
-
Igazi Primon se lehetett gyorsan gépelni :D, sőt. Már értem is, hogy miért, én eddig csak az érintőbillentyűkre gondoltam :) Nem lehet a bill lekérdező részt átalakítani? A delayeket kihagyva direktben lekérdezni a B5-ös portot? Pl írtad, hogy a Primo az ismételt portok segítségével kérdezi le az összes billentyűt a delay-es ciklus kihagyásával, és annak kiértékelésének módosításával.
Gratula :)
-
Igazi Primon se lehetett gyorsan gépelni :D, sőt. Már értem is, hogy miért, én eddig csak az érintőbillentyűkre gondoltam :) Nem lehet a bill lekérdező részt átalakítani? A delayeket kihagyva direktben lekérdezni a B5-ös portot? Pl írtad, hogy a Primo az ismételt portok segítségével kérdezi le az összes billentyűt a delay-es ciklus kihagyásával, és annak kiértékelésének módosításával.
Gratula :)
Valojaban kihagyhatnam, mivel a kerdeses reszt "klonoztam" az emulator kodjaba, es a ROM-ban JP-vel oda ugrok, tehat ott azt csinalok amit akarok :) Majd kiprobalom hogy mi van, ha total kihagyom a delay-eket, amde lehet pl keyboard repeat stb miatt nem lesz szep. Eleve a delay parametert RAM-ban tarolja, es ahogy nezem, neha atallitja, nem tudom mit akar ezzel pontosan elerni mondjuk ...
Amugy is a primoval az a "gond" amugy, hogy nem hasznal interrupt-ot belsoleg (IRQ) max ha CDOS-al egy commodore floppy vagy hasonlo van rakotve. Van periodikus megszakitas (minden tv felkepnel, 1/50 sec-enkent) de az NMI :) Ez meg ugye vicces, mert ezt emulalni nehez EP-n, hogy en periodikus NMI-t kerek ... Szoval jelenleg ezt total kihagytam. Erdekes modon igy is megy :) Tehat a keyboard scan nem interrupt handlerben van primon! Talaltam erre utalast, hogy vegulis az NMI csak arra kell primon, hogy lekerdezze a "reset" gombot (nem valodi reset tehat, csak annak becezik!), illetve vmi szamlalot novel a RAM-ban. Most azon gondolkodom, hogy interrupt-bol meghivom azt a reszt ami az NMI handler lenne a primon (kiprobaltam, szep fagyas lett belole), vagy pedig en - ismet csak klonozva - megcsinalom az adott szamlalo noveleset a ROM-ban levo kod szerint. Bar nem teljesen vilagos, mire kell neki az a szamlalo amugy :)
A file I/O meg azert erdekes, mert a Primo ugye azert nem EP :) Azaz nincs fejlett OS-e, mint EP-n az EXOS. Igy amit tenni tudok az max az, hogy a tape alacsony szintu rutinokat valahogy mappelem, vagy esetleg fixen az emulatorhoz kell "csattolni" egy tape emu file-t, es nem lehet EXOS/EXDOS szintu file-okat emubol kezelni, csak a csattolt tape file-on belul :( Ez azert is kerdeses, mert az atlagos PC-n futo primo emuk - ha jol nezem - a tape emu file-okat vegulis kb alacsony szinten hasznaljak mint ami a szallagon van, egyedul a szinron blokk nincs benne, de amugy erdekesen strukturalt felepitesu, es tobb "file" is lehet benne, stb. Szoval ezen meg gondolkodnom kell, hogy ezzel mi legyen. En azert szeretnem valahogy megtrukkozni, hogy ne "csattolj egy filet" legyen, hanem az EXOS/EXDOS/stb "erejet" felhasznalva barmilyen file-t be lehessen tolteni az EP alatt futo primo emubol, az lenne a szep :)
A masik meg a primo "B" modellek kerdese ... Ott van normalis billencs, es a ROM viszont sokkal tobb ponton mas mint az A modellek kozott (ott ahogy nezem max a RAM meret miatt mas). A billentyuzet kiosztas is kulonbozo sajna pl. Viszont mivel nem kapacitiv a billencs, elkepzelheto, hogy ott mar nem teljesen olyan a kbd scan rutin. Plusz ott meg a CDOS, ami kozelebb lenne talan picivel az EP-hez, de CDOS-t csak nem implementalnek ha nem kotelezo, mert akkor mar lassan teljes commodore floppy emulacio is kene, az meg ugye egy full szamitogep (6502-es CPU-val, ROM-mal es RAM-mal), szoval az azert kisse nagy agyu lenne. Meg nem is sok embernek volt imho, tehat kerdeses, hogy erdemes-e ilyesmit akarcsak megprobalni is emulalni ...
-
Nah, megkerestem a billencs I/O portokat, en ezt talaltam:
http://eprimo.lgb.hu/primo_kbd_codes.png (http://eprimo.lgb.hu/primo_kbd_codes.png)
-
Úgy gondoltam, hogy a LOAD parancs kiadása után csak elvégez a PRIMO is bizonyos beállításokat, fájlnév tárolása, töltési cím, file hossza, és csak utána tölt, na, ha ezek megvannak, akkor ezeket az értékeket kibányászni, és EXOS hívásokkal file open, majd beolvas/ír, majd csatorna lezár. Csak a PTP-kből kéne kinyerni a külön fájlokat. Vagy rosszul gondolom?
Vagy esetleg még azt lehetne, hogy betöltés előtt egy valamilyen bill lenyomása után megadjuk a PTP file nevét és nyitjuk meg EXOS 1-gyel, majd beolvassa a névblokot (ami, ha jól látom, pont az EXOS számára is pont emészthető, file hossz byte, majd név), összehasonlítja a LOAD"" ban megadott file-névvel, ha stimmt, akkor elkezdi beolvasni az adatblokkokat, egészen a végéig, ha a PTP file végére ért, akkor lezárja azt, ha nem ért a végére, de egy másik PTP-t akarunk megnyitni, akkor a PTP kiválasztó gomb megnyomására először bezárja a csatornát, még akkor is kiadható a csatornára az EXOS 3, ha nincs nyitva.
-
Nah, megkerestem a billencs I/O portokat, en ezt talaltam:
http://eprimo.lgb.hu/primo_kbd_codes.png (http://eprimo.lgb.hu/primo_kbd_codes.png)
Tehát ha kiadsz egy in a,(00h)-t, akkor a billentyűzet bit az Y státuszát adja vissza?
-
Tehát ha kiadsz egy in a,(00h)-t, akkor a billentyűzet bit az Y státuszát adja vissza?
Igen, pontosan. Amugy Primo "egyszeru" gep ez mar az I/O cimdekodolasan is meglatszik, az egesz I/O port tartomany (na jo, a 8 bites also fele, mert mint tudjuk elvileg lehetne 16 bites I/O cimeket is hasznalni ...) 4 fele van osztva, es nincs tovabb dekodolva ... Egyedul a "BE-1"-nek nevezett 00-3F tartomany tunik kulonlegesnek annyibol, hogy ott szamit az konkret I/O cim a tartomanyon belul. Amugy a Primo ROM IN A,(C)-t hasznal, ez azert is jo, mert ugye ott patch-eltem meg a ROM-ot, es igy kvazi a C regiszter erteket nezem, es az alapjan talalom ki h melyik EP billencset kell nezni hozza a mar vazolt "mapping" tablam segitsegevel. Amugy miert kerded, te is primo emut akarsz irni, lesz konkurencia? :D
-
Úgy gondoltam, hogy a LOAD parancs kiadása után csak elvégez a PRIMO is bizonyos beállításokat, fájlnév tárolása, töltési cím, file hossza, és csak utána tölt, na, ha ezek megvannak, akkor ezeket az értékeket kibányászni, és EXOS hívásokkal file open, majd beolvas/ír, majd csatorna lezár. Csak a PTP-kből kéne kinyerni a külön fájlokat. Vagy rosszul gondolom?
Haat, amennyit eddig lattam (bar oszinten: meg nem is masztam bele elegge, csak "nezelodtem") a dolog nem ilyen egyszeru mert eleve pl irhatsz LOAD-ot is filenev nelkul ... A ROM-jaban vmi olyasmi van amugy, hogy megadhatsz neki ugyan nevet, de a kazettan akkor vegignez mindent ami egyezik, es ha az elso megadott karakterszamnyi egyezik, az nala mar OK, azaz ha a string nulla hosszu (LOAD parameter nelkul) akkor a kazettan a kovetkezot jelenti. Plusz, igazabol a ROM rutinok blokk olvasasra vannak irva primoban, marmint nem disk blokk, hanem van filename block meg data block stb, es ugy tunik ezt sok helyen hasznalja, kevesbe lehet megtalalni a "kapaszkodot" hogy valami felsobb szintu interfaced legyen ahol pl mar csak egy konkret filenevet adsz, o meg betolti es kesz. Na meg ugye, ha ezt meg is irna az ember: legyen egy jatek PTP-ben, ami utantoltos ... Akkor maris gaz, ha mi file szinten EXOS-hoz fordulunk, mivel az utantolto esetleg csak a kov adat blokkot kerni nev nelkul, azt nehez lesz belokalalizalni igy ...
Vagy esetleg még azt lehetne, hogy betöltés előtt egy valamilyen bill lenyomása után megadjuk a PTP file nevét és nyitjuk meg EXOS 1-gyel, majd beolvassa a névblokot (ami, ha jól látom, pont az EXOS számára is pont emészthető, file hossz byte, majd név), összehasonlítja a LOAD"" ban megadott file-névvel, ha stimmt, akkor elkezdi beolvasni az adatblokkokat, egészen a végéig, ha a PTP file végére ért, akkor lezárja azt, ha nem ért a végére, de egy másik PTP-t akarunk megnyitni, akkor a PTP kiválasztó gomb megnyomására először bezárja a csatornát, még akkor is kiadható a csatornára az EXOS 3, ha nincs nyitva.
Na igen, erre celoztam pont, amikor "egy PTP csattolasa" cimu eloadasomat vazoltam, es nem feltetlen 1:1 primo:exos file kezeles megvalositast csinal az ember ....
-
Amugy miert kerded, te is primo emut akarsz irni, lesz konkurencia? :D
Á nem, csak érdekelt, mert nem értettem, amikor a port táblát néztem, hogy 1 biten, hogy kérdezi le az összes billentyűt :D , amikor elkezdtél róla beszélni, akkor esett le :) Van egy csomó más elmaradásom, szépen lassan csak feldolgozom őket :D
-
A második megoldással a fejléc nélküli file-okat is könnyedén be lehet tölteni. Amúgy EP-n is van fejléc blokk, meg 4kb-os adatblokkok, ha magnóról töltünk :)
-
A második megoldással a fejléc nélküli file-okat is könnyedén be lehet tölteni. Amúgy EP-n is van fejléc blokk, meg 4kb-os adatblokkok, ha magnóról töltünk :)
Jo hat igen, csak ma mar ki "akar szenvedni" magnoval, retro feeling ide vagy oda :) Szoval a dolog azert is erdekes, mert PRIMO oldalrol ugye magnoban gondolkodunk (marmint azt kene emulalni) mig az emulator (EP/EXOS/stb) oldalan pedig valami 'fejletebb' OS szeru entitas all mar, nem olyan alacsony szintu. Szerintem marad a csattolasos jatek, az nem tunik bonyolultnak, max elsore eleg a read-only modszer, meg ha ugy menteni nem is lehet vele ...
-
A csatolós jó, csak lehessen csatolni az emuból is, mondjuk egy bill lenyomására a státusz sorba beírható a PTP neve, És onnantól EXOS 6-tal lehet olvasgatni belőle.
-
A csatolós jó, csak lehessen csatolni az emuból is, mondjuk egy bill lenyomására a státusz sorba beírható a PTP neve, És onnantól EXOS 6-tal lehet olvasgatni belőle.
Ja. Mondjuk en speciel arra gondoltam hogy a zozotoolsban is megtalalhato FILE-t hasznalnam file kivalasztasra. De ez nem gond, mert az emu ettol meg folytathato utana reset nelkul is!
Kozben viszont rajottem miert nem ment nekem a primo 48 emulacio: ugy tunik a primo oldalrol letoltott rom image 48-hoz nem korrekt. En meg az ott levo alapjan csinaltam a diffet a 32-es romjahoz kepest (par byte csak az elteres!) hogy patch-elje meg szepen, ha 48-at akar az ember emulalni. Most igy megy a 48-as emulacio is (32K RAM + 16K ROM). Amugy a PRI file-okat is lehetne nyomatni, bar ahogy nezem az mas emukban (PC-re marmint) is kb ugy megy h beleirja az emu maga a memoriaba, aztan csokolom, tehat nem o maga tolti be. Nem tudom ennek mennyi ertelme van ui elvileg konverter van a ket formatum kozott, en meg nem feltetlen szeretnek ket kulon formatumot tamogatni.
Persze az egesz emura igaz, hogy nem fog mukodni, ha olyan program fut, ami kozvetlenul I/O portokat bizeral, es nem a ROM-on keresztul csinalja (amit megpatch-elek az emuhoz).
Esetleg ha vkit erdekel, forraskodban is prezentalhatom az emulatort majd, legalabb ki leszek oktatva, mit csinalok rosszul vagy legalabbis nem a "standard" modon, mivel - mint mindig hangsulyozom - EP teruleten nem vagyok regi motoros hozzatok kepest.
-
Elég az egyiket támogatni, az elterjedtebbet, a másikat lehet konvertálni, nem egy nagy móka :) A memóriába írással csak az a baj, hogy nagyobb lesz az emulátor memóriaigénye. Forráskód engem spec érdekel, amúgy én se vagyok régi motoros assemblyben, 2006 környékén kezdtem el foglalkozni vele, és azóta se jutottam magas szintre :lol: