Welcome, Guest. Please login or register.


Author Topic: EP128emu (Read 394202 times)

Offline lgb

  • EP addict
  • *
  • Posts: 3563
  • Country: hu
  • æðsta yfirmaður
    • http://lgb.hu/
Re: EP128emu
« Reply #750 on: 2016.October.13. 13:05:05 »
Ja meg annyi, hogy ahhoz kepest ami abban a "patkolt" ep128emu-ban volt SD-hez azert ujabb a mostani Xep128-ban levo SD cuccos, foleg, mivel pl ebben iras is van azota ......... Meg pl flash-eles az sd card cartridge flash-ehez. Meg meg par dolog, amit szerintem nem is commit-oltam meg github-ra sem :(

Offline Zozosoft

  • Global Moderator
  • EP addict
  • *
  • Posts: 14722
  • Country: hu
    • http://enterprise.iko.hu/
Re: EP128emu
« Reply #751 on: 2016.October.13. 13:37:03 »
Egy apróság: az EP64 TASMON configokban mehet már 4-5-re a TASMON, módosítva lett a gyorstesztje, hogy EXOS 2.0-val is menjen.

Offline Zozosoft

  • Global Moderator
  • EP addict
  • *
  • Posts: 14722
  • Country: hu
    • http://enterprise.iko.hu/
Re: EP128emu
« Reply #752 on: 2016.October.13. 14:45:24 »
A WD hiba javítva:
Működik is a WD vizsgálat, régi emuval not ready lesz, az újjal működik :-)

Offline lgb

  • EP addict
  • *
  • Posts: 3563
  • Country: hu
  • æðsta yfirmaður
    • http://lgb.hu/
Re: EP128emu
« Reply #753 on: 2016.October.13. 16:12:35 »
Bocsi, flood-olom itt a temat a hulysegeimmel :) Csak meg annyit, hogy az ep128emu "ganyolasom" SD temaban, es az Xep128-ban levo kod is _nagyon_ ronda, biztos jobb lenne inkabb ujrairni :) Marmint nekem is, csak mindig lusta voltam belefogni :-/ Ettol persze, folelem bele lehet tennie ep128emu-ba, GPL mindket project, szoval nem gaz, csak epp nem szep, nem is C++ meg stb :)

Offline Zozosoft

  • Global Moderator
  • EP addict
  • *
  • Posts: 14722
  • Country: hu
    • http://enterprise.iko.hu/
Re: EP128emu
« Reply #754 on: 2016.October.13. 19:21:18 »
Ha ez az IDE szektor olvasó rutin, akkor talán lehetne gyorsítani rajta:
Köszi az ötletet, majd a következő verzióba beépítem! Biztos lehet még mit optimalizálni rajta :oops:

Offline IstvanV

  • EP addict
  • *
  • Posts: 4822
Re: EP128emu
« Reply #755 on: 2016.October.13. 21:11:29 »
SD kártya hack az itt található forráskód alapján:
[ Guests cannot view attachments ]

Az image file az IDE secondary slave helyett választható, ami ebben a verzióban nem használható IDE lemezként. A lapozható ROM csak a 07h szegmens tartalma (16 KB, a többi FFh byte), az eredeti változattal ellentétben nem használ külön (fix nevű) file-t erre a célra. Ebből a csomagból az sd-cart-0.1-64k.rom a 04-07h szegmensekre töltve működik.

Egyéb változások:
- az IDE emuláció a VHD formátumú image-t akkor is elfogadja, ha nem .vhd a kiterjesztése
- az asmon15.rom minden konfigurációban a 4-5 szegmensekre kerül

Offline Zozosoft

  • Global Moderator
  • EP addict
  • *
  • Posts: 14722
  • Country: hu
    • http://enterprise.iko.hu/
Re: EP128emu
« Reply #756 on: 2016.October.13. 21:17:17 »
Itt a legutolsó SD ROM csomag, a 0.4 már működik IDE-vel együtt is.
De hamarosan készül újabb is, friss EXDOS 1.4-el ill. FILE 1.4-el (ahol ilyen is van a konfigban).

Offline lgb

  • EP addict
  • *
  • Posts: 3563
  • Country: hu
  • æðsta yfirmaður
    • http://lgb.hu/
Re: EP128emu
« Reply #757 on: 2016.October.13. 23:54:35 »
Az image file az IDE secondary slave helyett választható, ami ebben a verzióban nem használható IDE lemezként. A lapozható ROM csak a 07h szegmens tartalma (16 KB, a többi FFh byte), az eredeti változattal ellentétben nem használ külön (fix nevű) file-t erre a célra. Ebből a csomagból az sd-cart-0.1-64k.rom a 04-07h szegmensekre töltve működik.

:) Jo, azert megjegyzem am, hogy amit es ahogy betettem az ep128emu-ba (fix nevu file meg minden egyeb galadsagok) az egy gyors "szorakozas" akart lenni a reszemrol, hogy meg tudnam-e csinalni, szoval elnezest a ganyolasaimert, utolag is :)

Offline lgb

  • EP addict
  • *
  • Posts: 3563
  • Country: hu
  • æðsta yfirmaður
    • http://lgb.hu/
Re: EP128emu
« Reply #758 on: 2016.October.14. 08:12:22 »
Amugy itt a viszonylag friss sdext.c verzio a Xep128-bol ez github-on sincs meg kint. Egyreszt ez tud irni is, masreszt van benne VHD detect (en amugy nem is tudtam, hogy ilyen formatum kulon van a vegen azzal az info blokkal, csak akkor derult ki, amikor Zozo tesztelte, es sehogy nem jott ki a meret ...), illetve SD kartya "meretezes" ervenyes meretre (ha MS VHD forumatum, akkor ezzel viszont elrontja ...), meg pl ures image letrehozas is, egy RLE tomoritett "beepitett" image-rol (ez mondjuk nincs benne, include-olja), no meg flash-eles support. Ami van (es volt az elozoben is) fopen/fileno kerveredes az azert van, mert az Xemu specifikus open_emu_file() van hasznalva az image megnyitasara (ez megnezi pl az exe-vel kozos konyvtarban, aztan az SDL altal visszaadott "preferences directory"-ban, stb, legtobb dolog Xep128-ban ezen 'at" van megnyitva, am ez FILE *-t ad vissza file handler-nek (tehat fopen-t hasznal). Mivel ezek a pufferelt I/O miegymas funkciok tapasztalataim szerint nem tul elonyesek aztan image-nek (magyaran lassu), ezert aztan a fileno()-val lekerem a normalis UNIX file descriptorat a megnyitott file-nak, es utana mar azt kezelem read()/write()/lseek()-el. Az nagyon valoszinu, hogy ep128emu-ban messze nem ez lenne az idealis eljaras, lehet xep128-ban sem :-P

Ami - tobbek kozott - igen ronda ebben az az, hogy ugye adott SD parancsra a file muvelet "azonnal kesz", kb nulla (emulalt) Z80 orajelciklus. Szoval, ha van egy EP-s program ami SD kartyat olvas intenziven, akkor remekul elrontja az idozitest, hiszen itt azert libc, majd kernel funkciot kell hivni a file olvasashoz, ugyanakkor az emulator szempontjabol nem telt el ido :( Foleg, ha egymas utan olvas szektorokat szegeny EP-s program, akkor erdekes lesz ... A normalis megoldas az lenne, hogy adott ideig busy statuszt visszzadni, igy "belassitani" kicsit a dolgot, hogy valosagosabb legyen. Ehhez viszont normalisabban kene megirni :D Igy mos az a nagyon ronda trukk van benne, hogy:

z80ex_w_states(40);

Ezzel a CPU emulatorral elhitetem, hogy X orajelciklusikg tartott, igy "belassitom" normalis(-abb) szinte igy. Persze ez total hulye megoldas (mivel a valosagban persze nem a Z80 "all" ilyenkor amikor az SD dolgozna ...), a normalis a fenti lenne: beolvasni, de nem visszaadni az eredmeny, hanem egy ideig busy-t "szimulalni", aztan csak utana "kiszolgalni". Stb.

Ezeken, es azon kivul, hogy amugy is randa, meg az a baj a megoldassal, hogy esetleges hiba eseten (I/O error emulator szinten, seek-eles az image mereten kivul, esetleg read-only modban nyitott image-re iras) en az SD kartya parancsra adok vissza hibat. Na ezt lathatoan EXDOS/DISKIO/akarmi nagyon rosszul viseli, es onnantol _semmit_ nem hajlando csinalni, mindenre error-t ad, ez mondjuk nem tudom miert van. Gondolom a problema az, hogy amugy nem a parancsot kene "vissza-error-zni" ilyen esetben, mert van SD-nel (bocsanat, fejbol mar nem remlik pontosan) as mas jellegu hiba is, amikor a parancsot elfogadod, csak annak eredmenye az error. Azt viszont nehezebb a jelenlegi kisse szedett-vetett megoldassal megcsinalni, azt azert nem tettem eddig :) Mindig csak a lustasag, ehmm :)
« Last Edit: 2016.October.14. 08:28:09 by lgb »

Offline Zozosoft

  • Global Moderator
  • EP addict
  • *
  • Posts: 14722
  • Country: hu
    • http://enterprise.iko.hu/
Re: EP128emu
« Reply #759 on: 2016.October.14. 09:25:55 »
Ezeken, es azon kivul, hogy amugy is randa, meg az a baj a megoldassal, hogy esetleges hiba eseten (I/O error emulator szinten, seek-eles az image mereten kivul, esetleg read-only modban nyitott image-re iras) en az SD kartya parancsra adok vissza hibat. Na ezt lathatoan EXDOS/DISKIO/akarmi nagyon rosszul viseli, es onnantol _semmit_ nem hajlando csinalni, mindenre error-t ad, ez mondjuk nem tudom miert van.
Elvileg működni kéne :oops: Mondjuk rendes EXDOS hibakódok a 0.2 verziótól lettek :-) Sőt úgy emlékszem, hogy ezt a kártyán kívüli olvasást teszteltem is.
Egy bad sectoros kártyát is már begyűjtöttem a teszthez.

Amitől biztosan kiakad jelenleg, az a kártyacsere, utána not ready lesz, resetig. Ez nem is baj egyelőre, hiszen itt jönne a korábban tárgyalt partíciók újradetektálása, és egyeztetése az EXDOS-szal. Ehhez kell egy rakás belső átszervezés is, ami a 0.4-el már elkezdődött.
(Viszont a SymbOS már most is kezeli a kártyacserét, igaz neki egyszerűbb dolga van, mert csak primary partíciókat kezel.)

Offline lgb

  • EP addict
  • *
  • Posts: 3563
  • Country: hu
  • æðsta yfirmaður
    • http://lgb.hu/
Re: EP128emu
« Reply #760 on: 2016.October.14. 09:28:07 »
Elvileg működni kéne :oops: Mondjuk rendes EXDOS hibakódok a 0.2 verziótól lettek :-) Sőt úgy emlékszem, hogy ezt a kártyán kívüli olvasást teszteltem is.
Egy bad sectoros kártyát is már begyűjtöttem a teszthez.

Ja, csak _szerintem_ (nem teszteltem) egy valodi SD katya bad sector/akarmi eseten a data valaszban ad error-t. En meg egyszeruseg kedveert a command-ra mondom hogy error, szerintem ez zavarja, azaz a parancsot sem fogadom el hibaval ... Valoszinu, hogy valodi kartya a parancsot elfogadja, csak utana ad error-t, ami egy mas "hiba szint" az SD kommunikacioban teljesen.

Offline IstvanV

  • EP addict
  • *
  • Posts: 4822
Re: EP128emu
« Reply #761 on: 2016.October.14. 10:42:40 »
Mivel ezek a pufferelt I/O miegymas funkciok tapasztalataim szerint nem tul elonyesek aztan image-nek (magyaran lassu), ezert aztan a fileno()-val lekerem a normalis UNIX file descriptorat a megnyitott file-nak, es utana mar azt kezelem read()/write()/lseek()-el.

Az stdio lassúságának emulátorban nem sok jelentősége van, ha az emulált gépen 100 KB/s adatátvitel már nagyon gyorsnak számít. :) Ezért én nem is használom az Unix specifikus alacsony szintű függvényeket, csak akkor, ha a probléma nem megoldható stdio-val (pl. stat() használata). A pufferelés letiltható setvbuf()-al, bár ha a blokk méret kisebb mint a puffer, akkor valójában a puffer gyorsít. Egy egyébként nagyon lassú és elavult laptopon egy 900 MB-os - már cache-elt - file olvasása 512 byte-onként fread() függvénnyel pufferelés nélkül kb. 2 másodperc (0.3 user és 1.7 system), puffereléssel pedig 0.9 (0.3 user és 0.6 system). A read() a nem pufferelt fread()-hoz képest kb. 0.1-0.2 másodpercet gyorsít.

Quote
Ami - tobbek kozott - igen ronda ebben az az, hogy ugye adott SD parancsra a file muvelet "azonnal kesz", kb nulla (emulalt) Z80 orajelciklus. Szoval, ha van egy EP-s program ami SD kartyat olvas intenziven, akkor remekul elrontja az idozitest, hiszen itt azert libc, majd kernel funkciot kell hivni a file olvasashoz, ugyanakkor az emulator szempontjabol nem telt el ido :( Foleg, ha egymas utan olvas szektorokat szegeny EP-s program, akkor erdekes lesz ...

Ha valódi gépen az SD kártya nem igényel várakozást (azaz regiszter vagy port hozzáférések között nem kell legalább X us-t várni), akkor ez valószínűleg nem nagy probléma, szekvenciális olvasásnál egy "lassú" SD kártya is lényegesen gyorsabb, mint amit egy EP-s program követni tud. Én az IDE vezérlőnél nem emulálok semmilyen időzítést, bár a 0 időtartamú seek nem egészen felel meg a valóságnak. :) Nagyobb probléma, hogy a WD-nél sincs időzítés, ezt (és a lemez forgását stb.) csak a Plus/4-nél (1541) és korlátozottan a CPC-nél valósítottam meg. :oops:

Amitől biztosan kiakad jelenleg, az a kártyacsere, utána not ready lesz, resetig. Ez nem is baj egyelőre, hiszen itt jönne a korábban tárgyalt partíciók újradetektálása, és egyeztetése az EXDOS-szal. Ehhez kell egy rakás belső átszervezés is, ami a 0.4-el már elkezdődött.

Ez hasznos lenne az IDE.ROM-nál is (ha megoldható), mert most bármilyen image file csere vagy új megnyitása, illetve snapshot töltés után hidegindításra van szükség ahhoz, hogy az IDE meghajtókat lássa az EXDOS.
« Last Edit: 2016.October.14. 10:59:23 by IstvanV »

Offline lgb

  • EP addict
  • *
  • Posts: 3563
  • Country: hu
  • æðsta yfirmaður
    • http://lgb.hu/
Re: EP128emu
« Reply #762 on: 2016.October.14. 10:56:21 »
Az stdio lassúságának emulátorban nem sok jelentősége van, ha az emulált gépen 100 KB/s adatátvitel már nagyon gyorsnak számít. :) Ezért én nem is használom az Unix specifikus alacsony szintű függvényeket, csak akkor, ha a probléma nem megoldható stdio-val (pl. stat() használata). A pufferelés letiltható setvbuf()-al, bár ha a blokk méret kisebb mint a puffer, akkor valójában a puffer gyorsít. Egy egyébként nagyon lassú és elavult laptopon egy 900 MB-os - már cache-elt - file olvasása 512 byte-onként fread() függvénnyel pufferelés nélkül kb. 2 másodperc (0.3 user és 1.7 system), puffereléssel pedig 0.9 (0.3 user és 0.6 system). A read() a nem pufferelt fread()-hoz képest kb. 0.1-0.2 másodpercet gyorsít.

Hat nem tudom :) En tapasztalatbol mondom. Eloszor igy csinaltam meg Xep128-ban, es ha vmit nagyon toltott SD-rol kb 50% cpu-t zabalt es akadozott is. Atterve a sima read-re/fread-rol, 20% ala esett, es folyamatos is ... Kulonosen pl az SD audio player-nel ahol ugye multiblock-read SD command van.

Quote
Ha valódi gépen az SD kártya nem igényel várakozást (azaz regiszter vagy port hozzáférések között nem kell legalább X us-t várni), akkor ez valószínűleg nem nagy probléma, szekvenciális olvasásnál egy "lassú" SD kártya is lényegesen gyorsabb, mint amit egy EP-s program követni tud. Én az IDE vezérlőnél nem emulálok semmilyen időzítést, bár a 0 időtartamú seek nem egészen felel meg a valóságnak. :) Nagyobb probléma, hogy a WD-nél sincs időzítés, ezt (és a lemez forgását stb.) csak a CPC-nél és Plus/4-nél valósítottam meg. :oops:

Varni annyit kell, amig busy :) Marmint a command kiadasa utan a kartya (ha byte szinten nezzuk, mert SPI soros, dehat ugye az SD cartridge mar byte-ban adja neked ...) 0xFF erkezik addig, amig nem tudja adni a kartya az adatot. Utana jon egy 0xFE, ez a data token, jelzi vele, hogy most akkor adna az adatokat, amit kertel. Szerintem meg egy Z80 szempontjabol sem igaz, hogy "nulla ido alatt" kepes vegrehajtani egy read parancsot egy kartya ... Mivel en ennyire nem akartam tulszofisztikalni, ezert adok egyetlen egy 0xFF-et (a biztonsag kedveert, hatha vmi program nezki ki tudja), de utana mindig 0xFE jon (data token) majd mar az adat. Viszont tartok tole, hogy egy valodi gepen (ezt le kene amugy tesztelni!!!!!) azert tobb ideig lesz 0xFF, bar ez nyilvan kartyatol is fugg ... De mondjuk az az extrem eset is elkepzelheto (oke, ennek erteme nem sok!) hogy valami EP-s program kuld egy read parancsot a kartyanak, majd az eredmeny nem igazan erdekli, es kuld megint egyet stb. Ebben az esetben ugye egy valodi EP/kartya eseten az SD-n levu pici kis MCU csinalgatja a dolgat, no problem. Emulatornal viszont gond, mert mindegyik ilyennel lesz belole egy lseek() meg read(), ami mivel egyszalu az emulator, addig feltartja a gep emulalasat ... Ha meg igazan durvan nyomatja a program a cuccost, ez akar idozitesi gondhoz is vezethet. Azon elmelkedtem anno, hogy kulon thread-be tenni az olvasast, de sajnos ez sem tul nyero otlet, mivel egy mai modern multitask OS-nel eleg sok minden fut, lehet lesz "egesz sok ido" mire a masik thread eszreveszi h uj read request van, osszessegeben meg lassabb lenne mint egy valodi EP/SD kombo ... Amire meg gondoltam: non-blocking I/O hasznalata. Akkor ugye, ha a host OS nem tudja adni az adatokat visszkapom h meg varjak ... Raadasul ezt valami emulator idoziteshez hasonlitva (tudomisen osszes eddig felhasznalt cpu ido, vagy pl a Nick slot-ok szama, szoval vmi olyan ami amug is konyvelve van es miatta nem vezetek be uj idozitot/szamalalot, azt nem szeretem), mondjuk limitalom, hogy azert egy szuk ciklus ami nezi csak h jon-e a data token ne okozzon minden egyes opcode-nal majdnem egy host OS syscall-t, hogy megvan-e mar az adat, mert azert az megiscsak X szazezer-millio kozotti rendszerhivas masodpercenkent. Persze, lehet, csak en vagyok ennyire aggodos tipus, es nem kene ennyire feltenem egy modern PC-t, csak elbirja azt :-P

Offline IstvanV

  • EP addict
  • *
  • Posts: 4822
Re: EP128emu
« Reply #763 on: 2016.October.14. 11:20:27 »
Hat nem tudom :) En tapasztalatbol mondom. Eloszor igy csinaltam meg Xep128-ban, es ha vmit nagyon toltott SD-rol kb 50% cpu-t zabalt es akadozott is. Atterve a sima read-re/fread-rol, 20% ala esett, es folyamatos is ... Kulonosen pl az SD audio player-nel ahol ugye multiblock-read SD command van.

Itt szerintem valami más probléma lehetett, vagy ez valamilyen nagyon lassú fread() implementáció (Windows vagy OS X?). Ami biztosan gyorsított, az a sok debug printf() letiltása. :)

Quote
Ha meg igazan durvan nyomatja a program a cuccost, ez akar idozitesi gondhoz is vezethet. Azon elmelkedtem anno, hogy kulon thread-be tenni az olvasast

Egy 4 MHz-es Z80 CPU-n egy NOP utasítás is 1 us, értelmes programnak nem kellene 100% alá lassítani az emulációt egy mai PC-n, még akkor sem, ha az csak stdio-t használ egy szálon.

Offline Zozosoft

  • Global Moderator
  • EP addict
  • *
  • Posts: 14722
  • Country: hu
    • http://enterprise.iko.hu/
Re: EP128emu
« Reply #764 on: 2016.October.14. 11:35:34 »
valódi gépen az SD kártya nem igényel várakozást (azaz regiszter vagy port hozzáférések között nem kell legalább X us-t várni)
Nincs ilyen, 10MHz-en, 0 wait-tal is működik.
(A WD-nél egyébként van, most a WD vizsgálatnál elő is jött, be kellett rakni PUSH/POP várakozásokat a regiszter írás/olvasások közé, hogy valódi gépen is megbízhatóan működjön. Az EXDOS is inkább ezért nézi a 18h porton a WD DRQ lábát a status register helyett.)

Quote
Én az IDE vezérlőnél nem emulálok semmilyen időzítést, bár a 0 időtartamú seek nem egészen felel meg a valóságnak. :)
Ha CF kártya van rákötve, akkor már megfelel :-)

Quote
Nagyobb probléma, hogy a WD-nél sincs időzítés, ezt (és a lemez forgását stb.)
Viszont így nem kellett Turbo EXDOS meg turbó gép, hogy az 1.44-es lemezek is menjenek emu alatt. Szóval az adatátvitel maradhat így.
Viszont ha a fejléptetést a megfelelő ütemben kiadott hanghatással meg lehetne oldani, az tetszene :-) (Mint pl a Saint féle Atari ST emulátorban, vagy a közelmúltban készült magyar TAP34 emulátorban.)