Enterprise Forever
:HUN => Programozás => Topic started by: Zozosoft on 2007.May.16. 01:10:45
-
Eredetileg a befejezetlen projektekbe akartam, de most hála az ep128emu debuggerének meg találtam azt a bugot amivel 12 éve elakadtam :-)
Az egyik angol srác kért angol EXOS 2.3-at ehhez keresgéltem, hogy melyik forrásszöveg az aktuális. Így találtam a "közforgalomban" lévõ EXOS 2.3-nál több újabbat is, a legfrissebb egy EXOS 2.31-nek elkeresztelt változat 1995-bõl, ami egy kicsit bugos volt...
De most már mûködik :-)
Változások az ismert 2.3-hoz képest:
-javítva a "WP 80 karakteres módban rejtélyes villogó pixel, ha nincs EXDOS" címû hiba (ha jól emlékszem még az Indexes idõkben jelezte ezt MrPrise)
-EDCW-nél a SETUP szegmens is megõrzõdik
-2 szektoros clusterû RAMDISK-et is felismer a RAMDISK megõrzõ rutin (2 megánál nagyobbhoz ez kell, igaz jelenleg az EXDOS ilyet nem tud létrehozni, de kezeli, ha ASMON-ból "diskeditáljuk" :-) )
-a teszt induláskor hajlandó átadni a vezérlést egy HsoftROM kezdetû szegmensnek (EPDOS 2.1...)
-memória teszt alapértelmezésben a 4-es szegmensig fut le, vagyis a cartridgeban található SRAM külön gombnyomás nélkül memóriabõvítésként üzemel. 5,6,7,8-as gombokkal lehet elérni, ha részben vagy teljesen nem szeretnénk élni ezzel a lehetõséggel
-azonos ROM-ok vizsgálatakor a szegmens eleje helyett 0000H,1000H,2000H,3000H címeken ellenõriz 16-16 bájtot
-kisebb javítás a hibás RAM szegmensek detektálásakor, hogy egyes turbós gépeken, ahol az üres adatbusz nincs stabil értékre beállva, ne jelenjenek meg fantom hibás szegmensek
-STOP és HOLD billentyûk kezelésén némi finomítás, hogy ne olyan érzékenyen mûködjenek
-STOP gomb hatása második fázisban felfedezett hibás szegmensek esetén is érvényesül. (Az elsõ fázisban letesztelõdnek a szegmensek, akkor növekszik a "TESTED"-nél látható érték. Ilyenkor minden szegmensben egy egyedi érték lesz hátrahagyva. A második fáziban végig megy a tesztelt szegmenseken, és leellenõrzi, hogy meg van-e az ellenõrzõ érték. Ha igen, csak akkor kerül át az OK-ba. Így lehet pl címvezeték hibákat kiszûrni.)
-a WP 2.6-ban el lett dugva pár újabb nyomtató vezérlõkód MP80-as nyomtatóhoz, de ilyenem úgyis csak nekem van :-) (ezért a HELP-ben sincs benne :-) )
-az induló képen olvasható "F8-as nullásszegmens" funkció még nincs kész
[attachimg=1]
-
Gratulálok a bug levadászásához! :-)
Úgy látom az EP EXOS-a lassan kényelmesebb lesz mint a Windows ;-)
-
Ha van valakinek ötlete ennél angolosabb szövegre, ne tartsa magában :-)
[attachimg=1]
-
Angol nyelvű lesz? Vagy marad a magyar is?
Úgy látom újabb funkcióval bővült: ALT - csak 64k-ig tesztel?
Régebben volt egy csomó ötletem, miket lehetne javítani benne, de most nem jut eszembe egy se... :-)
De az epdos 2.1 egy-két jól sikerült cuccát bele lehetne csempészni az új EXOS-ba. Pl. nekem a KEYBOARD:-ja nagyon tetszik!
Meg hogy CTRL+ALT-ra előugrik egy memória-dump.
-
Angol nyelvû lesz? Vagy marad a magyar is?
Amilyet a kedves felhasználó óhajt :-)
Úgy látom újabb funkcióval bõvült: ALT - csak 64k-ig tesztel?
Az eddig is volt, csak nem volt dokumentálva :-)
Anno csak poénnak volt szánva, de miután Lacika talált rá értelmes indokot (egyes játékok 64K-s gépen futnak normális sebességgel), így gondoltam beteszem a help-be is :-)
-
Ez tök jó, akkor majd nekem is újra égetheted... :-D
-
Esetleg a hétvégi összejövetelen lehetne tartani egy kis "EPROM-égetés bemutatót", melynek keretein belül megfrissíthaténk az én gépem EPROM-ját is... :oops:
-
Mindenki azt szeretné, ha 2007-es évszámmal indulna a gépe? :-)
-
Mindenki azt szeretné, ha 2007-es évszámmal indulna a gépe? :-)
Nekem valahogy az 1985-2007 felirat szimpatikusabb lenne... Bár gondolom sokkal macerásabb :)
-
Ha van valakinek ötlete ennél angolosabb szövegre, ne tartsa magában :-)
Szerintem a STOP sorában lévő szöveg nem egészen jó.
A Halt az megállást jelent, nem várakozást. Nem tudom a funkció pontosan mit csinál, de ha a halt kell ide, akkor az on nem kell szerintem, tehát
halt when bad segment found.
Ha várakozás, akkor esetleg wait on bad segments vagy wait when bad segment found.
Na, de szóljon hozzá tőlem jobb angolos is ;-)
-
A halt on-t a PC-s BIOS-okból szedtem, ott van valami hasonló :-)
Azt csinálja, hogy ha hibás szegmenst talál akkor megáll a teszt, hogy el lehessen olvasni, melyik szegmens a hibás. Billentyû lenyomásra folytatja.
-
A halt on-t a PC-s BIOS-okból szedtem, ott van valami hasonló :-)
Igen, de ott nincs when, ha jól emlékszem. A "halt on akármi", azt jelenti, hogy "megállni akármin", akármi esetén, tehát a when nem kell.
Azt csinálja, hogy ha hibás szegmenst talál akkor megáll a teszt, hogy el lehessen olvasni, melyik szegmens a hibás. Billentyû lenyomásra folytatja.
Akkor talán a wait vagy suspend, esetleg pause jöhetne szóba.
-
Akkor talán a wait vagy suspend, esetleg pause jöhetne szóba.
Én a pause szót javaslom. A halt on kifejezéssel még nem találkoztam, de lehet, hogy az a jó, meg kéne kérdezni egy angol anyanyelvû fórumozót.
A jump helyett talán a go jobb lenne az utolsó sorban, vagy még jobb a return to startup screen. Meg szerintem a startup screennél a startup elegánsabb egybe írva. Bár én kötõjellel írnám: start-up screen. (Persze amikor igeként használjuk akkor külön jó.) (vö.: built-in joystick - jelzõként; to built in a joystick - igeként)
A test rom enable így furán hangzik, enable test rom lenne a helyes szórend, esetleg talán a test rom enabling még elmenne ebben a szórendben. Ugyanilyen a ram disk delete is. Szerintem a ram disk deletion jobb lenne, bár így ebben a formában nem hallottam még a "szaknyelvben", inkább Press R to delete ramdisk, csak ahhoz fel kéne bolygatni a szórendet.
Nem lehetne inkább így?
C: Cold reset
S: Slow test
E: Exos reset
N: Normal test
T: Enable test rom
R: Enable ram disk
Szubjektív véleményem, hogy a megnyomandó gombok jelét lehetne esetleg más színnel kiírni. De nem akarok már ennyire belekontárkodni. :oops:
Nem tudom, hogy az enable test rom mit jelent, de talán jobb lenne az enable rom test, illetve (jelentéstõl függõen) az enable testing rom.
Bocs a kissé késõi reagálásért, csak most néztem a fórumot az utóbbi napokban.
Zozo, sztem legjobb lenne az angol fórumban felvetni a nyelvhelyességgel kapcsolatos kérdésed. Persze lehet, csak az én mániám, hogy az ilyen nyelvi dolgokba így belemegyek, de érdekelne, az angol anyanyelvûek mit gondolnak errõl. :mrgreen:
Amúgy sztem a halt on when is jó lenne, de nem vagyok benne teljesen biztos.
Még annyit, hogy lehetne a továbbiakban az angol indítóképernyõnél maradni, ennyit mindenki meg kell, hogy értsen szerintem, és az EP amúgy is angol nyelvû eredetileg. Az angol képernyõ nekem elegánsabbnak tûnik.
Ja, és a 2007-es évszám tetszik! Meg marha jó az egész! :smt041
-
-javítva a "WP 80 karakteres módban rejtélyes villogó pixel, ha nincs EXDOS" címû hiba (ha jól emlékszem még az Indexes idõkben jelezte ezt MrPrise)
Jól emlékszel:
Első találkozás a buggal (http://forum.index.hu/Article/showArticle?t=9010641&go=49436373)
Kép a bugról (http://forum.index.hu/Article/showArticle?t=9010641&go=49586380)
Szerény elmélkedésem a bug mibenlétéről (http://forum.index.hu/Article/showArticle?t=9010641&go=49627663)
-
Ez nem biztos, hogy a program hibája. Valamiért az EXOS 0 (reset) hívás néha lefagy. Ez összefügghet azzal, hogy a vissztéréskor engedélyezett lehet a megszakítás, pedig az EXOS leírás alapján mindig tiltottnak kellene lennie. A hibás mûködés nem fordul elõ a C=40h hívásnál (memória felszabadítása), tehát az valószínûleg nem is fagy le, véletlenszerûen fordul elõ C=10h esetén (csatornák bezárása, eszközök újrainicializálása), és többnyire engedélyezett a megszakítás C=20h (csatornák bezárása, eszközök újrainicializálása, periférialánc újraépítése) után. Ami egyben azt is jelenti, hogy az 5-ös fejlécû programok indításakor az automatikus C=20h-s reset miatt engedélyezett a megszakítás, pedig a veremmutató érvénytelen (tehát a legjobb, ha a program azonnal DI vagy LD SP, nnnn utasítással kezdõdik).
Így lehet, hogy olyankor történik megszakítás az EXOS reset közben vagy után, amikor nem lenne szabad (pl. nincs érvényes veremmutató). A lefagyás gyakorisága függhet az idõzítéstõl, például hogy egy 5-ös fejécû program mennyi idõ alatt töltõdik be.
Érdemes kipróbálni ezt a rövid programot, amely egy idõ után lefagy:
l1: di
ld sp, 100h
ld c, 20h
exos 0
jr l1
Elõször azt hittem, hogy a hibát az okozhatja, hogy egyes bõvítõ eszközök (pl. DISK: és FILE:) EXOS hívásokat végeznek az inicializálás közben, ami engedélyezi a megszakítást, de a hiba valójában akkor is elõfordul, ha az EXOS 2.1-en kívül semmilyen ROM nincs a rendszerben (de ha van EXDOS, akkor mintha gyakoribb lenne a lefagyás). Ez tehát EXOS bug is lehet, amit esetleg javítani is lehetne (EXOS 2.32 :)) ?
Na ezt érdemes lenne kinyomozni! Ezzel a buggal szerintem én is rengetegszer találkoztam, de eddig valamelyik bõvítõre gyanakodtam...
Sõt sokáig arra gondoltam, hogy az agyontunningolt valódi gépnek van valami hw bizonytalansága, de most, hogy emulátorral is pontosan úgyanazt tapasztalom, így a hw hiba kizárható.
Jellemzõ "X-akták":
- memteszt után nem jön be az EP felírat (EXOS 2.3 esetén ottmarad a zöld háttér)
- EP felírattól BASIC-et hívva, nem indul el
- HEASS lefagy induláskor (mindegy, hogy EP felírattól hívjuk, vagy pedig BASIC-bõl)
- párszor már ASMON 1.5 indításakor is elõfordult.
Egy meleg Reset nyomása után megy minden tovább rendben.
Szerintem minél több bõvítõ van a rendszerben annál nagyobb az esélye. A leírásod alapján gyaníthatóan azért, mert több bõvítõn, periférián lassabban hajtódik végre az inicializálás, így nagyobb esélye van befutni egy megszakításnak akkor, amikor nem kéne engedélyezve lennie.
-
Érdemes kipróbálni ezt a rövid programot, amely egy idõ után lefagy:
Nem is kell túl sok idõ hozzá...
Ha berakunk egy poke 56,201-et az elejére, akkor nem fagy le.
-
Na csináltam egy EI vadász scriptet :-)
clearBreakPoints()
for i = 0, 0xFFFF do
setBreakPoint(4, i, 2)
end
function breakPointCallback(t, a, v)
if t == 3 then
return true
end
if readMemory(getPC()) ~= 0xFB then
return false
end
return true
end
Így kiderült, hogy az 1-es szegmensben az E9DD címen van egy EI, ez a TAPE periféria kezelõben van. Ha ezt aljas módon likvidáljuk, akkor úgy tûnik az alapgépes konfig nem fagy le. Viszont ha elkezdünk további ROM-okat adni a rendszerhez, akkor újabb EI seregek jelennel meg (némelyik az EXOS használatával, mint pl a DISK periféria felvétele).
Tehát a megoldás valószínüleg egy jól elhelyezett DI lesz a reset rutinban...
-
Úgy tûnik meg is van :ds_icon_cheesygrin:
Eredetiben így néz ki:
DI
LD HL,0000
LD (BFF8),HL
LD (003D),HL
LD (BFED),HL
XOR A
LD (0056),A
LD A,C
ADD A,A
JP C,C000
ADD A,A
PUSH AF
CALL C,C7D8
POP AF
CALL NZ,C23A
LD A,0FBH
LD (0056),A
XOR A
LD (BF79),A
LD H,C9
POP BC
JP C46C
A C46C-n lévõ visszatérési rutinban pedig intenzíven el kezdi piszkálni a veremmutatót, így érthetõ miért száll el, ha befut egy megszakítás...
Szerencsére elfelejtettek spórolni, így akad egy felesleges bájt, ami helyére befér a DI, így néz ki módosítva:
DI
XOR A
LD H,A
LD L,A
LD (BFF8),HL
LD (003D),HL
LD (BFED),HL
LD (0056),A
LD A,C
ADD A,A
JP C,C000
ADD A,A
PUSH AF
CALL C,C7D8
POP AF
CALL NZ,C23A
DI
LD A,0FBH
LD (0056),A
XOR A
LD (BF79),A
LD H,C9
POP BC
JP C46C
EXOS 2.32 Smiley
Legyen :-)
De azért meg csináltam a javítást a 2.0 és 2.1-en is :-)
De nem teljesen csak az EXOS volt a hibás, úgy tûnik az ASMON 1.5 ROM tud még EXOS 0 fagyást okozni... remélhetõleg az már annak a ROM-nak az egyéni hibája, nem újabb EXOS bug...
Rakás más ROM-mal együtt nem volt fagyás.
Teszteljétek!
A csomagban benne van az idõközben kifejlesztett cartridge-os verziója is a gyorstesztnek, azok számára akik nem akarják megbontani a gépet. Így a hibajavításokon kívül a többi funkció mûködik így is.
-
Ezzel a rejtélyes hibával szerintem időnki mindenkivel találkozott... Szerencsére nagyon nem volt zavaró, nem tulajdonítottunk neki jelentőséget.
Mindenesetre jó, hogy újabb hiba lett javítva! :ds_icon_cheesygrin:
És még egy tipp: ha jól tudom, a BASIC-ba egyetlen byte-ot kell átírni, hogy a GOTO működjön parancssorban?
Még az órajel detektáló - órabeállító rutint kellene belerakni.
Apropó! A jelenlegi EXOS-okban mi a 191-es port alapértelmezése? Ha esetleg bekapcsolt memóriavárakozás, akkor azt érdemes lenne kikapcsolni, a mai emulátoros világban.
-
A jelenlegi EXOS-okban mi a 191-es port alapértelmezése? Ha esetleg bekapcsolt memóriavárakozás, akkor azt érdemes lenne kikapcsolni, a mai emulátoros világban.
Ugyanaz mint gyárilag. Ha letiltjuk akkor lehet, hogy pár játék gyorsabb lesz a megszokottnál.
-
Ugyanaz mint gyárilag. Ha letiltjuk akkor lehet, hogy pár játék gyorsabb lesz a megszokottnál.
Azt nem kellene megváltoztatni mert ha valaki ROM ba tölti és igzi gépben probálná nem 100%, hogy müködne.
Esetleg rom megjegyzésnek "csak emu" vagy " EXOSv2x.ROM /E "
-
De nem teljesen csak az EXOS volt a hibás, úgy tûnik az ASMON 1.5 ROM tud még EXOS 0 fagyást okozni... remélhetõleg az már annak a ROM-nak az egyéni hibája, nem újabb EXOS bug...
Rakás más ROM-mal együtt nem volt fagyás.
:smt041
Az ASMON ROM-ot akkor (feltéve, hogy nem sikerül azt is kijavítani :)) érdemes lenne eltávolítani az emulátor konfigurációkból, kivéve természetesen azokat, amelyeknek "TASMON" van a nevében ? Vagy csak az ASMON indításakor okozhat fagyást, és nem bármilyen programból végzett EXOS 0 hívásnál ?
Ugyanaz mint gyárilag. Ha letiltjuk akkor lehet, hogy pár játék gyorsabb lesz a megszokottnál.
Az emulátor EXOS 2.3-as konfigurációiban le van tiltva a várakozás. Először azt hittem, az új EXOS verziók tiltják le, de kiderült, hogy csak az EXOS 2.3x ROM-okat betöltve nem így van. Úgy látszik, valójában a TPT.ROM miatt lesz 0Ch a várakozási mód - lehet, hogy ennek sem kellene alapértelmezés szerint a konfigurációkban lenni (már csak azért sem, mert a turbós és tömörített magnós mentést teszi alapértelmezetté, ami nem kompatibilis az EXOS eredeti TAPE: betöltőjével) ?
-
Az ASMON ROM-ot akkor (feltéve, hogy nem sikerül azt is kijavítani :))
Kijavítva :-)
A hibát Puskás Zsolt (õt ismeri valaki?) követte el, amikor a Gyányi Sanyi gyorstesztjét beépítette az eredeti ASMON ROM üres területére. Ebben a nehézség az, hogy az EXOS-nál kétféle ROM kezdet lehet, ami nem kompatibilis egymással:
- TEST_ROM az elsõ 8 bájton, rögtön a szöveg után indul a program
- EXOS_ROM az elsõ 8 bájton, utána 16 bites cím a perifériának, majd csak ez után indul a program.
Nem gondolták az Intelligent Software-nál, hogy kellhet majd mindkét funkció is egyazon ROM-ban :-(
(De ha megnézitek a cartridge-os gyorsteszt verziómat, látható, hogy némi trükkel megoldható :) )
Ráadásul az ASMON INC/DEC-cel vált szegmensszámot, nem XOR-al, így nem cserélhetõek fel a szegmensei. Viszont hely a második szegmensben volt...
Így azt a megoldást választotta, hogy a ROM elejei lettek megcserélve, majd az ott belépõ program átlapozza magát a másik szegmensre, a TEST ROM programmal nincs is gond, mert az DI alatt fut...
Az EXOS ROM belépési program így néz ki az átvariálás után:
C00A DB B2 IN A, (B2)
C00C 08 EX AF, AF'
C00D DB B3 IN A, (B3)
C00F D3 B2 OUT (B2), A
C011 C3 14 80 JP 8014
8014 3D DEC A
8015 D3 B3 OUT (B3), A
8017 C3 F0 FF JP FFF0
FFF0 08 EX AF, AF'
FFF1 D3 B2 OUT (B2), A
FFF3 79 LD A, C
FFF4 C3 0B C0 JP C00B
C00B C3 CD DB JP DBCD
Itt már látható is a hiba: ideiglenesen kilapozza a rendszerszegmenst a második lapról, pedig ilyenkor oda mutat a veremmutató, így ha ezen pár pillanatban fut be a megszakítás, kész a fagyás!
Vagy csak az ASMON indításakor okozhat fagyást, és nem bármilyen programból végzett EXOS 0 hívásnál ?
Bármikor okozhat fagyást, amikor körbe vannak hívva az EXOS ROM-ok. Így belegondolva emlékszem pár HELP lista fagyásra is...
A hibát okozó lapozás amúgy teljesen felesleges, nem kell elugrani azért a 3-as lapról, hogy kicseréljük az ott futó program alatt a szegmenst.
Ime a javítás:
C00A C3 EB FF JP FFEB
FFEB DB B3 IN A, (B3)
FFED 3D DEC A
FFEE D3 B3 OUT (B3), A
FFF0 79 LD A, C
FFF1 C3 CD DB JP DBCD
Úgy látszik, valójában a TPT.ROM miatt lesz 0Ch a várakozási mód - lehet, hogy ennek sem kellene alapértelmezés szerint a konfigurációkban lenni (már csak azért sem, mert a turbós és tömörített magnós mentést teszi alapértelmezetté, ami nem kompatibilis az EXOS eredeti TAPE: betöltõjével) ?
TPT forráskódunk van, így nincs akadálya más alapértelmezésû változat fordításának.
-
A játékokban nem mûködne, mert indításkor fix 0Ch értéket írnak a portra,
Azért nem mindegyik. Amúgy meg a nagy EXOS kompatibilis betöltõ készítõ mozgalomban ezt is el lehetne intézni :-)
Ezen kívül a BFh port (mint a NICK összes és a DAVE I/O portjainak a többsége :() csak írható, tehát arra sincs lehetõség, hogy egy program csak a memória várakozást tiltsa le a hanggenerátor frekvencia változatlanul hagyása mellett. Ehhez még külön EXOS változót is kellene létrehozni.
Erre gondoltam én is, pl lehetne likvidálni a trükkös védelmet (http://enterpriseforever.com/programozas/trukkos_vedelem_az_exosban-t278.0.html), akkor kapuk egy szabad bájtot, ahova elférne az új változó.
Ami kérdéses, hogy hogyan lehetne megoldani legjobban az órajelváltozás figyelését?
Az alapverzió az lenne, hogy pl a WP 2.6 inicializálási rutinjába beletenni egy mérést, így akkor reset rutin lefutása után helyes lenne a hangfrekvencia.
De még jobb lenne állandó megfigyelés, valami olyanra gondoltam, hogy egy periféria (pl a RAMDISK megõrzéshez létrehozott RDISK) ráül a videó és az 1 Hz-es megszakításra, és számolgatja õket, és ha egy 1Hz-es megszakítás alatt túl sok vagy túl kevés videó megszakítás volt, akkor változott az órajel, és ehhez korrigálni kell a hangfrekvenciát.
-
Egyébként ha már a megszakításoknál tartunk: úgy tûnik van még egy bug az EXOS-ban.
Turbos gépen is lehet érzékelni, de igazán akkor jön elõ, ha ALT-W-vel nyomunk egy padlógázt az emulátoron. Ekkor nem lehet gépelni, mert egy pillanatnyi gombnyomásból lesz vagy 50 karakter...
Viszont a leírás szerint a videómegszakítást használja a KEYBOARD, az viszont nem gyorsul a turboval! Akkor miért is változik a billentyûzet sebessége?
Szintén érdekes a kurzor õrült villogás, igaz az annyira nem zavaró, csak poén :-)
-
Egyébként ha már a megszakításoknál tartunk: úgy tûnik van még egy bug az EXOS-ban.
Turbos gépen is lehet érzékelni, de igazán akkor jön elõ, ha ALT-W-vel nyomunk egy padlógázt az emulátoron. Ekkor nem lehet gépelni, mert egy pillanatnyi gombnyomásból lesz vagy 50 karakter...
Viszont a leírás szerint a videómegszakítást használja a KEYBOARD, az viszont nem gyorsul a turboval! Akkor miért is változik a billentyûzet sebessége?
Alt+W-nél az egész emuláció gyorsul (Z80, NICK, és DAVE is), az órakártya kivételével, tehát a nagyon "lelassuló" CMOS órától eltekintve ezt az EP-s programok nem tudják érzékelni, és mivel valós (nem emulált) időben a video megszakítások is gyorsabbak, így érthető, hogy nehezebb gépelni.
Viszont turbós hardver emulációjakor - a Machine configuration ablakban a Z80 és DAVE frekvenciát átírva - nem kellene ilyen problémának lenni, és nekem jónak is tűnik, legalábbis IS-BASIC alatt, mást nem néztem. 100 MHz-s Z80-at és a memória várakozások emulációjának kikapcsolását (hogy ne legyen ~100 ciklus várakozás video RAM hozzáférésnél) beállítva még mindig jól lehet gépelni.
-
Na csináltam egy EI vadász scriptet :-)
Ezt valamivel egyszerűbben is lehet írni:
function breakPointCallback(t, a, v)
return (t == 3 or readMemory(getPC()) == 0xFB)
end
Itt egyébként az "or" utáni memória olvasás nem is fut le, ha a "t == 3" igaz (ez így van a C/C++ nyelvnél is).
-
Alt+W-nél az egész emuláció gyorsul (Z80, NICK, és DAVE is), az órakártya kivételével, tehát a nagyon "lelassuló" CMOS órától eltekintve ezt az EP-s programok nem tudják érzékelni, és mivel valós (nem emulált) idõben a video megszakítások is gyorsabbak, így érthetõ, hogy nehezebb gépelni.
Áhá! Akkor ez kavart meg, azt hittem az 50Hz marad 50Hz ilyenkor is :oops:
-
Ez EXOS "hiba", a ~ karakter érvénytelen fájlnévben.
Igazából már régebben is gondoltam arra, hogy ezt ki kéne javítani :oops:
Így néz ki a kérdéses rész EXOS 2.0-ban:
CCE6 1A LD A, (DE)
CCE7 FE 2D CP 2D
CCE9 38 23 JR C, CD0E
CCEB FE 3A CP 3A
CCED 38 15 JR C, CD04
CCEF FE 5F CP 5F
CCF1 28 11 JR Z, CD04
CCF3 FE 5C CP 5C
CCF5 28 0D JR Z, CD04
CCF7 38 02 JR C, CCFB
CCF9 D6 20 SUB 20
CCFB FE 41 CP 41
CCFD 38 0F JR C, CD0E
CCFF FE 5B CP 5B
CD01 3F CCF
CD02 38 0A JR C, CD0E
CD04 23 INC HL
CD05 77 LD (HL), A
És így 2.1-ben:
CD05 1A LD A, (DE)
CD06 FE 23 CP 23
CD08 38 2D JR C, CD37
CD0A FE 2B CP 2B
CD0C 38 1F JR C, CD2D
CD0E FE 2D CP 2D
CD10 38 25 JR C, CD37
CD12 FE 3A CP 3A
CD14 38 17 JR C, CD2D
CD16 FE 3F CP 3F
CD18 28 13 JR Z, CD2D
CD1A FE 5B CP 5B
CD1C 38 06 JR C, CD24
CD1E FE 61 CP 61
CD20 38 0B JR C, CD2D
CD22 D6 20 SUB 20
CD24 FE 41 CP 41
CD26 38 0F JR C, CD37
CD28 FE 5B CP 5B
CD2A 3F CCF
CD2B 38 0A JR C, CD37
CD2D 23 INC HL
CD2E 77 LD (HL), A
2.0 esetén invalid a 2Dh-nál (minuszjelnél) kisebb karakterek, onnantól elfogadható a 9-esig (3Ah), az alsóvonal (5Fh), a visszaper (5Ch), és nagybetûsítés után A-Z-ig.
Aztán amikor elkészültek az EXDOS-szal, rájöttek, hogy van itt némi bibi, az EXOS nem fogadja el a lemezes rendszerben gyakran használatos * és ? jokekaraktereket se :oops:
Így a 2.1-ben kibõvült a rutin, így 23h (fontjel vagy kettõskereszt UK/BRD) lett az alsó határ (ezt speciel meg az EXDOS nem fogadja el :-) ), egészen a csillagig (2Ah), majd folytatódik a minuszjeltõl (2Dh) a 9-esig (3Ah), ahogy a 2.0-ban is. Külön vizsgálattal bekerült a kérdõjel is (3Fh). Nagybetûsítés elõtt még elfogadja a 5B-60h karaktereket is.
De ez még így sem lett tökéletes, mint ahogy azt a ~ mutatja, amely 10 évvel az EP kifejlesztése után lett gyakori fájlnév karakter.
További csúnya probléma a ! nem elfogadása, mivel az EXDOS-ban ez használható a \ helyettesítésére (mivel a német billentyûzeten nincs visszaper), de ez így csak EXDOS parancsok esetén mûködik, EXOS fájlnév megadásnál nem lehet így megadni az útvonalat. Ugyanilyen funkciójú a ' is, ez esetben csak EP64-en van ez a probléma, EXOS 2.1 esetén már belekerült a szórásba :-)
A kis z feletti tartományban pedig nemcsak a PC felõl érkezõ ~ okozhat gondot, ilyet EP-n is elõ lehet állítani, az EXDOS parancsok elfogadják ~ karaktert, meg a szomszédos kapcsos zárójeleket is, valamint továbbá az összes ALT-tal elõhívható karaktert is, így pl HFONT-os rendszerben REN paranccsal elõállíthatóak EP-s ékezetes fájlnevek, MD-vel könyvtárak...
...csak betölteni nem lehet az ilyeneket tartalmazó fájlokat :-)
Ezért én azt mondanám, hogy ne lacafacázzunk, legyen elfogadva a teljes EP-s karakter tartomány (33-160)!
Vélemény?
-
Ezért én azt mondanám, hogy ne lacafacázzunk, legyen elfogadva a teljes EP-s karakter tartomány (33-160)!
Vélemény?
Nem tartom jó ötletnek, ha szerény véleményemre vagytok kíváncsiak. Abból lenne csak kavarodás. Konzervatív vagyok, csak a hullámjelet adjuk hozzá az elfogadható karakterekhez.
-
Szerintem jó ötlet, és ha jól látom, akkor a kód is egyszerűsödne, maradna pár szabad bájt, ami esetleg később jól jöhetne.
-
Na, nem mintha ebben a témában annyira otthon lennék, de ha igazából nincs gyakorlati haszna annak, hogy egyes karakterek nem fogadhatók el, akkor miért ne lehetnének elfogadhatók mind...
-
Na, nem mintha ebben a témában annyira otthon lennék, de ha igazából nincs gyakorlati haszna annak, hogy egyes karakterek nem fogadhatók el, akkor miért ne lehetnének elfogadhatók mind...
Az EP fejlesztői szemmel láthatóan az MS-DOS kompatibilitást tűzték ki célul.
-
Az EP fejlesztői szemmel láthatóan az MS-DOS kompatibilitást tűzték ki célul.
Ezzel a változtatással maradnánk MS-DOS kompatibilisek, ez a módosítás csak az EXOS-t érintené, ha jól sejtem, ott is a LOAD rutint.
-
Az EP fejlesztõi szemmel láthatóan az MS-DOS kompatibilitást tûzték ki célul.
Akkor kompromisszumos megoldásként megnéztem PC-n a nagyjából EP korabeli 2.1-es DOS-t, ez alapján lehetne 33-126-ig.
-
Azt nem lehetne, hogy az EXOS fogadja el azokat a karaktereket, amiket az EXDOS is elfogad?
-
Azt nem lehetne, hogy az EXOS fogadja el azokat a karaktereket, amiket az EXDOS is elfogad?
Pont ezt javasoltam tegnap :-)
-
MS-DOS 3.3 már elfogad 127 feletti kódokat is.
-
Pont ezt javasoltam tegnap :-)
Akkor, én meg erre bólogattam bőszen :) , és még mindig bólogatok ;)
-
MS-DOS 3.3 már elfogad 127 feletti kódokat is.
Ok, megadom magamat... :lol:
-
Azt nem lehetne, hogy az EXOS fogadja el azokat a karaktereket, amiket az EXDOS is elfogad?
Nem tudom, a témához tartozik-e, de egyszer olyan problémám adódott, hogy magnóról floppyra másolásnál a magnós * jelet nem tudta átmásolni floppyra. Esetleg lehetne azt, hogy magnóra ne lehessen ilyen floppys vezérlõkódos karaktereket menteni. Persze ha régebbi, így kimentett fájlt felismer, az jó.
-
EPDOS-szal kell magnóról másolni, az minden fájlnál megkérdezi a fájlnevet :)
Sok értelme nem lenne ilyen korlátozásnak, amúgy is más szabályok játszanak magnón, pl nincs a 8+3-as név korlátozás.
-
Nem tudom, ide tartozik-e, vagy egy új verziószámú IS-BASIC kéne.
Majd lehetne a következõ verzióban javítani azt a bugot, hogy AUTO sorszámozásnál a READ IF MISSING... után ne a 616-os sor jöjjön mindig.
Ha jól emlékszem, volt még néhány utasítás, ami "összekócolta" a sorszámozást, de már nem tudom, mik voltak azok...
-
- A PRINT USING (http://ep128.hu/Ep_Konyv/Enterpress_Tippek.htm) is hibás.
- ha jól tudom, ahhoz, hogy a gép elfogadja a GOTO-t parancsmódban, egyetlen byte-ot kellene átírni.
- és akkor már a VERNUM értékét is érdemes lenne módosítani
-
Szerintem az a baj, ha ezek a javítások megtörténnek, akkor az új BASIC verzió alá fogják ezentúl írni a programokat (na nem mintha tolonganának a programozók :D ), amik a régi verzióval már nem mûködnek, és sokan vannak talán, akik a régi verziókat nem cserélik majd le az igazi Enterprise-on (pl. külföldiek). Persze emulátoron én is EXOS 2.31-et használok már.
Igaz, talán a PRINT USING kivételével nem érintenék a BASIC programozást ezek a hibajavítások.
Az EXT utasítás utáni GOTO sem kell már az új verzióban, de ezáltal az új BASIC programok, amik már nem használnak GOTO-t ilyenkor, már nem kompatibilisek a régi BASIC verziókkal...
-
- ha jól tudom, ahhoz, hogy a gép elfogadja a GOTO-t parancsmódban, egyetlen byte-ot kellene átírni.
Van ennek jelentõsége?
Parancsmódban használható a GOTO 50 helyett a RUN 50.
Talán valamiért így látták célszerûnek az IS-BASIC megalkotói - nem tudom, miért.
De ettõl is egyéni az IS-BASIC, ahogy pl. a START parancs sincs meg tudtommal más basicben.
-
Szerintem az a baj, ha ezek a javítások megtörténnek, akkor az új BASIC verzió alá fogják ezentúl írni a programokat
Nem hiszem, hogy ez manapság nagyon "fenyegető" probléma lenne... :ds_icon_cheesygrin:
A fenti problémák kiszűrésére lenne alkalmas a VERNUM változó ellenőrzése.
-
Van ennek jelentõsége?
A RUN és a START törli a változókat, a GOTO nem.
Nekem igazából ez sosem volt probléma, SPECTRUM-ról áttérők vetették fel anno.
-
vagy hibás a RAM a gépben. Az utóbbi esetben könnyen lehetséges, hogy a hiba csak M1 (utasítás) olvasásnál és várakozás nélkül fordul elõ, és így is csak bizonyos címeken vagy akár egyetlen byte-on.
Az ilyen X-aktás esetek miatt gondolkozom azon, hogy kéne egy olyan EP-s RAM teszt, mint ami PC-n a Memtest86+ (http://www.memtest.org/) , ahol nem a gyorsaság a lényeg, hanem az, hogy minél több módszerrel, minél jobban megkínozza a memóriát, hogy kibukjanak az ilyen dolgok.
István! Lenne ötleted, miféle algoritmusokkal kéne nekiesni?
Magát a programot úgy képzelném, hogy az EXOS 2.4-ben lehetne induláskor egy gombnyomással elõcsalogatni, de lenne betölthetõ verziója is a hagyományos gépek számára. meg kapná egy listában az alap RAM teszt alapján felderített RAM szegmensek listáját, aztán azt kínozná, amíg le nem lövik :-)
Ne kelljen játékfagyásokat keresgélni, vagy RAMDISK másolásokkal fájlsérülést keresni, stb hanem legyen egy olyan teszt ami 99.999%-ra kihozza, hogy jó-e a konfig vagy se.
-
Az ilyen X-aktás esetek miatt gondolkozom azon, hogy kéne egy olyan EP-s RAM teszt, mint ami PC-n a Memtest86+ (http://www.memtest.org/) , ahol nem a gyorsaság a lényeg, hanem az, hogy minél több módszerrel, minél jobban megkínozza a memóriát, hogy kibukjanak az ilyen dolgok.
István! Lenne ötleted, miféle algoritmusokkal kéne nekiesni?
Talán át lehetne venni néhány ötletet a memtest86-ból :) Itt (http://www.memtest86.com/tech.html#philo) található rövid leírás a különböző algoritmusokról. Érdekes probléma lehet még a csak utasításelérésnél (M1), a rövidebb időzítés miatt előforduló hibák keresése.
-
Érdekes probléma lehet még a csak utasításelérésnél (M1), a rövidebb idõzítés miatt elõforduló hibák keresése.
Olyanra gondoltam, hogy valami 16K-n keresztül futó bonyolult számítást kéne generálni, ami megáll HALT-tal a szegmens végén. Beprogramozni egy 1 Hz-es megszakítást, és az IRQ-n keresztül lép ki a tesztbõl, és ellenõrzi, hogy a regiszterekben az elvárt eredmény van-e. Ha netán összekutyulódik hiba miatt, akkor is van esély, hogy a megszakítás lelövi az elszabadult programot. Legrosszabb esetben azt látja a felhasználó, hogy a TESTING xx-nél lefagyott, végülis ez is felér egy hibaüzenettel :ds_icon_cheesygrin:
-
Esetleg megfontolandó lenne, hogy a HFONT-ot berakjuk az EXOS mellé, mivel az EPDOS-ból kikerült, de "ipari szabvány" lett.
-
mivel az EPDOS-ból kikerült
1.9-be visszakerült.
-
Van 2.2 -es exos is? Ha igen, az miben más mint a gyári 2.1?
-
Van 2.2 -es exos is? Ha igen, az miben más mint a gyári 2.1?
Van:
(http://ep128.hu/Ep_Util/Pic/Exos22.gif)
Ha igen, az miben más mint a gyári 2.1?
Lásd itt. (http://ep128.hu/Ep_Util/Exos.htm)
-
Lásd itt. (http://ep128.hu/Ep_Util/Exos.htm)
Igazából itt sincs sok szó "vesztegetve" a 2.2-es változatra...
Tényleg, mi az, ami már a 2.2-ben is benne volt? csak a gyorsteszt?
-
Tényleg, mi az, ami már a 2.2-ben is benne volt? csak a gyorsteszt?
Volt gyorsteszt, de kevesebbet tudott: nem volt még ROM szimulációs lehetõség, és EDCW bõvítések megõrzése, és a kijelzés is kevésbé részletes.
WP 2.6 és a EXT hibával javított BASIC már benne volt ebben is.
-
A Kurczu gépében (http://enterpriseforever.com/hardver/milyen_ep_konfigod_van-t31.0.html;msg14547#msg14547) egyébként olyan EXOS 2.2-t találtam, ami még nem keres minden szegmensen ROM-ot, csak 64K-s EPROM-ra van gondolva, így F3-F0, E3-E0,.... 13-10, 07-04, 03-02 szegmenseken keres.
-
Ha nagy cpu orajelre allitom a szimulatort, akkor ugye begyorsur a cursor villogasa es a hanglejatszas ( gondolok itt elsosorban a billentyuzethangra, de gondolom nem csak arra korlatozodik ) is begyorsul es igy magasabb hangon jatszik le, ill. rovidebb ideig tart.
Ez a ket funkcio kozul egyik sem lett vona megszakitasokkal idozitve az exosban ? Hogyhogy felgyorsulnak ezek ?
-
Ha nagy cpu orajelre allitom a szimulatort, akkor ugye begyorsur a cursor villogasa es a hanglejatszas ( gondolok itt elsosorban a billentyuzethangra, de gondolom nem csak arra korlatozodik ) is begyorsul es igy magasabb hangon jatszik le, ill. rovidebb ideig tart.
Ez a ket funkcio kozul egyik sem lett vona megszakitasokkal idozitve az exosban ? Hogyhogy felgyorsulnak ezek ?
Gondolom a Dave magasabb órajele miatt gyorsul a hangképzés meg a megszakítás is. 6 MHz-re viszont felkészítették...
-
a dave ezexerint a cpu urajelerol menne ? es valahogy a hangkepzesenek a generalt frekijeibe beleszamit a bemeneti orajele ?
es ki es hogyan keszitette fel a 6 mhz- re ?
es a kurzor villogas ? nics szinkronizalva egy 50hz- hez, vagy valami ilyen cpu orajel fuggetlen dologhoz ?
-
es ki es hogyan keszitette fel a 6 mhz- re ?
A BFh (191) port 1. bitjének a beállítása - pl. BASIC-ben "out 191, 6" - 2/3-ára lassítja a DAVE-t.
es a kurzor villogas ? nics szinkronizalva egy 50hz- hez, vagy valami ilyen cpu orajel fuggetlen dologhoz ?
A kurzor villogásának az időzítése nem megszakítás alapú, és a sebessége a Z80-tól függ.
-
Megneztem a bf port leirasat, akkor ez azt jelenti, hogy anno mikor a dave- et terveztek es legyartottak, mar akkor gondoltak arra, hogy majd a cpu orajele fogja ot is hajtani, es gondoltak hogy lehessen mind 4 mind 6 mhz- es z80- nal ( orajelevel ) hasznalni ?
Es miert 8 ill. 12 megahertznek hivja a doksi ? Van a dave- ben ( vagy a z80 orajele es a dave bemenete kozott ) meg valami freki duplazo ?
Es ez egyebkent azt is jelenti, hogy ha betennenk +1 orajelgeneratort az ep- be, hogy sajat orajelrol menjen a dave, akkor fuggetleniteni lehetne a z80- tol ? vagyis lehetne az, hogy az emuban ( ha ez emulalva lenne ), akkor mondjuk 40 mhz- n megy a z80, de a hangok meg ugyanugy szolnak ?
Mert ha ez igy lehetne, akkor ugye lehetne 10X sebesseggel forditani emun mondjuk heassban, de a billhangok meg maradnanak normalisak. Meg ugy egyebkent is tok jo hogy olyan gyors az ep... minden veszett modon gyors mar mondjuk 40 mhz- es cpu frekin ... gyorsan valtanak a programok egyikrol a masikra, stb. tok villamvill lesz tole az emulalt ep. tok gyorsan frissiti a kepet, stb. csak eltolja a hangokat.
Az meg hogy van hogy a cpu- tol fugg a cursor villogas ? En ugy tudom hogy a kurzor villogas az valahogy altalanositva van az exosban. ( talan meg a sebesseget is lehet allitani ... nem emlexem ) de az biztos hogy nem az egyes programok valositjak meg a villogast ( basic, exdos, wp, stb. ) hanem valahogy az exos.
namost mikor a programok futnak, olyankor az exos nem fut ... nem tud loop- ot futtatni kurzor villogashoz ... csak valami megszakitasbol kellene villogtassa ... hogy csinalja ezt cpu- val ?
-
Esetleg a VIDEO: kezelõt bõvíteni BASIC -al egyetemben HIRES, LORES, ZXRES ilyenkor nem kellene megadni a
VIDEO 32
VIDEO 24
VIDEO MODE ZX
De lehet, hogy nem lehet ilyen nagy LPT blokkot behelyettesíteni EXOS-ba?
Ezzel a megoldással már közelebb lehetne lépni az EXOS kompatibilitás hoz.
Maradhatna az IM1-es RST 30H megszakítás.
Lehet a ZX program lassabban fog futni de a program alatt lehetne Exos parancs sort használni.
-
Es miert 8 ill. 12 megahertznek hivja a doksi ? Van a dave- ben ( vagy a z80 orajele es a dave bemenete kozott ) meg valami freki duplazo ?
Nem duplázó hanem osztó Nick-be megy be ott osztja 2-vel és küldi a Z80-nak és ami a NICK-be megy az megy a Dave-be
Es ez egyebkent azt is jelenti, hogy ha betennenk +1 orajelgeneratort az ep- be, hogy sajat orajelrol menjen a dave, akkor fuggetleniteni lehetne a z80- tol ? vagyis lehetne az, hogy az emuban ( ha ez emulalva lenne ), akkor mondjuk 40 mhz- n megy a z80, de a hangok meg ugyanugy szolnak ?
Igen fügettlen generátor a Dave-nek 8MHz ,a NICK -> Z80 meg egy másik 12/6/,16/8/,20/10/ MHz
Mert ha ez igy lehetne, akkor ugye lehetne 10X sebesseggel forditani emun mondjuk heassban, de a billhangok meg maradnanak normalisak. Meg ugy egyebkent is tok jo hogy olyan gyors az ep... minden veszett modon gyors mar mondjuk 40 mhz- es cpu frekin ... gyorsan valtanak a programok egyikrol a masikra, stb. tok villamvill lesz tole az emulalt ep. tok gyorsan frissiti a kepet, stb. csak eltolja a hangokat.
Emuban én erre a "W" billentyût használom mikor fordítom a kódokat max sebességre rakom aztán amit a gép bír miután lefordította visszatérek a normál sebességbe.
-
Megneztem a bf port leirasat, akkor ez azt jelenti, hogy anno mikor a dave- et terveztek es legyartottak, mar akkor gondoltak arra, hogy majd a cpu orajele fogja ot is hajtani, es gondoltak hogy lehessen mind 4 mind 6 mhz- es z80- nal ( orajelevel ) hasznalni ?
Igen.
Es miert 8 ill. 12 megahertznek hivja a doksi ? Van a dave- ben ( vagy a z80 orajele es a dave bemenete kozott ) meg valami freki duplazo ?
A rendszer órajel 8 (vagy 12) MHz, ez egyben a DAVE órajele, a Z80-é pedig ennek a fele.
Es ez egyebkent azt is jelenti, hogy ha betennenk +1 orajelgeneratort az ep- be, hogy sajat orajelrol menjen a dave, akkor fuggetleniteni lehetne a z80- tol ? vagyis lehetne az, hogy az emuban ( ha ez emulalva lenne ), akkor mondjuk 40 mhz- n megy a z80, de a hangok meg ugyanugy szolnak ?
Az emulátorban nincs akadálya a független órajelnek, már most is be lehet állítani jóval nagyobb Z80 frekvenciát a hang változása nélkül.
Az meg hogy van hogy a cpu- tol fugg a cursor villogas ? En ugy tudom hogy a kurzor villogas az valahogy altalanositva van az exosban. ( talan meg a sebesseget is lehet allitani ... nem emlexem ) de az biztos hogy nem az egyes programok valositjak meg a villogast ( basic, exdos, wp, stb. ) hanem valahogy az exos.
A villogást az EDITOR: eszköz valósítja meg (akkor látható, amikor az EDITOR: bemenetre vár), ha jól tudom, és az időzítése egyszerű üres ciklust használ.
-
Emuban én erre a "W" billentyût használom mikor fordítom a kódokat max sebességre rakom aztán amit a gép bír miután lefordította visszatérek a normál sebességbe.
Nalam a w billentyu w karaktert ir ... :) Nem ertem mire gondolsz ...
-
Nalam a w billentyu w karaktert ir ... :) Nem ertem mire gondolsz ...
Alt+W
-
Az emulátorban nincs akadálya a független órajelnek, már most is be lehet állítani jóval nagyobb Z80 frekvenciát a hang változása nélkül.
Hat en most bementem a konfigba, es utanairtam a cpu 4 000 000 hertzenek egy plussz nullat igy lett belole 40 000 000
Ha igy futtatom az emut, akkor a click hang egy ilyen pottyenesre modosul ...
Nem a rendes billentyu klikk hang szol ...
Ha ugy lenne ahogy mondod, akkor a rendes klikk hang szolna, 10X- es cpu sebessegnel is, nem ?
-
Alt+W
Igen, a W Gyorsbillentyû azaz ALT+W
-
Hat en most bementem a konfigba, es utanairtam a cpu 4 000 000 hertzenek egy plussz nullat igy lett belole 40 000 000
Ha igy futtatom az emut, akkor a click hang egy ilyen pottyenesre modosul ...
Nem a rendes billentyu klikk hang szol ...
Ha ugy lenne ahogy mondod, akkor a rendes klikk hang szolna, 10X- es cpu sebessegnel is, nem ?
De lehet,hogy csak 1/10-ed ideig hallanád
-
Igen, a W Gyorsbillentyû azaz ALT+W
aham, jo trukk ez, ha igazan nagy a forditani valo forras, de ezen a sebessegen gepelni, ilyesmit mar nem nagyon lehet,
jo lenne nekem a 10X-20X -os sebessegnovekedes is, ekkor meg kenyelmesen lehet gepelni is, meg mar kisebb forrast eleg gyorsan is fordit, csak a kurzorvillogas bolondul meg tole, meg a klikkhang torzul el.
-
De lehet,hogy csak 1/10-ed ideig hallanád
ja, hogy abbol eredne a "torzulas" hogy a klikk hangok mar egymasba ernenek, es az ep meg nem mixelne ossze oket egymas melle, hanem mindegyiknek csak az elejet hallanam ?
na kiprobalom akkor 2X- ezessel meg ilyenek... akkor meg nem szabad egymasba erjenek ( mert rovid a klikk hang ) csak surubben, de ugyanolyan magassagban/ideig kene szoljanak ...
-
Ha ugy lenne ahogy mondod, akkor a rendes klikk hang szolna, 10X- es cpu sebessegnel is, nem ?
A key click időzítése szintén üres ciklus alapú. Egyébként a nagyobb gyorsuláshoz érdemes kikapcsolni az "Enable memory timing emulation"-t, mert a video RAM sebessége nem változik (azaz nagy Z80 órajelet beállítva akár 100-nál több ciklust is kellene várni rá). Az újabb PC-ken akár 200-250 MHz-es Z80 is emulálható.
-
Kiprobaltam, nem ez a jelenseg, ha csak 8 000 000 allitom a cpu orajelet,
akkor sem csak surubben hallom a klikk hangot,
hanem maga a klikk hang is megvan valtozva, "torzulva", magassagban emelkedve ...
-
A key click időzítése szintén üres ciklus alapú.
Na ezt mar vegkepp nem ertem. A kurzor villogas meg ok, utana kell nezzek mit tud interfeszben az az editor: eszkoz, de gondolom mikor meghivom valami funkciojat, akkor blokkol, es addig ( ezexerint ures ciklus alapon ) villogtatja a kurzort, mindenki ezt hivja, es mikor visszater, akkor mar nem villogtatja a kurzort ...
Vagy ugyanez van a klikk hangnal is ... ameddig a editor: eszkoz fut, klikk hangot is csak addig tud adni, es akkor az is ilyen Z80 alapon idozitve van megoldva, amig az editor: eszkozben van a loop ?
Es akkor nincs is ilyen funkcio az exosban hogy siman csak "adj ki klikk hangot", vagy ha van is, akkor az is blokkol ? Mert pld. "ping" hang mintha remlene, hogy van benne ... vagy a "ping" hang kiadasa is blokkol, mert Z80 alapon van idozitve ?
-
Pld. a key wait/repeate tokeletesen mukodik 100 mhz- es z80- nal is ... gondolom azokat megszakitassal idozitik ...
Muszaly hogy a kurzor/klikk hang z80- nal legyen idozitve ? lehetseges egy olyan exos ( ezek szerint editor: eszkoz ?) modositas ahol a kurzor villogas es a klikk hang megszakitas alapon idozitodik ?
-
Az EXOS 2.0 és 2.1 hibája, hogy a basic EXT után egy GOTO is kell a programban (http://wiki.enterpriseforever.com/images/0/0b/Basichibaexos21.gif), teljesen ki lett javítva? Az emulátorban próbálkoztam, és nem okozott gondot, ha NEXT elõtt nincs GOTO, az EXOS 2.0-ban és a 2.1-ben sem.
Ja, és ide (http://wiki.enterpriseforever.com/index.php/Unofficial_EXOS_versions_by_Zozosoft) az EXOS 2.32-rõl nem kéne írni valamit?
-
Az EXOS 2.0 és 2.1 hibája, hogy a basic EXT után egy GOTO is kell a programban (http://wiki.enterpriseforever.com/images/0/0b/Basichibaexos21.gif), teljesen ki lett javítva? Az emulátorban próbálkoztam, és nem okozott gondot, ha NEXT elõtt nincs GOTO, az EXOS 2.0-ban és a 2.1-ben sem.
Ez a IS-BASIC hibája, az emulátor ROM csomagjában a javított BASIC ROM-ok vannak benne.
-
Ez a IS-BASIC hibája, az emulátor ROM csomagjában a javított BASIC ROM-ok vannak benne.
De akkor már nem az eredeti 2.0-ás és 2.1-es basic romok azok. Vagy az nem baj? (Csak mert akkor nem kompatibilis az emulátor 2.1 basicjében írt program az igazi EP 2.1-es basicjével, mert ha ott elfelejt GOTO-t tenni EXT után a felhasználó, nem lesz hiba, de igazi gépen már lesz. Vagy igazi gépen már úgyse használ senki 2.1-es vagy régebbi eredeti basic-et?)
-
Azt lehetséges megoldani, hogy az EDITOR: a 129-157 közötti ASCII kódú karaktereket betûnek tekintse, ahol nem illik kettévágni sortörésnél a szavakat? Ezzel a WP is a "használhatatlan" kategóriából a "gyengén használható"-ba kerülne...
-
EXOS 2.3 EXOS 2.0 kompatibilissá téve :ds_icon_cheesygrin:
Na jó, pontosítsunk: a gyorsteszt rész, ami múltkor már cartridgeba tehetõ formában is elkészült, azok számára, akik nem akarják megbontani a gépet. Ez most már egyaránt mûködik 2.0 és 2.1 EXOS-al is. Ha el nem rontottam valamit :oops: kéretik tesztelgetni!
Így ugyanaz a gyorstesztes cartridge jó lesz EP64 és 128-hoz is. (Na nem mintha eddig túl sok féle lett volna EP64-hez, csak a múltkor kijavított ASMON 1.5-ben lévõ.)
-
kéretik tesztelgetni!
Ez hogyan mûködik?
Ha 4-es szegmensre rakom és a BASIC-et az 5-ösre nincs BASIC.
ha a BASIC marad 4-esen, nincs gyorsteszt.
Azért kellene ebbõl is angol, hisz az EP64 tulajdonosok jellemzõen nem magyarok
-
Ha 4-es szegmensre rakom és a BASIC-et az 5-ösre nincs BASIC.
Mért ne lenne??? :shock:
[attachthumb=1]
Azért kellene ebbõl is angol, hisz az EP64 tulajdonosok jellemzõen nem magyarok
Van belõle az is, csak azzal most nem akartam a fórum szerverét tömni :-)
-
[attachthumb=1]
-
(Attachment Link)
No, ez már érdekes!!! :smt041
-
No, ez már érdekes!!! :smt041
Az a "Z80" felirat csak sima "PRINT", vagy kiírja a proci típusát? Bár jobban belegondolva nem hiszem, hogy lehet dekektálni, hogy Z80, Z80A vagy Z80B van a gépben.
-
Ja, és ez már kész van? Mikor lehet próbálgatni?
-
Az a "Z80" felirat csak sima "PRINT", vagy kiírja a proci típusát? Bár jobban belegondolva nem hiszem, hogy lehet dekektálni, hogy Z80, Z80A vagy Z80B van a gépben.
Azt sajnos nem lehet, az NMOS/CMOS-t megpróbálom. (CPC-s Pinballnál jött elõ a kérdés anno.)
-
Gondolom az órajelmérésen kívül a 191-es portot is beállítja?
-
Gondolom az órajelmérésen kívül a 191-es portot is beállítja?
Igen, és erre menet közben is figyel, és pár másodperc után átállítja.
Ehhez majd lesz egy új EXOS változó is, amivel tiltható a funkció, ill. a memória várakozás értéke adható meg.
Ennek kapcsán közvélemény kutatás:
Akarjuk-e még alapértelmezésben lassítani a gépet? :)
Tehát az utasításonkénti várakozás alapértelmezésben:
a) bekapcsolva, mint eddig
b) kikapcsolva, hogy a gép teljes sebességgel menjen
c) bekapcsolva, de indításkor gombnyomással tiltható (azaz az új EXOS változó ennek megfelelõ értékkel indul)
d) kikapcsolva, de indításkor gombnyomással engedélyezhetõ (azaz az új EXOS változó ennek megfelelõ értékkel indul)
-
Akarjuk-e még alapértelmezésben lassítani a gépet? :)
Tõmondatban: nem.
Kicsit bõvebben: az órajelfigyelés mennyi idõt visz el? a gondolom azért "kompenzál" valamit?
-
c) bekapcsolva, de indításkor gombnyomással tiltható (azaz az új EXOS változó ennek megfelelõ értékkel indul)
C opcióra szavazok.
-
Igen, és erre menet közben is figyel, és pár másodperc után átállítja.
És 7.12 MHz-re mit lép? Eddig az EXOS csak a 6 MHz-t tudta idõzítésben kezelni.
-
Ja, és ez már kész van? Mikor lehet próbálgatni?
Nagyon nincs még kész, de a türelmetlenek próbálgathatják :-) beta teszterek meg pláne jól jönnek :ds_icon_cheesygrin:
Órajel figyelésen kívül változások:
-beépítésre került a sípolós teszt funkció (http://enterpriseforever.com/hardver/diagnosztikai_romok-t155.0.html;msg5132#msg5132), ezt mûködõ gépen csak B gomb indításkori lenyomásával jön elõ :-)
Az EXOS úgy indult, hogy elsõként letesztelte az FF szegmenst, és ha az hibás, akkor pörgõ keretszínnel jelezné a hibát. Viszont a gyakorlati tapasztalat azt mutatta, hogy ez nem valósul meg, mivel a tesztet CALL-al hívja meg, miközben a verem az ellenõrizetlen FE szegmensben van, amely ugyanazokat a RAM IC-ket használja, mint az FF. Így ha az hibás, a verem is az lesz, a CALL-ból nem tér vissza, a végeredmény se kép se hang gép...
A 2.4-ben a CALL elõtt leteszteli az FF elsõ bájtját (0-255 értékekkel), ha hibás, akkor ugrik a sípolós tesztre. (Ill. a B gombbal egybõl ez indul).
-a soha nem használt SLOW teszt le lett cserélve ADVANCED-re, ami a korábbiaknál sokkal alaposabban vizsgálja át a memóriákat (lásd PC-n Memtest86), itt külön említendõ a RANDOM FILL teszt, ami pszeudo véletlenszámokkal tölti fel a szegmenst, és ellenõrzi le. A véletlenszám generátor a szegmensszámmal van inicializálva, így minden szegmens egyedi mintával lesz feltöltve, ami a végsõ összeszámolós fázisban újra vissza lesz ellenõrizve. Itt a visszaellenõrzés elõtt vár egy gombnyomásra, így lehetõség van a RAM frissítés tesztelésére, ott kell hagyni pár órára a gépet, és utána engedni tovább.
-címvezeték hibák feltárása is fejlesztve lett, minden szegmens elejére beírja a szegmensszámot és az invertáltját, ezt visszaellenõrzi a szegmensen belüli teszt után (ez eddig még nem volt), és végén az összeszámolós fázisban is.
-
És 7.12 MHz-re mit lép? Eddig az EXOS csak a 6 MHz-t tudta idõzítésben kezelni.
Ez nem az EXOS-on múlik, hanem a DAVE-n. Ahhoz is a 6-ost állítja be, mint a kisebbik rossz :-)
-
Tényleg, és a BRD-féle módosított LPT belekerült? Ügye nem megszakításban?
-
Ez az Advanced test nagyon komoly! :smt041
-
Tõmondatban: nem.
C opcióra szavazok.
Akkor most nem vagy igen? :oops:
Kicsit bõvebben: az órajelfigyelés mennyi idõt visz el? a gondolom azért "kompenzál" valamit?
Nem sokat, alig pár utasítást, mármint ez a 191 állítgató.
Az 50Hz-es megszakításban növel egy számlálót, az 1Hz-es megszakításban megnézi, hogy 50 lett-e? Ha túl sok (4Mhz Z80 6Mhz-re állított DAVE-el), vagy túl kevés (turbó Z80 4Mhz-re állított DAVE-el), akkor korrigál. A korrigálás feltétele az is, hogy az aktuális és a megelõzõ mérés eredménye egyforma legyen, mivel lehet másodperc közbeni átkapcsolás, vagy megszakítás letiltás (pl lemez mûvelet) miatt ingadozás. Ebbõl adódik a pár másodperc reakcióidõ.
Ebben az esetben nem akarunk pontos órajelet mérni, csak azt, hogy az aktuális DAVE beállítás lassú vagy gyors. Induláskor viszont pontos érték kell, itt az van mérve, hogy egy 50Hz-es megszakítás alatt mennyi INC HL fut le, és a kapott értékbõl számolva az órajel. (Egyelõre 13.435 Mhz-ig számol jól, ez valódi gépen bõven lefedi a lehetõségeket :-) emulátoron efölött marhaság lesz :oops: )
-
Akkor most nem vagy igen? :oops:
d. pont, d. pont, nyomdahiba... :oops:
-
d) kikapcsolva, de indításkor gombnyomással engedélyezhetõ (azaz az új EXOS változó ennek megfelelõ értékkel indul)
Ha jól értem, akkor nekem is ez tetszik inkább.
Tehát azt jelenti, hogy ha memóriateszt alatt lenyomunk valamit, az egyenértékû azzal, mintha kiadnánk az OUT 191,12 utasítást?
Bár szerintem akkora ügyet nem kell csinálni belõle. Aki nagyon akarja, basicbõl is kiadhatja az OUT 191,12-õt. Talán vannak idõrabló utasítások, amik megvárakoztatnak, esetleg ezek idejére bekapcsolhat az OUT 191,12, de nem is tudok fejbõl ilyen utasításokat. Talán magnóról töltés közben, hogy picivel rövidebb legyen a PAUSE, de ez nem is lenne észrevehetõ.
Szerintem alapból bekapcsolni nem jó, mert ha így indítjuk el a régi programokat, a szokottól eltérõ sebességgel fognak futni, ami nem szimpi.
Hanglejátszáskor is gyorsít. Amikor egy zenélõ programnál futtatás végén megjelenik az OK felirat, de a zene még megy, begyorsul.
De lehet, hogy rosszul értem az egészet...
-
Szerintem alapból bekapcsolni nem jó, mert ha így indítjuk el a régi programokat, a szokottól eltérõ sebességgel fognak futni, ami nem szimpi.
Hanglejátszáskor is gyorsít. Amikor egy zenélõ programnál futtatás végén megjelenik az OK felirat, de a zene még megy, begyorsul.
Ezért lesz a plusz billentyû, ha valaki játszani akar, azt kell megnyomni...
A hang nem változik, pont ezért állítgatja a 191-es portot.
-
Sikerült egyszer BASIC-bõl úgy melegreset-elnem, hogy kiakadt. Órajelmérés közben reset-et kezeli?
-
Sikerült egyszer BASIC-bõl úgy melegreset-elnem, hogy kiakadt. Órajelmérés közben reset-et kezeli?
Órajelmérésnek biztos nincs köze hozzá. Sõt úgy általában a 2.4-nek se :-)
Körülmények? Lehet, hogy még más programban is lappang valami bug, ahogy azt korábban találtunk már az Asmonban és az EXOS-ban is.
Nyomogattam most úgy kb 100 melegindítást 2.4+EXDOS konfigban, de nem sikerült semmi rendelleneset produkálni.
-
Körülmények? Lehet, hogy még más programban is lappang valami bug, ahogy azt korábban találtunk már az Asmonban és az EXOS-ban is.
BASIC-bõl TEXT 80 módban programlistázás közben RESET-et nyomtam. Programban semmiféle gépi kódú rutin nem volt, ami megbolygathatta volna a gép lelkivilágát.
Én is kb. 100-szor nyomtam azóta RESET-et, de még nem sikerült reprodukálni.
-
Zozo!
A click hangból úgy veszem észre, hogy a melegreset visszaállítja a 191 port értékét. Most már ennek nincs jelentõsége, sõt keresztbe dolgozik az új "módival".
-
A click hangból úgy veszem észre, hogy a melegreset visszaállítja a 191 port értékét. Most már ennek nincs jelentõsége, sõt keresztbe dolgozik az új "módival".
Majd a következõ verzió ezt is megoldja :-)
-
:smt041 :smt041 :smt042
Nagyon jól néz ki az EXOS 2.4 tesztje, egyelőre csak képen láttam :oops:, de az szimpi :)
-
Ez az Advanced test nagyon komoly! :smt041
Nem szép dolog az öndicséret, de az eddigi valódi gépeken végzett tapasztalatok alapján határozottan jól mûködik :ds_icon_cheesygrin:
Idézet a 320K cikkbõl: (http://gafz.enterpriseforever.com/Hardware/320k/320.htm)
"Megjegyzem hogy találkoztam már olyan memóriabõvítéssel, amelyik nem foglalkozott az utóbb ismertetett frissítés megoldásával, és csodák-csodájára mûködött is!"
Keveredett hozzám is egy ilyen gép, eddigi tesztekkel, akár normál EXOS teszttel se látszott semmi probléma, csak voltak "furcsa dolgai"...
[attachthumb=1]
Advanced test egybõl kihozza, hogy 64K OK, 256K BAD :ds_icon_cheesygrin:
Szalai régóta nálam lévõ :oops: :oops: :oops: :oops: :oops: gépénél is végre egzaktul megmutatja, hogy alaplapi 64K-n kívül semmilyen DRAM-ot nem kezel rendesen. Eddig ez se látszott semmilyen tesztben, csak homályos, nehezen reprodukálható RAMDISK ide-oda másolások, Small Demo futtatás, és hasonlókkal látszott, hogy valami nincs rendben.
Bevallom ez a gép volt az ösztönzõ a fejlettebb RAM teszt írásához :-)
-
Újabb beta verzió, már van rendszerváltozó a 191-es porthoz, stílszerûen 191-es :-) szerencsére ez még szabad volt.
Használata kb ugyanaz mint a 191-es port, tehát pl SET 191,12 vagy SET 191,4
0. bit nincs használva
1. bit automatikusan beáll az órajelérzékelés függvényében (0 normál, 1 turbo)
2-3. bit a memóriavárakozásokat állítja be
4-6. bitek nem használtak
7. ha 1, akkor a 191 port állítgatása letiltva.
A teszt képernyõn már a Z80 típusa (NMOS/CMOS) is látható.
-
EXOS 2.4 beta 3
-Már nem fagy valódi gépen (lásd Z80 reset téma) (http://enterpriseforever.com/programozas/z80-reset/msg32201/#msg32201)
-resetnél az aktuális frekvencia kerül visszaírásra a 191-es portra
-memória várakozások alapértelmezésben tiltva (SET 191,4 engedélyezi)
-
Újabb beta verzió, már van rendszerváltozó a 191-es porthoz, stílszerûen 191-es :-) szerencsére ez még szabad volt.
Használata kb ugyanaz mint a 191-es port, tehát pl SET 191,12 vagy SET 191,4
.
.
.
7. ha 1, akkor a 191 port állítgatása letiltva.
És ha későbbiekben módosítani szeretném a 191-es portot akkor az hogyan fogom?/ Kikapcsolom a gépet/
Vagy csak bekapcsolás után addig módosítgatom amíg a 7. bittet be nem állítóm?
-
OUT 191 helyett SET 191-et írsz a programba.
Vagy a 7. bitet 1-re a változóban, onnantól mehet az OUT-olás.
Ha egyébként az órajel nem változik, akkor nem írja felül az OUT-olt értéket.
-
OUT 191 helyett SET 191-et írsz a programba.
Vagy a 7. bitet 1-re a változóban, onnantól mehet az OUT-olás.
Ha egyébként az órajel nem változik, akkor nem írja felül az OUT-olt értéket.
Ezt most nem értem, akkor az előző nem jó "7. ha 1, akkor a 191 port állítgatása letiltva."
De ha a port írást letiltom ... várjunk ezt Exosxx /Set-el vagy Z80 out (191),a utasítással tiltom?
Vagy akkor a 7.bitre nem érvényes az írás tiltása
-
A 7. bit azt tiltja le, hogy az EXOS átírja a 191-es portot, ha változást tapasztal.
Tehát ha 4 Mhz-es gépen kiadod, hogy OUT 191,6, akkor azt észreveszi, hogy nem jó beállítás, és visszaírja.
Ha előtte volt SET 191,128 akkor nem foglalkozik vele.
-
igen össze keveredtem a hardver port(191) és a rendszerváltózó set 191,xx között
Bár akkor szerencsésebb lenne
7. ha 1, akkor az EXOS automatikus javítás letiltva, a 191-es portra.
-
:smt041 :smt041 :smt041
-
Es ha mar EXOS2.4: ajanlhato mar EPROM-ba egetesre es hasznalatra, vagy aze' inkabb ne? :) Mondjuk emulatoron nekem nem volt vele gondom, pedig az van.
Működni működik...
Ami probléma, hogy ez a megszakításból turbó figyelgetés megzavarodik, amikor az EXDOS lemez műveletekhez letiltogatja a megszakításokat.
Ez emulátoron nem jön elő, mert a WD1772 időzítései nincsenek emulálva, így a valódinál gyorsabb az átvitel, nincs olyan hosszú megszakítás letiltás.
Valószínűleg több másodpercre kell kiterjeszteni a mérést, és ha több egyforma eredmény jön ki, aszerint állítgatni a 191-es portot.
Amúgy meg az Editorba szeretne még mindenfélét Lacika :oops:
Én most arra gondolok, hogy a jelenlegi verzióból csinálni egy olyat, ahol a 191-es port megszakításból állítgatása le van tiltva alapból, és ezt elnevezni 2.33-nak.
-
Azon elmelkedtem, hogy anno kerdeztem mar, miert nem lehet olyat csinalni, hogy egy programbol meghivod a masikat, es ha az lefut, visszakapod a vezerelest. Gondoljunk itt pl egy commander (volkov commander szeru, hogy a regi szep idoket idezzem) cuccra. Akkor meg nem teljesen ertettem a problemat, hogy a nullas lapnak annyi lenne, nehez lenne visszaterni az elozo programhoz. Viszont ami felmerult bennem az az, hogy miert van egyetlen nullas lap? Mi lenne, ha lenne egy EXOS/M nevu rendszer (M mint Multiprogram) ahol egy exos hivassal inditasz egy programot, ami ki tud lepni, akkor visszaadja a vezerlest. Ugy mukodne, hogy az uj programnak foglal egy szegmenst, amit addig amig az fut, elnevezi azt nullas lapnak ugymond. Nyilvan azert a system page-en is lehetne olyasmi amit sajnos menteni kell, stb. Ezt elmeletileg is nehez lenne kivitelezni?
Akkor meg mar adodna az is, hogy pl kulso jelre lehet programot valtani :D mondjuk bill kombinacio, vagy reset gombra egy exos menu jonne be, hogy melyiket folytassa. Na az mar eleg durva lenen :D csak tartok tole hogy tenyleg pl csatornak nyilvantartasa miegymas az mind total megkeveredni, el kene menteni hozza ........ Elvileg amugy fix nullas lappal is mukodhetne, ha azt addig elbackup-oljuk vhova :D Az egesz hatranya az lenne hogy nagy a memoriaigeny (valoszinu legalabb a nullas lapot de talan a system page-et is el kene menteni valahova), illetve a masolas miatt kisse lassu lenne a valtas. Tovabba, a programnak nem celszeru kozvetlenul piszkalni a hw-t exos-on kivul mert kulonben erdekes lesz az eredmeny egy valtas majd visszavaltas utan, nem uaz az allapot all elo pl nick bizeralasa utan.
-
Aktuális változat:
Mint már emlegetve lett, Z180 miatt az összes nem dokumentált utasítás el lett távolítva a kódból. Z180-at inicializálja: belső várakozási ciklusok tiltva, és a belső I/O portok 40-7Fh-ra helyezve, hogy ne akadjon össze az EXDOS-szal
A fő újdonság, hogy SlashNet kérése alapján lett betölthető verzió is a teszt program részből.
Az MT.COM az Advanced RAM teszttel indul alapból, így lehetséges memória tesztelése EXOS 2.4 EPROM (vagy a gyorstesztes cartridge változat) beépítése nélkül is.
A QT.COM pedig a normál gyorstesztet futtatja, ennek akkor van értelme, ha nagyobb EPROM-okkal szerelt rendszert alap EXOS-os géphez csatlakoztatunk, és az nem látja az összes ROM programot. Pl. egy tartalék gépet próbálunk ki a bővített EXDOS kártyánkkal.
-
Ez már működik igazi gépen is?
-
Új funkció hozzáadva a gyorsteszthez, F6-al kihagyja a Cartridge-ben található ROM-okat.
Ez az SD Cartridgehez készült, aminek a Flash ROM-ja EP-ről frissíthető, de mivel felületszerelt az IC, ezért ha valami félresikerül nehéz helyreállítani, ha a hibás ROM-mal el se indul a rendszer. Ezzel a funkcióval ez megoldható, és floppyról (akinek van EXDOS kártyája) vagy magnóról (PC-ről hangkábelen) betölthető helyreállító Flash program.
-
A basic automatikus sorszámozás (AUTO utasítás) bugot nem lenne érdemes javítani? READ IF MISSING és néhány hasonló utasítás után jelentkezik, hogy 616 körül folytatja a számozást.
Lehet, hogy van más basic bug is még, már nem tudom, de az EXT bug javítva lett, azt tudom.
-
A basic automatikus sorszámozás (AUTO utasítás) bugot nem lenne érdemes javítani?
Érdemes lenne, csak előbb meg kéne találni :oops:
-
Érdemes lenne, csak előbb meg kéne találni :oops:
Ja, az bonyolult? Sajnos ahhoz a részéhez nem értek.