És, hogy miért is hoztam fel az előbbi cuccot?
Azért mert rá akarom venni Lgb-t, hogy írjon egy hasonlót, modern kiadásban
O jajj! Nem eleg nekem a C65 emulator?
amugy mit kapok erte, ha megcsinalom? FAT16-os EXDOS jo lesz
A történet ott kezdődik, hogy az EXOS, EXDOS, IS-DOS mint Microsoft Macro-80 Assemblerben készült (CP/M alatt M80.Com és L80.COM).
Ebben olyan bonyolult szintaktikák vannak, hogy nyugodtan nevezhetjük külön programnyelvnek, az IS fiúk lehetőségeket maximálisan kihasználták.
Most tenyleg nem azert, de nem lehet, hogy konyebb lenne egy konvertert irni az asm szintaxisra?
Vagy akar egy assembler-t is. Ez overkill-nek tunik, _DE_: ha jovoben te, vagy barki mas akar foglalkozni az EP eredeti forrasaival ez folyamatosan problema lesz. Nem lenne szebb akkor, ha egy szelesebb korben elerheto/ismert assembler-rel (aminek van "normal" valtozata ami pl akar PC-n is fut) is lehetne rajtuk dolgozni? Ui tegyuk fel, hogy van a post-odban szereplo CP/M emulator szeruseg. Annal - erzesem szerint - akkor is jobb/ismertebb/emeszthetobb lenne, ha nativ/ismert tool-okkal lehetne rajta tovabb dolgozni, nem? Speciel, mivel nem tudom milyen a szintaxis, persze nem tudom megmondani mennyire lenne trivialis pl sjasm altal hasznalt szintaxisra foritani, na meg mondjuk a link-eles az kulon erdekes tema ... De meg mindig van mas Z80 assembler is, ami azert letezik manapsag is, es ott a linkeles tenyleg kulon lepes (talan az sdcc altal hasznalt assembler is tud ilyet pl, igaz o belsoleg vmi intel hex format szeru vackot hasznal object file-nak, de tokmind1, hogy belsoleg hogy kezeli le, ha ettol meg mukodik .......).
EP-n ISDOS alatt sikerült is lefordítani ezeket, de valami förtelmesen lassúak, még 3000%-on futó emulátorral, és RAMDISK használattal is jó pár percig tart egy fordítás.
Valódi gépen valószínűleg több óra is lenne (majd egyszer lemérem ). Van olyan rész, ahol commentben bele is van írva, hogy csak ez a fájl 20 percig fog tartani.
Néztem, de ezeknek a programoknak nem készült PC-s verziója, a PC-s Microsoft Macro Assembler csak x86-ot tud.
Sőt nagyon úgy tűnik akkoriban egyáltalán nem volt PC-s Z80 assembler, ezért is vesződtek Brucék PC-s Z80 kártyákkal, amin mivel valódi Z80-on futott a cucc, pont olyan lassan futott mint ahogy most EP-n.
A németeknek/magyaroknak meg nem futotta Z80-as kártyára, ezért volt ez a szoftveres CP/M emuláló dolog. (Mondjuk az is érdekes kérdés, hogy egy 4.77 MHz-es XT-n futó emulált Z80 milyen gyors lehet...) Mondjuk ők teljes fordítást nem is csináltak, csak kisebb részeket.
Most az IS-DOS alatti fordítással az a baj, hogy FILE: nem használható, mindent rá kell tenni floppy image-re. Onnan aztán be a RAMDISK-be, meg a végén ki a RAMDISK-ből. És még így is bazi lassú, hiába a 2-3000%-os emulátor sebesség.
Xep128-al egyreszt lehet menne a FILE: mar ugye (EXOS 10 support/miegymas), masreszt ha meg nem, SD kartya emulacio? Igaz, Xep128-al nem lehet - jelenleg - gyorsitani az emulacio sebesseget (bar beleganyolhatnek hogy vmi ideiglenes nem tul szep modon akar legyen "warp" speed) ... Viszont ep128emu-ban van Zozo IDE emulacio nem? Valami Zozo nevu srac csinalta a hw-t ....
Az nem hasznalhato? ott lenne eleg hely akkor, mar ha csak a hely problemat nezzuk szigoruan, nem kene RAMDISK-elni, miegymas. Oke, ertem en, hogy meg 3000%-on is lassu, akkor lassu. Amugy most neztem a Xep128 altal hasznalt Z80 emulaciot, van erre egy teszt programom: ha csak a Z80-at kell emulalni, akkor a nem tul uj PC-men azt mondja, hogy ~450MHz-es Z80-nak felelne meg a real-time speed. Egy kis Xep128 ganyolassal lehet el lehetne erni, hogy adott billentyunyomasig vagy tudom is en, iktasson ki minnel tobb dolog emulaciojat, meg a real time tartasara vonatkozo idozitest, es akkor azert jelentosen gyosabb lenne, bar a fenti virtualis 450MHz orajelet biztos nem erne el, mert mindent kiszedni akkor sem tudok belole, vagy csak nagy aldozatok aran
Az előbbi CP/M emulátorral meg az a baj, hogy mai x64-es Windowsok alatt nem fut, csak DOSBOX-ban, ez is macerás, meg lassú. De a legnagyobb gond, hogy valahogy nem tökéletesen működik az L80 vele, nem bírja az EXDOS-t összerakni, mert kb az 5. fájlnál kiakad, hogy nincs ilyen file... gyanítom, hogy túl kevés megnyitott fájlt tud kezelni a CP/M emuláció.
Itt jön a kérés Lgb-hez
Tudnál-e olyan lebutított XEP128-at csinálni, ami alkalmas az M80 és L80 futtatására:
-Z80 emuláció mindenféle időzítés nélkül, fusson olyan gyorsan ahogy csak bír
-64K CP/M memória kell, pár CP/M változó beállításával
Mire gondolsz? Ami 0x100 alatt van, CBIOS, BDOS hivashoz cucc, I/O BYTE meg ezek?
Amugy "multkoriban" eppen sajat Z80-as "mini gepet" epitettem volna, de csak emulacioban lett valosag
Ott tapasztaltam, hogy egyes CP/M programokat futtathatova lehet tenni osszesen kb 1 darab CP/M hivassal is akar
Talan a BBC basic Z80 portja volt ilyen, vagy nem emlekszem mar. Oszinten engem az FCB es a file muveletek remitenek el, az a baj, hogy akkor mar nem trivialis messze, ha sajat BDOS-t akar irni az ember. Bar amugy jut eszembe, az nem jo, amit en is csinaltam, hogy siman felhasznalom a DR eredeti BDOS-at es irok egy sajat CBIOS-t?
Annak mondjuk a hatalmas hatranya az, hogy akkor CP/M lemezekkel (vagy hat image file-okkal, ha mar emulator) fog csak mukodni, sajat BDOS eseten meg ugye lehetne a normal filerendszer adott directory-jat kezelni file szinen .......... Az emlitett "sajat gep" emulaciojaban a CP/M is ment sajat primitiv CBIOS-szal, vagy hat mondjuk ugy, hogy neha "csuklott" 1-2-ot de "altalaban" ment
-program betöltve 100h-ra, ha 0000h-ra lép az kilépés. 0005h-ös BDOS hívásokat kell trapolni, és emulálni
-hívások: írás karakteres képernyőre, billentyűzet olvasás, fájl megnyitás/lezárás/törlés, szekvenciális írás/olvasás 128 bájtos blokkokban (Az M80-ban, majd még az L80-at is megnézem, van-e valami extra még)
Anyuuuu, nem akarok iskolaba menni, ize ... FCB-kkel szenvedni!!!!!
-a parancssor CP/M-es része átmásolva 0080h-00FFh-ra, hosszbájttal.
-Windowsos parancssoros EXE, képernyőre kiírás simán csak a "DOS" ablakban
Hmm. Ilyet egyszer irtam mar
Amikor CP/M emulatort akartam irni, magyarul egy "sajat" CP/M-et, BDOS+CBIOS implementacio nativ C kodban. Igaz en Linux/UNIX-ra irtam, hogy nativan illesztheto legyen atlag parancssoros UNIX kornyezetbe, mintha "nativ" program lenne a kerdeses CP/M program futtatasa. Volt par hasonlo projectem, pl a karakteres modban mukodo C64 emulator (ncurses, nc64), illetve a DOSRUN, ami Linux alatt vm86() syscall-al es sajat DOS implementacioval dolgzott (vegulis, hasonlit a DOSBOX-ra ilyen szempontbol csak az sima parancssoros kornyezetben is ment, anelkul, hogy sajat ablak kellene, illetve ncruses-t hasznalva a Volkov Commander elindult Linux alatt nativ nativ X terminal ablakban is akar, hogy latta a teljes Linux filerendszert - na persze mindez DOSBOX-ban amugy sokkal jobban megy, szoval sok ertelme nincs a dolognak ma mar ...).
Na, de: ott is azert buktam el, mert ez az alien FCB szornyedveny megfekudte a gyomrom. Foleg, hogy egyes programok trukkosen hasznaljak az FCB-t, minden apro implementacios dolgot kihasznalnak, miegymas. Mennyivel jobb a file handle fogalma amit a UNIX kitalalt, egy szammal hivatkozol a file-ra oszt kesz. Kesobb DOS le is nyulta, igy vannak benne FCB-szeru es UNIX-stilusu file funkciok aztan ...