Tükröződés az az, amikor egy kisebb ROM chip van egy nagyobb címtartományra bepakolva, így több szegmensszámon is ugyanaz a tartalom látszik.ezt ertem ...
Pl gyárilag angol gépen 16K BASIC van a cartridge-ban, ami 04-07h szegmensek mindegyikén látszik.
Ugyanez a helyzet az EXDOS kártyán, ahol az EXDOS ROM 20-2Fh címeken látszik. Ahhoz több alkatrész kellett volna, hogy csak a konkrét szükséges címen látszódjon.
De nem is baj ez a spórolás, ez tette lehetővé, hogy amikor jöttek az egyre nagyobb ROM chipek, könnyen ki lehessen használni a területet.ezt mar nem ... mit segitett ez ? Ez egy hardware dolog, hogy a BASIC vagy EXDOS -t ugy sporoltak ossze, hogy nem csak korrekt helyeken, hanem meg X helyen latszanak... Igenyesebb hardver csak 1 helyne latszik, egyszeru meg sok helyen... ok, de mit konnyit ez egy nagyobb IC eseten ? Hat az majd eldonti hogy o igenyes vagy igenytelen hw lesz, es majd ott latszik, ahol akar, nem ?
Az EXOS 2.3-ban már minden címen keres ROM-ot, és egy 256K tartományban (x0h-xFh) ugyanúgy keresi a tükröződéseket mint az eredeti teszt a cartridge-ban, így kiszűrve azt, hogy kisebb ROM chip van a címterületen.Ez azt jelenti, hogy minden uj rom, binarisan el van kezdve osszehasonlitva az elozoekkel, amik csak mar be lettek mappolva ?
2.1-ben is lehet olyan ROM ami átnyúlik a x1h címre, de ez csak egy nagyobb program lehet, pl EXDOS 1.3 vagy ASMON, amik 32K-sak.Na es ez lett volna a fo kerdes: en ugy vettem eszre hogy egy 16K- nal nagyobb ROM is ugy van megoldva, hogy az tulajdonkepp N darab 16K- s rom. tehat egy 64K- s rom, az 4 darab 16k- s rom, kulon "rom header"- rel, meg ami abba van, "EXOS ROM", satobbi, ami le van irva az EXOS- ban. Szoval az az adott romokon mulik, ha ok egyutt akarnak mukodni, az EXOS kulon 16K bovito ROM szegmensnek fogja latni oket. Namost ezek utan ha egyszer az EXOS 21 csak a 10H- s cimen nezi a romot, akkor miert fogja bemappolni a 11H- t ? Mert ha azok nagy romok, irod, akkor lehet. De miert ? Mitol kulonbozik a nagy rom ? Egyebkent meg bonuszkerdes: es akkor ha nem latom el "EXOS ROM" headerrel a ROM- jaimat 16K- nkent, akkor az EXOS nem is lancolja be oket ? Ha igy van akkor egy asmon miert nem csak az elso szegmenset "EXOS ROM"- olja be, fizikailag ugyis tudja, hogy ha o a 20h, akkor a 21h az meg a masodik resze, anelkul hogy az EXOS bemappolta volna ...
nem csak korrekt helyeken, hanem meg X helyen latszanak... Igenyesebb hardver csak 1 helyne latszik, egyszeru meg sok helyen... ok, de mit konnyit ez egy nagyobb IC eseten ?Ahhoz, hogy az EXDOS csak 20-21h címen legyen, plusz IC-ket kellett volna még rárakni. Amikor nagyobb IC-ket kezdtünk volna belerakni, akkor ezeket kellett volna kivagdosni, átkötözgetni.
tenyleg az emu milyen tukrozodeseket emulal?Semmilyet. Megfelelő konfig fájllal (többször betett ROM-ok) lehet emulálni.
amiben EXOS 21 van, es egy asmont vagy ilyesmit siman mukodtet a 20,21 hexan.Hol van EXOS ROM header az ASMON másik felén? Max egy TEST ROM-ot láthatsz ott, mert ha fordított sorrendben van beégetve, és a cartridge elejébe rakva, akkor van benne gyors teszt.
Marpedig abbol csak az elsot kene bemappolja nem ? Vagy lehet hogy csak az elso (20h) van bemappolva, a masodik (21h)- ra tett eprom felben csak sportbol van az EXOS ROM header, mert azt ugyse keresi majd az EXOS ?
Arra akkor meg nem volt valasz, hogy a tukrozodes kiszurese akkor egy binaris osszehasonlitas az osszes tobbi rommal ?Az eredeti EXOS teszt az első 64 bájtot hasonlítja össze, 07h-04h szegmenseken.
RAM ugye ilyen modon nem tukrozodhet, ez csak a romoknal engedelyezett.RAM-nál nagy baj a tükröződés, címvezeték szakadás okozhat ilyen hibát. Az eredeti EXOS RAM teszt nem veszi ezt észre, a 2.3 tesztje igen (a jónak bizonyult szegmensek elejére beírja a szegmensszámát, esetleges tükröződés esetén ez felülírodik, a végén egy újabb menetben visszaellenőrzi ezeket, és csak az kerül a RAM listába ahol megörződött a beírt érték. Ezért pörög elsőként a TESTED számláló, majd végül az OK számláló).
Jol beszelek ?Igen.
A szoftver megszakítást nézik, pl az EXDOS-ból:
Ezek nem felhasználó parancsok, hanem ROM-ok közötti komunikáció:
"EXDOS",0FFH ;EXDOS bővítőktől az általuk kezelt meghajtók adatainak lekérdezése
"EXDOS",0FDH ;EXDOS bővítő utólagos beláncolása
"EXDOS",0FCH ;EXDOS bővítések hidegindítási inicializálása
"EXDOS",0FBH ;EXDOS bővítések melegindítási inicializálása
"BASICX" IS-BASIC bővítések lekérdezése
;reads one line from editor:
;input: -
;output: HL=15aeh (the typed line is copied here, last char is chr(0))
l037b: push bc
push de
ld hl,l15ae ;editor-puffer
push hl
l0381: ld a,121
exos 5 ;reads a char from editor: (#121)
or a
jp nz,ErrorEXOS
ld a,b ;A:=ascii code of char
ld (hl),a ;put it to (HL)
inc hl
cp 10 ;=LF?
jr nz,l0381 ;if not LF, then read one more character
dec hl
ld (hl),00h
pop hl
pop de
pop bc
ret
5-ös fejlécű program esetében a 100h alatti cimeken hol lehet garázdálkodni?Természetesen. És 5Ch-FFh is szabad.
értelemszerűen 30h 38h környékén nem, de mi van 0-30h-ig? Tehetek oda saját rutinokat, amiket majd RST-vel érek el?
Egy saját VIDEO: eszközt kell csinálni, ami így működik.De gondolom ez azzal járna, hogy a video eszköz összes funkcióját támogatnom kéne, ráadásul figyelnem kéne hogy a funkciók között hol és milyen módon hivatkozhattak a mindenkori "9. sorra" (bármivel, pld. karakterkészletmegadásnál(gondolom lehet a video eszközzel ilyet)), és azt valahogy ügyesen és kompatibilisen kezelni 8 sorosan ...
De gondolom ez azzal járna, hogy a video eszköz összes funkcióját támogatnom kéne, ráadásul figyelnem kéne hogy a funkciók között hol és milyen módon hivatkozhattak a mindenkori "9. sorra" (bármivel, pld. karakterkészletmegadásnál(gondolom lehet a video eszközzel ilyet)), és azt valahogy ügyesen és kompatibilisen kezelni 8 sorosan ...
Nem tűnik kis munkának ... vagy igen ?
A 0xc0 - 0xef -ig (192 - 239) karakterkódokat használja valamire az EXOS?Alapból elvileg nem, de lehet olyan új eszköz ami igen.
Amennyire tippelni tudok, a valasz igen, de azert megkerdezem: ha beallitottam warm reset cimet, es ratapadok a reset gombra, akkor a vezerles megkapasa utan foglaltak maradnak az altalam lefoglalt szegmensek (ideertve a "teljes" szegmenseket es esetleg a shared szegmenst is)? Logikusan igen, mert ugye az lenne a lenyege szerintem, hogy a memoriatartalom megmarad. A csatornak viszont bezarodnak, tehat pl volt nyiltva video channel, azt ujra meg kell nyitni.Igen. (http://ep128.hu/Ep_Konyv/Exos.htm#11)
Nem, az EXOS az átrendezi csatorna bezáráskor a maradékot, hogy egybefüggő legyen. Ha videólapok is érintettek a dologban, akkor ez látható is kis villanással a képen.
szep mely konyvtarstruktura vanEz már önmagában perverzség :-) aminél csak az nagyobb, hogy nem aktuális könyvtárból fájlt nyitni.
A masik dolog, ami EXOS kapcsan eszembe jutott kerdes, az a status line. Az mar regebben feltunt, hogy ha oda irok vmit, akkor nem latszik az eleje.Az eleje a billentyűzet kezelőé, odaírja, hogy CAPS/SHIFT/ALT ill. alapból a semmit. A vége meg az EDITOR-é, a szabad bájtokat írja.
hú ez komolyA perifériakezelőknek kell lennie puffer mozgatási alprogramnak, aminek az EXOS megmondja, hogy mennyivel mozgatta el a csatorna puffert, és a perifériakezelő ennek megfelelően regisztrálja át magának a tárolt címeit.
nem lehet erről olvasni valahol részletesebben?
Ez már önmagában perverzség :-) aminél csak az nagyobb, hogy nem aktuális könyvtárból fájlt nyitni.
Ha CD-vel belelépsz, akkor elég csak a fájlnév.
Az eleje a billentyűzet kezelőé, odaírja, hogy CAPS/SHIFT/ALT ill. alapból a semmit. A vége meg az EDITOR-é, a szabad bájtokat írja.
Tenyleg, az aktualis konyvtar teljes eleresi ut, arra EXDOS (ez mar ugye nem EXOS tema mondjuk) szintjen van limitalva, hogy milyen hosszu lehet?63 karakter
A perifériakezelőknek kell lennie puffer mozgatási alprogramnak, aminek az EXOS megmondja, hogy mennyivel mozgatta el a csatorna puffert, és a perifériakezelő ennek megfelelően regisztrálja át magának a tárolt címeit.
Ill. a videólap cím lekérdezésnél említi, hogy ügyeljünk arra, hogy ez változhat, így olyan művelet után ami EXOS puffer mozgatást okoz (pl csatorna nyitás vagy zárás), újra le kell kérdezni.
Ennél részletesebben az EXOS visszafejtésben :-)
Nem, az EXOS az átrendezi csatorna bezáráskor a maradékot, hogy egybefüggő legyen. Ha videólapok is érintettek a dologban, akkor ez látható is kis villanással a képen.Endi, nézd meg Itt (http://enterpriseforever.com/programozas/mit-lehetne-kihozni-az-ep-basic-bol/msg43037/#msg43037) a Snamber játékomban: amikor a program indulása után a "menüben" megnyomjuk a space-t a játék indításához, elég csúnyán tűnik el az attribútum képernyő. Már akartam is kérdezni, nem lehetne-e ezzel csinálni valamit. De most jut eszembe, ez lehet, hogy nem is amiatt van, amiről most írsz.
Endi, nézd meg Itt (http://enterpriseforever.com/programozas/mit-lehetne-kihozni-az-ep-basic-bol/msg43037/#msg43037) a Snamber játékomban: amikor a program indulása után a "menüben" megnyomjuk a space-t a játék indításához, elég csúnyán tűnik el az attribútum képernyő. Már akartam is kérdezni, nem lehetne-e ezzel csinálni valamit. De most jut eszembe, ez lehet, hogy nem is amiatt van, amiről most írsz.
az editor: nem erre való amiről írsz?
Editorbol tudod olvasni amit beleírtak. De mire kell ez a titokzatos funkció?
DIR-t olvastak úgy Basic másolók, hogy egy jó hosszú videólapra kérték, és arról olvasták be.
A legális ha csinálsz egy saját eszközt, az meg odarakja neked, ahova akarod.
Igen, de itt akadtam el, hogy egy sima header-5 user app-bol hogy tudok en eszkozt letrehozni? Olyat mar csinaltam egyszer teszt keppen, hogy sajat EXOS_ROM-os jatek, de ugye itt nem errol van szo.EXOS 21 (http://ep128.hu/Ep_Konyv/Exos.htm#68)
EXOS 21 (http://ep128.hu/Ep_Konyv/Exos.htm#68)
Cool. Es megszuntetni meg tudom? Vagy nem igazan, es vmi EXOS 0 szeru reset kell hozza?EXOS 0, bit 5 beállítva.
miért csak 1 karakteres az exos keyboard bufferje?Nekem ez tök jó, kevesebbet kell visszatörölni :D
szerintem tök jó lett volna ha több
azt észrevettétek amúgy, hogy a funkcióbillentyűk mintha más bufferben lennének?
azt észrevettétek amúgy, hogy a funkcióbillentyűk mintha más bufferben lennének?Szerintem a funkcióbillentyűk is ugyanabban a bufferben vannak, csak a billentyűt jegyzi meg a gép, utána ontja magából a szöveget, amit belőttünk a SET FKEY után, vagy ami alapból benne van.
azt észrevettétek amúgy, hogy a funkcióbillentyűk mintha más bufferben lennének?Nincsenek pufferben, az eltárolt funkcióbillentyű szövegre mutatót teszi el ilyenkor, és hogy hány karakter van ott, és aztán ez alapján adagolja a karaktereket.
Nincsenek pufferben, az eltárolt funkcióbillentyű szövegre mutatót teszi el ilyenkor, és hogy hány karakter van ott, és aztán ez alapján adagolja a karaktereket.
De ugyanezen alapon lehetne több karakter tárolós puffert belerakni, csak hely kéne a puffernek. Mondjuk egy módosított BRD-be bele lehetne rakni, az amúgy is foglal plusz RAM-ot.
létezik valahol olyan oldal a neten, ahol fönt vannak az ep128 default karakterkészlete, 8x9-es grid-del, és a kóddal (valahogy úgy, ahogy a demo kazettán volt a TEIL_3-ban)?Ezek nem jók? (http://www.ep128.hu/Ep_Util/Brd.htm)
nem, én olyasmire gondoltam, hogy ami kiírja azt is, hogy pl. SPACE=32,0,0,0,0,0,0,0,0,0Könnyen lehet ilyen programot írni, az a demokazettás program jó kiindulási alap.
meg egy ábra
Nem tudod elmondani hogy hol van a click hang, és mit kell átállítani hozzá ?Bár engem nem Zozónak hívnak, de itt van (https://enterpriseforever.com/sound/zeneprogramozas/msg30758/#msg30758). Viszont nem tudom, mit kell állítani hozzá. Aki ért hozzá, át is írhatja más hangra, pl. mélyebbre.
Bár engem nem Zozónak hívnak, de itt van (https://enterpriseforever.com/sound/zeneprogramozas/msg30758/#msg30758).És ebből is látszik, hogy max hangerő.
És ebből is látszik, hogy max hangerő.Viszont pl. mélyebbre lehet állítani, hátha az hangosabb(nak hallatszik). Már amennyire sejtem.
egy érdekes dolog: van egy sor, aminek az elejére állunk a kurzorral és a del-el elkezdjük törölni. nyomva tartjuk a del-t. ilyenkor az alapgépen nem frissítődik a sor, gondolom a sebesség miatt. csak amikor elengedjük akkor frissül.Igen, ez nekem többször zavaró is volt. Nem tudni, meddig kell nyomva tartani a gombot. Nem tudom, más gépeken ez hogyan van. Gondolom, nem így.
mellékeltem a snapshotot is, lestoppolva ez lesz az eredményEzt jól ki lehetne használni, pl. olyan játékban, ahol a föld alatt kell bóklászni, ahol sötét van, a föld felett pedig süt a Nap.
5-ös fejlécűnél semmi értelme.
Nezem a legveget, a peldaprogramot. Itt ugye egy 5-os fejlecu cuccos van, minden vilagos. Ami nekem ujdonsag itt az a legvege: "EXOS end-of-file module header".
Rémlik, hogy egyszer csináltam olyat, hogy valamilyen exos fejléccel rendelkező képfájl formátumot hozzáfűztem egy BASIC progi után, így a képet is betöltötte, de már nem emlékszem a részletekre...Olyan fájlokat amik nem veszik át végleg a vezérlést, simán össze lehet fűzni.
micsoda szép lehetőség ez a vírusoknak :)
amúgy volt egy vírus ep-n állítólag, erről tud valaki?
micsoda szép lehetőség ez a vírusoknak :)
amúgy volt egy vírus ep-n állítólag, erről tud valaki?
Tenyleg? :) Amugy C64-re pl volt ...
az ENTERPRESS-ben volt egy cikk egyszer, hogy valaki kapott valami vírust IS-DOS alatt, a vírusirtó forráskódját gyorsan le is közölte az újság :-)
Akkor az vmi CP/M virus volt? :) Vagy EP specifikus volt tenyleg?
Kicsit off kérdés: ha ezt a karakterkészletet szeretném felhasználni (például egy saját fejlesztésű PC játékban), annak szerintetek van valamilyen jogi vagy egyéb akadálya?
Enterprise-on kívüli felhasználásra gondoltam, pl. egy windows-os játékba beleraknám ezt a bitmap fontot, hogy Enterprise-szal nem rendelkezők is élvezhessék :)
Az, hogy hogy nyerem ki, ebből a szempontból lényegtelen. A ROM-beli tömörítést főleg saját érdeklődés miatt fejtettem meg, na meg azért, hogy biztos legyek benne, hogy a kinyert font "gyári" Enterprise-os, és szoftveresen nincs módosítva (pl. a BASIC induláskor nem definiálja át kicsit)
Azt ugy is elerheted (elvileg - ha nem tevedek), hogy nyomsz egy font reset-et a display csatornara a megnyitasa utan.
http://ep.homeserver.hu/Dokumentacio/Konyvek/EXOS_2.1_technikal_information/exos/video/Ch7.html#FONT
"7.3 Resetting the Character Font"
Lehet, hogy volt már, de nem találtam meg, ezért kiderítettem, hogy az EXOS ROM-ban hogy van eltárolva az alapértelmezett karakterkészlet.Egész pontosan így :-)
Egész pontosan így :-)
van ez a dolog EP-n, ami ha jól tudom egyedülálló, hogy a kurzormozgató gombokkal ferdén is lehet mozgatni a kurzort ha kettő gombot egyszerre nyomunk
nem láttam ilyet még más gépen
és ki is próbáltam, ha kiiratjuk a lenyomott gomb kódját, kurzor gombok esetén felváltva adja egyiket és másikat :)
persze valszeg annak idején ez azért nem tűnt fel, mert nem volt összehasonlítási alapom
pedig milyen egyszerű, de jó ötlet, más gépen is megcsinálhatták volna
ezt ügyebár csak emun tudjuk megtenni, vagy az EP szétszedett állapotában :)Vagy a Model 911-en :-) (http://ep128.hu/Album/Pic/Ep_PW360_1.jpg)
Vagy a Model 911-en :-) (http://ep128.hu/Album/Pic/Ep_PW360_1.jpg)
hajaj. ez hivatalos volt? :DIgen, bár csak prototípusig (http://ep128.hu/Ep_Hardware/Ep_Model_911.htm) jutottak, aztán csődbe ment a cég.
de itt egy trükk, kíváncsi vagyok ki fejti meg kilistázás nélkül :)Valamelyik újságban volt egyszer hasonló. A delay vagy a rate-t maximumra kell állítani, és amíg le van nyomva, addig folyamatosan érzékeli.
Valamelyik újságban volt egyszer hasonló. A delay vagy a rate-t maximumra kell állítani, és amíg le van nyomva, addig folyamatosan érzékeli.
1) BFEFh CRDISP_FLAG, amit 8-as akciókód : inicializálás esetén kell kezelni
2) 1-es akciókód : hidegindítás
3) Ezt teszi az EXDOS is az EXDOS.INI-vel (mondjuk legegyszerübb ide berakni egy LOAD parancsot)
lehetne olyat csinálni hogy beleírunk az exos lpt-be pár sort hogy ott is hang megszakítás generálódjon?A SOUND az a DAVE hangmegszakítással megy.
mármint hogy a sound: eszköz meghívódjon ott is :)
A SOUND az a DAVE hangmegszakítással megy.
és akkor dave-vel "sűríteni"?Nem lehet, mert fixen benne van a Dave-ben. Ha eltérő sebességű megszakítást akarsz, ahhoz fel kell használni egy hangcsatornát. Vagy még 1kHz lehetséges hardverből.
A SOUND az a DAVE hangmegszakítással megy.
Nem a video megszakítást használja az is ? Én úgy látom, az EXOS csak az INT1-et és az 1 Hz-es megszakítást engedélyezi, és például az LPT-ben egy második video megszakítást beépítve a BASIC PING parancsa hallhatóan gyorsabb lesz.
Nem a video megszakítást használja az is ?Érdekes... ez bug vagy feature? :-)
Btw, EDITOR ... Nem lehetne vmi "EXOS patch" :) hogy turbo EP-n ne legyen olyan gyors a kurzor? ;)SET CURSOR SPEED x ? :D
SET CURSOR SPEED x ? :D
Ez azonban szerintem hibas megallapitas, mivel ami kettes komplemens alapjan negativ, csak az szamit error code-nak, nem??Ilyen hol van írva? Minden ami NZ az hiba :-)
Ilyen hol van írva? Minden ami NZ az hiba :-)
Egyébként hibás a leírás, mert a 7Fh-t használja az EXOS maga...
Csak azt nem értem, hogyan hozod elő a problémát, amikor évtizedek óta 127 alatti kódokat használ minden nem IS program, és működik :-)
:LOAD FILE:nincsilyenfile
*** EXOS error type 9248.
Egyébként erősen azt gondolom, hogy fejlesztés közben csinálták az EXOS leírást, és idővel nem frissítették a régebbi részeket, lásd pl. hogy az általuk használt 127-es kódot elfelejtettek az ajánlásban.
Mit ertesz mukodes alatt?Azt, hogy vannak a hibák, szöveggel.
Azt, hogy vannak a hibák, szöveggel.
http://ep.homeserver.hu/Dokumentacio/Konyvek/EXOS_2.1_technikal_information/exos/constants/Ch3.htmlArról volt szó régebben, a homeserver-es oldalt inkább felejtsük el. Az egész tartalma megvan a gafz.enterpriseforever.com -on:
Arról volt szó régebben, a homeserver-es oldalt inkább felejtsük el.Azóta szereztem hozzá jelszót, ill. az ős 8bit.hu verzióhoz is, mindhármon azonos tartalom van.
Oke, de device-ok eseten? :)Izgi...
Izgi...
Itt valamiért ezt az EXOS hibát generálja, amihez nincs szöveg az EXOS ROM-ban:
err .NOBUF ;0F8h No ALLOCATE BUFFER call made (OPEN/CREATE)
Igen, ezt en is lattam. El is gondolkoztam rajta. Ugye open/create channel-nel a leiras szerint *kell* channel buffer-t allokalnia a hivonak ... En nyilvan nem teszem, abbol a felindulasbol, hogy eleve tudom, hogy ha amugy sem sikerult megnyitni a file-t, akkor minek.Ha megteszed, akkor már szépen működik a hibakód.
Vegulis nem nagy dolog, hasznalok majd 0x80 feletti error code-otAmi már mind stipi-stopizva van :oops:
Ha megteszed, akkor már szépen működik a hibakód.
Ami már mind stipi-stopizva van :oops:
Használhatod az EXDOS-os file not foundod (István féle is ezt teszi), a ROM-odba meg berakni rá ugyanazt a szöveget (Istváné ezt nem teszi :oops: )
Ez az egy meg csak egy szabálytalan eszközkezelővel jön elő :oops:
holott en nem akarok olyat mert NEM sikerult a muvelet ...De valódi gépen nem tudsz semmilyen műveletet végezni, ha nincs hozzá puffered. Ezt csak ilyen gépen túli, túlvilági módszerekkel tudod megtenni.
Felszabadítja:
Cool. De ha ez az en erdeti asm-om volt, az nem jo pelda, akkor bele kene rakni a teszt-hez az EXOS 27 hivast is!Beleraktam, és aztán írtam, hogy úgy működik :-)
Ezek szerint o ellenorzi, hogy foglaltam-e, ez valami biztonsagi intezkedes, vagy miert kell az EXOS-nak ez a "tudat" hogy megtettem?Igen, ez akkor is lefut, ha 0-át adsz vissza.
; The device descriptor chain is then searced for the required device and an
; error given if it is not found. If it is found then the appropriate entry
; point of the device is called. BUFFER_NOT_ALLOCATED is set non-zero which
; will allow the device to make an "ALLOCATE CHANNEL BUFFER" call to obtain
; its channel RAM. The device descriptor address is saved at CURRENT_DEVICE
; since the buffer allocation routine needs to know it to insert it into the
; channel descriptor.
;
; Having done all this the device OPEN or CREATE entry point is called and
; the return code returned to the user. If BUFFER_NOT_ALLOCATED is still
; non-zero then an error code is forced (unless the device returned a -ve
; error anyway).
Már eleve vannak konfliktusok :oops:
ZT átmegy majd 104-re, hogy ne legyen ütközés a Venus-szal, Entercom-ot pedig 119-126-ra kéne módosítani (elméleti kérdés, modem hw nélkül túl sokan nem fogják használni :-) )
192-206-ot meghagyjuk EXDOS következő verzióinak, Bruce pedig 50h-5fh (80-95), 80h-94h (128-148) használja EPNET-hez.
Összeszedtem az ismert kódokat. (http://enterprise.iko.hu/errors.htm)
Úgy nézem emulátor kódokat szerintem legokosabb lenne 1-től kezdeni, úgy tűnik azt a tartományt még senki nem nézte ki magának :-)
az alap EXOS filozofiaban ez nehezkes, mert ugye az explain error code hivasnak odaadvaVagy nem, mert direktben használja az értéket a program :-)
HEASS is egy szem software, es sajat kodokat hasznal, kvazi egy szinten azokkal az errorokkal amit maga az egesz EXOS/kernel ...Ezen én is meglepődtem :oops: HDIGI is ilyen...
Vagy nem, mert direktben használja az értéket a program :-)
Ezen én is meglepődtem :oops: HDIGI is ilyen...
Ha jól sejtem itt a kényelem volt az ok, nem kell foglalkozni azzal, hogy külső vagy belső a hiba oka, ugyanúgy érkezik rá a szöveg.
Majd megnézem a forrásban, hogy mit lehetne tenni ez ellen.
Hat igen, soknak tunik az a 255 az elejen :) Ha EP igazan sikeres gep lett volna, valoszinu, hogy ez a problema mar elojon elobb is :)Most Bruce támadott be pár tucattal :-) De akad még pár tucat szabadon.
Összeszedtem az ismert kódokat. (http://enterprise.iko.hu/errors.htm)Szép kis lista!
Most Bruce támadott be pár tucattal :-) De akad még pár tucat szabadon.
Aztán ott van az ENTERCOM, a dán modem kártya szoftvere, hw nélkül nem valószínű, hogy sokan fogják használni...
Venus-t se használ szerintem a mindennapokban senki.
OFF: És ilyen kellemes kis táblázatot hogyan lehet csinálni? Simán Word-ben?
table, td, tr html tag-ek, es kb eleg is hozza.Na, ez nekem kínai. Lehet, én az Excel-t választom inkább. :D
Spanyolul nem lesznek ott a hibaüzenetek?Spanyolnak ott a rublika kihagyva. Csak majd ami lista kijön EP-n, abban le kell cserélni a spéci karaktereket PC-sra. Magyarnál ez nem volt akkora gond, spanyollal meg kell még küzdeni :-)
OFF: És ilyen kellemes kis táblázatot hogyan lehet csinálni? Simán Word-ben?Microsoft FrontPage 2003
Microsoft FrontPage 2003
milyen jó lenne ha lennének olyan exos funkciók hogy az adott videólap memóriabeli címét visszaadja meg egyéb ilyesmi paramétereitSpeciális funkciókat nézted már? :oops:
@@SIZE = 2 - return mode & size of page
@@ADDR = 3 - return video RAM address
Speciális funkciókat nézted már? :oops:Code: [Select]@@SIZE = 2 - return mode & size of page
@@ADDR = 3 - return video RAM address
hol van ez leírva?A nagy EXOS könyvben:
ha jól értem nem exos hívás. vagy az?11-es EXOS hívás.
11-es EXOS hívás.
erre jó az EXOS 9?Igen.
EXOS 10 (http://ep128.hu/Ep_Konyv/Exos.htm#61)
De az csak fájlkezelő eszközökkel működik. EXDOS-szal, vagy az XEP FILE eszköze is tudja elvileg már. Az ep128emu FILE-je nem tudja :-(
Nem javitott EXDOS nem enged 2MB-nál nagyobbat.
Szerintem pont forditva, az alacsony van elöl. (Ha jól tudom Motorolánál van a magas elöl)
Az ep128emu FILE-je nem tudja :-(
Ha hazaertem, akkor tudok pontosabbat. Ami fejbol biztos: ha nagyobbra van allitva, akkor az EXDOS megnoveli a filet, nullakat irva a vegere.
Az EXOS 1-nél is irhato a fájl (ha nem irásvédett), ekkor 0. bájtról indul a mutató. Ha hozzáfüzni akarunk, akkor át kell állitani a mutatot a fájl végére.
EXOS 2-nél ha létezik (és nem irásvédett), akkor felülirodik, uj 0 bájtos fájl keletkezik.
- a "védelmi byte" hasznossága nem egyértelműAz EXOS leírás szerint: "Protection byte (yet to be defined)". Az EXDOS fixen nullázza a második 8 bájtot, így ezt is.
a zzzip vajon mennyire exos kompatibilis ezzel a call usr 6144 hívással?Kb semennyire :oops:
Kb semennyire :oops:
Kipróbáltam angol gépen 1088K memóriával már nem is indul el a zzzippelt program. Német gépen már 944K-val sem megy.
Egyéb bővítéseket most még nem is néztem.
amúgy basic betöltő minek neki? úgy értem a zzzippelt program esetleg meghív csak basic-ban létező rutionokat? egyáltalán ez lehetséges? úgy tudom csak exos hívások léteznek.BASIC-nak vannak saját hívásai, főleg az RST 10h-n, de az RST 08h,18h,20h is fel van használva. bővebben itt írnak erről. (http://ep128.hu/Ep_Konyv/Isbasic.htm)
BASIC-nak vannak saját hívásai, főleg az RST 10h-n, de az RST 08h,18h,20h is fel van használva. bővebben itt írnak erről. (http://ep128.hu/Ep_Konyv/Isbasic.htm)
És ahogy debugerrel gyorsan ránéztem, buzgón hívogatja ezeket. A fő lényeg az lehet, hogy előemészti az utasítás sorozatot, és egyből azokat hívogatja amit az interpreter csinálna, miután kielemezte az utasításokat, a hosszas elemezgetés marad ki. Plusz a bonyolult - ezért lassú - lebegőpontos matematika helyett van egy egyszerűbb egész számos.
aha... és ezek a basic hívások miért nem exos dolgok?Sajnos nem tudom rendesen kifejezni magamat, de azért, mert a BASIC nem EXOS, és az EXOS nem BASIC. Másként olyan lenne az Enterprise is, mint a Commodore gépek, ahol egyáltalán nem volt rendes operációs rendszer szerűen megoldva a bővítés. Hát komondort akarnál csinálni az EP-ből? :D Funkcionálisan független dolgokat – amennyire lehet – nem keverünk össze, mert rontja a rugalmasságot, és felesleges dolgok integrálásával szükségtelenül növeljük az erőforrás (itt ROM méret) igényt. Pl. ezért is szentségelnek bizonyos operációs rendszerek, vagy felhasználói programok kapcsán egyesek, mert a toronyórát lánccal is belegyömöszölik, aztán mindennek csak a töredéke van használatban.
Sajnos nem tudom rendesen kifejezni magamat, de azért, mert a BASIC nem EXOS, és az EXOS nem BASIC. Másként olyan lenne az Enterprise is, mint a Commodore gépek, ahol egyáltalán nem volt rendes operációs rendszer szerűen megoldva a bővítés. Hát komondort akarnál csinálni az EP-ből? :D Funkcionálisan független dolgokat – amennyire lehet – nem keverünk össze, mert rontja a rugalmasságot, és felesleges dolgok integrálásával szükségtelenül növeljük az erőforrás (itt ROM méret) igényt. Pl. ezért is szentségelnek bizonyos operációs rendszerek, vagy felhasználói programok kapcsán egyesek, mert a toronyórát lánccal is belegyömöszölik, aztán mindennek csak a töredéke van használatban.
Rájöttem mit kérdez Endi: miért nem fordít teljes gépi kódra (ami max EXOS hívásokat használ) a Zzzip.
Rájöttem mit kérdez Endi: miért nem fordít teljes gépi kódra (ami max EXOS hívásokat használ) a Zzzip.
meg az hogy miért érhetők el rts hívásokkal basic dolgok?Mért lenne logikus? Az RST-ket pont azért rakták a Z80-ba, hogy a gyakran hívogatott dolgokat oda tudják rakni a programok.
csak az exos lenne logikisan elérhető.
Mért lenne logikus? Az RST-ket pont azért rakták a Z80-ba, hogy a gyakran hívogatott dolgokat oda tudják rakni a programok.
Az EXOS lefoglalja magának a 30h/38h-t a többi szabad. A BASIC a sajátjait rakja oda, az IS-DOS a CP/M dolgokat, Spectrum átiratokban oda szoktuk rakni billentyű, joy lekérdezést, stb.
visszatérve az eredeti kérdésre, a zzzipnél akkor mi az a rész ami miatt nem exos kompatibilis?Szerintem pont emiatt nem EXOS kompatibilis... A fix cím miatt.
fix címre fordítja le magát azt látjuk. vagy valami ilyesmi van.
kérdés: az exosnak "hol" van a megszakítása, a képernyő tetején?Tekintve hogy a DAVE-nek van 50 Hz-es megszakítása, az EXOS megszakítás jöhet abból is. Nem mintha tudnám konkrétan hogyan van megvalósítva.
az ok hogy 50hz, meg gondolom video megszakítás. vagy ez se igaz?
Megnéztem, a képernyő alján, a keret kezdete után 14-16 sorral, és úgy látom csak Nick, Dave nincs.
exitApplication:
di
ld c, 0x40
exos 0
inc a
out (0xb3), a
ld a, 6
jp 0xc00d
Nem lenullázni kell, hanem rájuk definiálni valami karakterkódot.Tehát, ha hossz egyet állítok be, meg egy karakterkódot, akkor jó lesz?
Tehát, ha hossz egyet állítok be, meg egy karakterkódot, akkor jó lesz?Igen.
Igen.Köszi, erre nem gondoltam.
még sose írtam be hogy toggle border :)
most beírtam :)
Az élet apró örömei, na... :-)
még sose írtam be hogy toggle border :)Én már próbáltam régebben. Most is kicsit szórakozgattam vele:
most beírtam :)
ja amúgy erről most az jut eszembe, hogy hogy utáltam hogy nincs xor az ep basicben...
"Gépközeli" (de nem assembly) programozásra a legjobban talán a C nyelv használható, itt megfelelően támogatottak a különböző méretű és előjelességű egész típusok, a mutatók (POKE/PEEK helyett), és a bitenkénti műveletek (&, I, ^, ~, <<, >>).
ja amúgy erről most az jut eszembe, hogy hogy utáltam hogy nincs xor az ep basicben...
(A BOR B)-(A AND B)na ja
bor van :)Sör nincs?
tök jól nézett ki az EP felirat más karakterekkelGraphics 16 módban basicből is előállítható az EP felirat, előtte be lehet tölteni karakterkészletet.
Tényleg, az EP-t villogtató kódrész megvan valahol visszafejtve? Simán RND-vel váltogatja a színeket? Mind a 255 szín előfordulhat, kivéve a fekete? Vagy lehet fekete is?
Az R regiszter olvasásával generál véletlenszerű színeket 0 és 127 között.Érdekes, hogy 127 színt használ csak, nem mind a 256-ot. Lehet, nem nézne ki olyan jól? Pedig biztos jó lenne az is.
Érdekes, hogy 127 színt használ csak, nem mind a 256-ot. Lehet, nem nézne ki olyan jól? Pedig biztos jó lenne az is.
Meg lehet hívni vajon az EP feliratot kiíró és villogtató kódrészt úgy (pl. programból), hogy nincs újraindulás?
pl minden plot utasítás vizsgálja hogy melyik szegmensre kell írnia? vagy eleve lehetséges úgy grafikus oldalt kérni hogy egy szegmensen legyen? (a mutant test c. játékoban exos képernyőre rakok sprite-okat, de valszeg nem túl kompatibilis megoldással).
azon gondolkodtam, hogy vajon a hivatalos átiratok, sorcery, batman, wriggler stb exos képernyőt használnak vagy saját lpt-t?
wrigglerrel játszogattam (jó az extendedben a pálya léptetős cheat), és hát milyen szépen lehetne raszter színezni... :)
vajon lehet valahogy olyat hogy az esc szekvenciákat tartalmazó fájlt valahogy betölteni a memóriába, hogy ne kelljen mindig fájlból lejátszani?
lehetőleg ügye exdos nélkül, mert tudom, azon ott a ramdisk. (mekkora királyság lett volna ha alapból része az exdosnak a ramdisk...).
persze tudom, stringbe be lehet tölteni és azt szépen kiírogatni a csatornára, csak hát az valszeg tök lassú lesz.
BASIC-ben sok más lehetőség nincs, esetleg memóriába olvasni és onnan egy rövid gépi kódú rutinnal lejátszani. De a lassúság talán nem is nagy probléma ha a program egyébként is 250 MHz-es CPU-t igényel. :)
most egy demót írok ami 10 generált zenét tartalmaz, ahhoz kéne. ez sima gépen is megy. ki lehet választani 10 zenét.DATA sorokban tárold le, ami a kimentett ESC szekvenciákban van benne. Karakterenként.
na mindegy, akkor csak exdossal fog menni :)
DATA sorokban tárold le, ami a kimentett ESC szekvenciákban van benne. Karakterenként.
nem tehetem meg hogy hang esc szekvenciákat kiírok mondjuk egy szöveges képernyőre, majd onnan bármikor le tudom játszani get és hasonló parancsokkal kiolvasva...Nyithatsz 256 színű grafikus lapot, oda plottal kiírhatod a szekvencia éppen aktuális bájtjának megfelelő színkódokat sorban pontokként, és a look utasítással beolvashatod. De gondolom, kicsit sok helyet foglal. A look-ot ne használd önmagában paraméterek nélkül, különben Picasso alkotást fog mutatni a gép lefagyás előtt.
az a baj hogy nincs olyan csatorna fajta hogy "buffer". mert ügye nem tehetem meg hogy hang esc szekvenciákat kiírok mondjuk egy szöveges képernyőre, majd onnan bármikor le tudom játszani get és hasonló parancsokkal kiolvasva...
Az ALLOCATE utasítással lehetséges puffert foglalni, amibe utána EXOS 6 hívással lehet csatornáról olvasni, vagy EXOS 8 hívással csatornára írni. Ez néhány byte gépi kód. Példa ennek a használatára:
(Attachment Link)
Talán célszerűbb lenne, ha a visszatérési érték a ténylegesen olvasott vagy írt adat mérete lenne, ez hasznos ismeretlen méretű file olvasásánál.
igen, talán ez lesz a megoldás. remélem elég gyors lesz az esc szekvenciák küldéséhez.Gépi kódú rutinnál nehezen tudok elképzelni gyorsabbat :-)
Gépi kódú rutinnál nehezen tudok elképzelni gyorsabbat :-)
olyat lehet exos-al, hogy direkt video szegmenset igényelni?Szerintem ezt már többször is írták, hogy nem. Addig kell foglalgatni sorban a szegmenseket, amíg amit kapsz az videó szegmenst, vagy hibával ki kell lépni a programból. Persze a felesleges szegmenseket fel kell szabadítani.
Az ilyen módon foglalt szegmens természetesen nem lenne használható az EXOS VIDEO: eszközével, tehát BASIC-ben mindent POKE utasításokkal kellene rajzolni vagy kiírni. :)
azon gondolkodtam, hogy egy exos video sorban (tehát 9 pixel magas sor) változhat-e a videómemória szegmense?Az biztos, hogy lehetnek mixelve az LPB-k címei, és szerintem egy LPB címe is változhat szegmensek között, ha arról van szó.
mert elvileg megcsinálhatták azt hogy úgy választják meg a videólap kezdőcímét, hogy ezt kiküszöböljék.
ez azért elég hasznos lehetne.
vajon igaz lehet ez az állítás? exos alatt az lpt-t tartalmazó videolap mindig be van lapozva.
másik topikban van szó a relocatable kódról.a rendszerbővítő nem ilyen? az mindig a 3. lapon fut
na most arra emlékszem hogy van relatív ugrás meg ilyesmik, de más most nem ugrik be, hogy hogyan is kell megoldani (változók, memóriakezelés stb).
de nem is ez a kérdésem. hanem az hogy ügye a lapozással lehetne olyan "áthelyezhető" programot csinálni aminek nem kell relatív kódon futnia, igaz, így elfoglal mindig 16K-t, és ügye mindig csak megadott lapra lapozható be.
ilyet támogat az exos?
nem mintha akarnék ilyet csinálni, csak érdekesség...
Vagy elég csak 16 byte-nyi területet fönntartanom neki (ami bárhol lehet a nullás lapon), és annak a puffernak a címét írjam a DE-be?
kidobhatod a BASIC-et az ED-ből.mi az az ED? Vagy SD akart lenni? Benne van a BASIC???
mi az az ED? Vagy SD akart lenni? Benne van a BASIC???SD akart lenni :oops:
Tudsz olyan friss FLASH.ROM-ot küldeni, ami az első generációs SD-kártyához jó (nincs benne RTC), és van benne ISDOS is?A most béta tesztelődő EXDOS 3.0-val lesz ISDOS is (az már kihasználja a lapozható részt is a 7-es szegmensen).
a 4-5-re bármit tehetek?Az 4-5 az variálható, ha van EXOS 2.4 a gépben. (Amúgy is, csak akkor nem lesz BASIC, FILE meg gyorsteszt)
A másik kérdés: EXOS reset-kor kéne meghívódni a rutinomnak. Ez hogyan oldható meg? (meleg reset-kor is)Rendszerbővítőt (http://ep128.hu/Ep_Konyv/Exos.htm#38) kell írni, és aztán ott a 8-as akciókód.
Ha igen, akkor először mindenképpen az 1-es kód jár körbe, és a 8-as már nem fog? Vagy hideg-reset esetében mindkettő kód körbeszaglássza a bővítőket?Elsőként 7-es aztán 8-as, itt jön bejelentkező kép. Aztán jön az 1-es, ebben nézi az EXDOS az EXDOS.INI-t, majd pedig a BASIC indul (ha nincs más magától induló berakva).
Elsőként 7-es aztán 8-as, itt jön bejelentkező kép. Aztán jön az 1-es, ebben nézi az EXDOS az EXDOS.INI-t, majd pedig a BASIC indul (ha nincs más magától induló berakva).hm... akkor ha jól értem, ha induláskor (hideg reset-kor) ki akarom írni, hogy "hello", akkor ezt intézzem a 7-es kóddal (itt használnahatok-e szabályos videolap nyitást, vagy lpt-varázslat kell?), és ha nem kell egyébként RAM, akkor return-kor küldjem vissza a C-t változatlanul, (a többi regisztert elronthatom?), és ezek után még meg fog hívódni a 8-as akciókód is?
A BASIC-ben van ilyen, hogy ACCESS INPUT / OUTPUT, de ennek valójában mi a gépi kódú megfelelője?EXOS 1/EXOS 2
EXOS 1/EXOS 2és akkor ha jól értem, szükségem lesz egy byte-nyi csatorna RAM-ra is, amiben eltárolom, hogy most írása, vagy olvasásra van-e megnyitva a csatorna, és ez alapján hajtom végre pl. a blokkírás funkciót, vagy dobok egy hibát.
ha a blokkírás / olvasás implementálva van, akkor onnantól kezdve működik automaikusan a :load, :copy stb. parancs is az adott eszközre? (vagy a BASIC LOAD, SAVE?)Kell hozzá a karakterírás/olvasás is, de igen.
ill. másik kérdésem az EOF -val kapcsolatos. Maga az EEPROM 4kB-os, de ha csak pl. 1kB-nyi adat van rámentve, akkor honnét tudja majd az EXOS, hogy elérte a fájlvéget? Nyilván nekem (a saját periféria vezérlőmnek) kéne küldenie EOF hibaüzenetet, ha többet próbálunk olvasni az eszközről, mint 1kB (a példánál maradva). De ebben az esetben akkor úgy látom, nekem a fájlhosszt is le kéne menteni az EEPROM-ba, mondjuk pl. úgy, hogy azt az első két byte tartalmazná?Így van.
A Quadrillion Full a START programmal indítva valamiért gyakran lefagy, nem tudom, ez a START hibája-e, vagy EXOS bug az 5-ös fejlécű modul betöltésénél, régebben is volt hasonló véletlenszerű fagyás EXOS 0 hívásoknál. :oops: A 100h címet mindenesetre már nem éri el.
az EPDOS is csak ROM formában van megMeg betölthetőben :-) (https://enterpriseforever.com/programozas/epdos-fejlesztese/msg27081/#msg27081)
De ha csak simán betöltöd egy szegmensre, és nyomsz egy hideg resetet (C+Reset), a gyors tesztem megtalálja ROM szimulációként.Na, ez tűnik egyelőre a legegyszerűbbnek, és működik!
READ_BLCK:
; exos 6
ld a, b
or c
ret z
push de
in a, (0b1h)
ex af, af' ; save A
call SET_USER_SEGMENT
call rdChr
ld (de), a
ex af, af' ; restore A
out (0b1h), a
pop de
inc de
dec bc
jp READ_BLCK
; ======================================================================
READ_CHR:
; exos 5
call rdChr
ld b, a
xor a
ret
rdChr: ld a, CMD_RD_BYTE_EEPROM
out (port_PIC), a
jr $ + 2 ; wait 12T cycle
in a, (port_PIC)
ret
; ======================================================================
EXOS 6 valamiért nem lép ki EOF hibaüzenettel, amikor eléri a fájlvéget...Az ide betett kódodban nincs EOF vizsgálat :oops:
Az ide betett kódodban nincs EOF vizsgálat :oops:tudom, azóta változott:
; ======================================================================
READ_CHR:
; exos 5
ld a, (ix-1)
or (ix-2)
ld a, 0E4h ; End of file
ret z
call rdChr
ld b, a
xor a
ret
rdChr: ld a, CMD_RD_BYTE_EEPROM
out (port_PIC), a
jr $ + 2 ; wait 12T cycle
in a, (port_PIC)
inc (ix-2)
ret nz
inc (ix-1)
ret
; ======================================================================
READ_BLCK:
; exos 6
ld a, b
or c
ret z
ld a, (ix-1)
or (ix-2)
ld a, 0E4h ; End of file
ret z
push de
in a, (0b1h)
ex af, af' ; save A
call SET_USER_SEGMENT
call rdChr
ld (de), a
ex af, af' ; restore A
out (0b1h), a
pop de
inc de
dec bc
jp READ_BLCK
; ======================================================================
egyébként ami nem világos nekem az EXOS leírásból: milyen regisztereket kell megőriznem?Asszem meg van a megoldás: "A perifériakezelő alprogramok tönkretehetik az összes regiszter - közöttük az indexregiszterek és az alternatív regiszterkészlet regisztereinek - tartalmát, mivel ezek a tárolását az EXOS hajtja végre. "
az ugye világos, hogy az A-ban adok vissza hibakódot, vagy nullát. BC és DE regiszterben meg eredményt. De pl. mi van olyan hívásoknál, ahol nincs eredmény, csak az A-ban? Pl. EXOS 1 esetén? Akkor BCDE-t is elronthatom? Mi van a vesszős regiszterekkel? Azokat is megváltoztathatom?
READ_BLCK:
; exos 6
bit 0, (ix-3)
jp nz, RET_NOFN
; HL = pointer to buffer
ld l, (ix-6)
ld h, (ix-5)
; DE' = DE
push de
exx
pop de
exx
in a, (0b0h)
push af
di
call SET_USER_SEGMENT0 ; at return DE points to P0
.loop: ld a, b
or c
jr z, .vege ; if (BC == 0) { A = 0; goto vege; }
ld a, (ix-1)
or (ix-2)
jr z, .eof
inc (ix-4)
call z, Read256ByteFromEeprom
ldi
exx
inc de
exx
bit 6, d
call nz, SET_USER_SEGMENT0
inc (ix-2)
jp nz, READ_BLCK.loop
inc (ix-1)
jp READ_BLCK.loop
.eof: ld d, ERR_EOF ; End of file
db 020h ; JR NZ, .. skip next byte
.vege: ld d, a ; no error
pop af
out (0b0h), a
ei
ld a, d
ld (ix-6), l
ld (ix-5), h
exx
push de
exx
pop de
ret
van-e valami hátrány, ha kilapozom a rendszer alól a nullás lapszegmenst, vagy tiltott megszakítás mellett nem lehet semmi gond, ugye?Elméletileg nem, azt nézd meg lapozás előtt, hogy ne ott legyen a verem.
van olyan számláló ep-n, ami a bekapcsolástól elkezd számolni?Az óra nem jó? Vagy ott van még a RANDOM_IRQ változó.
exos-al elérhető ez, illetve peek jobb lenne.
Van egy 50 Hz számláló. Az elég?
István írt sokszor a polinomszámlálókról, meg talán másról is, amik pörögnek ezerrel, a hang is azoktól van, vagy nincs.
SPEEK(255,16364)
Mind addig míg be nem zárod a csatornát.És másikat se. Meg nem is nyitsz. Mert ilyen műveleteknél áthelyezésre kerülhet.
És másikat se. Meg nem is nyitsz. Mert ilyen műveleteknél áthelyezésre kerülhet.
CLOSE #102
SET VIDEO X,a
SET VIDEO Y,b
...
OPEN #255
Ez lesz az a memória amit szeretnélKülönben is milyen EXOS lenne ha e lefoglalt puffert átrakná pláne ha az DISPLAY alatt van.Pedig szokott ilyet csinálni, ezért kell a periféraiakezelőknek puffermozgatásra felkészülni. (http://ep128.hu/Ep_Konyv/Exos.htm#32)
És hogy ne legyen kihasználatlan hely ilyenkor a #4 pufferét áthelyezi B9D0 -> B9E0És aztán egyből a #5 pufferét is áthelyezi B9C0 -> B9D0
És aztán egyből a #5 pufferét is áthelyezi B9C0 -> B9D0
Arra törekszik, hogy a videó memória szabad része mindig egybefüggő legyen, hogy új videó lap nyitásakor a lehető legnagyobb méret legyen elérhető.
Milyen "set" utasítással lehet lehalkítani a belső hangszórót a magnós töltés idejére.SET TAPE SOUND OFF
Ki kell számolni a módosítás utáni új értéketHogyan kell kiszámolni? Gondolom, nem az összes addigi karakter kódjának az összege, mert akkor nem befolyásolná, ha csak megcserélek két karaktert.
OPEN #1:"exos21.rom" ACCESS INPUT
LET X=0
FOR A=1 TO 32768
GET #1:A$
LET X=X+ORD(A$)
NEXT
CLOSE #1
PRINT "Ezt kell beírni a végére (hex alakban):" X
OPEN #1:"exos21.rom" ACCESS INPUT
LET X=0
FOR A=1 TO 16384
GET #1:A$
LET Y=ORD(A$)
GET #1:A$
LET Y=Y+ORD(A$)*256
LET X=X+Y
NEXT
CLOSE #1
PRINT "Összeg:" X
Az miért van, hogy ha pl. az exos21.rom tartalmában valamit átírok hex editorral, és azt rakom az emulátorba, akkor Internal checksum error üzenettel el sem kezdődik a memóriateszt? Gondolom, a fájlban lévő karakterek kódja alapján ellenőrzi, milyen érték jön ki, és ha nem az, ami kell, akkor nem engedi elindulni a gépet. Viszont ha csak két karaktert megcserélek a rom-ban, akkor is ugyanannyi kéne, hogy legyen a kódok összege, azt sem fogadja el.a későbbi exos verziókban ki lett irtva ez a cheksum, azokban már büntetlenül átírhatod a szöveget (de lehet, h rosszul tudom)
Megtaláltam a rom-ban a funkcióbillentyűk szövegeit sorban egymás után. Először azt hittem, a basic romban lesz. A toggle speaker-t akartam átírni valami másra.
Így hogyan lehet romokat fejleszteni? Vagy az ellenőrző rutin is a romban van benne és felül lehet írni mással?
a későbbi exos verziókban ki lett irtva ez a cheksum, azokban már büntetlenül átírhatod a szöveget (de lehet, h rosszul tudom)Rosszul tudod.
// Javítsa az EXOS ellenorzo összeget (az elso szegmens utolsó 2 bájtjában tárolva).
// Fix the EXOS checksum (stored in the last 2 bytes of the first bank).
{
uint16_t * pChecksum = (uint16_t *) aRomBuffer;
pChecksum[ 0x1FFF ] = 0;
j = 0;
for (i = 0; i < 0x4000; ++i)
{
j += pChecksum[i];
}
j = 0 - j;
pChecksum[ 0x1FFF ] = (uint16_t) j;
}
Gondolom, nem az összes addigi karakter kódjának az összege, mert akkor nem befolyásolná, ha csak megcserélek két karaktert.Azért lesz más a checksum, mert nem byte-onént adja össze a számokat, hanem 16 bites értékekként.
Hát vagy épp az EXOS 2.0 leírását nézed :D , és akkor nem hibás az, hanem human error történt :D :DAkkor a SET 5,akármennyi és hasonló SET-ek máshogy működnek 64-es és 128-as gépen? Akkor lehet, basicből érdemesebb kiírni a teljes szöveget (Pl. set key click off), mint elintézni szép frappánsan a set 6,akármennyivel, különben a kompatibilitásnak lőttek?
Ha "Új alkalmazói program" ami 5-ös fejléccel lett fordítva, akkor a 0x100 címtôl kezdi elhelyezni.Először beolvassa az első 16 bájtot ami a fejléc ezt elemezve dönti el a további tartalom hová kerüljön.
forrás:
Fejezet 10.6
http://www.ep128.hu/Ep_Konyv/Exos.htm#42
A fejléc tartalmazza a betöltendô fájl hosszát, így a betöltött program több szegmensen is landolhat => F8, F9, FA
Nem tudom a 100h címre tölteni, mert elszáll az asmon 1.5.Igen
Azt csináltam, hogy a 0x40F0 címre töltöttem. Absolute JUMP és CALL esetében mindig kivonok gondolatban 0x4000-et.
Az exos hívások után, amikor visszatér a fôprogramhoz, a regisztereket/ árnyékregisztereket visszaállítja az eredeti állapotra?A HL biztosan megmarad. A vesszős regisztereket nem tudom.
Ha lapoznia kell, akkor megjegyzi az utolsó állapotot és visszalapoz mindent?Persze, hiszen maga az EXOS rutin is a ROM területen fut (általában), tehát mindenképpen lapozni fog. Azt a lapkiosztást visszaállítja, ami hívás előtt volt.
Mi van akkor ha közben jön egy megszakitás? Vagy ilyenkor az le van tiltva?Szerintem ez EXOS funkció függő, hogy le van-e közben tiltva a megszakítás. De nem látok olyan okot, ami miatt probléma lenne az exos hívás közben lévő megszakítási rutin hívás miatt, ha maga megszakítási rutin jól van megírva.
Az EXOS-hívások a paramétereket az A-, BC- és DE-regiszterekben veszik át, és az eredményeket ugyanezekben a regiszterekben adják vissza. Az A-regiszter állapotkódot hoz vissza, ami nulla, ha a hívás sikeres volt, egyébként pedig egy nullától különböző értékű állapotkód. Az összes többi regiszter (HL, IX, IY, AF', BC', DE', HL') tartalmát minden EXOS-hvás megőrzi és változatlan marad a felhasználói lapkiosztás is. EXOS-hívást bármely Z80-as lap bármely címéről kérhetünk, és a felhasználói veremmemória is elhelyezkedhet a négy lap bármelyikén.
EXOS-hívást bármely Z80-as lap bármely címéről kérhetünk
Akkor ez azt jelenti, hogy az exos lapozó rutin a 0-ás lapon azzal kezd, hogy eltárolja a 3. lapon a szegmensszámot, majd ide belapozza a romot. Ott végrehajtja a feladatot majd - itt jön a kérdés hogy jól látom-e a dolgot - visszatér a 0-ás lapra a végrehajtás, ott visszalapozza a korábbi szegmenst és végül visszaugrik az Exos hívás utáni részre?Lényegében igen.
Vannak játékkok mint a Sorcery vagy néhány betöltő kép nélküli játék, ahol ez a 9 képpont magas sort, a töltés alatt végig fent mutatja.Ez utóbbiakat én csak "nagy searching-es"-nek hívtam gyerekkoromban :-)
Vannak viszont olyan játékok (pl. Untouchables), ahol ez a status sor alul jelenik meg egy olyan kb. 18 képpont magas és elég vastagok a betűk a sorban.
a magnó jelszintjelző sem nagyon ugrál, csak a PAUSE felirat jelenik meg.A Zozosoft&Apuci Demo az egyetlen program ami áthelyezett Status sort használ, és működik a szintjelző! (És a képernyő közepére tettem, mert olyat még senki nem csinált :-) )
Beépített lehetőség, vagy valaki ezt kitalálta?Beépített lehetőség a Nick chipben, hogy olyan LPT-t definiálsz amilyet csak akarsz. Valaki kitalálta, aztán néhány átíró ezt a megoldást használta a betöltőjében.
Más gépeken van ilyen betöltő status sor alul vagy felül mint az EP-n?Én nem tudok ilyenről. Rendszerint a Searching, Loading, fájlnevek, stb a normál képernyőbe beírva jelennek meg. Ha van is valami effektus a magnóbemenethez, az keretcsíkozás szokott lenni.
Nem egybe rakja be a 9 pixel magas karaktersort, hanem 9-szer 1 pixel magasat, úgy, hogy minden sort megdupláz. Soronként szín állítás meg sima ügy.ezek gyerekként nagyon nagy mágiának tűntek nekem...
a nagy szent grál az volt, hogy írjunk a status sorba (BASIC-ből)Én kb egy év alatt eljutottam odáig :-)
nem sikerült, a könyv alapján se :-D
Igen, előbb a rendszerszegmensre másolja, a 0-ás szegmensen sehol nem találod azt a kódot, mert maga az EXDOS intézi a másolástPontosabban az a periféria, amely éppen intézi a töltést. Lehet TAPE:, DISK:, FILE:, SERIAL:, CBM:, ROM: hogy csak a leggyakoribbakat említsem.
Az EXDOS ROM-on belül a 2959h (belapozva E959h környéke)Ami aztán változhat a ROM verzióval :oops:
Innentől túl sok értelmét nem látom ilyen kódra vadászni. :oops: Ez nem Spectrum vagy C64, ahol van egy ROM LOAD rutin aztán csá...Akkor van értelme, ha az ember turpisságot szeretne elkövetni, mint pl töltés közbeni zene, igaz, azzal meg az a baj, hogy csak adott média forrással fog működni.
Ami aztán változhat a ROM verzióval :oops:
Ami aztán változhat a ROM verzióval :oops:Jáááá, nem is akartam felhasználni a címet sehova, Tuby128 szeretné tanulmányozni azt a részt, hát hajrá.
Amúgy ha alaposan megnézed ez a másolás csak az első szektorra igaz, mivel ott csonka olvasás van: elsőnek be van olvasva 16 bájt a fejlécnek, és aztán később 496 bájt már a fájl. Ezért van el téve az EXDOS rendszer szegmensen lévő pufferébe ez a szektor.Szuper, ez tök jó, hogy teljes szektornál egyből a célmemóriába tölt. :)
További olvasásnál, ahol ha legalább egy szektornyi adat lesz beolvasva, a szektor olvasó rutin eleve a cél memóriába tölti az adatokat.
Az utolsó szektornál, ha úgy jön ki a fájl vége, hogy nem teljes szektornyi, akkor megint csak az EXDOS pufferbe olvassa, és aztán másolja át amennyi kell.
Úgy hangzik mint egy egyedi LOADER.Jáááá, csak érdekességképp, meg még meg szeretnék csinálni egy játékot, amiben ez a zenélős tape loader lesz, természetesen lesz nem spéci betöltős verziója is.
De így nem lesz EXOS kompatibilis vagy EXDOS!?!Nem hát, speciel az én verzióm csak magnóról műxik.
Akkor ajánlanám, keresd a TAPE: részt.Pimpa, már megvan pár hónapja, az EP128emuval megkeresetem a szükséges részt, kiszedtem, csináltam forrást, majd beszúrtam a zenelejátszót :ds_icon_cheesygrin:
Talán a "turbo tape".ext et vissza fejted nem kell akkor a nulláról kezdened.
Vagy a az EXOS.ROM 01. szegmens visszafejtése irodalmat.
Vagy ha úgyis egyedi lesz kazis akkor alkalmazd a Spectrum LOAD/SAVE rutint és módosítsd valamivel könnyebb dolgod lesz.
A Spectrum loadert nem szeretem, mert az lassú, és nem toleráns a hibára, és a programot is abban a formátumban kéne kimenteni, így bármely EP-s magnós program alá be lehetne szúrni a zenélgetést.És hogyan?
az EP128emuval megkeresetem a szükséges részt, kiszedtem, csináltam forrástNem egyszerűbb lett volna elővenni a Hsoft csomagból a TPT forrást? :-)
És hogyan?Vagy +betöltő, vagy a betöltőben lehetne választható, hogy ki hogy szeretné.
Mindegyik elé fel vennél egy plusz betöltőt?
Vagy +ROM ba töltenéd mint a "turbó tape:"-t?
Nem egyszerűbb lett volna elővenni a Hsoft csomagból a TPT forrást? :-)Biztos egyszerűbb lett volna, ha eszembe jutott volna :smt040
Vagy +betöltő, vagy a betöltőben lehetne választható, hogy ki hogy szeretné.Hát.
Hát.Nem kell újramásolni a kazikat, ilyen verzió, ha készül, 1-2 játék lesz ilyen, és esélyed se lesz választani, ha csak egy loader lesz, és abban kell választani :D :D
1. Én nem másolnám újra a kazikat.
2. Ha + betöltő /TAPE: + zene, zenék mert, hogy választhatok 2kB-16kB?/ ez idő alatt már betöltődik a játék 1/4,1/5 .
Viszont ha ROM-ban van 16,32,64kB TAPE: + zenék + zene lejátszó gondolom ja fentebb is +zene le játszó az már elfogadhatóbb lenne szerintem.
Ez a CH64 mód valamelyik ALTIND# jelzőbit bekapcsolt állapotával, ugye? (Az EXOS könyvben ez mintha ellentmondásosan lenne leírva. Vö.: 288. oldal a 294. oldal aljával és a 295. oldallal szemben.)
Ez akkor nem jó így?Az ott jó, máshol a hiba.
Ladányi Péter Mikromagazin 1990 május 23 számában azt írja, az ALTIND és BALT bitek szerepe tévesen fordítva jelent meg az EXOS leírásban.Nem a szerepük jelent meg fordítva, hanem a helyük.