Enterprise Forever
:HUN => Programozás => Topic started by: Povi on 2006.June.12. 18:58:44
-
A CPC írt valaki errõl az op. rendszerrõl.
http://www.symbos.de/index.htm
Találtam egy fórumot, ahol a Symbos szerzõje (Prodatron) kb. 1 hét alatt átírta MSX-re is. Ahogy olvasom a fórumot, úgy tûnik, hogy az alkalmazásokhoz nem is kellett hozzányúlni, azok már múködnek maguktól. A fórum itt található: http://www.msx.org/forumtopic6203.html
Kéne írni neki, hogy szeretnénk ezt megcsinálni EP-re is, és hogy küldje el a forráskódot, esetleg segíthetne is, ha van hozzá kedve. Megírhatom én is, de lehet, hogy annak kéne, aki jobban ért az EP-hez.
Ha ezt tényleg sikerülne átírni/portolni EP-re, akkor mindenkit meghívok egy sörre (vagy arra, amit szeret).
-
Találtam egy fórumot, ahol a Symbos szerzõje (Prodatron) kb. 1 hét alatt átírta MSX-re is. Ahogy olvasom a fórumot, úgy tûnik, hogy az alkalmazásokhoz nem is kellett hozzányúlni, azok már múködnek maguktól.
Persze hogy mukodnek, miert ne tennek? Ha minden hw fuggo dolgot vmi OS funkcion at hivsz akkor ugyanaz a CPU eleg hogy fusson valtoztatas nelkul ugyanaz a cucc, ez teljesen nyilvanvalo. Pont ez a "szep" egy "modern" OS-ben - tobbek kozott - ellentetben egy olyan geppel ahol mindent maga csinal minden program (pl Commodore 64), hogy az applikaciok binaris szinten hordozhatova valnak mivel egyfajta HAL (Hardware Abstraction Layer) van a cuccon.
Kéne írni neki, hogy szeretnénk ezt megcsinálni EP-re is, és hogy küldje el a forráskódot, esetleg segíthetne is, ha van hozzá kedve. Megírhatom én is, de lehet, hogy annak kéne, aki jobban ért az EP-hez.
Es odaadja, gondolod? Mert en felek attol hogy nem fogja, foleg ha figyelembe veszed, hogy akkor eleve open source formaban nyomathatta volna eddig is, megse igy van :(
-
Es odaadja, gondolod? Mert en felek attol hogy nem fogja, foleg ha figyelembe veszed, hogy akkor eleve open source formaban nyomathatta volna eddig is, megse igy van :(
Egy próbát mindesetre megér. De miért ne adná oda?! Ennyre nem lehet irigy! :-) Ha nem, akkor írja át EP-re!!! :smt003 Legalább miközben írja, rájön, mennyivel sokkal jobb gép, mint a CPC! :-)
-
Szerintem az õ érdeke is, hogy EP-n legyen SymbOS. Így legalább mi is fejleszthetnénk rá alkalmazásokat, amiket aztán õ is futtathatna a saját CPC-jén.
-
Prodatron írta az MSX konvertálásról:
"Yesterday I started to work on the MSX with the help of BlueMSX and I already managed to port the micro kernel. So it seems to be more easy and fast, as I first expected.
But now I definitely need your help. The following other parts of the operating systems include system dependant code, too:
1.) screen manager (=low level screen output routines)
2.) device manager (=keyboard, mouse, realtime clock, screen mode and colours)
3.) low level part of the file manager (=disc and hard disc sector read/write routines)"
Az 1-es ponttal az EP esetén lényegben nem is kéne foglalkozni, hiszen (ha jól értem, ugye Zozo?) az EP teljesen tudja emulálni a CPC videóját.
A 2-es pontokat tudja az EXOS, remélhetõleg nem használja a SymbOS az RST 30h-t (ha igen, biztos lehet valamit trükközni). Mert hát minek írjuk meg mégegyszer pl. az egérvezérlõt, amikor ilyen már van?
-
Az 1-es ponttal az EP esetén lényegben nem is kéne foglalkozni, hiszen (ha jól értem, ugye Zozo?) az EP teljesen tudja emulálni a CPC videóját.
A 2-es pontokat tudja az EXOS, remélhetõleg nem használja a SymbOS az RST 30h-t (ha igen, biztos lehet valamit trükközni). Mert hát minek írjuk meg mégegyszer pl. az egérvezérlõt, amikor ilyen már van?
Azert azt vedd figyelembe hogy a SymbOS egy onallo es raadasul viszonylag modern OS, nem biztos, hogy ra tudod ultetni az EXOS tetejere. Arrol nem is beszelve, hogy mivel az EP sem egy AMD64 izebize erogep, nyilvan az eroforrasokat nem igazan "illik" pazarolni ha elfogadhato sebesseget akarsz, lehet tul lassu lenne egyszeruen ha layerezgetni kezdened az EXOS fole. Persze ez 1altalan nem biztos hogy igy van, foleg lehet nem egy pl egernel, de van ami performancia szempontjabol kritikus lehet, nameg lehet ossze se lehet hozni ertelmesen ... Na nekem meg nem kene irkalni X sör utan, es foleg nem akkor ha meg nem is lattam hogy epul fel :) Szal ki ker forrast? :)
-
Írok neki, és kérek forrást. De ha jó fej, lehet, hogy õ is átírja. :-) Az MSX-re kb. 10 nap kellett neki.
Az EXOS-ra ültetést azért gondoltam, mert pl. a lemezvezérésnél nem kéne újra írni az egész DOS-t, hanem lehetne az EXDOS-t kérni, hogy pl. nyisson meg egy file-t.
De hát azt is lehet, hogy egy TEST_ROM-os romba tesszük, és nem törõdünk az EXOS-szal...
Nem hiszem, hogy lassú lenne. Kipróbáltam CPC emulátoron, és simán jó volt.
-
Írok neki, és kérek forrást. De ha jó fej, lehet, hogy õ is átírja. :-)
Ha van barmi hir / valasz, please ird meg ide, mert engem is erdekelne! Koszi elore is.
-
Még nem válaszolt... :-(
-
Válaszolt:
"Hi Povi!
sorry for the late answer. I am interested in an Enterprise port of SymbOS and I already had a look on your forum on enterpriseforever.com (and even tried to translate the texts :-).
Currently I am very busy with the MSX port, and unfortunately I can't make SymbOS open source at the moment, as I have to clarify some legal stuff first (there is someone, who wants to use SymbOS for commercial things, what I want to prevent).
But maybe we can already discuss about an Enterprise port. I would like to know some data about the EP:
- what are the bankswitching possibilities? In which ways can the Z80 access more than 64K?
- what are the screen modes/resolutions? How is the video ram organized and where in memory is it placed?
- are there standard floppy drives and file systems existing?
- are there emulators for the Enterprise available? Do they contain a monitor/debugger?
In any case I will try to organize an EP and maybe a EP-SymbOS could be possible in the future :-)
CU,
Prodatron"
-
Írom az angolba a választ, írd meg neki hogy jöjjön oda, és ott tárgyaljuk meg a kérdéseket.
-
Van valami hír a Symbos-szal kapcsolatban?
-
Tényleg! Van valami Symbos-szal kapcsolatban?
-
http://www.symbos.de/preview.htm
Érdemes ellátogatni a SymbOS oldalára, gőzerővel folynak a fejlesztések!!! (symzilla)
-
Geco!
Ezt mekkora munka lenne átírni? :oops:
Már van MSX változat is a CPC mellett...
http://www.symbos.de/index.htm
-
Geco!
Ezt mekkora munka lenne átírni? :oops:
Már van MSX változat is a CPC mellett...
http://www.symbos.de/index.htm
Nem tudom, a források megvannak, azt nem tudom, hogy használ-e floppy kezelést portokon keresztül, mondjuk az lenne a szép, ha igazán EP-sítve lenne, nem csak a porthívások átírva, hanem a képességek az EP-nek megfelelően kihasználva, az már elég nagy lenne.
-
a források megvannak
Azok hol vannak? Néztem az oldalukat, de csak az alkalmazásokhoz írták, hogy van sources.
-
források tényleg nincsenek, csak az alkalmazásokhoz...
hááát izé....
Vissza kéne fejteni, vagy újból fel venni a szerzőjével a kapcsolatot.
Annak idején (sok éve) regisztrált ő is ide, Zozo válaszolgatott a kérdéseire, azt hiszem még egy EP64-et is vásárolt magának, aztán elakadt ott a projekt, hogy nincs se memóriabővítése, se floppy-meghajtója, se IDE kártyája a fickónak, az AIO kártyára vár azóta is szerintem... :mrgreen:
Most az ep128emu már tudja a vinyót is emulálni, és tök jó debugger van benne, nem hiszem, hogy nagy ügy lenne átportolnia a szerzőnek a progit, csak ehhez újra fel kéne venni a kapcsolatot vele...
Vagy lehet, hogy most már odaadná a forrást is...
-
Azok hol vannak? Néztem az oldalukat, de csak az alkalmazásokhoz írták, hogy van sources.
Akkor tévedtem :D, és összekevertem az alkalmazás source-okat a full source-szal
-
források tényleg nincsenek, csak az alkalmazásokhoz...
hááát izé....
Vissza kéne fejteni, vagy újból fel venni a szerzőjével a kapcsolatot.
Annak idején (sok éve) regisztrált ő is ide, Zozo válaszolgatott a kérdéseire, azt hiszem még egy EP64-et is vásárolt magának, aztán elakadt ott a projekt, hogy nincs se memóriabővítése, se floppy-meghajtója, se IDE kártyája a fickónak, az AIO kártyára vár azóta is szerintem... :mrgreen:
Most az ep128emu már tudja a vinyót is emulálni, és tök jó debugger van benne, nem hiszem, hogy nagy ügy lenne átportolnia a szerzőnek a progit, csak ehhez újra fel kéne venni a kapcsolatot vele...
Vagy lehet, hogy most már odaadná a forrást is...
Lehet jobb lenne a forrást elkérni, úgy hamarabb lenne SYMBOS-unk :)
-
Lehet jobb lenne a forrást elkérni, úgy hamarabb lenne SYMBOS-unk :)
Sõt biztos!
-
SymbOS témában lassan őrölnek a malmok... A forrás kiadása elől elzárkózott a szerző, vagy lenne értelme elkérni ismét? Tuti elfelejtette azóta.
A History-ban azt írja 2012. XI. 1-én: "After exactly 5 years of absence I am back on SymbOS."
Hátha...
-
Annak ellenere, hogy szerintem "tulzas" (8 bites MS windows feeling), tech demonak legalabbis erdekes. Neki is alltam fellelni az elerheto doksikat, ez alapjan (jelenleg C-ben es PC-n fut, egy beepitett Z80 emulatorral) elkezdte futtatni a symshell alapu applikaciokat legalabbis. Hat erdekes, mert implementalni kell egy rakas kernel message-t (un message alapu a kommunikacio a komponensek kozott). Mondjuk speciel nem is ertem, hogy foleg ilyen korokben (nem PC-s milliokat ero bizniszrol van szo) miert nem teszi mindenki kozze a forraskodot ... Portolni EP-re amugy nem lenne nehez (az EP-t a doksi is emliti!), foleg mivel ez egy kb mikrokernel based cucc, szoval szinte alig kene modositani, max par "driver" kene hozza reszelni aztan.
-
Jól értem, hogy C-ben írtál egy progit, ami PC-n futtatja a Symbos alkalmazásokat?
-
Jól értem, hogy C-ben írtál egy progit, ami PC-n futtatja a Symbos alkalmazásokat?
Jol erted, mar amennyire a cmdtest.com futtatasa alapjan altalanositani lehetne az osszes tobbi lenyegesen komplexebb es grafikus alkalmazasra :) GUI elemekrol szo sincs, az kicsit nagy melo lenne! A cmdtest.com symshell alkalmazas, nem hasznal semmi grafikus elemet, ablakot, menut, egeret, stb ... SymbOS-en a SymShell-en belul futna amugy.
-
ja, ja, közben elolvastam az angol nyelvű topikban is (ott kicsit részletesebben leírtad :-)), izgalmasan hangzik egyébként!
-
Belekezdtem a vilag leghulyebb projectebe: protoljuk a symbOS-t EP-re a forraskod nelkul. Modositott JSEP-n (nemi CPC portokat beletettem, hogy "atforditsa" a portelereseket EP-ben ismertekre) mar elindul, bar semmit nem lehet vele kezdeni, de mivel a "taskbaron" az ora ketyeg, valoszinuleg valamennyire mukodik (mukodne ...) es nem fagy. Mivel loader-t, drivereket stb irni elegge lehetetlen melyebb ismeretek nelkul, fogtam a caprice32 CPC emulatorbol (elotte kicsit atirtam ...) a memory dump-ot es nemi rettenetesen ronda python script es binaris patching-el (jelenleg csak az interrupt kezelesben vegeztem modositasokat, CPC-s verzio ahogy nezem 300Hz-es interrupt alapjan var mindig 6-ot, hogy 50Hz legyen, ezt kigyomlaltam es VINT-re ratettem) gyartottam belole egy ep128 snapshot-ot, felvertezve CPC videomodot emulalo LPT-vel stb. Ezt eszi meg jelenleg a modositott (tehat normal EP-n, vagy EP emun se futna) JSEP. Kovetkezo project: az emulator logjai alapjan a portelereseket nezem, es megprobalom mindent EP-siteni, hogy fusson "normal" emulatoron is, rendes EP portokkal, ahogy a valodi gepen is van. Azt mondjuk en sem ertem, hogy ennek mi ertelme, de jo moka :) Ezek utan valodi gepen max azert nem futna, mert kene ala loader, ami ezt be is tolti a memoriaba ahogy van stb, tehat amit az EP emulatorok is csinalnak egy snapshot betoltesnel. Lehet fikazni, hogy nem vagyok normalis :) Viszont igy legalabb gyorsan "bootol" a SymbOS, hiszen futas kozben kepzett (mar betoltodott) memory dump-al kezd ...
-
Lehet fikazni, hogy nem vagyok normalis :)
Tényleg nem vagy normális! :mrgreen:
Viszont nagyon kiváncsi vagyok, mi lesz ebből... :-)
-
Tényleg nem vagy normális! :mrgreen:
Viszont nagyon kiváncsi vagyok, mi lesz ebből... :-)
En is :)
... jezusom, CPC-n mennyit tudnak szenvedni kbd olvasashoz, EP-re nem gyozom a kod 3/4-et ki-NOP-olni :D
-
... jezusom, CPC-n mennyit tudnak szenvedni kbd olvasashoz, EP-re nem gyozom a kod 3/4-et ki-NOP-olni :D
Nem csak a bill olvasással :D , de a billentyű olvasás felér egy külön programmal :D
Az összes AY eléréssel :D
A CRTC regiszter írás rövidebb, de az is hosszú, előbb regiszter kiválaszt, aztán érték beír 4 utasítás.
Kíváncsi vagyok mi sül ki a projectedből :)
Sztem, ha a loader részt is kidobod (gondolom direct hardware kütyülés track olvasással), és lecseréled EXDOS-os track olvasásra, akkor egy full, működő átirat lesz.
-
Nem csak a bill olvasással :D , de a billentyű olvasás felér egy külön programmal :D
Az összes AY eléréssel :D
A CRTC regiszter írás rövidebb, de az is hosszú, előbb regiszter kiválaszt, aztán érték beír 4 utasítás.
Kíváncsi vagyok mi sül ki a projectedből :)
Sztem, ha a loader részt is kidobod (gondolom direct hardware kütyülés track olvasással), és lecseréled EXDOS-os track olvasásra, akkor egy full, működő átirat lesz.
Jo, hat en CPC-t most latok eloszor :) Na jo, nem CPC-t konkretan mint gepet, hanem hozza irt software-t. Amugy a CRTC kevesbe erdekel: mivel remelhetoleg legalabbis a videomod ugyanaz marad, az meg kezdetben inicializalva lett altalam olyan LPT-vel amivel szimulalom a CPC kepfelepiteset, nincs szukseg azokat nekem kezelni. Ami van kb es hozza kell nyulnom:
* memoria lapozas: ez jelenleg JSep modositott verzioja intezi, de mar ott is ugy van, hogy "atvezeti" a B0..B3 irasokra. Ezt kell majd magaban a kodban megoldanom, hogy ne kelljen hozza hack-elt emu.
* billentyuzet: maga a scan EP-n egyszeru lett, mar atirtam a memory dump-ban, hogy EP-rol vegye, csak ugye a matrix nem stimmel utana ami alapjan dekodolja, hogy melyik billencs mit jelent. Viszont megkeresve, hogy EP-n milyen gomb van azon a pozicion ahol CPC-n joy1 van, az egerkurzor mar remekul mozog! A kerdeses helyek is megvannak disasm alapjan, csak neki kene fognom atirni.
* floppy vezerlo: na itt eleg tanacstalan vagyok, az se teljesen vilagos, mi van a CPC-ben erre hw. A portokat latom persze amit irna. A fenti screenshotomon latszik is, hogy a symshell elinditasa hibat dob fel, nem csoda, mert amit probal I/O az nem csinal semmit :) Ha ez nagyon mas mint a WD az EP-ben, azt erdekes lesz megoldani Z80 program szintjen, hogy forditsa at :(
* interrupt: atirva, CPC-n gondolom a 300Hz-es megszakitasra akaszkodott ra, minden 6.-ra csinalt csak vmit, ergo 50Hz-et akart kihozni. EP-n ez egyszerubb, inkabb beallitottam az INT1 engedelyezest Dave-ben, LPT-ben van egy megszakitasos sor, aztan kiirtottam a kodbol ez a minden 6.-ra varunk dolgot. Masik megoldas amit mondasz, hogy WD bizeralas helyett EXDOS hivas, amde itt szkeptikus vagyok, mert alaposan atveszem a memoria hasznalatat. A 128K meg elegge tele van (marmint az emulalt CPC 128K RAM), az LPT el sem fert, igy eleve 128K-s EP-n nem fog menni :( Egy normalis atirat persze menne, de ahhoz inkabb forraskod szinten kene EP-re portolni, nem utolag kutyulgatni (pl akkor eleve nem a CPC "8 reszes" cimzes lehetne hanem linearis - de ehhez gondolom az egesz GUI kodjaba be kene avatkozni - igy nem kell 200 soros LPT tabla csak az egyes sorokra, a tobb vsync stb-rol nem is beszelve - konkretan ezt nem tudtam bezsufolni a 128K ram-ba).
Amugy az sem vilagos CPC kapcsan, hogy miert jo az (mashol is latom), hogy 16 bites I/O cimeket hasznalnak. Szerintem ez netto hulyeseg. Csak bonyolitjak az eletekut, ami aztan problemakat okoz (pl nem lehet normalis konstanssal megadott portra I/O-zni, INI es hasonlo opcode-ok igy kevesbe mennek ertelmesen stb). Tudja vki, hogy ennek mi ertelme? Az also 8 bitet is eleg lenne dekodolni (a felso 8 helyett ...), tehat semmivel sem lenne nehezebb, viszont elonyei vannak, es Zilog ajanlasa is ez. Akkor miert csinaljak, szivatasbol?
-
mi van a CPC-ben erre hw.
NEC 765A. Viszont a SymbOS írója WD-ről kérdezett, lehet, hogy az MSX verzióban azt használnak?
-
NEC 765A. Viszont a SymbOS írója WD-ről kérdezett, lehet, hogy az MSX verzióban azt használnak?
Szerintem igen.
-
NEC 765A. Viszont a SymbOS írója WD-ről kérdezett, lehet, hogy az MSX verzióban azt használnak?
Lehet, MSX-et es PCW-t sem ismerem, azt hiszem ezeken fut meg SymbOS jelenleg CPC-n kivul. Valojaban celszerubb lehetett volna a fenti gepekrol "lecsorni" a memory dump-ot es portolni probalni ebben a formaban EP-re, azonban a PCW kepszerkezetet nezve az EP-n kevesbe implementalhato (nalam meg kulcskerdes volt, hogy a GUI-s cuccok azert SymbOS szintu rendszernel nem trivialisak nem akarok hozzanyulni binaris formaban ....), a CPC kepszerkezete viszont jol emulalhato, ezert valasztottam ezt. Az MSX viszont passz ...
Amugy valoszinu, hogy a SymbOS iroja (vagy akinek megvan a forras a kernelrol is stb ...) szinte percek alatt (na jo, koltoi tulzas, de parnap biztos eleg) potolhatna EP-re, foleg ha pl megalkuszik elso korben azzal, hogy marad a CPC kepszerkezet, memory mapping-et atirja, nemi loader, par port nyilvan mashol/maskepp, es elvileg akkor talan WD-hez van vmi driver vmelyik portban ami hasznalhato :) Igy en most, hogy egy CPC emu snapshot-at beleeroszakolom az EP ram-jaba es atirok benne ezt-azt az kisse hmmm ganyolas :) Nem is kisse. Viszont mas megoldas sokkal nehezebb lenne forras nelkul, akkor kene irni sajat loader-t, driver-eket fejleszteni stb. Bar nyilvan ertelmes es tartos felhasznalasra a "normalis" portolas a megfelelo eljaras!!
-
A CRTC bizergálását gyanúsan nem is kell nyomon követni, mert a képméret az nem változik, hacsak nem két képernyőt használ a megjelnítéshez, mert akkor a videócím megadását kell, a videó módot, és a színeket kell még majd, ha eddig nincs meg, az tán a 7fxx porton keresztül megy, ugyanazon, mint a memórialapozás.
A legjobb megoldás az lenne a floppy vezérlő kapcsán: elfelejteni az eredeti floppyvezérlős dolgot, kinyerni fájlokba a kódot, és EXOS fájlbetöltésre átalakítani, így minden konfiggal menne, még magnóról is :D
Az interruptot is sokoszor le lehet butítani EP-n, pláne az ilyen 50Hz-es várakozós esetekben, pont ahogy említetted is.
128K-s gépen csak akkor futhatna a program, ha az EXOS-t kidobod, és a CPC címzést is átalakítod ha a SYMBOS használja az összes lapot, ez túl nagy munka forrás nélkül, szerintem ezt az átalakítást érdemesebb bővítős gépre megcsinálni.
Ez a port címzés érdekes dolog, eddig én csak a TVC-vel ZX81-gyel, Spectrummal, és EP-vel találkoztam, aminél az alsó 8 bit elég az IN/OUT műveletekhez, érdekes, hogy az AY SP128-on már 16 bites címzéssel lett megoldva, pedig volt ott még szabad regiszter, vagy épp a billentyűzet elhasználta az összes lehetőséget a kombinációkkal?
Nem tudom mi volt a 16 bites címzés haszálat megtartásának lényege CPC-n, lehet akartak bőven lehetőséget hagyni a jövőben csatlakoztatott eszközökhöz?
-
CPC kepszerkezete viszont jol emulalhato, ezert valasztottam ezt. Az MSX viszont passz ...
Amugy valoszinu, hogy a SymbOS iroja (vagy akinek megvan a forras a kernelrol is stb ...) szinte percek alatt (na jo, koltoi tulzas, de parnap biztos eleg) potolhatna EP-re, foleg ha pl megalkuszik elso korben azzal, hogy marad a CPC kepszerkezet, memory mapping-et atirja, nemi loader, par port nyilvan mashol/maskepp, es elvileg akkor talan WD-hez van vmi driver vmelyik portban ami hasznalhato :) Igy en most, hogy egy CPC emu snapshot-at beleeroszakolom az EP ram-jaba es atirok benne ezt-azt az kisse hmmm ganyolas :) Nem is kisse. Viszont mas megoldas sokkal nehezebb lenne forras nelkul, akkor kene irni sajat loader-t, driver-eket fejleszteni stb. Bar nyilvan ertelmes es tartos felhasznalasra a "normalis" portolas a megfelelo eljaras!!
Az MSX képfelépítése nem emulálható EP-n, pl attributum módban egy karakter 8 byte-ja c64-szerűen egymás mellett tárolódik el a videómemóriában, az attributum területtel nem lenne gond.
Szerintem is gyorsan át lehetne portolni EP-re a forrás alapján a fent említett dolgok megőrzésével, de szerintem a CPC címzés megszűntetése se hosszabbítaná meg nagyon az időt, ami jó lenne, de gondolom sok időbe telne, a váltott soros LPT-s megvalósítás.
Szerintem ez a snapshotos eljárás is megfelelő, már minden lényeges dolog betöltődött a memóriába, átírsz benne mindent, csak egy loadert kell eléírni, teljesen jól használható program lehet belőle.
-
A CRTC bizergálását gyanúsan nem is kell nyomon követni, mert a képméret az nem változik, hacsak nem két képernyőt használ a megjelnítéshez, mert akkor a videócím megadását kell, a videó módot, és a színeket kell még majd, ha eddig nincs meg, az tán a 7fxx porton keresztül megy, ugyanazon, mint a memórialapozás.
Ja, az gate array stb cuccos a CPC-n, tudom (mostmar!).
A legjobb megoldás az lenne a floppy vezérlő kapcsán: elfelejteni az eredeti floppyvezérlős dolgot, kinyerni fájlokba a kódot, és EXOS fájlbetöltésre átalakítani, így minden konfiggal menne, még magnóról is :D
Ebben azert nem vagyok biztos. Ez nem egy jatek, vagy "monotask" OS, van benne olyan, hogy ha nincs kesz vmi, addig futhat mas process, tehat "fejlett" multitask I/O sleep-el stb. Ha kozben az EXDOS-t meg kell hivni az erdekes problema lehet. Ok, mondjuk lehet itt is ganyolni, hogy addig VINT letiltva aztan max lagzik I/O eseten a felulet kicsit ... Viszont nem trivialis igy se esetleg, hogy ez mennyire zavar be a lelkivilagaba, azt (meg) nem tudom. Majd kiderul :) Elsore nekem az is eredmeny lesz, ha sima EP-n (bar tobb RAM-al mint 128K) elfut, meg ha disk access nincs is. Igaz, igy sok mindenre nem jo, de elmondhato, hogy maga az OS mar fut legalabb.
128K-s gépen csak akkor futhatna a program, ha az EXOS-t kidobod, és a CPC címzést is átalakítod ha a SYMBOS használja az összes lapot, ez túl nagy munka forrás nélkül, szerintem ezt az átalakítást érdemesebb bővítős gépre megcsinálni.
Azert nem megy, mert a memoria dump-ot nezve a CPC emurol elegge "tele" van, nem fer hova az LPT :( Foleg, mivel 200 sorhoz CPC screen-t emulalva kell 16*200=3200 byte (plusz meg a "toltelek", vsync stb) LPT ennyi hely meg latholat nincs (azt neztem hol van sok nulla byte-os resz, de meg akkor sem lehetek biztos, hogy egy program futtatasanal nem hasznalja aztan azt a teruletet is, sot ...). Ezert van, hogy igy tuti nem fog 128K rammal menni. Mint mondtam, ha lenne normalis atirat, tehat tenyleg SymbOS forras szinten lenne EP port, akkor meg lehetne oldani siman, szerintem. Igy viszont a "ganyolas" megoldassal kevesbe! A CPC cimzes kidobasa alatt gondolom azt erted, hogy linearisan kezelje a video RAM-ot, igy eleg a pixel adatokhoz 16 byte LPB reszlet a 3200 helyett. Ez igaz, amde egy SymbOS szintu software-nel szerintem ez messze nem olyan egyszeru, changelog is irja, hogy fuuu de optimakolva van a CPC screen-re a CPC port, es erosen nem csak egy helyen irogat videoram-ba, kezdve a mindenfele window kezelestol, az osszes text rendering, menu, miegymas ezer helyen ... Ezt forras hianyaban mind modositani ... na erre nem vallalkoznek :) Amugy is, elvileg lesz hivatalos EP port, ami mindenkeppen jobb megoldas! Egy ilyen "preview" portolasnal meg ugyse feltetlen a 100%-os hasznalhatosag a lenyeg elso korben legalabbis.
Ez a port címzés érdekes dolog, eddig én csak a TVC-vel ZX81-gyel, Spectrummal, és EP-vel találkoztam, aminél az alsó 8 bit elég az IN/OUT műveletekhez, érdekes, hogy az AY SP128-on már 16 bites címzéssel lett megoldva, pedig volt ott még szabad regiszter, vagy épp a billentyűzet elhasználta az összes lehetőséget a kombinációkkal?
Spectrumot sem ismerem igazan, de mindenesetre olyan gepnel, ahol alapbol az I/O dekodolas primitiv (mondjuk 1-2 bitet neztek csak) ott gond lehet, hogy elfogy az I/O cimtartomany, ha compatible akarsz lenne, es minden "ghost" pozicion kell tovabbra is menjen ... Pl talan Spectrumnal van, hogy egyik port minden paros (v paratlan?) I/O cimen megy, szoval egy szem bitet neztek az address busrol I/O eseten. Ilyen esetben persze utolag gondban van az ember, mivel regen nem oldottak meg rendesen a cimdekodolast :( Tehat itt meg ertem is. Viszont CPC-n latszolag alapbol is szepen dekodoljak a 16 bites cim felso reszet (nincs a fenti problema) tehat megtehettek volna inkabb az also 8 bittel is ugyanugy, es mindenkinek jobb lett volna!
Nem tudom mi volt a 16 bites címzés haszálat megtartásának lényege CPC-n, lehet akartak bőven lehetőséget hagyni a jövőben csatlakoztatott eszközökhöz?
Hat en ketlem, tenyleg dekodolva van teljesen a felso 8 bit ahogy nezem, tehat boven van hely. Voltakeppen ha jol latom CPC az I/O cim felso 8 bitjet nezi, es teljesen dekodolja azt. Akkor viszont siman tehettek volna az also 8 bitre ...
-
Az MSX képfelépítése nem emulálható EP-n, pl attributum módban egy karakter 8 byte-ja c64-szerűen egymás mellett tárolódik el a videómemóriában, az attributum területtel nem lenne gond.
PCW-n is vmi olyan gond volt, ha jol remlik, hogy attrib ugyan nincs (asszem') de soron belul sem linearis. Amugy ilyen gondokra milyen jo lenne egy plusz Nick feature: az LD1 erteket pl ne eggyel novelje hanem az altalam megadott ertekkel minden read utan :D
Szerintem is gyorsan át lehetne portolni EP-re a forrás alapján a fent említett dolgok megőrzésével, de szerintem a CPC címzés megszűntetése se hosszabbítaná meg nagyon az időt, ami jó lenne, de gondolom sok időbe telne, a váltott soros LPT-s megvalósítás.
Szerintem ez a snapshotos eljárás is megfelelő, már minden lényeges dolog betöltődött a memóriába, átírsz benne mindent, csak egy loadert kell eléírni, teljesen jól használható program lehet belőle.
Igen, csak mivel nem ismerjuk annyira ugye a SymbOS belso mukodeset, igy minimalis kis kodmositasokon tul nehez lenne barmit belepakolni, pl mas drivereket, esetleg boxsoft mouse drivert, hogy EP-n mehessen egerrel, vagy barmit, amihez 1-2 byte-nal tobb hely kell, vagy eleg par opcode-ot modositani. Mondjuk a CPC video cimzes megtartasanak egy elonye lehet: a symplay alkalmazas (vagy mi is) ami tud videot lejatszani kulon formatumot hasznal cpc-re es msx-re,gondolom azert, mert lassu lenne konvertalni, es mar a celvideomodhoz hasonlo formaban van a file-ban is. A CPC felepites megtartasaval a CPC videokat le tudna jatszani, mig linearis kepfelepites eseten nem biztos (vagy ahhoz az lejatszot kene modostani, hogy pakolja maskepp ki).
-
Hm , érdekes ez a lejátszósdi, a CPC címzés végülis nem gáz, pláne ha arra van optimalizálva a futás is, a címzés átalakítást is úgy írtam ,hogy azt csak meglévő forrással lenne érdemes, mert marha nagy munka lenne, sőt még az is lehet, hogy lehetetlen, vagy iszonyat kódnövekedéssel járna forrás nélkül.
-
Ja, meg a masik: EP brutal egy gep lehet, ha mar egyszeruen (nem ugy mint CPC-n) es egysegesen egesz sok RAM-ot kezel, jo lenne nem csak a 128K-s verziot hasznalni. Azonban ez a memoriadump-ot athozzuk es atirjuk meg 128K-s verzional is necces, mivel CPC-n elegge elkefelt a memorialapozas, ha meg jon >128K-s verzio is, az meg bonyolultabb lenne. Egy tiszta EP atirat azert is lenne jo, mert tamogathatna annyi RAM-ot ami van (kozben opcionalisan - ha van hozza eleg mem) EXOS comaptible modon is (ja es ha van eleg RAM, akkor jobb esetben en a videorambol csak 16K-t hasznalnek, mert a vram ugye lassabb vmivel ...).
-
Igen, teljesen jó ötlet, annyi VRAM, amennyi elengedhetetlenül szükséges, az elkefélt memórialapozással egyetértek :D Nem tudom, hogy a 128K+ lapozása hogy van, de szerintem hasonlóan "egyszerű" lehet :D
-
István féle cpcemuban el lehet indítani a SymbOS-t? Van sok ramos, floppys config is benne.
-
István féle cpcemuban el lehet indítani a SymbOS-t? Van sok ramos, floppys config is benne.
Gondolom el, nem probaltam, hogy oszinte legyek, mivel cap32 egyszerubb, nem C++, igy bele tudtam nyulni, meg tanulmanyozni, ha kellett.
-
István féle cpcemuban el lehet indítani a SymbOS-t? Van sok ramos, floppys config is benne.
Szerintem én ott teszteltem anno, de lehet rosszul emléxem, de csak az alap 128Kb-tal.
-
Igen, teljesen jó ötlet, annyi VRAM, amennyi elengedhetetlenül szükséges, az elkefélt memórialapozással egyetértek :D Nem tudom, hogy a 128K+ lapozása hogy van, de szerintem hasonlóan "egyszerű" lehet :D
Mondhatjuk forditva is: tobb gepen "atlagos", EP-n csinaltak meg jol a memorialapozast :) Last Commodore-os megoldasok, az is meger egy miset, kb nem is lehet rendesen boviteni RAM-ot (C64, vagy C128-on lehet de szamomra az is bonyolult), mas gepeken meg esetleg, csak eppen ... EP-n meg milyen szep, logikus, atgondolt es allat egyszeru, megis out-of-the-box 4Mbyte cimtartomany van mar eleve, nem kell kulon felmilliard aramkort beepiteni ha meg boviteni akarsz, stb.
-
Kisse elakadtam az orult projectemmel. Az egy dolog, hogy 128K-nyi RAM image van nekem disasm-olva es abban probalok rajonni, hogy mit csinal ... Ami mar sikerult: keyboard scan, hogy mikodik, EP-sites. Memorialapozas: tobbe-kevesbe ertem, EP-siteset halasztottam (a kvazi felig CPC/felig EP JsEP modositasom igy kezeli most). Ami viszont problema, es anelkul semmire sem lesz jo (egy alkalmazast sem lehet elinditani, max eger kurzort ide-oda vinni a kepernyon ...) az e lemezkezeles. Ebben kernem a segitseget, ha valakinek van otlete ... A tervem ugye egyenlore az, hogy (mivel extra bonyolult lenne forras hianyaban atirni), hogy a CPC verziohoz adott disk image-t lassa az EP-re "portolt" SymbOS, vagy ugy, hogy memoriaba betoltom (nyilvan 128K rammal nem fog menni, de amugy se menne, mert mar az LPT-hez sincs eleg RAM igy sajnos ...), es onnan "olvasok disk-et", vagy pedig EXOS file muveleteken at, visszalapozva azon idore a rendszerszegmenst stb, mivel azt erintetlenul hagyom.
A terv szep, amde a megvalositasa nem konnyu. A disasm alapjan haladtam vele, a CPC fdc controller IC-jenek leirasa alapjan mar egy csomo dolgot azonositottam, mindenfele csunya dolgokat csinal, rekalibracios seek muvelet stb, haaaat. Ezeket kvazi kiNOP-oztam :-) Amde most odaig jutottam, hogy nem jutok tul egy reszen, ahol vmi readID nevu muveletet nyom el, es nem ertem, azzal mi a celja, vagy az mire valo egyaltalan. A CPC wiki-n van nemi leiras, a kerdeses controller IC-nek is van datasheet-je elerheto, de meg igy sem ertem, mire jo ez a readID, es miert kell neki. Az vilagos, hogy seek-el track-ra all, es akkor ott pl nyomna egy readsector-t (ezt latom is hol van a kodban). Viszont ez a readID baromsag bezavar, es azt se ertem miert kell, miert nem eleg a track seek majd read sector. Illetve, hogy a readID-nek mi az eredmenye, az se vilagos. Valakinek van otlete mire jo ez? Koszi elore is!
Masik: a disasm orakig tarto bamulasa kozepette par dolgot megertettem a SymbOS multiask mukodesebol, erdekel valakit, hogy hosszabban irjak rola, mint erdekesseg, vagy tartsam meg magamnak? :)
-
Engem érdekel a Symbos multitask.
Az FDC readID-ban sajnos nem tudok segíteni.
-
engem is érdekel a lelkivilága :-)
lemezkezelés ügyben pedig lehet, hogy magát a szerzőt kéne megkérdezni
bár kérdés, vajon hogy fogadja, hogy félig már disassembláltad a progiját, gondolom nem véletlenül nem publikus a forráskódja :-)
-
Egy erdeklodo mar van, ezert remek lehetoseg, hogy kieljem grafoman maniamat, mondjuk a szokasos modon ekezetek nelkul, es nem keves gepelesi hibaval, mint mindig :D
Szoval, a SymbOS alapvetoen mikrokernel felepitesu rendszer. Errol azt kell tudni, hogy ilyen modern OS-eknel is van, alapvetoen monolitikus- versus mikrokernel szokott lenni a ket irany. A monolitikus kernel az, hogy a kernel es funkcioja "egyben" van (ebbe beletartozik az is, ha be tud tolteni egy dolgot, amit "belancol" a kernelbe, innentol viszont resze lesz!). Anno amugy Linuxnal ez okozott vitat Linus Torvalds (aki irta a Linux kernelt ugye) es a professzora kozott: az utobbi szidta tanitvanyat, hogy miert monolitikus kernelt tervez, amikor a mikorkernel elmeleti megfontolasok alapjan modernebb. Amde hozza kell tenni, hogy a mikorkernel valamivel lassabb is az un context switch-ek miatt, ami regebben foleg problema volt szerenyebb teljesitmenyu hardware-ek eseten. Mivel egy 8 bites rendszernel (lasd pl EP ...) alapvetoen nem szokott hw-es context fogalma meg hw-es memoriavedelem stb lenni, itt ez kevesbe erdekes :)
Szoval mikrokernel: a kernel alapvetoen picike, minimalis dologra jo. Meg egy modern hw-n levo mikokernel is akar csak par Kbyte koddal rendelkezik! A lenyeg az, hogy minden mas funkcionalitast ado dolog az ugy fut, mintha userapp-okhoz hasonlo process-ek lennenek (tehat nem a kernel resze), es ezek kommunikalnak egymassal. A mikrokernel egyeduli feladata kb csak az, hogy ezt koordinalja. Alapvetoen tehat a mikokernel onmagaban semmire sem jo persze, nem ad "funkcionalitast", max pl uzenetkuldes lehetoseget mas process-nek, de ha nincs ott az a masik process, meg disk-et sem eri el stb, mert azt is ilyenek csinalnak. Na, a SymbOS valahogy igy epul fel. Alapvetoen egy user process (de amugy egy system process is ...) uzeneteket fogadnak es kuldenek egymasnak. Azaz pl file olvasas nem ugy van, hogy a kernelt hivod (pl EP-s pelda egy EXOS funkcio), hanem uzenetet kuldesz a device manager process-nek, hogy legyen szives tenni mar vmit, es varakozol a valaszra.
SymbOS-ben a 0x38-as cimen ulo hw interrupt 50Hz-es rataval erkezik (valojaban CPC-n 300, azt hiszem ott kotott a 300Hz, de azt csinalja a SymbOS, hogy minden hatodiknal csinal csak vmit, kulonben visszater kb azonnal, tehat effektive 50Hz, EP-sites soran pl ezt en kiirtottam - igy gyorsabb is vmivel nem kell vizsgalni - es a nick VINT okozza az interrupt-ot). Egy-egy futo process/app/ahogy hivjuk (legyen az user vagy system jellegu is) csinal amit akar, amde amikor jon ez a megszakitas, akkor a SymbOS szepen felfuggeszti azt (letarolva aktualis regiszter ertekeket stb) es atadja egy masik futasra varo process-nek a CPU-t (itt fontos, hogy SymbOS-ben process prioritasok vannak, ez a modszernel csak olyan kaphatja meg a vezerlest, akinek nem alacsonyabb a prioritasa, ez gondolom arra jo, hogy egy vegtelen ciklust futtato user app ne okozza azt, hogy szegeny system process-ek sem kapnak CPU idot az utemezotol - scheduler). Van viszont arra is lehetoseg, hogy egy process "onkent lemondjon" (hw interrupt nelkul) a futasrol, mert pl var valamire, pl egy uzenetre egy masik processtol. Ez az un "soft interrupt" amit a process maga kezdemenyez. Ez persze jo, mert minek foglalja a CPU-t a kovetkezo "hard interrupt-ig" (amit a valodi VINT okoz), ha amugy nincs mit csinalnia. Amugy a soft interrupt az RTS 0x30 (ami jelen esetben ugye nem az EXOS hivasa ...). Hasonlo muvelet meg az uzenet fogadasa, ahol pl process addig "alszik" (= nem kap ujra CPU idot) amig nem kap uzenetet egy masik process-tol.
Namost, ami erdekes a disk kezeles kapcsan: a disasm-ot tanulmanyozva lattam, hogy milyen okos modon van ez SymbOS-ben megcsinalva. Legyen a kovetkezo a gond: valaki file-t szeretne olvasni. Most ugorjunk rogton oda, hogy mar konkret disk block-ot kene olvasni. Ez ugye idobe kerul, seek-elni kell, stb. Ez egy egyszeru monolitikus/monotasking rendszer eseten nem ugy: var szepen addig, amig nincs kesz. Ez SymbOS eseten kisse gaz lenne, ui akkor addig mas program nem futhatna. Ergo addig "megfagyna" a felulet. Amde a SymbOS ennel okosabban van megirva, hala a mikorkernel architekturanak, es ami ebbol kovetkezik, hogy a disk I/O -t vegzo cucc is csak egy "process" es nem a kernel resze. Az van, hogy a megfelelo process ami ezt csinalja (es ami ugye uzenetet kapott egy pl user app-tol hogy neki kell olvasnia disk-rol, ez a user app valoszinuleg kozben "alszik" amig nem kap valaszt) elkezdi a muveletet, eloszor is pl masik track-re kell seekelnie. Ebben az esetben pl CPC-n az FDC vezerlot nezi, hogy meg busy-e. Ha igen, akkor nyom egy soft interrupt kerest a mikrokernel fele. Ergo, amig a disk dolgozik, megkapja mas process a CPU-t hogy fusson, a rendszer "nem akad meg" addig! Megakadas nyilvan akkor lesz, ha masik process is van, ami disk I/O-zna, hiszen ha megprobal uzenetet kuldeni a device manager-nek, az mar alszik az elozo I/O befejezetlensege miatt, vagy ha eppen csinalja is a konkret olvasast, addig nem fog ujabb uzenetet venni, tehat az a masik I/O-s msg-t kuldo process mar aludni kenyszerul.
Ebbol kovetkezik az en orult projectemnek a limitacioja is: ha tegyuk fel, hogy szimulalom a CPC disk-et EXOS funkcio hivasaval, nyilvan a fenti trukk nem fog mukodni, mert ehhez magat az EXOS-t kene SymbOS processkent megirni :) Azaz, ha ezt meg is tudom oldani, a valodi es rendes EP SymbOS verziotol elteroen megakadast fog okozni azonnal ... Ez mutatja azt is amugy, hogy miert nem lehet normalisan meg forras eseten sem SymbOS-t raultetni EXDOS/EXOS-ra, es miert kell neki hw szintu hozzaferes mindenhez, kikerulve az dott gep eredeti OS-et, mivel a SymbOS felepitese egyszeruen nem osszegyeztetheto az EXOS/EXDOS mukodesevel, ahol szo sincs mikrokernelrol, de foleg nem multitaskrol.
No, nem tudom erdekelt-e vkit, amit osszehordtam itt, szerintem erdekes. Ez azonban az en velemenyem :)
Fontos: mivel az infokat nagyreszt disasm alapjan szereztem, en olyan fogalmakat hasznaltam ami OS-eknel szokasos, lehet SymbOS iroja tok mas nevekkel illetne ezeket, nem ahogy en elveneztem, de funkcioban kb azt jelenti :)
-
Lelkivilága érdekelne engem is! Semmit nem tudok erről az egészről, csak annyit, hogy valami ablakos izé :oops:
Az angol topicban is írtam, hogy többet kéne tudni róla, hogy lehessen a legalkalmasabb EP verzióról gondolkodni, de a szerző még nem kezdett mesedélutánba :-(
ReadID, ha jól tippelem WD-s tapasztalataim alapján megmondja neked, hogy melyik oldalon/sávon állsz, ezt használja az EXDOS is lemezkompatibilitás ellenőrzésére.
Ha a 1. oldalról olvas ID-t, és 0. oldalit talál, akkor egy kétoldalas lemezt raktunk egy oldalas meghajtóba. Hasonlóképpen ha 4. sávról olvas, és 2. sávot talál, akkor 80 sávos lemez van 40 sávos meghajtóban.
-
Lelkivilága érdekelne engem is! Semmit nem tudok erről az egészről, csak annyit, hogy valami ablakos izé :oops:
Az angol topicban is írtam, hogy többet kéne tudni róla, hogy lehessen a legalkalmasabb EP verzióról gondolkodni, de a szerző még nem kezdett mesedélutánba :-(
Elkestel, fentebb mar kiadtam magambol a novellat :)
ReadID, ha jól tippelem WD-s tapasztalataim alapján megmondja neked, hogy melyik oldalon/sávon állsz, ezt használja az EXDOS is lemezkompatibilitás ellenőrzésére.
Ha a 1. oldalról olvas ID-t, és 0. oldalit talál, akkor egy kétoldalas lemezt raktunk egy oldalas meghajtóba. Hasonlóképpen ha 4. sávról olvas, és 2. sávot talál, akkor 80 sávos lemez van 40 sávos meghajtóban.
Na igen, kb azert gondolom mire jo, csak nem sikerul rajonnom, milyen ertekeket kene visszaadnia, SymbOS-t futtatva es emulalva a dolgot nem lesz tobb I/O es kozli, hogy disk error 00 vagy hasonlo. Valoszinu, azert, mert ellenorzi a kapott ertekeket (ami jelen esetben 7 byte a readID-re) de a kod itt olyan szovevenyes, hogy eddig mindig belekeveredtem, amikor megprobaltam rajonni, hogy mi nem tetszik az emulalt ertekeimen neki :( Pl a SectorID nem tudom mit jelent. A SymbOS oldalarol letoltheto CPC verzio (amibol kiindultam) ugye tartalmaz egy disk image-et, amit elobb meg kellett fejtenem: kisse misztikus, mert nem sima data stream a byte-okrol hanem olyan infok is vannak benne hogy pl gap meret, es igen, sectorID. A gond az, hogy a diskimage-ben a sectorID-re minden letezo helyen az van hogy (ha jol emlekszem most!) 193, semmi mas. Ha ez a sectort azonositja, mert nem mas mindenhol, pl az adott track/head-en levo sector szama?
-
És memória térképet is lehetne kérni? :oops:
-
És memória térképet is lehetne kérni? :oops:
http://lgb.hu/temp/symbos-cpc-memory-dump-128k.dump (http://lgb.hu/temp/symbos-cpc-memory-dump-128k.dump)
Ez a 128K mentve a CPC memoriajabol. Ugye ezt probalom patch-elgetni, hogy EP-n elfusson majd :) Ebbol az also 64K az ami a CPC-n a "base page", ebben van a video RAM is, elvileg ha jol emlekszem 0xC000-tol, tehat ha ott megnezed mi van a dump-ban epp a felulet kepet kapod, 4 szinu modban a CPC-re jellemzo "8 reszre szetszort" cimzessel. A felso 64K pedig a "memory expansion" vagy mi persze. EP-n ez valojaban nalam forditva van (de mindegy, mivel EP szegmensegeket lat, neki mind1, hogy "valojaban" milyen sorrendben van) azaz, ami a memory dump-ban az elso 64K az EP-n nalam az F9-FC szegmens, a masodik CPC 64K pedig az F5-F8. Ezt azert csinaltam igy, mert lattom, hogy alap 128K-ban ugyse fer el (a plusz CPC-t emulalo hosszu LPT miatt pl, meg amugy is akartam majd ugye EXOS-on at emulalni a disk-et disk image file-bol akkor meg pl a rendszerszegmenst sem art nem felulirni stb), akkor meg mar legyen ugy, hogy csak a SymbOS altal hasznalt 0xC000-0xFFFF tartomany essen EP-n videoram-ra, mert annak elerese ugyis lassabb :) Meg eleve teljesen video ram-ra tenni a CPC also 64K-jat nem tul jo otlet a fenti okok miatt (exos hasznalhatosag kozben, illetve LPT-nek kell videoram, amihez kell nem hasznalt ep vram szegmensbol kb 3Kbyte minimum).
Szoval az en tervezett amator EP-s SymbOS-em max demonak jo :) es alap EP-n nem is futna 128K rammal :( Nyilvan hivatalos port eseten, foleg, ha kiirtjak belole a CPC-s videoram szervezest, az LPT bezsufolhato a normal 128K ram-ba, illetve eleve EP-s driverekkel nem kell az OS-hez se beszelni kozben (mint nalam a tervezett emulaljuk a disk-et disk image-bol funkcio ...), igy az normal 128K-s EP-vel is mukodhetne elvileg, ahogy 128K-s CPC-n is megy (az mas kerdes, hogy irja: 128K az valojaban nem eleg normalis futasra, vmi 21K szabad RAM marad, ha semmi alkalmazas nem fut, eleve pl hatterkepet ajanlja kikapcsolni ekkor: amugy bar 21K elegnek tunik hogy az LPT-t bezsufoljam CPC-s szervezes eseten is, a gond az, hogy nincs fix cimem, es SymbOS kozbe ossze-vissza hasznalja a RAM-ot, nem tudom garantalni hogy LPT-t ne irja felul, ha csak bevagnam valahova).
-
Kicsit részletesebben lehetne? :oops:
Ilyenekre gondolok hol lakik a kernel, a driverek, az alkalmazások...
A videó RAM-ot említetted, ez egyben azt is jelenti, hogy max 16K videó memóriát tud kezelni? Magyarán akkor az kizárva, hogy EP-n teljes képernyős legyen (border nélkül), mivel az már nem fér egy szegmensbe?
-
Kicsit részletesebben lehetne? :oops:
Ilyenekre gondolok hol lakik a kernel, a driverek, az alkalmazások...
A videó RAM-ot említetted, ez egyben azt is jelenti, hogy max 16K videó memóriát tud kezelni? Magyarán akkor az kizárva, hogy EP-n teljes képernyős legyen (border nélkül), mivel az már nem fér egy szegmensbe?
Fogalmam sincs, hogy oszinte legyek, hogy a nagy "katyvasz" (128K memoria tartalom) pontosan hogy oszlik meg, azaz ebbol melyik a kernel stb. Pont az volt a lenyege, hogy forras ismerete nelkul csak memoria dump-bol abbol indultam ki, hogy a SymbOS mar inicializalva van, nem kell torodnom vele, hogy ki kivel mivel stb. En azt csinaltam, hogy az "epbas" projectem kereteben levo disassemblerrel :) disasm-oltattam az elso 64K-t es a felso 64K-t kulon. Adtam neki "code hints"-et (tehat hol biztosan kod van) az RST cimekre, es mivel a disassembler a projectemben koveti az ugrasi stb utasitasokat, eleg turheto eredmenyt adott (aprobb vicc benne, hogy az RST 0x30-at a kov byte-tal elnevezte EXOS n -nek, hehe). En ebbol indultam ki, pontosabban kezdve a hw interrupt vectorral, tehat a 0x38 cimen. Ugy tunik, hogy a felso es also 64K egy darabig azonos, nem csoda, mert interrupt akkor is lehet, ha a felso van belopzva, ezert talalkozunk mar az elejetol nem messze CPC memorialapozassal. Illetve azonnal latszik az is, hogy az AF' regisztert hasznalja arra, hogy a velhetoen 300Hz-es (oszinten fog'sincs CPC-t semennyire nem ismertem elotte, ez a project miatt kezdtem tanulmanyozni!), hogy 50Hz-et "csinaljon" belole, ugy, hogy minden 6.-nal csinal erdemben csak valamit. Gondolom a speed miatt is van, hogy az AF' erre van fenntartva, masra nem hasznalhato (ne kelljen menteni mindig). Amit meg tudok, hogy az I regisztert erdekes modon szinten fenntartja, es abban a CPC memoria config van, gondolom ugyanazert: ne kelljen letarolni memoriaba es beolvasni kulon mindig.
Ezek utan azt a modszert alkalmaztam, hogy a modositott EP emulatormban (ahol loggolok most 16 bites I/O-t, es emulalok is jelenleg par dolgot az alapjan) lattam, hogy melyik PC erteknel van valami port iras/olvasas. Ezt persze korrigaltam a CPC memoriaconfiguracio szerint, hogy "linearis" 128K-s cimet kapjak, ami a memoria dump-ban ertelmezheto. Ez alapjan nezegettem a disasm listat, hogy mi van azon a kornyeken, igy jottem ra par dologra, pl hol a keyboard scan, mi alapjan csinalja, stb, ezt sikeresen modositottam is. Amugy 0x1527-nel kezdodik, HL altal letarolja a kbd matrixot 10 bytenyi memoriaba (az elotte levo sok OUT az gondolom CPC-n azert kell hogy felprogramozza ehhez a megfelelo adatiranyt miegymas, EP-n ez total nem kell es felesleges). Ezek utan a "modosito" billentyuket (SHIFT, ALT - ez utobbi valojaban a COPY gomb a CPC-n ha jol nezem a matrixat, es CTRL) kiirja egy kulon byte-ba (0x14FC). Ezek utan a 10 byte-ra bitenkent hivatkova ad egy "billentyu indexet" (0...79), es ez alapjan hivatkozik a billentyukre innentol. 0x15B2-nel nezi caps lock-ot pl, utana meg hogy alt le van-e nyomva aztan kurzorvezerlo gombokat (ALT+kurzor gombokkal lehet eger nelkul SymbOS-ben navigalni). Ilyesmik. Ami meg feltunt: 0x15711 cimen (azaz a masodik 64K -ban) van 4 tablazat egymas utan ami gyanusan a CPC matrix gombokat mutatja, imho a fenti "system level" kbd.index-ek utan ezen tablazat alapjan konvertalja az egyes gombok erteket arra, hogy minek felel meg (pl karakterkod). Gondolom azert van 4db tablazat egymas utan, mert sima, shifted, ctrl-al es alt-tal, talan :)
Most tobb peldat nem irok, szovegesen hosszu lenne, es igazabol egyben csak text file-ba rittyentettem le magamnak, a disasm listat se igazan dekoraltam meg ezekkel fel :( A disk kezeles kapcsan is van persze par cimem, ahol latom es kb ertem is, hogy mi tortenik, a ket alapveto rutin amugy: 0xACDD/0xACE0 (1 byte-ot kuld ki, elotte var az RQM jelre az FDCctrl status regiszterben az 0xACD4 kornyeken, ket cimet azert adtam, mert egyiknel I/O cimet beteszi BC-be, masiknal meg nem, ez utobbi nyilvan azert mert mar ott van, ha vmi ezt hivja) es az 0xACF3 (1 byte-ot olvas, szinten RQM-re var). Ha ezek alpajan nezed, hogy mi hivja ezeket a rutinokat, egesz jol kirajzolodik a dolog, a write elso hivasa a command fdc-nek, ami CPC wiki-ben szepen ott van, tehat igy nem tul macera modon kb megvan, hogy a kodban hol, milyen FDC muvelet zajlik.
Bocsi, hogy csak leirom, tenyleg lusta voltam ezt asm-ban felkommentezni, foleg mivel sajat diassembleremet hasznalom ami ugye sajna nem eleg intelligens: ha ujra kene disasm-olnom, akkor kezdhetnem elolrol a comment irast :D Tudom van IDA miegymas, de nekem az Linux alatt sose jott ossze igazan, meg mindig a sajat cuccom volt szamomra a hasznalhato.
A video memorias kerdesed: legalabbis ugy tunik, hogy a CPC-n adott a 320*200-as felbontas 4 szinnel (symbos site-on emlitenek 2 szines 640*200-at is amire at lehet allitani), ugye mindket fenti felbontas pont 16ezer byte. Gondolom CPC-n nem lehet olyan szabadon allitani a felbontast CRTC-vel (vagy igen?), ezert lett ez a felbontas. Vagy talan azert is, mert a CPC memoriaszervezese (lapozas) eleg gaz (EP-hez viszonyitva). Szerintem nem lehet igazan vele olyat csinalni, hogy ket egymas melle eso 16K-s reszt "egyszerre" lapozni. De mondom, CPC-hez csak feluletesen ertek par napja. Az iroja is egyszer emlitette ugye, hogy alapvetoen a CPC korlatai minden portnal megvannak, ott is, ahol amugy a hw tudna tobbet, mert az a cel, hogy menjen minden eddigi rendszeren, es az applikaciok is "hordozhatoak" legyenek, azaz barmelyik CPC porton ugyanugy fussanak valtoztatas nelkul. Amennyire tudom, a CPC is tudna elvileg talan felbontast novelni valahogy, csak a memorialapozas miatt kevesbe lehetne egy ilyen OS-ben ezt normalisan kihasznalni. Nem tartom kizartnak, hogy esetleg forras szinten nezve a screen manager (vagy hogy hivhatjak) process modosithato ugy, hogy nagyobb legyen a kep, ez viszont szerintem olyan jellegu modositas ami 128K memoria dump alapjan allat nehez lenne vegigverzni a rendszeren csak binarisan "patch-elve". Bar nyilvan nem lehetetlen ... az is lehet, nekem nincs ehhez akkora tehetsegem, az FDC-vel is azert szenvedek :)
Bocs, ha esetleg csalodast okoztam, de en csak ilyen modszerekkel ismertem meg a dolgot, nem tettem kulonbseget hol a driver hol a kernel hol a system app, stb, csak sima memoriatartalomkent kezelem es probalgatom atirni :)
Amugy amit mondtam FDC-rol, es multitaskrol SymbOS-ben az elozo hosszu leirasomban, pl nezd meg a kodot kb itt: 0xAD76
Ez kuld egy 8-as parancsot (LD A,8 majd hivja a write byte-ot) az FDC-nek ami a sense interrupt state. Utana azonnal olvassa az eremdenyt, majd nezi az 5-os bit-et ami a seek end, ha jol remlik. Ha a seek meg folyamatban van, nyom egy RST 0x30-at. Na ez az, amit taglaltam a multiasknal: ha az FDC-ra varni kell, akkor inkabb soft interrupt-ot ker a system app, es azt mondja: "varni kell a seekelesre, addig fusson mas process es ne unatkozzon a CPU az fdc-re varva". Kb :-)
Nem tudom ezekkel a leirasokkal mit segitettem ...
-
Meg egy dolog elozokhoz kepest: valahol olvastam is, hogy a CPC memoriaszervezes miatt a SymbOS kulonbseget tesz, hogy a memoria egyes 16K-s reszein mi lehet es mi nem (EP-nel barmi, CPC-n ez sokkal korlatozottabb). A 0xC000-0xFFFF az a tartomany, amit adatcserere hasznalnak a process-ek kozott, ha jol remlik, gondolom ez is az oka annak, hogy a video pixel adatokat epp ide tettek, hogy elerheto legyen azon system process (process-ek) szamara, aminek kell. Amugy kesz horror, neha egesz hosszu szubrutinok vannak ami memoriacim alapjan kitalalja, hogy mit irjon a CPC gate array-nak RAM config-ra, haat nem mondom, EP-n ez azert egyszerubb lenne :)
-
Ize, na bocsi, sorban jutnak eszembe a dolgok :) Szoval egy CPC app egy relokacios tablaval es fejleccel ellatott file-ban vannak, amit a fejlecben levo SymExe10 alapjan en is ennek hivok :) Azt nem tudom, hogy driver-ek is ilyen formatumban vannak-e, szerintem nem (az se vilagos, hogy ezt mar SymbOS tolti be, vagy a loader meg a kernel valodi futtatasa elott). Ami viszont erdekes (errol vhol leiras is volt ...), hogy a SymExe10 formatum alapvetoen harom kulonbozo memoriat kulonboztet meg, es meg van szabva, hogy melyiket hova lehet tenni, illetve ennek a korlatozasnak is pont a CPC memoriaszervezese az oka, nevesint: nem lehet barmilyen kombinacioban 16K-kat lapozni sajna (nem ugy mint EP-n). Elvileg csak EP-re lehetne SymbOS-nel optimalisabb OS-t irni :) de szerintem egy SymbOS-nek is orulhetunk siman :) Vagyhat orulhetnenk.
Talan amugy az MSX portnal irja, hogy az MSX hw is sokkal rugalmasabb memorialapozast tenne lehetove, de a CPC-vel valo kompatibilitast meg kell tartani, mivel nyilvan nem akar kulon OS-t fejleszteni mindegyik gepre, a memorialpozas pedig erinti pl maganak az applikacioknak a felepiteset is, tehat innentol mar az app-ok se lennenek mindegyik SymbOS porton futtathatoak, ha itt komoly elteres lenne :(
-
Mivel a legtobb (mind?) SymbOS alkalmazas a screen manager process-en at rak ki dolgokat (mondjuk video lejatszo az erdekes kerdes, ha igy lenne, holt lassu lenne, de lehet, az nem atlagos alkalmazas, eleve pl abbol van kulon video forumatum is cpc-re es msx-re!), elkepzelheto, hogy SymbOS "normalis" port eseten, bar megmaradnak a cpc-re jellemzo lapozasi korlatok, a screen manager esetleg kicsit at lenne irva, hogy mondjuk tobb mint 16K helyen lasson video adatot. Igy az alkalmazasokat ez a bovites nem erinti, max a specialisokat ahol felig-meddig kozvetlen eleres van (vagy lehet?) pl a video lejatszo app. Persze ezek tippek, ehhez egesz melyen ismerni kene a rendszert, forraskod szinten ...
-
Tehát ha jól értem egy driver vagy akármi, max 1/50-ed (0.02) másodpercig futhat?
Ep-n ezzel a korláttal szerintem nem lehet floppyt kezelni.
Legrosszabb esetben egy teljes fordulatot kell várni a szektor írás/olvasás parancs kiadása után, és egy fordulat az 1/5 (0.2) másodperc, ami már 10x annyi idő...
Maga az 512 bájtos szektor átvitele 0.016386 másodperc, vagyis 0,003616 másodperc jutna a parancs kiadására, és a szektor megtalálására. Olvasásánál még ugyan lehetne hagyni a fenébe, ha nem sikerül időn belül elkezdeni, de írásnál ha nem toljuk az adatot a WD-nek amikor kéri, akkor tele írja 00 bájtokkal a szektort.
CPC/MSX esetén van hardver IRQ-ja vagy esetleg DMA-ja a floppynak? És ha van, akkor azt használja a SymbOS?
IDE/SD esetén nincs gond, ott a parancskiadási részen kívül akár BASIC-ből is mehet az átvitel :-)
-
Tehát ha jól értem egy driver vagy akármi, max 1/50-ed (0.02) másodpercig futhat?
Ep-n ezzel a korláttal szerintem nem lehet floppyt kezelni.
Legrosszabb esetben egy teljes fordulatot kell várni a szektor írás/olvasás parancs kiadása után, és egy fordulat az 1/5 (0.2) másodperc, ami már 10x annyi idő...
Maga az 512 bájtos szektor átvitele 0.016386 másodperc, vagyis 0,003616 másodperc jutna a parancs kiadására, és a szektor megtalálására. Olvasásánál még ugyan lehetne hagyni a fenébe, ha nem sikerül időn belül elkezdeni, de írásnál ha nem toljuk az adatot a WD-nek amikor kéri, akkor tele írja 00 bájtokkal a szektort
No igen, ez erdekes kerdes. A SymbOS irojat kene megkerdezni, de elmeletem azert van ra, mondjuk ellenorizni kene, de azert ime:
Ami biztos: nezzuk eloszor a seek-et (peldakent, kov bekezdes mar a sector olvasas)! Az olyan muvelet, hogy nem kritikus, ha tovabb varsz, mint hogy vege van, de azt meg kell varni, hogy vege legyen azert, es az adott track-re keruljunk. Ilyenkor, a SymbOS ha varina kell FDC-re szandekosan abba is hagyja a process futtatasat es atadja masnak (aka multitasking, sleep-on-I/O a processnek), es majd ha ujra hozza kerul a vezereles remelhetoleg kesz az eredmeny. Szoval ez nem bug, ez feature :D Ezt probaltam az elso hosszu mesemben kifejteni: SymbOS nem var I/O-ra seek-nel, inkabb atadja a kovetkezo process-nek addig a futas lehetoseget, mert kulonben mi ertelme lenne a multitaskingnak, hogy ott varjon amig vegez, amikor kozbe futhatna masik process ("program") akinek esetleg nem kell a disk, csak CPU idoszeletre ahitozik, mikozben az I/O-t vegzo cucc-nak nem kell CPU mert csak varakozik az I/O-ra. Bolondsag lenne nem kihasznalni, igy mindketten jol jarnak :) Igen, ez kicsit mas feeling mint egy monotasking rendszer pl EXDOS, ahol o szepen varja (kozben nem csinal semmi hasznosat szegeny CPU csak ott varakozik tesztelgetve, hogy kesz van-e) az wd-t, hogy mikor keszul el.
Node, azt nem tudom, valoszinuleg abban igazad van, hogy a sector olvasas _NEM_ ilyen, mert ott ha a megtalalja a megfelelo szektort, ugye azonnal olvasnod kell az eredmenyt, es nincs ido szorakozni, hogy addig mas process fusson, mert mire ujra rad kerul a sor, lehet, mar le is maradtal rola (gondolom a WD es a NEC sem buffereli az eredmenyt, hanem "real time" olvasnod kell!). Jo kerdes, hogy ilyenkor mi van. Egyreszt time critical cuccoknal latni neha, hogy DI ... EI kozott van nemi kod. Lehet egyszeruen azt csinalja, hogy ha nem megszakithato resz van ami fontos, akkor egyszeruen letiltja az interrupt-okat, igy biztosan nem veszi el tole a kernel a vezerlest addig, meg akkor sem, ha amugy nagyon szeretne :) Ez persze olyan szabaly, ami zavarja a multitaskingot nemikepp, hisz "darabosabb" lesz a valtas a processek kozott, mert pl a device manager eroszakkal (megszakitas leiltasaval) maganal tartja hosszabb ideig a vezerlest (atlag user app ne csinaljon DI-t, de van ahol pl system process-nel nem kikerulheto). Dehat ez van, gondonolom vannak dolgok (mint pl ez is) amit nem igazan lehet maskepp megoldani (pl DMA nelkul ...). Persze segitene (de imho EP-n es CPC-n sincs ilyen hasznalva), ha a floppy vezerlo interrupt-ot kuldhetne a CPU-nak ha kesz, igy OS szabadon csinalhatna mast, ugyis kap megszakitast a CPU, ha elkeszul, an interrupt kezelesre kello ido talan nem lenne tul sok (bar ki tudja ...), hogy elkezdje az adattransfert konkretan. Mert ahogy irod is, kozben lehet, hogy a lemeznek majdnem egesz fordulatot kell tennie, es addig mast nem lehet tenni, attol felven, hogy lemaradsz.
Bar most ahogy igy mondod :) Eszembe jutott az, hogy nem lehet-e, hogy pont ezert kell az altalam ertetlenul fogadott readID command? Azaz, elolvassa mi van a fej alatt eppen. Ha a keresett sector eleg messze van, azaz 1/50 masodpercnel tobb ido, akkor megeri masik process-t futtatni addig, es utana probalni ujra. Lehet ezen szepen finomitgatni, ami eleg alien fogalmaknak hangzik a megszokott (nem multitask) 8 bites OS-ek vilagaban azert :) Nemt tudom meg, hogy ezzel a trukkel el-e a SymbOS, vagy csak seek track-nel csinal ilyen soft interrupt dolgot, hogy masnak adja a vezerlest. Ha van kedved megnezni: ahogy nezem 0xADAE cimen van az a kod, ami kikuld egy sector read v sector write parancsot az FDC fele, ez a disasm listam alapjan ket helyrol van hivva, valoszinu az egyik a sector read a masik a sector write, es egyik regiszterben (talan a B? most hirtelen ranezve van eleg trukkos POP/PUSH magia) adja at, hogy a ket FDC parancs kozul melyik. Szoval ezt visszakovetve (megnezni mi hivja azokat a subrutinokat, aztan azokat amiket az hiv, stb) elvileg kiderulne, hogy mit csinal. Epp itt tartottam amugy en is az elemzessel, de 1-2 napja inkabb irkalok/firkalok rola ide a forumba, es nem volt vele idom foglalkozni :(
CPC/MSX esetén van hardver IRQ-ja vagy esetleg DMA-ja a floppynak? És ha van, akkor azt használja a SymbOS?
Jo kerdes, ahogy mondtam is, CPC-t azota ismerem, miota par napja erdekel a SymbOS visszafejtese es EP-n futtathatova tetele. MSX-et meg ennyire sem ismerem ... Bar a CPC wiki-n azt irjak emlekeim szerint, hogy az a NEC controller ami abban van floppy-ra tudna DMA-t, de CPC-n nem lehet hasznalni, mert nem ugy van megoldva a dolog. MSX-et meg konkretan nulla egesz nulla szinten ismerem, azon kivul, hogy tudom mi a fogalom.
IDE/SD esetén nincs gond, ott a parancskiadási részen kívül akár BASIC-ből is mehet az átvitel :-)
Ja, az cool am :) Foleg egy SymbOS szintu OS-nel ahol mindig kerulendo (de neha nem kikerulheto sajnos!) hogy letiltsa a schedulert az ember (azaz letiltsa az interrupt-ot), mert annak mindig negativ hatasa van a multitasking "folyamatossagara".
-
Btw, en ezeket nezegetem, CPC wiki alatt, I/O-rol osszefoglalas:
http://www.cpcwiki.eu/index.php/I/O_Port_Summary (http://www.cpcwiki.eu/index.php/I/O_Port_Summary)
Floppy vezerlesrol:
http://www.cpcwiki.eu/index.php/765_FDC (http://www.cpcwiki.eu/index.php/765_FDC)
Amugy jo ez a CPC wiki, segit azert sokszor, pl memorialapozasos dolgoknal is ezt nezegettem!
-
A DI-EI mindenképpen kell az átvitelhez.
Ha lehet némi "darabosság", azaz mondjuk 2-3 időszeletet is rászánunk a szektorműveletre, úgy már meg lehet csinálni, és az említett ID olvasás trükkel lehet finomítani.
Mondjuk összességében egész biztos, hogy jóval lassabban fogja kezelni a lemezeket mint az EXDOS, mivel nem tud szektorblokkokat olvasni, és a sima szektornál is várni kell mire a driver meg a lemez pont alkalmas pillanatban találkozik.
Ami még kérdés: CPC-n mi történik a DI alatt érkezett megszakítással? Mert nálunk ugye eltárolódik a Daveben, és EI-nél aktivizálódik. Így ha kicsit kicsúszunk az 1/50 időből, még nagy baj nem lesz.
Mondjuk CPC-n meg ott 300Hz, így ott is tud hamarosan pótlódni.
-
Mindenesetre újra elkezdtem elmélkedni a DMA-s EXDOS kártyán :-)
-
Mindenesetre újra elkezdtem elmélkedni a DMA-s EXDOS kártyán :-)
Ti biztos értitek mit jelent mindez, de két szóban elárulnád hogy miért volna jó egy DMA -s EXDOS ?
(Eccerűen ... "felhasználói" szempontból ...)
-
A DI-EI mindenképpen kell az átvitelhez.
Van is a kodban par helyen DI...EI, ahogy nezem :) Meg a keyboard scannel is, az pl EP-nel szerintem nem kell. CPC-n valszeg azert, mert ott mindenfele elbonyolitott modon van raakasztva a kbd matrix, es elobb fel kell programozni a megfelelo eszkozoket az adott adatiranyra miegymas (gondolom), EP-n felteve ha mas process nem akar kbd-t scannelni (szerintem SymbOS-en egy process vegzi es azzal kommikal minden mas), akkor ez nem gond, tehat itt egy "megakaszto tenyezo" azonnal letudva :)
Ha lehet némi "darabosság", azaz mondjuk 2-3 időszeletet is rászánunk a szektorműveletre, úgy már meg lehet csinálni, és az említett ID olvasás trükkel lehet finomítani.
Mondjuk összességében egész biztos, hogy jóval lassabban fogja kezelni a lemezeket mint az EXDOS, mivel nem tud szektorblokkokat olvasni, és a sima szektornál is várni kell mire a driver meg a lemez pont alkalmas pillanatban találkozik.
Hat, mindennek ara van, a multitasking mindenkeppen lassit, hiszen overhead-et jelent az, hogy idonkent megszakitva van vmi. Meg akkor is, ha semmi nincs benne ami idozites specifikus mint pl disk sector olvasas, es mas process eppen nem akar futni, akkor is a scheduler jon 1/50 masodpercenkent es megvizsgalja mi a szitu, es ha vmi varazslat folytan mas nem is akar futni, akkor is ido kell mar ehhez is eleve.
Igen, ezen en is gondolkodtam ("lassu lesz"), hogy ha SymbOS single sectort-t olvas (a kod alapjan ugy tunik ...) akkor a kov sectorhoz varni kell amig a lemez korbefordul. Nem tudom. Lehet, eleve interlaved modon volt CPC-n a szektor kiosztas, igy a kov sector a disken nem fizikailag utana jon pont? Illetve, bovitesi lehetoseg: ha van eleg RAM, lehetne bufferelni a kov sectort is ha epp ugyis "keznel" van, es foleg, ha tudjuk (hmm, ezt azert nem egyszeru megmondani), hogy kell a kovetkezo is, akkor le lehetne tarolni, es ha read jon ra, mar ki lehet szolgalni. Ezzel eljutottunk a modern OS-ek disk cache fogalmahoz, amikor a nem hasznalt RAM-ot automatice disk cache-kent utilizalja (anno meg 2000 elott mindig panaszkodtak ismerosok hogy sz** a Linux, alig van/nincs szabad RAM! Azt nem ertettek, hogy a RAM eroforras; az a jo, ha tokig ki van hasznalva, kulonben minek van a gepben, ha csak uresen all? Nyilvan a kernel atadja app-nak es nem kezeli tobbe cache-kent, ha valakinek meg RAM kell ... szoval egy modern OS-t irni azert nem egyszeru, van benne trukk ezerrel egy csomo, es meg az x86 es hasonlo hw-k adta lehetoseg pl lapvedelem, CoW - Copy On Write - stb dolgok hasznalatarol meg nem is szoltunk, ez utobbi viszont mar nem Z80 tema erosen, a disk cache elvileg lehetne meg).
Az is baj, hogy jokat talalgatunk, de valojaban a SymbOS szerzoje nyilvan pontosabb valaszokat tudna adni :) Azert az erezheto, hogy ahogy egy doksiban is van: azert alap gep hiaba kiraly a SymbOS igen szukos neki, 128K RAM pl szinte semmire nem eleg normalisan dolgozni vele, illetve vmi SymbiFace vagy mi nevu hw is van amin RTC, IDE stb CPC-re (CPC wiki-n ott van valahol, az I/O port summary-ban is emlekeim szerint). Tehat az oke, hogy alap CPC-n es nyilvan alap EP-n is elfut(-na), de az eleg minimal neki mar, es talan kenyelmesebb hasznalatahoz azert tobb kell. Vegulis, tegyuk szivunkre a kezunket, meg multitask nelkul EXDOS-szal is mindenki SD kartyara vagyik mar, es esetleg kevesbe preferalja a floppyzgatast, az ido szava meg a regi gepeket sem hagyja erintetlenul ... Arrol nem is beszelve, hogy anno CPC/EP stb fenykoraban valoszinuleg nem is igazan jutott volna meg eszebe senkinek mikrokernelt meg ilyen modernebb OS fogalmakat alkalmazni sehol, meg nagyobb gepeken sem igazan, vagy csak elvetve legalabbis ...
Ami még kérdés: CPC-n mi történik a DI alatt érkezett megszakítással? Mert nálunk ugye eltárolódik a Daveben, és EI-nél aktivizálódik. Így ha kicsit kicsúszunk az 1/50 időből, még nagy baj nem lesz.
Mondjuk CPC-n meg ott 300Hz, így ott is tud hamarosan pótlódni.
Jo kerdes, passzolom :) A mostani felig EP-s SymbOS ganyolasom (ugye JSep alapbol EP emulator, Nick-hez LPT-hez - azokat inicializalom magam a snapshot alapjan amit szinten en gyartottam -, memorialapozashoz nem nyultam, ami most ganyolva van benne az atiras miatt az az I/O port-ok CPC szerinti ertelmezese, meg par ilyen kisebb dolog) peldaja okan azt csinalom, hogy atirtam ahova az rst 0x38 mutat. Eloszor is kiirtottam ezt a 300Hz/6 varakozast, mivel eleve 50Hz-unk van, VINT-bol. Aztan nyomok azonnal egy dave latch reset-et mar az elejen. Igy mukodni latszik, jelenleg a berhalt JSep-vel elindul a SymbOS, a kicsit atirt kbd scan koddal pedig tudom mozgatni az egerkurzort, csak ugye ha valamit megprobalok elinditani, akkor ablakot kirakva (ezt mar kuldtem egy regebbi hozzaszolasomban) kozli velem, hogy disk error, ami nem is csoda, mert meg nincs kesz :) Lehet, EP-n a kritikus szekciot amugy nem eleg vedni DI-EI-vel hanem Dave VINT (azaz INT1) enable/disable kene inkabb helyette?
Amugy visszaterve EP-hez: en azt gondolnam, hogy igazi "EP-only" OS eseten vagy meg kell tartani az EXOS/EXDOS-t es raultetni vmit (ez szerintem az EGI iranyvonala), esetleg nemi multitasking bevetesevel (ahol EXOS funkcio futasa eseten nyilvan nincs process valtas), vagy irni nullarol (na ez nem lenne kis melo) egy uj EXOS-t ami eleve tud ilyesmiket is. Azt persze, hogy ez kompatibilis legyen, nehez v szinte lehetetlen megcsinalni. Gondolok itt pl arra, hogy nem igazan van lehetoseg (a kompatibilitas megtartasaval!) hogy pl ne egy szem rendszerszegmenst turkaljon mindenki egyszerre, vagy ne is nyuljanak hozza, es legyen az az EXOS maganugye belsoleg. Stb. Az is lehet, hogy ilyen jellegu OS eseten kvazi nem igazan realisztikus megtartani az eredeti EP software-ek futtatasat ilyen kornyezetben, ha ilyeneket (pl exos-5 fejlec) futtat vki, akkor az monotaskingra atall, de be lehet vezetni uj fejleccel megaldoitt sw-ket, amire szigoru eloirasok vannak, hogy mit hogyan szabad neki es mit nem, es azokat pl lehetne vhogy parhuzamosan is futtatni akkor, es akkor nincs kompatibilitasi gond, mert ez egy uj "program tipus" lenne. Viszont erosen vitathato, hogy lenne-e ertelme, azert olyan nagy erdeklodes nem lenne ra ... A SymbOS olyan szempontbol jo, hogy mar tobb gepen is megy, es az app-ok hordozhatoak is kb, es EP-nel (sajnos ...) nepszerubb gepeken is fut. Viszont egy EP only uj OS haaat ... nem tudom :)
-
Ti biztos értitek mit jelent mindez, de két szóban elárulnád hogy miért volna jó egy DMA -s EXDOS ?
(Eccerűen ... "felhasználói" szempontból ...)
Felhasználói szempontból csak annyi, hogy 4MHz-es gép is tudná a HD-s lemezeket kezelni :-)
Programozói szempontból, lásd SymbOS: nem a proci lenne terhelve az átvitellel, azt a háttérben megoldaná a DMA. Magyarán a driver csak elküldi a parancsot, hogy mit kell csinálni, aztán időnként ránéz az állapotbitekre, hogy befejeződött-e a művelet, vagy pedig valami hiba van, de mindeközben a megszakításokat nem kell tiltani.
-
Ti biztos értitek mit jelent mindez, de két szóban elárulnád hogy miért volna jó egy DMA -s EXDOS ?
(Eccerűen ... "felhasználói" szempontból ...)
DMA a Direct Memory Access (asszem) roviditese, es arra utal, hogy nem a CPU vegez memoriamuveletet. Azaz, pl megmondod a floppy controllernek, hogy akarod ezt a szektort, DMA vezerlovel egyezteted, hogy majd lesz szives elkerni a controllertol es ide es oda lerakni a memoriaba aztan. A Z80 meg kozben total mast csinal, "varazslatosan" megjelenik majd a memoriaban a szektor, anelkul, hogy Z80-nak varnia kene ra, es/vagy neki kene az adatokat beolvasnia. Ez egy EXDOS eseten nem feltetlen ertelmes, mert amugy is monotasking (ill max annyi, hogy lehet a DMA gyorsabb mintha a CPU csinalna!), viszont egy SymbOS eseten (vagy barmi hasonlo multitask OS) nagyon hasznos, ugyanis kozben szabadon futhat mas program addig amig a DMA dolgozik, ami maskepp nem lenne lehetseges. Az eredmeny egy SymbOS v hasonlo OS eseten: disk I/O alatt sem "darabosodik" a disk ativeteli sebesseg javul, stb. Amugy hasonlo meg a win95 kornyeken (?) volt, ahol floppy format az hazavagta a dolgokat erosen, mert (nem ertek a windows-hoz, tippelek, es ezt a gondot is onnan tudom h haverok mergelodtek mindig) kozben a OS talan BIOS funkciokat hivott 16 bites modba valtva addig, es felfuggesztve a multitaskingot. Ha ez az elmeletem a win95 kapcsan igaz, akkor az a vicces szitu, hogy ez teljesen hasonlo lenne, mint amikor a SymbOS-t megprobalnank EXOS/EXDOS funkciokra raultetni a sajat hw szintu driverei helyett (ahogy ott BIOS-t hivott hw kozeli sajat lekezeles helyett).
-
Felhasználói szempontból csak annyi, hogy 4MHz-es gép is tudná a HD-s lemezeket kezelni :-)
Ok, és minek nekünk HD -s lemez ? Vagy még a winyo/SD -knél is fáj nekünk a z80 memcopy ?
Úgy értem az LDIR -es SD már tényleg álom sebességű ... még nagyobbat akarsz álmodni ?
-
Ok, és minek nekünk HD -s lemez ? Vagy még a winyo/SD -knél is fáj nekünk a z80 memcopy ?
Úgy értem az LDIR -es SD már tényleg álom sebességű ... még nagyobbat akarsz álmodni ?
Jo, hat ha nem koveted a melylelektan OS ismeretek cimu eloadasomat, akkor nem erted :) SymbOS eseten erosebb a lassulas mint EXDOS eseten mert multitask OS, mast is csinalnia kell, lecsuszhat dolgokrol es tovabb kell varni stb, itt tobbet segitene a DMA. EXDOS eseten a gyorsulas talan kevesbe kritikus, mert o amugy is csak var amig nincs kesz, mas dolga nincs (multitask OS-nel lenne boven!). Marmint hozzaszolasom most csak az atviteli sebessegre vonatkozik mono es multitask OS versus DMA esetre. A HD-s floppys kerdest majd Zozo tudja, lehet a 4MHz-es Z80 lassu hozza hogy LDIR-el is bekerje? Az, hogy miert kell HD floppy az meg passz, en eleve nem is floppyzgatnek mar, de tudom, en ilyen problemas eset vagyok, hogy keverem a modernt a retroval :)
-
Na vagyis akkor a kérdésemre a válasz az felhasználói szempontból az,
hogy azért volna jó a DMA, mert akkor egyik alkalmazás lemezkezelése (konkrétan ami hosszú belőle, az adatátvitel) nem fogná be a párhuzamosan futó többi alkalmazást,
az alkalmazások nem blokkolnák be egymást ...
Persze ettől még ugye a párhuzamos lemezműveletek még ugyanúgy blokkolnák egymást, nem hinném hogy minden alkalmazásnak külön DMA csatornájna lenne ...
Mondjuk az azért valóban elég világbajnok dolog, hogy egy teszem azt 10 másodperces betöltés egy valamilyen editorba, vagy épp egy induló programnál nem fogná be 10 másodpercig a már futó óra vagy számológép alkalmazást, akik pedig épp nem nyúlnak storage -hoz ... valóban.
-
Amugy legfuturisztikusabb otlet DMA/eleg memoria eseten: readID-el lekerdezzuk hol vagyunk aztan (nem tudom FDC engedi-e WD ill a CPC-s NEC eseten) onnantol a teljes savot bezuzzuk memoriaba. Aztan ha ugyanarrol a track-rol kell adat, akkor memoriabol adhatjuk (figyelem, ha sector iras van, nem art a disk cache-t ervenyteleniteni vagy ott is atirni ... az mar az advanced hozzaallas netovabbja, hogy delayed write is legyen, azaz ne irja azonnal disk-re csak ha osszegyult tobb valtozas vagy sok ido eseten nem volt tobb irni valo - ez viszont azzal jar hogy a floppy-t nem illik barmikor kivenni hanem szabalyosan le kell valasztani, ez gondoiom pl pendrive eseten mindenkinek ismeros - Mac-eken regen - most nem tudom - nem is volt mechanikus kiado gomb, mert ne vedd ki a lemezt, ha tartalma meg inkonzisztens lehet! Amugy FAT eseten ez hasznos mert pl irasnal ossze-vissza ugralni kell az adatblokk felirasa majd FAT update-elese kozott, bar igaz a FAT minden csak nem koreszu filerendszer ...).
Mondjuk az lenne a szep DMA-s floppy stb eseten, ha barhova a fizikai RAM-ba tudna DMA-zni. Azaz nem csak oda, ami eppen Z80-nak be van lapozva. Azt viszont nem tudom, hogy a 22 bites EP cimbusz felso 8 bitje ami a dave 4 "lapozo" regisztererol jon (B0...B3) levalaszthato-e buszrol, azaz azt mondd a Dave-nek hogy tegye magas impedanciaju allapotba a kimeneteit, es hagyja beken a buszt szepen. Pedig ez lenne a szep, ugy Nick modra: ugye Nick is olvassa LPT-t, videoram-ot stb (voltakeppen DMA-zik, read-only modban allandoan!) akkor is, ha egy VRAM szegmens sincs belapozva Z80-ra. DMA-nal is jo lenne, ha szabadon DMA-zhatnank barhova, Z80 szegmens lapozasatol fuggetlenul a Dave altal.
Lehetne meg fokozni, de szerintem kisse elszaladt velem a lo ;)
-
Persze ettől még ugye a párhuzamos lemezműveletek még ugyanúgy blokkolnák egymást, nem hinném hogy minden alkalmazásnak külön DMA csatornájna lenne ...
Ennek nem lenne ertelme: a disk-nek egy feje van (na jo, ket oldalas eseten ketto, de akkor sem tud egyszerre mindkettovel olvasni v irni), egyszerre akkor is csak egy dolgot tud olvasni, de meg egy SD kartya is egyszerre egy parancsot szolgal ki ...
-
Ennek nem lenne ertelme: a disk-nek egy feje van (na jo, ket oldalas eseten ketto, de akkor sem tud egyszerre mindkettovel olvasni v irni), egyszerre akkor is csak egy dolgot tud olvasni, de meg egy SD kartya is egyszerre egy parancsot szolgal ki ...
2 SD kártya 4 winyó kombó ? :)
-
2 SD kártya 4 winyó kombó ? :)
ugy oke :)
-
Ok, és minek nekünk HD -s lemez ?
Nekem azért mert szeretem a floppyt :ds_icon_cheesygrin: Az még olyan ember közeli periféria, lehet látni, hallani hogyan dolgozik. A flancos modern dolgokon, mint az SD kártya még egy LED sincs :twisted:
-
Nekem azért mert szeretem a floppyt :ds_icon_cheesygrin:
Na ja ...
A flancos modern dolgokon, mint az SD kártya még egy LED sincs
Az én avr lapomon beépítve van vagy 3 ... villog is mindenfélék közben, mint a karácsonyfa ...
Meglepne, ha megnéznéd az SD nyákot, és nem találnál rajta 20 helyet, ahova beköthetsz ledeket, és mindenféléket kijeleznének neked ...
Adtál is egy jó ötletet ... a cartridge -ba szerelhető verziónál miután megvannak ezek a helyek, akkor ki lehetne szépen fúrni a házat, és ledeket tenni a furatokba ... :)
-
Hat, sokra nem jutottam SymbOS EP-re "ganyolasa" temaban sajnos :( Ez a disk kezeles kemeny dio. Hiaba hiszem, hogy ertem, csak nem mukodik. Raadasul itt mar nem is a konkret FDC vezerlo a problema, nemes egyszeruseggel SymbOS mindenre azt mondja hogy File not found :( Az eredeti CPC disk image-ekkel is, szoval otletem sincs. Amig nem emulalgattam es/vagy irtam at a megfelelo rutinokat addig legalabb disk error volt, ami ertheto. De ez a file not found arra utal, hogy nem az "alacsony" szintu disk kezeles a gond, hanem az, ami a disk-en van, arra viszont nincs rahatasom. Vagy nem tudom ...
-
kár... :-(
-
kár... :-(
Nagyobb kár, hogy a hivatalos verzió ügyben nem látni mozgolódást :-(
-
Nagyobb kár, hogy a hivatalos verzió ügyben nem látni mozgolódást :-(
Igen. Emlekeim szerint volt mar ilyen, hogy elkezdtunk beszelgetni, a srac is bekapcsolodott, lelkes volt stb, aztan ott megallt a dolog. Most kb ugyanez. Persze ertheto azert, ha hobby szinten csinal vmit, nem elvarhato, hogy szamon kerjuk rajta. Viszont legalabb a forrast adhatna (penzt ugyse nagyon tud csinalni belole szerintem stb), hogy nekiallahassunk pl mi. Az pedig neki is jo lenne, ha kiirhatna az oldalara, hogy EP-n is megy, meg ha neki nincs is ideje foglalkozni ezzel a reszevel. En irtam neki maganban errol (persze szep udvarisan, erdeklodve stb) de valasz nem erkezett.
-
En irtam neki maganban errol (persze szep udvarisan, erdeklodve stb)
Ez viszont jó hír, lehet, hogy segíteni fog, ha látja a lelkesedésünket (a munkádat :-))
-
Ez viszont jó hír, lehet, hogy segíteni fog, ha látja a lelkesedésünket (a munkádat :-))
Hehe. Rahibaztal :) Azert is szeretnem (szerettem volna .... ?) ha sikerul osszeganyolni az "Ep-n futo CPC valtozatat" a SymbOS-nek, mert talan felkeltene a figyelmet, hogy tenyleg komolyan erdekel, nem csak a forrast akarom "megszerezni" aztan annyi, hanem tenyleg szeretnek (-nenk) EP-n nativan futo valtozatot.
Amugy fura, akar hogy is nezem, a diskkezeles elvileg OK, valamiert nem talalja meg a sajat disk image-en amit akar ... Mondjuk nem teljesen ertem: a CPC verziohoz adott disk-ek lathatoan vmi CP/M szeru filernedszert hasznalnak (ami nem meglepo, mert az a CPC-s AMSDOS vagy mi az ha jol tudom megtartotta a CP/M disk formatumot, es nem FAT ...). Ebben az erdekes az, hogy a SymbOS-rol az iroja is azt irta, hogy FAT-et hasznal csak. Viszont tenyleg mindegyik disk image-en a CPC verzional ami letolheto a symbos.de-rol azonnal a directory szeruseg van elol (legeleso track legeleso sectora), ami FAT-re nagyon nem jellemzo ugye :)
-
Első körben jó lenne végre "gyári" információkat hallani, memóriafelépítés, driverek, stb ügyben.
Egyelőre csak annyit tudunk amit Lgb kiokoskodott.
-
Első körben jó lenne végre "gyári" információkat hallani, memóriafelépítés, driverek, stb ügyben.
Egyelőre csak annyit tudunk amit Lgb kiokoskodott.
Epp tegnap (v tegnap elott?) keresgeltem: http://symbos.de/download.htm (http://symbos.de/download.htm) Itt azert lentebb kicsit vannak doksik is, amiben leirnak par dolgot. Ami meg erdekes, hogy egyes app-okrol talaltam forraskodot is, de sajnos maga a "lenyeg" a kernel, arrol persze nincs, hogy "normalisan" portolni lehessen :( Vagy csak az en figyelmemet kerulte el ...
-
Közben megnéztem, az ep128emu CPC módjában (576K+AMSDOS) bebootol :-)
-
Közben megnéztem, az ep128emu CPC módjában (576K+AMSDOS) bebootol :-)
Az lehet :) En azert nem is probaltam meg, mert az ep128emu nekem "kinai" marmint mivel C++ nem vallakoznek hogy beleirjak, a caprice CPC emulatornal ez nem volt problema :) Azt sose ertettem minek egy emulatort C++-ban irni, dehat nem is en irtam, es valoszinu ilyen szintu emulatort sem tudnek irni, szoval inkabb befogom a szamat, a C++ nem ismerete meg ugye az en hianyossagom.
-
És mi lenne, ha a CPC-s device drivereket kidobnád a francba (legalábbis a floppy-t), a Symbos download oldalon ott vannak az MSX driverek source-okkal, ráadásul az is WD-t használ.
Az FDCSVI.asm WD1793-hoz driver.
-
És mi lenne, ha a CPC-s device drivereket kidobnád a francba (legalábbis a floppy-t), a Symbos download oldalon ott vannak az MSX driverek source-okkal, ráadásul az is WD-t használ.
Az FDCSVI.asm WD1793-hoz driver.
Mint mondtam, memory image-em van CPC-rol, halvany lila gozom sincs, hogy honnan mit tolt be, mar ugy van betoltve es kesz azt kell patchelni binarisan :) Amit mondsz az akkor lenne jarhato ut, ha forraskod szintu portolasrol van szo. Hiaba van XYZ driver forrasban is, hova tegyem, ha 128K-nyi mem image van, es abban max par dologrol tudom hogy ott mi lehet? :) Nyilvan ez akkor mukodne ha full port, loader stb mindenestul lenne, es nem a snapshot-os megoldassal jatszanek.
Masreszt ugye itt a tervem pont az volt, hogy nem lesz WD, disk image file-t hasznal helyette (EXOS-on at), szoval a kozvetlen hw nem is lenyeg.
-
Amúgy meg megnézve a betölthető verziókat, abban sincsenek driverek külön :-( egy nagy fájlba van összerakva az egész, amiről ugyanúgy nem tudni, hol és mi van benne :-(
-
Igen, en is neztem. Persze az is alternativ ut, hogy az ember visszafejti a loader-t, mit csinal azzal a nagy file-al, es kitalalja ez alapjan hogy az hogy epul fel, stb. Ez azonban erzesem szerint joval nagyobb melo lenne, mint egy mar betoltott rendszer memoriakepet fogni, es par helyen beleirogatni. Ez utobbi sikerult is nekem felig, hiszen pl EP kbd scan rutint mar beleeroszakoltam a CPC-s helyett. Illetve kivagtam az egesz alacsony szintu (NEC fdc) floppy cuccost, mert megtalaltam hol hiv eloszor barmit, ami azzal kommunikalni, es igy kb az "olvass be egy szektort" rutinba irtam inkabb bele (ahelyett h hw-t programozza kozvetlenul). Ennek alapjan mukodni is latszik, latom, hogy a track 0 sector 1-et olvassa, majd a track 1, sector 1, 2, 3, 4-et sorban, amit jelenleg a modositott JSep-vel es a patchelt memoria image-ben emulalok is rendesen. Csak ugye itt a bokkeno, hogy SymbOS kozli, hogy file not found :( Ezt mondjuk nem tuodm miert, mert elvileg igy mukodnie kene ...
-
Belenézve az elérhető forrásokba: használnak undocumented utasításokat, elég sokat.
Szóval Z180-on nem fog futni, pedig egy ilyen rendszernek jönne jól minden plusz CPU teljesítmény!
-
Az nem lehet, hogy a betöltés ellenőrzésekor más értékkel tér vissza az eredeti, mint az emulált verzió, és ez a visszatérés a Symbosban egy file not found hibakód?
-
Az nem lehet, hogy a betöltés ellenőrzésekor más értékkel tér vissza az eredeti, mint az emulált verzió, és ez a visszatérés a Symbosban egy file not found hibakód?
Barmi lehet :) Nem tartom amugy valoszinunek, barmelyik disk image-et adom hozza, es barmit probalok SymbOS-ben elinditani mindig a track 0, sector 1-et, majd a track 1, sector 1-4-et olvassa pont ilyen sorrendben. Ez alapjan nem ugy tunik, mintha magat a file-t olvasna, hanem mar a directory-n (ami a CPC-s AMSDOS-os alapvetoen CP/M filerendszeren a disk legelejen van) elhasal vmiert, es nem talalja meg. Az is lehet, hogy persze olyan prozai okai vannak a dolognak, hogy en mar betoltott SymbOS-t CPC-n mentettem mint memoria allapot es CPU regiszterek, es epp a kihagyott rutinok (alacsony szintu disk kezeles) modositananak vhol vmit a memoriaban, amivel jelez valamit, es ez igy ugye kimarad. De ezt total vegigkovetni disasm alapjan nem tul egyszeru ... :(
-
A file not found egyébként mire jön?
Az emulátorban, amikor bebootol van 4 ikon, a SymCommander, és a SymShell az file not found, a Controll panel és a Task manager az működik.
-
A file not found egyébként mire jön?
Az emulátorban, amikor bebootol van 4 ikon, a SymCommander, és a SymShell az file not found, a Controll panel és a Task manager az működik.
Azt irja vhol egy readme jellegu file a CPC-s symbos download-nal, hogy bebootolas utan disk-et kell cserelni az applications disk-re. En ezen felbuzdulva, kiprobaltam mindket disk image-et, es kb probaltam szinte mindent, de mindenre file not found-ot kaptam (marmint a "felig" portolt SymbOS-rol van most szo). Azt probaltad, hogy az applications disk-et beteszed miutan felallt a rendszer, es akkor is file not found a symcommander es symshell-re?
-
Így már jó :-)
-
Így már jó :-)
Cool. Kar, hogy nalam nem :D
-
A PCW esetén 720*256 kétszínű képernyő van, ami 22.5K, 2 szegmenses. Ha ez megy, akkor EP-n se lehet gond a 2 szegmenses videó memória.
Egyébként ennek a PCW-nek is van LPT szerűsége. Meg szabadon lapozható szegmensei, igaz itt csak 7 bites a címzés, azaz 2MB a max memória. Mindenesetre gyanús, hogy Amstradék még tovább loptak az EP-ből :-)
-
A PCW esetén 720*256 kétszínű képernyő van, ami 22.5K, 2 szegmenses. Ha ez megy, akkor EP-n se lehet gond a 2 szegmenses videó memória.
Egyébként ennek a PCW-nek is van LPT szerűsége. Meg szabadon lapozható szegmensei, igaz itt csak 7 bites a címzés, azaz 2MB a max memória. Mindenesetre gyanús, hogy Amstradék még tovább loptak az EP-ből :-)
Nyilvan meg lehet oldani :) En a 16K limitaciot inkabb amiatt ertettem, ha egy "gyors" CPC->EP portolasrol van szo, es nem akar az ember hozzanyulni feltetlen tul sok dologhoz. Bar, ha az embernek a forraskod is megvan, akkor talan ez nem is olyan nagy melo :) Illetve persze 128K-s alapgepen minden K szamit, csokkenti a szabad memoriat a nagyobb video RAM, sot, ha hatterkep is van, akkor meg duplan :(
-
Erdekes. Probakeppen kitalaltam, hogy mi van ha nem 0-tol kezdodik a szektorszamozas meg stb. Ennek eredmenye eleg erdekes, nem file not found, hanem, hogy nem symbos file, ezert nem tudja futtatni. Ez felvet egy erdekes kerdest: valahogy itt nagyon meg van kutyulva a sector/track kiosztas es "rossz" adatokat adok neki. CP/M eseten van a "skewing" (az kb olyan lehet mint az interleaved kiosztas ha minden igaz), CPC AMSDOS is vmi CP/M voltakepp. A problema ezzel viszont az, hogy ahol talalkozok ezzel az mar kozvetlenul a NEC fdc vezerlonek meno parancsok, tehat itt mar nem kene, hogy ervenyesuljon barmi ilyen, hiszen itt mar a hw fele megy kozvetlenul a keres ...
-
En a 16K limitaciot inkabb amiatt ertettem, ha egy "gyors" CPC->EP portolasrol van szo
Engem viszont az izgat, hogy rendes portolás esetén mit lehetne kihasználni az EP képességeiből :-)
-
Én kíváncsi lennék hogy oldották meg ebben a Symosban azt hogy más-más architektúrák máshogy kezelik a lapozást, vagy ahhoz hasonló dolgokat.
Az EP extra képességeit, egyedi dolgait nem hiszem hogy ki tudná bárhogy használni.
-
Én kíváncsi lennék hogy oldották meg ebben a Symosban azt hogy más-más architektúrák máshogy kezelik a lapozást, vagy ahhoz hasonló dolgokat.
Az EP extra képességeit, egyedi dolgait nem hiszem hogy ki tudná bárhogy használni.
A memorialapozas a legkisebb kozos nevezo alapon megy, tehat amit tud minden gep amin SymbOS fut ... Ez voltakepp a rendszer teljes felepitesre es message-passing rendszerere hatassal van, de nem hinnem, hogy ez problemat okozna (CPC-n is van 1Mbyte RAM-ot kihasznalo verzio pl). "Extra kepessegek", hat hmmm, nem tudom :) Ugye azert azt vegyuk tudomasul, hogy egy tobb kulonbozo gepen futo OS-nek pont az az elonye ami a hatranya is: mindegyiken fut, app-ok uazok, de igy nem hasznalhat ki mindent, kulonben nem futna mind1iken ....
-
Engem viszont az izgat, hogy rendes portolás esetén mit lehetne kihasználni az EP képességeiből :-)
Nem ugyanarrol beszelunk, en azt irtam "gyors" te meg "rendes" portolas eseten :) Amugy tenyleg milyen kepessegre gondolsz, ahogy elobb irtam, szerintem sajnos azert vannak limitaciok amiatt, hogy nem valoszinu nem forkolna a srac egy SymbOS for EP-t, mert ugyan akkor EP dolgaira nagyon ra lehetne menni, de akkor vegul kb "onallo" OS lenne, o meg ugye egy OS-t fejlesztene, ami fut tobb gepen is. Szerintem azert pl beleferne, ami hirtelen eszembe jutott (elvegre ezek nem is annyira a core reszei ...):
* custom screen manager, nagyobb felbontas mint pl 320 pixel 4 szinu modnal
fuggoleges felbontas novelese? interlaced mar durva/lassu lenne :D
attribute gfx tamogatasa, ablakonket (ami ahogy nezem amugy is 8-as pix hataron van) mas sajat 2 szinnel [van ertelme?]
/mert ugye lehet tobb videomod is mas gepeken is/
* eleg memoria eseten "EXOS barat" uzemmod, ne irja felul a rendszert, foglaljon EXOS-tol memoriat a loader, es adja tovabb [kesobb a symbos mar nem hiv exos-t stb] a szamara hasznalhato szegmensszamokat, ennek elonye pl az igen sokoldalu EP memoriaszervezes (nem is kell folyamatosnak lennei fiziikailag, lehet "bad segment" is stb) amit SymbOS nem feltetlenul talalni ki jol betoleskor minden esetben
* SymbOS nyilvan "onallo" OS, es disk I/O-t nem EXDOS-ot at nyomna, de azert pl diskio alaocsony szintu rutinokat hasznalhatna
[nem kell mindenhez feltetlen hw driver], illetve "EXOS kompatibilis" (eleg memoria eseten!) SymbOS modban megtarthatna
a RAMdisk tartalmat, ami SymbOS alol is elerheto lenne, igy adott nemi adatcsere, foleg ha rendesen megy a kilepes symbOS-bol
stb
* boxsoft mouse tamogatas :-D
Most hirtelen ezek ugrottak be. Aztan nyilvan lehetne pl Dave muzix lejatszot stb, de ez mar mind applikacio, en most az OS szukebb ertelmeben vett reszeire gondolok csak elso korben ...
-
Az első amire gondolok, az teljes keret nélküli képméret, mondjuk a PAL szabványt alapul véve az 360*288 lenne 4 szín módban. A Nicl soronkénti trükkjei nem igen passzolnak ilyen ablakos rendszerhez :-( max alul a tálca lehetne más színű.
Aztán majd a hangnál jönne, hogy sztereó legyen :-)
-
attribute gfx tamogatasa, ablakonket (ami ahogy nezem amugy is 8-as pix hataron van) mas sajat 2 szinnel [van ertelme?]
Ha jól tudom az MSX az attributumos.
-
* eleg memoria eseten "EXOS barat" uzemmod, ne irja felul a rendszert, foglaljon EXOS-tol memoriat a loader, es adja tovabb [kesobb a symbos mar nem hiv exos-t stb] a szamara hasznalhato szegmensszamokat, ennek elonye pl az igen sokoldalu EP memoriaszervezes (nem is kell folyamatosnak lennei fiziikailag, lehet "bad segment" is stb) amit SymbOS nem feltetlenul talalni ki jol betoleskor minden esetben
Igen ilyenre is gondolok, ahogy már korábban is töprengtem ezen :-)
-
Az első amire gondolok, az teljes keret nélküli képméret, mondjuk a PAL szabványt alapul véve az 360*288 lenne 4 szín módban. A Nicl soronkénti trükkjei nem igen passzolnak ilyen ablakos rendszerhez :-( max alul a tálca lehetne más színű.
Na igen. Oda inkabb vmi Amiga szeru OS illene, ott volt vmi olyasmi ha jol remlik hogy egy screen-t "el tudsz huzni" fel-le,
oda illene :) Vagy kene pl slot-onkenti LPB :-P [na ez csak vicc volt)
Aztán majd a hangnál jönne, hogy sztereó legyen :-)
Na igen, de annak meg nincs koze igazan az OS magjahoz, max hanglejatszo applikaciohoz, amibol ugyis ujat kell irni, mert imho a meglevo symamp (vagy mi a neve) az ugye AY-re van ... Vagy esetleg ilyen "AY player Dave-re" ami mar van ha jol tudom (marmint nem SymbOS alkalmazas, nyilvan!)?
Ami meg felmerult a reszedrol pont: erdeklodni, hogy kernel/stb szintjen legalabbis mennyi nem dokumentalt utasitas lehet, a Z180 miatt ... Ha csak bizonyos appokban van az meg mindig kevesbe gaz, mintha az OS sem indul el vele, bar tartok tole, hogy az utobbi az igaz (de tegyuk is szivunkre a kezunket: egy 8 bites gepen vetek nem kihasznalni a trukkoket pl az undoc opcode-okat .... undoc hmmmm undok, galad kis opcode-ok ezek, amugy meg ugysem vagyok vicces, csak probalkozom neha)
-
Kozben ujabb hir a "gany portolas" vilagabol: fifikas ez a CPC disk image formatum, rajottem h valoban "skewing" van, tehat egy track-en belul 2-es lepesekkel vannak tarolva a sectorok. Ezt korrigaltam, de most se mux nekem meg, file not found tovabbra is :(
Lassan annyira bonyolult mar ez a melo (es ahhoz nem eleg ertelmes, hogy ennyi ideig tartson ...) hogy talan jobb lenne a SYM.BIN file alapjan visszafejteni aztan csinalni egy normalis portot, driverekkel stb, nem csak igy a memoriat patch-elgetni :)
-
Tényleg, milyen grafikus módban fut ez?
Ez nem okoz kompatibilitási problémát? Mert ha jól olvastam minden Symbos program fut minden platformon.
-
Tényleg, milyen grafikus módban fut ez?
CPC-n 320x200 4 szín, vagy 640x200 2 szín. A PCW az 720x256 2 szín. MSX az 512x212, és van ott mindenféle mód, meg külön grafikus kártya, stb
-
Tényleg, milyen grafikus módban fut ez?
Ez nem okoz kompatibilitási problémát? Mert ha jól olvastam minden Symbos program fut minden platformon.
Zozo elobb remekul leirta. Amugy a lenyeg kb az, hogy az OS-nek a screen manager (vagy mi) nevu komponense kezeli a GUI-t az egyes sw-k vele kommunikalnak. Ergo, ha mas a kep szerkezete, attol az app nem valtozik, felteve, ha a screen manager system komponens kepes kezelni azt a video modot. Ez az elmeletem :) Az biztos, hogy vannak olyan esetek amikor ez _nem_ igaz, es ennek performancialis okai vannak: pl a video lejatszo app tul lassu lenne nyilvan ha a screen manageren at nyomulna. Gondolom ezert is van ez, hogy erre a speci esetre viszont van mar inkompatbilitas az egyes hw-k kozott: ha megnezed a symbos.de download szekciot, videok a kulonbozo platformokra _kulon_ vannak ...
Viszont amit Zozo ir: "360*288 lenne 4 szín módban" ... 288 pixel fuggoleges felbontas? Ez hogy? En ugy tudtam, hogy 256 folott nem igazan latszik mar semmi, meg ha elvileg vmi 312.5 (vagy mennyi) is idore szamitva amugy egy felkep "magassaga" ... Monjuk ok, lehetne interlaced, de az mar tulzas azert :)
-
* eleg memoria eseten "EXOS barat" uzemmod, ne irja felul a rendszert, foglaljon EXOS-tol memoriat a loader, es adja tovabb [kesobb a symbos mar nem hiv exos-t stb] a szamara hasznalhato szegmensszamokat, ennek elonye pl az igen sokoldalu EP memoriaszervezes (nem is kell folyamatosnak lennei fiziikailag, lehet "bad segment" is stb) amit SymbOS nem feltetlenul talalni ki jol betoleskor minden esetben
* SymbOS nyilvan "onallo" OS, es disk I/O-t nem EXDOS-ot at nyomna, de azert pl diskio alaocsony szintu rutinokat hasznalhatna
[nem kell mindenhez feltetlen hw driver], illetve "EXOS kompatibilis" (eleg memoria eseten!) SymbOS modban megtarthatna
a RAMdisk tartalmat, ami SymbOS alol is elerheto lenne, igy adott nemi adatcsere, foleg ha rendesen megy a kilepes symbOS-bol
stb
Hm. Mondjujk én alapból úgy képzeltem el a Symbos megvalósítását, hogy TEST_ROM-ban lenne, ahol RAM-teszt után rögtön egy OS választó menü lenne, és így indulna el vagy az EXOS, vagy a Symbos, vagyis Symbos indítása után már csak hideg reset-tel lehetne visszatérni az EXOS-hoz. És így semmi köze nem lenne a két oprendhez egymáshoz. Ha EXOS-ból indulna a Symbos, ez esetben az egy 5-ös fejlécű progi lenne? Persze az is egy érdekes dolog, főleg RAMDISK tartalom megőrzés esetében :-)
-
Én 5-ös fejléccel, vagy :SYMB :-)
-
Hm. Mondjujk én alapból úgy képzeltem el a Symbos megvalósítását, hogy TEST_ROM-ban lenne, ahol RAM-teszt után rögtön egy OS választó menü lenne, és így indulna el vagy az EXOS, vagy a Symbos, vagyis Symbos indítása után már csak hideg reset-tel lehetne visszatérni az EXOS-hoz. És így semmi köze nem lenne a két oprendhez egymáshoz. Ha EXOS-ból indulna a Symbos, ez esetben az egy 5-ös fejlécű progi lenne? Persze az is egy érdekes dolog, főleg RAMDISK tartalom megőrzés esetében :-)
A loader maga igen, ahogy CPC-n is betoltod. Aztan a loader mar maga intezi persze. Mivel EP-n nem celszeru ugye csak ugy random feltetelezni h adott RAM szegmens pont ott van (illetve akkor adatmegorzes celjabol is gaz lehet) celszeru, ha a loader normalis modon EXOS-al lefoglal akar minden szegmenst, es akkor tudja, miket hasznalhat, igy nem EXOS "compatible" lesz legalabbis (az mas kerdes, hogy alap 128K RAM-al ez nem igazan mukodne persze, de arra figyelmeztethet, hogy pl 128K RAM-nal kevesebbet tudott foglalni, vegyel RAM-ot, szabadits fel, vagy pedig valaszt a "takeover" uzemmodot, de akkor cold reset lesz a kilepeskor).
Amugy CPC-n is van talam SymbOS-bol ROM-os verzio is, szoval az sem rossz otlet (plusz ha ROM-bol tud futni a kod - nem csak atmasolja magat, nem tudom ... - legalabb reszben, akkor a RAM-al is lehetne takarekoskodni), akar pl lehetne az is hogy nem feltetlen indul el magatol, hanem symbos exos parancs hatasara. Igy elotte lehet pl ramdisk-et csinalni oda pakolni, es megfelelo symbos driverrel kesobb inditva latna o is.
-
Én 5-ös fejléccel, vagy :SYMB :-)
Zozo megelozott, mikozben en a kisregenyemet irtam :D
-
Néztem a CPC-set, nem tudja betölteni a hagyományos progikat, azt mondja ez nem végrehajtható alkalmazás.
Mennyivel szebb lenne, ha EP-n azt írná ki, hogy mondjuk "Ez egy hagyományos alkalmazás, futtatásához ki kell lépni a SymbOS rendszerből. Kívánja futtatni?"
-
Néztem a CPC-set, nem tudja betölteni a hagyományos progikat, azt mondja ez nem végrehajtható alkalmazás.
Mennyivel szebb lenne, ha EP-n azt írná ki, hogy mondjuk "Ez egy hagyományos alkalmazás, futtatásához ki kell lépni a SymbOS rendszerből. Kívánja futtatni?"
Na igen. Sot egyeb meredek otletet is lehetne felvetni, ha mar ugyis van pl eleg RAM-unk RAMbovitessel stb meg gyors+nagy hattertar (SD), bar nem tudom mukodne-e: EP-s alkalmazas futtatasakor egyszeruen "lehibarlna" magat a SymbOS, azaz vegulis mint egy emulatorban a snapshot, a memoria (pontosabban az altala hasznalt memoriaszegmensek) tartalmat kirakja vhova, stb stb. Aztan akar ki is lehet lepni ugy, hogy egy specialis loader-el visszatolteni az elmentett allapotot. Persze ez azert nehany ponton megse ilyen egyszeru, de talan nem lehetetlen. Voltakepp en is ezt csinaltam a CPC-rol portolasi kiserletemnel: a CPC-n levo memoriatartalom, Z80 registerek erteket felhasznalva betoltom (most meg modositott ...) EP emulatoron, es ott folytatodik pont, ahol CPC-n felbemaradt.
-
Látom, hogy itt leselkedik a szerző is :-) Lgb veled chatel privátban, vagy translateval próbálja követni az itteni ötletbörzést? :-)
-
Látom, hogy itt leselkedik a szerző is :-) Lgb veled chatel privátban, vagy translateval próbálja követni az itteni ötletbörzést? :-)
Meg jo, hogy ekezetek nelkul irok, nehezebb leforditani geppel :) Komolytalanra forditva a szot, semmi privat itt, viszont megkerdeztem mail-ben par napja, hogy tudok-e segiteni, az elomozditana-e az EP port ugyet. Meg vegulis ugye a "hulye portolasi" projectem is talan segit, hogy lassa, tenyleg szeretnenk a dolgot (marmint normalis portot is, nem feltetlen az en bohockodasomat).
-
Olvasgatom a doksikat, de még nem állt össze bennem a kép :oops: annyit értek, hogy a CPC vacakul tud memóriát lapozni, ezért az a alap, és lesz jó bonyolult minden :-)
-
Olvasgatom a doksikat, de még nem állt össze bennem a kép :oops: annyit értek, hogy a CPC vacakul tud memóriát lapozni, ezért az a alap, és lesz jó bonyolult minden :-)
Kb latod a lenyeget. Ha tobb gepen akarod ugyanazt, sajnos az kell amit minden gep tud :( Szerintem SymbOS-t is lehetne kicsit maskepp portolni EP-re, de az pl kihatassal lenne az applikaciok memoriakiosztasara stb, igy azonnal elveszne az elony, hogy a legtobb SymbOS app binaris formaban futtathato barmelyik gepen azonnal, amire van SymbOS. Mindennek ara van ... Mondjuk a CPC memoriakezelese kapcsan en is teptem a hajamat, azota se ertem, miert nem lehetett mas gepeken is szep megoldas, mint az EP, kulonosen Commodore-os korokben idegesito dolgokat csinalnak, ahelyett hogy vmi ilyesmi holt egyszeru ugyanakkor hatekony megoldast csinalnanak, mindig elbonyoiitjak ... Vagy csak en nem ertem a motivaciot :) Amugy - lehet mar mondtam - Commodore DTV "joystick gepben" csinalta meg jol a csaj (marmint Jeri Ellsworth - ha jol irom a nevet igy fejbol), kb ugyanaz mint EP-n, csak ott a 4Mbyte kette van osztva, 2MByte SDRAM-ra (amit burst modban tud kezelni, azaz 32 bit prefetch stb), es 2Mbyte flash.
-
Ha jól nézem MSX2-nél is ugyanolyan 4 portos lapozás van mint EP-n. Kérdés, hogy az MSX verziójú SymbOS-ben hogyan van a lapozás megoldva? A belsőleg használt CPC-s 0-15 bankok, hogyan vannak lefordítva?
Mert ugye EP esetén kéne egy táblázat, amibe minden bankhoz le van tárolva 4 szegmensszám. Ez ugye alapból 16x4=64 bájt. Ez vajon elfér a rendszerben?
Meg nálunk nem kéne megállni 16 banknál, az csak nevetséges 1MB :-)
Meg jön a 64-el nem osztható szabad memória kérdése, azzal nem is tud mit kezdeni? Mondjuk úgy elkönyvelni, hogy a nem létező része foglalt és kész.
-
Ha jól nézem MSX2-nél is ugyanolyan 4 portos lapozás van mint EP-n. Kérdés, hogy az MSX verziójú SymbOS-ben hogyan van a lapozás megoldva? A belsőleg használt CPC-s 0-15 bankok, hogyan vannak lefordítva?
Az I regisztert fenntartja a SymbOS arra, hogy abban van az aktualis mem config reg erteke, azt irogatja aztan ki meg modositja, hogy ne kelljen mindig memoriabol felszedni. Vagy vmi hasonlo :)
Mert ugye EP esetén kéne egy táblázat, amibe minden bankhoz le van tárolva 4 szegmensszám. Ez ugye alapból 16x4=64 bájt. Ez vajon elfér a rendszerben?
Meg nálunk nem kéne megállni 16 banknál, az csak nevetséges 1MB :-)
Meg jön a 64-el nem osztható szabad memória kérdése, azzal nem is tud mit kezdeni? Mondjuk úgy elkönyvelni, hogy a nem létező része foglalt és kész.
Jo, hat ezt forras hianyaban nehez megmondani, SymbOS hogy mux belulrol. Szerintem, hogy maskepp tarolja a "memoria configot" az nem gond, mivel app-nak azzal sok dolga nincs (bar az nekem sem tiszta, hogy egy app hasznalhat-e tobb memoriat, amihez mar _neki_ kene lapoznia, vagy ez nem megengedett SymbOS-ben?), a kernel portolasnal ez eldol kb. CPC-n meg komplex is (neztem disasm-ban ...) van ahol egy oldalon at azt szamolgatja, hogy lesz "valodi" cimbol CPC mem cfg ertek :) Ez Ep-n azert egyszerubb. Meg lehet, eleg letarolni vmi kernel process strukturaban az EP segmens szamokat, es akkor szamolni sem kell tobbe, hanem azokat out-ozza azonnal, oszt' csokolom.
Amit irsz megoldas (tablazat) az kb nalam jonne be (tehat a "gany" portolasnal!), ha szep forras bizrtokaban levo portolast csinal, akkor eleve nem is kell CPC-EP memcfg "forditast" csinalni hanem nativan EP-s lehet. Az, hogy a symbOS alkalmazasok futnak minden platformon nem jelenti azt, hogy a kernelt ne lehessen valtoztatni akar jobban is, max az van ugye, hogy azt meg kell tartani, hogy az app-ok hordozhatoak legyenek. Felteve, hogy az app-ok szamara tilos kozvetlenul lapozgatni (ami gondolom igaz, kulonben most sem lennenek hordozhatoak az app-ok!), akkor meg a kernelben hogy van megoldva ez, az talan kevesbe lenyeges.
-
Felmerult itt bennem is egy kerdes: tudom, hogy a video RAM elerese a CPU-nak lassabb, mert osztoznia kell a Nick-el (jobban mondva a VRAM-ba meno memoira muveletek a Nick-en at mennek, es Nick szegeny Z80 orajelet bizeralja, hogy ne zavarjon be neki), viszont kifejezheto-e kb szazalekben, hogy mennyivel lassabb lesz mint a nem VRAM elerese, mondjuk egy alap 4Mhz-en futo Z80 szamara ez?
-
viszont kifejezheto-e kb szazalekben, hogy mennyivel lassabb lesz mint a nem VRAM elerese, mondjuk egy alap 4Mhz-en futo Z80 szamara ez?
Na ezt nehéz lenne kifejezni :-)
Itt írkáltam az elméletről. (http://enterpriseforever.com/hardver/nick/msg32723/#msg32723)
A dolog erősen függ attól, hogy éppen melyik Nick fázisban próbálkozik a Z80, ha jól számol a legrosszabb esetben 772,6... nsot kell várnia (ez Z80 sebbeségétől független).
Normál memória elérésnél 2.5 órajel az MREQ (http://www.piclist.com/techref/mem/dram/slide4.html), az 625ns, utasítás olvasás esetén 1.5 órajel, ami 375ns. Vagyis a legrosszabb esetben, utasítás esetén 3x, sima elérés esetén is több mint 2x annyi ideig tart. De persze ha pont jó pillanatban érkezik a Z80, akkor nincs várakozás.
Bonyolultabb kódra mutattam ott a Nickes témában példát, hogy a 4Mhz-es Z80 sok hozzáférési ablakról lecsúszik, egyre nagyobb turbóval egyre több lehetőséget tud elkapni.
-
Na ezt nehéz lenne kifejezni :-)
Tudom, inkabb csak olyan "erzes" kategoriaban gondolkoztam, bar tudom, hogy fugg konkretan attol, hogy pl ha Z80 kod van ott, mlyen utasitasok stb. Szoval csak ugy atlagosan nagysagrendileg stb :)
-
Kipróbáltam az MSX verziót emulátorban (az még is csak közelebb áll az EP-hez, WD, 720-as DOS lemezek), és nekem úgy tűnik, hogy amikor dolgozik a floppy, akkor megáll az élet.
-
A CPC verziót megnézve is ez történik, amikor tölt, akkor épp nem mozog a kurzor, én még mindig leragadtam az EXOS-osításnál, az nem megoldható, hogyha megkapod a betöltendő fájl nevét, azt EXOS-szak megnyitod, és utána 256/512 byteonként beolvasod, minden sikeres olvasás után ugyanúgy visszaadva a vezérlést a SYMBOSnak, mint ahogy a CPC floppyolvasásnál van, annyi, hogy minden EXOS hívásnál mindent állítgatni kell oda-vissza SYMBOS és EXOS között, de szerintem így is gyorsabb lenne a töltés EP-n, mint CPC-n.
Úgy látom az összes file-t könnyedén ki lehet nyerni az image-ekből.
-
Kipróbáltam az MSX verziót emulátorban (az még is csak közelebb áll az EP-hez, WD, 720-as DOS lemezek), és nekem úgy tűnik, hogy amikor dolgozik a floppy, akkor megáll az élet.
Nyilvan, kikerulni teljesen nem tudod, max ugy lehetne, ha DMA-val menne, meg ilyesmi. Amivel disasm soran talalkoztam az max az, hogy seek track-nal csinalja azt a jatekot, de ezt valoszinu ezek szerint hogy sector read-kor mar nem tudja eljatszani. Mondjuk imho ez nem olyan meglepo azert.
-
A CPC verziót megnézve is ez történik, amikor tölt, akkor épp nem mozog a kurzor, én még mindig leragadtam az EXOS-osításnál, az nem megoldható, hogyha megkapod a betöltendő fájl nevét, azt EXOS-szak megnyitod, és utána 256/512 byteonként beolvasod, minden sikeres olvasás után ugyanúgy visszaadva a vezérlést a SYMBOSnak, mint ahogy a CPC floppyolvasásnál van, annyi, hogy minden EXOS hívásnál mindent állítgatni kell oda-vissza SYMBOS és EXOS között, de szerintem így is gyorsabb lenne a töltés EP-n, mint CPC-n.
Úgy látom az összes file-t könnyedén ki lehet nyerni az image-ekből.
Nem tudom, hogy lassabb lenne-e a SymbOS jelentosen ... Egyreszt, ha fejet mozgatni kell (seek) akkor - ahogy irtam - van nemi trukk legalabb arra (igaz WD-nel nem tudom megoldotta-e!), hogy amig nincs kesz fut mas process, igy lehet lecsuszik arrol, hogy mar kesz, es kicsit kesobb jon ra, cserebe nem all meg addig az elet teljesen. De ez _csak_ a seek ugy tunik. Ha jol ertem. Maga a sector olasas: abban nem vagyok biztos, mennyire lassabb-gyorsabb, foleg ha tobb sector kell. Disasm alapjan a CPC fdc verzio ugy tunik ugy mux, hogy van egy "entitas" ami un logikai szektor szam (nincs fej/track/stb) alapjan ir X db sectort egymas utan vagy olvas. Nagyjabaol aztan az osszes szovevenyes al-rutin ebbol a ket rutinobol hivodik kozvetve vagy kozvetlenul, hogy atalakitja fizikai lemez fej/sav/szektor szamma, kiadja a konkret fdc parancsokat, hibakodot ad vissza, stb. Ezt probaltam meg lecserelni en ugye, hogy legalabb egy image file-bol dolgozzon valodi hw helyett, ami valamiert nekem nem ment eddig, de talan kiderul miert (amugy megkerdeztem az irot hehe, azt mondta, hogy valoszinu azt nem veszem figyelembe, hogy CPC-n is van FAT es CP/M disk, es mas sector offset-teket hasznalnak amit a kod megprobal detektalni elobb, hogy kitalalja milyen tipusu disk-et kell kezelni - hmmm).
Most ugye modern szohasznalattal elve a "block layer"-rol van szo, ez kb hasonlo feluletes peldaval elve, mint EXDOS-nal a diskio. Az megint mas kerdes, hogy mi van, ha kidobjuk a SymbOS-bol a fentieket is, sot azt is, hogy o kezeljen filerendszereket stb, es _mindenert_ az EXOS-t hivogassa. Az biztos, hogy az bonyolultabb lenne disasm alapjan megtalalni, az ilyen fdc fuggo hw bizeralast meg mindig egyszerubb IN/OUT alapjan megtalalni, de ugye a "filerendszer" kezeles eleg absztrakt kod lehet. Valoszinu, hogy nem lenne teljesen lehetetlen megoldani. Amde ez felvet egy masik kerdest: alap EP-vel azonnal nem menne a cucc :( Ui 128K RAM az kb eppen eleg a SymbOS-nek barmi mas hardware-en is. Viszont az EXOS-ra epulo verzio eseten meg kene tartani a rendszerszegmenst legalabb. Bar az is igaz, hogy a SymbOS kod merete viszont csokkenne, mivel ki lehetne gyomlalni belole kb az osszes low level fdc I/O es filerendszer kezelest ugyanugy, ha az EXOS-on at menne, de tartok tole, hogy nem lenne annyi megtakaritas, hogy igy 128K-ba meg EXOS hasznalata mellett is belefer.
Amugy igazad van, cool lenne valahogy az EXOS hasznalata, mar csak azert is, mert megse kene kulon SymbOS driver SD kartyanak, RAM disknek (ha eleg RAM van ...), WD-s EXDOS-nak, esetleg Zozo fele IDE-nek ... Ja, es raadasul a CPC SymbOS verzio (disasm alapjan ahogy nezem, kozben neztem CPC wiki-t hogy milyen port micsoda) elegge "monolitikus" azaz eleve benne van vmi IDE-s cucc abban is (CPC wiki mondta par portra amit lattam, nem tudom mi az pontosan), legalabbis latszik, hogy csomo hasonlo rutin ketszer van a memoriaban is, gondolom NEC fdc-re, es az emlitett IDE-s valamire legalabb. Erdekes modon MSX-es verzioban viszont betoltheto driver-ek vannak ugymond, nem biztos, hogy ertem, mi a kulonbseg es miert van ez a kulonbseg a CPC es az MSX verzio kozott ....
Es itt nem csak arrol van szo, hogy a SymbOS vagy az EXDOS lenne-e a gyorsabb, hanem arrol is, hogy EXDOS mar kesz van, es rajta at minden elerheto, mivel EP-n softrware-ek ugye altalaban EXOS/EXDOS-on at vegeznek file muveleteket, ergo kb ami hattertar megoldas letezik EP-re, arra mar kesz az sw, es nem kene SymbOS ala ujraimplementalni drivert. Mondjuk egyetlen hatrany az a FAT12 amit EXDOS-nal latok, SymbOS talan FAT32-ot (???) is tamogat, meg persze FAT16-ot (illetve CPC-n pl az AMSDOS CP/M szeru formatumat is, de EP eseten ez mondjuk mind1). Node, semmi nem lehet tokeletes.
Mondjuk egy dolog utott szoget a fejembe, de most jutott csak szembe igy nem neztem meg: van ugye az a videolejatszo app. Mennyire "erezheto" az akadas rajta ami miatt olvasgatnia kell a file-t? Ezek utan kivancsi vagyok :D Lehet, meg is nezem mindjart.
-
Ami furcsaságot még találtam: nézegettem az MSX floppy drivereket, és olyan funkció is van benne, hogy logikai szektorszám konvertálása fizikaira. Na de ezt hogyan tudná megtenni, ha a lemez felépítését a fájlrendszer kezelő ismerheti, nem pedig az alacsony szintű lemez IO?
-
Ami furcsaságot még találtam: nézegettem az MSX floppy drivereket, és olyan funkció is van benne, hogy logikai szektorszám konvertálása fizikaira. Na de ezt hogyan tudná megtenni, ha a lemez felépítését a fájlrendszer kezelő ismerheti, nem pedig az alacsony szintű lemez IO?
Nem tudom pontosan mire gondolsz, de amivel en talalkoztam "logikai" szektor szam az valojaban fizikai :) Marmint ugy, hogy egyetlen szammal lehessen leirni track/head/sector helyett. Ennek atvaltasa legalabbis floppy-nal :) az nem igazan fugg a filerendszer tipusatol ugye. Ott vannak amugy a sector offset dolgok stb ami szinten alacsony szintu, es pl az a mar emitett skewing tartozik ide, meg olyasmi - ha jol ertem -, hogy az FDC readid paranccsal is lathato sector-ID-ek valoban 0xC0-vel tobb mint a szektor szam, ezzel detektalhato (?) hogy CP/M disk-rol van szo (raadasul AMSDOS eseten ketto ilyen is van 0x40 es 0xC0, gondolom data/system disk miatt - sajnos en nem feltetlen latom at a CPC-s vilagos, nem biztos, hogy ertem miert kell ez). DOS stilusu disk-en a sector offset allitolag nulla. Szoval ilyen es ehhez hasonlo dolgokat is konvertalgat vmi tablazat alapjan amit a unit aktivalo rutin irogat mint "detektalas" (bar lehet MSX-en ez pont nem focizik mert ott nincs talan CP/M disk formatum, ami CPC-nel kell mert ott lehet az, meg FATxy is!).
Amugy ha symbos.de-rol az MSX mass storage driver-t letoltod (gondolom azt nezed most is?) akkor pl lathato hogy ott az FDCOUT es FDCINP, ezek ami logikai szektorszam alapjan irnak/olvasnak. Az FDCACT az, ami inicializalja a disk-et, es pl megvizsgalja, hogy a sector offset mennyi, hany track van, sector/track stb, es ezt lejegyzi aztan: ez alapjan tortenik az FDCOUT es FDCINP-ben aztan a "logikai szektorszam" konvrtalasa a fizikaira. Es itt filerendszerrol meg szo sincs semmi! Amugy Amit pl latsz a FDC philips.asm-ban peldaul, ott latszik is, hogy fo rutin van kb 3 (amit mas dolgok hivnak), a tobbi mind olyasmi, amit valoszinuleg ezek a rutinok hivnak. A CPC-s memoriakep ugye kicsit talanyos volt, mivel nincs forraskod a CPC verziohoz (tudtommal ...) ezert azt is probaltam mar a vegen, hogy megnezem amihez van (pl MSX driverek) mert ott van legalabb comment hogy mi micsoda, es megprobalok hasonlot keresni a CPC disasm-ban is :) Ez nem olyan egyszeru, amde ha elotte az ember mar kb elnevezte maganak a rutinokat meg kb tudja 1-2-rol micsoda, akkor majdnem ranezesre is latszik, hogy felismertem, hogy hivhatta a szerzo a kerdeses rutinokat valszeg a CPC verzioban is, es mire valo 1-2 dolog benne amire eddig nem jottem ra. Szoval szep kis kirakosjatek :) Persze azt nem mondom, hogy teljesen ertem en ezt meg ...
-
Nem tudom pontosan mire gondolsz, de amivel en talalkoztam "logikai" szektor szam az valojaban fizikai :) Marmint ugy, hogy egyetlen szammal lehessen leirni track/head/sector helyett.
Ezt hívjuk LBA-nak, azaz Logical :-) ezt használja az EXDOS is.
Ennek atvaltasa legalabbis floppy-nal :) az nem igazan fugg a filerendszer tipusatol ugye.
Éppenséggel a FAT Boot szektorban van leírva, ami szerintem a fájlrendszerhez tartozik.
Az FDCACT az, ami inicializalja a disk-et, es pl megvizsgalja, hogy a sector offset mennyi, hany track van, sector/track stb, es ezt lejegyzi aztan: ez alapjan tortenik az FDCOUT es FDCINP-ben aztan a "logikai szektorszam" konvrtalasa a fizikaira.
Ok, így már működhet. Mondjuk az a rutin igen hiányosnak tűnik nekem, főleg az EXDOS után :-) Hiba és kompatibilitás ellenőrzést nem igen látok...
-
Ezt hívjuk LBA-nak, azaz Logical :-) ezt használja az EXDOS is.
Oke, LBA fogalmat en csak hdd-nel szoktam hasznalni (CHS/LBA), de igazad van, es egyszerubb + korrektebb lett volna igy magyarazni :)
Ok, így már működhet. Mondjuk az a rutin igen hiányosnak tűnik nekem, főleg az EXDOS után :-) Hiba és kompatibilitás ellenőrzést nem igen látok...
Jo hat, EXDOS-t valoszinu azert alaposabban irtak meg megis, es az egesz EP project nem hobby project volt, a SymbOS meg ugye azert az.
Btw, foleg ha lesz EXDOS-ban 16 bites FAT support, akkor tenyleg mar komolyan erdemes elgondolkodni olyan SymbOS verzion, ami EXOS-t hasznal a file muveletekre, nem is csak disk block I/O szinten, hanem ugymond FS szinten is. Max akkor tenyleg az lesz, hogy nem igazan fog SymbOS futni 128K rammal (bar kerdeses, hogy a rendszerszegmens mennyi helyet foglal "atlag" config eseten, most csak igy JSep-vel azt mondja az IS-BASIC hogy kb 128K ram eseten ~18K foglalt, tehat kicsit tobb mint egy szegmens sajnos. Igaz, kell a videoram-nak is hely pl, stb (illetve nem tudom, hogy IS-BASIC maga is foglal vmennyi RAM-ot es a kijelzes nem feltetlen tukrozi, hogy mennyi szabad RAM lenne a rendszerben, ha csak az a cel, hogy EXOS/EXDOS mukodokepes legyen).
-
nem igazan fog SymbOS futni 128K rammal
Ez szerintem nem nagy gond, a többi gépnél is azt írja, hogy ha használni is akard tegyél bele RAM-ot :-)
-
Amugy az is erdekes felvetes, hogy futhatna-e SymbOS ROM-bol. A disasm alapjan kevesbe, mivel ossze-vissza van kod/adat egymas hegyen/hatan sajnos. Pedig abbol a szempontbol erdekes lenne, hogy a RAM hasznalat jelentosen csokkene, ha a kod kozvetlenul ROM-bol is futtathato lenne, EP-n belapozni ROM-ot meg RAM-ot meg ugye uaz, csak max mas szegmensszam, elteroen nehany mas geptol ...
-
Oppa, ugy latom hasznos volt "zaklatni" a szerzot nekem maganban is, mert latom az angol SymbOS topic-ban maris domboritott valamit :) Mondjuk irtam neki jo par tobb oldalas mailt :) mindenfele otletekrol amit itt mi felvetettunk, meg EP-rol ugy altalaban stb. Szerintem egyszerubb volt elkezdenie, maskepp nem tud megszabadulni tolem :) Mondjuk WD-rol kerdezett dolgokat, amire azt mondtam, hogy talan tudok valaszolni ra, de Zozosoft jobban ert a temahoz.
Igy belegondolva, lehet neha jo, hogy "faraszto" vagyok, csak hogy magamat is fenyezzem: amikor Commodore LCD nevu geprol nulla info volt (emulator meg persze semmi, hiszen hw info se volt) nem hagytam magam levakarni, es minden embert zaklattam facebook-on is, aki velhetoen ex Commodore mernok volt akkoriban. Meg is lett az eredmenye :)
-
Nagyon kíváncsi leszek erre a SymbOS-ra, de van egy kis félelmem is. Végül is ez nem EP... Vagyis úgy érzem, hogy valahogy elveszik az EP benne.
Nem hiszem hogy bárki is írna rá valami EP-sebb programot... persze ne legyen igazam.
-
Ezen csodalkozni nem kell, hogy kevesbe EP, pont az a celja, hogy ne legyen az, hiszen multiplatform, ami kicsit pont azt is jelenti, amitol "felsz". Amugy nem hinnem, hogy ez baj, senkinek nem kotelezo SymbOS-t hasznalnia mindig, az EP felhasznalasnak mondjat mindenkeppen szelesiti, aki csak SymbOS-ezni akar es eddig nem EP-zett, az megteheti pl MSX-en vagy CPC-n is, nem hinnem, hogy ettol az EP maga kart szenvedne, sot pont forditva. Pont ide kapcsolodik az is, amikor elmelkedtunk "kulso" video hw-rol, meg Nick2-rol, stb "cool, de ki/mi fogja ezt tamogatni?". hat pl a SymbOS :-P Mivel az appok hordozhatoak, ki tudja hasznalni vegulis barmelyik az ilyesmit az. Azaz katalizalhatja is az EP hw-k fejleszteset, ami - kevesbe elvetemult peldakra nezve is - az "EP-sebb EP" felhasznalas mellett is esetleg jol johet elobb-utobb.
-
Sajnos a Nick csoda képességei pont nem passzolnak egy ablakozó rendszerhez :-(
-
Sajnos a Nick csoda képességei pont nem passzolnak egy ablakozó rendszerhez :-(
Azért az a vertical scroll, meg az amiga like multi screen nem lesz káros ...
-
Mivel a mas paletta miatt a taskbar amugy is kulon LPB, elvileg az is lehetne, hogy veritkalisan scroll a felulet tobbi reszere remekul megy, mig a taskbar marad szepen a helyen mindig. Nekem ez tetszene, bar lehet nem mindenki ert velem egyet.
Masreszt, lehetne horizontalis scroll is, az sem gond, max ugye kell hozza egy boszme nagy LPT sajnos akkor, illetve nem pixel finomsagu lenne a scroll, de szerintem ez nem olyan nagy katasztrofa azert itt. Itt is igaz, hogy a taskbar maradhatna a helyen.
Voltakeppen 128K eleg karcsu SymbOS-nek amugy is, ha meg van eleg RAM akkor talan az sem gond, ha nagy az LPT-nk a horizontalis scroll miatt, es hogy a maradek VRAM-ot ki is hasznaljuk rendesen azert, hogy legyen szeeeep "szeles'" scroll. Ha meg akarunk EXOS megorzest, akkor gond a system segment, de azt addig el is lehetne menteni mashova, igaz, igy a reset gomb eseten gondban vagyunk, ha nem "szabalyosan" symbos-bol leptunk ki, ami pl alkalmasint vissza is pakolna az eredeti helyere elobb.
Amugy en itt mar nem ereznem csalasnak azt sem, hogy csinaljunk kulso "videokartyat" EP-hez. Ok, egyfelol ott az Endi fele "ez mar nem is EP" aggodalom, ami nemileg jogos (de a SymbOS eleve nem EP ... vagyhat nem csak ...), masreszt, az MSX-es vakitasoknal a videokon szinten kulso GFX9000 cucc van, tehat ilyen elven EP-nek is lehetne kulso, hogy ugyanazt tudja a SymbOS EP-n, ami MSX-en is megy, es akkor megnyugszik az ember lelkivilaga talan :)
-
Sajnos a Nick csoda képességei pont nem passzolnak egy ablakozó rendszerhez :-(
Osztom Z80system véleményét, egy jó háttérkép váltott soros LPT-vel, akár attributum üzemmódban, majd egy 4 színű LPT rész az ablakos felületre egymást váltva maszkolva sztem jól nézhet ki.
-
Osztom Z80system véleményét, egy jó háttérkép váltott soros LPT-vel, akár attributum üzemmódban, majd egy 4 színű LPT rész az ablakos felületre egymást váltva maszkolva sztem jól nézhet ki.
Ekkor nem vibrálna nagyon a kép? Jó lenne ezt hosszú távon CRT monitoron nézni?
-
Ekkor nem vibrálna nagyon a kép? Jó lenne ezt hosszú távon CRT monitoron nézni?
De, de ha zavar már, akkor vissza lehet váltani nem váltott LPT módba :D
-
Ekkor nem vibrálna nagyon a kép? Jó lenne ezt hosszú távon CRT monitoron nézni?
De igen, nagyon vibralna, és hosszú távon arra érzékenyeknek vélhetőlen kifolyna a szeme ... ez egy kiegészítő fícsőr lenne, ízlés és tűrés kérdése a dolog ...
Fentebbi dolgok viszont ettől függetlenek. A szkrollozós virtuális és a huzigálós multi window ... mindkettó NICK fícsőr, és nem vibrálnak.
-
Viszont szerintem egy modern TFT monitoron jó lehetne, az interlace Iview képek is nagyon jók így.
-
Viszont szerintem egy modern TFT monitoron jó lehetne, az interlace Iview képek is nagyon jók így.
Igen, igaz még élőben TFT-n nem láttam, de gondolom az emulátoron megtekintetthez hasonló, szinte villanásmentes.
-
Viszont szerintem egy modern TFT monitoron jó lehetne, az interlace Iview képek is nagyon jók így.
Ezt már az angol oldalon is írtam,
ez egy egész más dolog szerintem.
Az interlace a TFT -n a deinterlace funkció miatt jó, amiatt hogy a két félképet összerakja neked egy darab duplázott függőleges felbontású képpé.
Ha ezt itt megteszi, akkor egy interleave -elt képet kapunk, ahol minden első sor a háttér, minden második sor a SymbOS desktop ... sztm ez béna lenne ...
Ha meg nem teszi, akkor TFT vagy sem, villogni fog. Hiszen 2 képet felvátva villogtatsz. Nem tud rezzenésmentes lenni.
-
Arról nem is beszélve, hogy mint ott is megállapítottuk, az igazán szép IVIEW képek attributum módban vannak,
attributum módban pedig nem tudnánk pixelhelyes maszkot rajzolni a képre,
és a mi kedvünkért sztm. nem lesz a SymbOS -ben 8 pixeles vízszintes window snap ... :)
(Mellesleg ez az én ízlésemnek megint akkora lórúgás lenne, hogy nem is nagyon érdekelne a dolog onnantól, hogy a vibrálás mellé még egy 8 pixeles vízszintes window snap is kéne ... de persze az ízlés az csak ízlés.)
Ha meg elhagynánk a maszkot, akkor a háttér belemosódna additívan a SymbOS ablakokba ... nyilván az is 0 eredmény ... az én ízlésemnek ...
-
Amugy nem vagyok rola meggyozodve (ellenorizni kene!), hogy SymbOS nem kenyszeriti ki a 8 pixeles hatarokat pl ablak poziciora. Ez csak egy tipp, de epp gondolkodtam, hogy a fenebe lehet megoldani, hogy egy felig 4db ablakkal takart masik ablakban aktivan van vmi, es csak az frissuljon, ami nincs kitakarva persze. Arra jutottam, hogy a legegyszerubb megoldas, ha pl 8*8-as (vagy mas, mind1, de a 8 logikusnak tunik legalabb vizszintesen) egysegenkent van a memoriaban egy "terkep" ami azt mutatja, hogy az adott "pixel blokk" melyik ID-el rendelkezo ablakhoz tartozik. Igy a rajzolo rutinoknak konny dolga van viszonylag. Persze elvileg akar pixelnekent is lehetne terkep, csak az durvan nagy lenne, nagyobb mint a teljes grafikus videoRAM merete 4 colour felobontasban :) Marmint, ha 1 byte van a window ID-re a SymbOS-en belul. Mas megoldast nem tudok elkepzelni hirtelen viszont, hogy hatekonyan hogy van lekezelve a felig takart ablak esete. Foleg, ha tenyleg sok ablak itt-ott takarja, akkor azert nem piskota kitalalni, hol latszik es hol nem eppen ... Szoval ezert tippelek a "terkep" megoldasra. Persze lehet, hogy tevedek. Ha pedig uj ablak jelenik meg, arrebb viszel egyet, bezart egyet stb, akkor a SymbOS-nek persze ujra kell generalnia az adott "terkep" vonatkozo reszet.
Ha tenyleg igy van, es "blokkosan", akkor lehet amugy is adott mar eleve, hogy ablak nem lehet "akarhol" hanem pl 8 pixelkent vagy tudomisen, ami hasznos lehet a fentebb vazolt technikakhoz. Vagy az is lehet, hogy ez a "blokossag" merteke allithato a SymbOS-ben (nem is usernek, hanem forraskod szinten marmint) es osszefuggesbe hozhato az attribute mode kivanalmaival.
Meg kene kerdezni a szerzot, hogy mukodi ez valojaban :)
-
sztem vízszintesen 4-es blok van, amúgy Attributum módban is meg lehet csinálni a pixel helyes kitakarást, csak az attributumok színét is állítani kell a kitakarós részen.
-
sztem vízszintesen 4-es blok van, amúgy Attributum módban is meg lehet csinálni a pixel helyes kitakarást, csak az attributumok színét is állítani kell a kitakarós részen.
Nem, attributumban sztm. 8 pixeles a bájt.
Az attributum arrol szól hogy 8 pixelen belül csak két szined lehet. Ha van egy képed ami ezt használja (a bájton belül a 2 színt) nem tudsz beleraki egy harmadikat (mask szín).
Evvan. Különböző megkötések kellenek. 8 pixeles ablak snap, vagy feleslegesen lemaszkolt részek, vagy csak megfelelő kombinációban alkalmazott 4/16 színüzemmódú IVIEW képek, amik azért nem annyira jók mint az attributumosak ... az élet kemény ...
-
(ellenorizni kene!)
Mi sem egyszerűbb ... ráklikkolsz a linkre ami az angol SymbOS topikban van, és java emulátorban látod a SymbOS működését ...
Meglepne ha nem bökte volna ki a szemem, hogy 8 pixel snap -osak az ablakok ... :)
-
Íme:
http://symbos.cpc-live.com/
-
Ezzel pontot is raktunk a kérdés végére:
-
Nem, attributumban sztm. 8 pixeles a bájt.
Az igaz, de meg lehet oldani a pixel helyes kimaszkolást is, az egyik színt le kell cserélni a háttérszínre a kérdéses területen, a másik eredeti szín marad, és azzal megoldani akár 1 pixel szélesen a kimaszkolást, igaz, abban az attributumban lesz egy kis elváltozás a képben, de az nem annyira zavaró, mint a 8 pixeles kimaszkolásból maradó űr.
-
de az nem annyira zavaró, mint a 8 pixeles kimaszkolásból maradó űr.
Ízlés kérdése. Sztm kifejezetten ronda lenne, ahogy pld. 7 pixel szélesen mindenféle szálkák meg zajok lennének az ablak mellett.
-
Az igaz, de meg lehet oldani a pixel helyes kimaszkolást is, az egyik színt le kell cserélni a háttérszínre a kérdéses területen, a másik eredeti szín marad, és azzal megoldani akár 1 pixel szélesen a kimaszkolást, igaz, abban az attributumban lesz egy kis elváltozás a képben, de az nem annyira zavaró, mint a 8 pixeles kimaszkolásból maradó űr.
Vagy rakenyszeriteni symbos-t hogy hatarra tegye az abalakokat ennel a mukodesnel. Ok, nem olyan szep, de elfogadhato. Szerintem.
-
Ízlés kérdése. Sztm kifejezetten ronda lenne, ahogy pld. 7 pixel szélesen mindenféle szálkák meg zajok lennének az ablak mellett.
Ezen is lehet finomítani, mindig a legkevesebb pixelt tartalmazó színt lecserélni, így a legkisebb a zavar.
-
Vagy rakenyszeriteni symbos-t hogy hatarra tegye az abalakokat ennel a mukodesnel. Ok, nem olyan szep, de elfogadhato. Szerintem.
Szerintem is :)
-
Énnekem ezek huszadmegoldások csak ... még minderre rá egy 25 Hz -es flash ... semmire nem jó az egész ...
-
Szerintem is kuldo video kene. EP-n ez meg "szep" is, mert ott vanak az EXTCOL bemenetek, igy egy kepen belul is lehetne olyan tartalom amit a Nick allit elo, es olyan is, amit a kulso cucc. Ok, persze dumalni konnyu, de meg is kene csinalni ...
-
Én a web emuban futó verzióban nem tudom irányítani az egérkurzort.
Az egeret használó demók mentek, csak ez nem megy. Vagy még nincs implementálva a Symbos-ba a EP egér?
Billentyűzetről két gombbal tudok balra és fel menni. :)
-
Én a web emuban futó verzióban nem tudom irányítani az egérkurzort.
Az egeret használó demók mentek, csak ez nem megy. Vagy még nincs implementálva a Symbos-ba a EP egér?
Billentyűzetről két gombbal tudok balra és fel menni. :)
Sajna SymbOS-ben nincs meg eger support :( En is azt varom :) Amugy elvileg ALT+kurzorgombok, csak eppen az ALT-ot meg nem kezelem az JSep-ben :( Helyette megprobalhatod (a demo.new-s verziot mindenkeppen!) az F9-et nyomni ALT helyett, es persze kozben a kurzor nyilakat. Amugy nekem a disk access gyanus: anno az JSep-nel az volt a celom, hogy legyen vmi minimalis implementacio amivel EXDOS elmegy. Kozel sem biztos, hogy SymbOS sajat disk rutinjaival is fog menni ...
-
Hogy a magyar fórumtársak se maradjanak le:
A ma reggeli teszt verzió. (http://enterpriseforever.com/programming/symbos-106/?action=dlattach;attach=11199)
Ez már fut sok memóriával.
Irányítás egyelőre "segédüzemmódban", míg nincs egér:
ALT+belső joy a mozgás
ALT+Space bal gomb
ALT+Ins jobb gomb
Egyelőre a floppy driverrel küzdés folyik, így valódi gépen tesztelve sok-sok retryzés folyik, valamint töltési hiba is lehet.
Ep128emuban működik, mivel az nem emulálja a WD időzítéseit.
-
És bug miatt fontos: legyen a B: meghajtóban is lemez :oops:
-
nekem a mai napig fogalmam sincs hogy kell disk image-t használni, és nem is akarom tudni :)
snapshot nincs? :)
-
nekem a mai napig fogalmam sincs hogy kell disk image-t használni, és nem is akarom tudni :)
Ez a te bajod :evil:
snapshot nincs? :)
Nincs, és nem is lesz. Snapshotba a lemezkép nincs elmentve, egy lemezes operációs rendszernél meg sokra nem mész lemezkép nélkül...
-
Ha majd kezeli a Ramdisket akkor lehet majd snapshotolni.
-
Hogy a magyar fórumtársak se maradjanak le:
A ma reggeli teszt verzió. (http://enterpriseforever.com/programming/symbos-106/?action=dlattach;attach=11199)
Ez már fut sok memóriával.
Irányítás egyelőre "segédüzemmódban", míg nincs egér:
ALT+belső joy a mozgás
ALT+Space bal gomb
ALT+Ins jobb gomb
Egyelőre a floppy driverrel küzdés folyik, így valódi gépen tesztelve sok-sok retryzés folyik, valamint töltési hiba is lehet.
Ep128emuban működik, mivel az nem emulálja a WD időzítéseit.
Köszi! Továbbra is kérnénk itt, (magyarul :-) ) helyzetjelentéseket majd... ;-)
-
Legújabb teszt verzió. (http://enterpriseforever.com/programming/symbos-106/msg43162/#msg43162)
-floppy szektor írás/olvasás rutinok kicserélve az EXDOS-os megoldásra, így nincs már állandó retryzés
-a tálca színe is már beállítható: control panel -> display -> "taskbar"-t nyomni
-ablak felfele scrollozásától már nem omlik össze a rendszer :-)
-asztal háttér választható már
-működik a képernyő védő
-kernelben hibajavítások
Még az előzőből:
-külső joystickkal is megy a mutató
-keytest rutin megvalósítva, így már megy a Tetris
-vezérlőpult EP-re szbva
-SymbOS bbot meghajtó az EXOS-tól átvéve (magyarán nem gond ha mondjuk B: meghajtóról töltjük)
-EXOS dátum/idó átvéve induláskor
-
Nekem NAGYON tetszik!!! :-) :-)
Valamiért az internal joy -al nálam nem csinál semmit, (most hogy ez "direkt" van e így, vagy nálam hibázik a program, azt nem tudom :-P ) de EXT1 -el tudom a kurzort irányítani! :-)
Nem fagy, nem hibázik, látszólag tudja, amit kell!
(Egérrel lenne / lesz fantasztikus majd! :-) )
-
Valamiért az internal joy -al nálam nem csinál semmit, (most hogy ez "direkt" van e így, vagy nálam hibázik a program, azt nem tudom :-P )
ALT-ot nyomj hozzá, úgy mozog. és ALT+Space a bal gomb, ALT+INS a jobb.
Alapból kurzor billentyű az Int joy, ami pl a fájlkezelőben, vagy Tetrisben, Pacmanban használható.
Ez az ALT-os egér mozgás, csak vészpótlék egérhiány esetére.
-
ALT-ot nyomj hozzá, úgy mozog. és ALT+Space a bal gomb, ALT+INS a jobb.
Alapból kurzor billentyű az Int joy, ami pl a fájlkezelőben, vagy Tetrisben, Pacmanban használható.
Ez az ALT-os egér mozgás, csak vészpótlék egérhiány esetére.
Na, igen, így már érthetőbb... :-) (Ok, nekem sajnos a BUS nem jöhetett szóba a Turbó miatt, így a "hagyományos" egérkártyától elestem... :-( De remélem, a PS2 -es project nem sokára révbe ér és úgy valóban fantasztikus lesz ezt a rendszert használni! :-) Kíváncsi leszek, mi javul / fejlődik még idővel rajta!
-
szerettem volna ezt a kis simbOS DSK állományt kipróbálni, de látom emu alatt kéne :-)
én inkább az eredeti vasat preferálom... milyen szoftveres emu alá kellene ezt felgyötörni ? please help ;-)
-
szerettem volna ezt a kis simbOS DSK állományt kipróbálni, de látom emu alatt kéne :-)
Ha van EXDOS kártyád, akkor megy, csak ki kell írni egy floppyra!
milyen szoftveres emu alá kellene ezt felgyötörni ? please help ;-)
ep128emu
Ott valami sok ram-os configot betölteni, ha jól emlékszem alapból van olyan benne, hogy 640K EXOS 2.3 EXDOS.
itt csak ALT+D-vel be kell rakni az A: meghajtónak a lemezképet.
-
http://ep.lgb.hu/jsep/demo.new/?disk=SymbOS-EP-Full.dsk&mem=1024 (http://ep.lgb.hu/jsep/demo.new/?disk=SymbOS-EP-Full.dsk&mem=1024)
Elindul JSep alatt is, csak eppen nem igazan lehet a mouse pointert semmivel vezerelni, mivel ALT nincs emulalva (browser nem is igazan engedne). F9-et beraktam ALT-ra, igy F9-et nyomva kurzormozgato gombok melle megy, de fura dolgok tortennek, at akarja pakolni az ikonokat. Szoval nem tudom. Az otlet, hogy INS-el lehessen valtani modot (alt nelkul is iranyitani) az jo, csak az meg nincs a SymbOS/EP verzioban, csak mint terv. USB gamepad/joy emu van JSep-ben csak eppen nem kulso joyt emulal ugye hanem belsot :-( Boxsoft mouse van JSep-ben, de olyat meg a SymbOS/EP nem tud ...
-
a numpados verziót megnéztem, tök jó
viszont ha nagyobb lenne a képernyő akkor lenne az igazi. ez így ilyen "piciben" eléggé depis érzést ad :)
-
a numpados verziót megnéztem, tök jó
viszont ha nagyobb lenne a képernyő akkor lenne az igazi. ez így ilyen "piciben" eléggé depis érzést ad :)
Marmint az EP felbontas nagyobb? Vagy az emulalt screen JSep-ben? Ez utobbi esetben valts fullscreen-re a Run stb gomboknal talalhato gombra klikkelve.
-
Ez a Symbos mennyire használható sima 128k-s gépen? Szóval mem bővítés nélkül.
-
Elindul rajta, de egyébként nem igazán használható. Az alkalmazások futtatásához már kell a plusz memória. Egy-két progi fut csak 128k-s gépen, pl. számológép, képernyővédő, talán még az aknakereső.
-
A tegnapi kiadás (http://enterpriseforever.com/programming/symbos-106/msg43612/#msg43612) újdonságai:
A legfontosabb, hogy most már kezeli az SD kártyákat.
Egér nélküli EP-hez most már kapcsolható a belső joy egér emulációja az INS gombbal.
Irányítás billentyűzet módban:
-belső joy = kurzor gombok
-Hold = F9 gomb
-ALT + belső joy = egér mozgás
-ALT + Space = bal egérgomb
-STOP = jobb egér gomb
-külső joy = egér, a tűz a bal gomb
Egér módban:
-belső joy = egér mozgás
-Hold = bal egérgomb
-STOP = jobb egérgomb
SD kártyák:
-Slot 1 a Micro SD, Slot 2 a normál SD
-SD kártyák menet közben cserélhetőek
-floppy meghajtók elérhetőek (akkor is ha nem floppys EXDOS van a rendszerben), persze ha léteznek :-)
-a SymbOS jelenlegi SD drivere nem kezeli az extended particiókat, csak a 4 primary-t
-de támogatja a FAT16 és FAT32 partíciókat, célszerű rakni a normál EXDOS-os particiók mellé (vagy egy másik kártyára) ilyet rakni a SymbOS cuccoknak
-a boot loader jelenleg a SYMBOS.INI fájlt az első 4 partíción keresi, elsőként a normál kártyán, majd a micro SD-n
-
Na, ez hatalmas előrelépés! :-)
(De még van hová fejlődni... :-) 4 floppy macera nélküli felismerése, vinyó kezelés, teljes képernyős futás, stb.)
... én meg (egér emuláció ide vagy oda) kapjam össze magam egérért. :-D
-
Na, ez hatalmas előrelépés! :-)
(De még van hová fejlődni... :-) 4 floppy macera nélküli felismerése, vinyó kezelés, teljes képernyős futás, stb.)
... én meg (egér emuláció ide vagy oda) kapjam össze magam egérért. :-D
A vinyokezeles nem biztos, hogy jo otlet. Ugyanis, mivel a driverek fixen benn vannak, annak hozzaadasa tovabb noveli a memoriaigenyet a rendszernek, es alap 128K-val igy is eppen csak jo valamire. Igaz, az elkepzelheto, hogy legyen tobb verzio. MSX verzio amugy tamogat betoltheto drivereket, de ennek is ara van. Szerintem manapsag is az SD kartyas megoldas a "meno", meverlemez lassan PC-ben sem lesz (csak SSD) ha a vilag igy halad tovabb. 4 floppy? :-) Uh. A teljes kepernyo alatt mit ertesz, 320*200-nal nagyonn felbontas?
-
De neki pont vinyója van, nem vigasztalja, hogy SD-t már tud :-)
Egyébként se hiszem, hogy a pár 100 bájtos driverektöl lenne tele a RAM. Igazából el se tudom képzelni, hogy mivel pakolja tele a 128K-t...
128K- így is - úgy is használhatatlan bármire, 1M-nál meg nem számít az a pár bájt.
Ep128 kollégának amúgy is 2.5M RAM-ja van...
Szóval szerintem tudjon csak mindent amit EP-re lehet kötni!
-
De neki pont vinyója van, nem vigasztalja, hogy SD-t már tud :-)
Egyébként se hiszem, hogy a pár 100 bájtos driverektöl lenne tele a RAM. Igazából el se tudom képzelni, hogy mivel pakolja tele a 128K-t...
128K- így is - úgy is használhatatlan bármire, 1M-nál meg nem számít az a pár bájt.
Ep128 kollégának amúgy is 2.5M RAM-ja van...
Szóval szerintem tudjon csak mindent amit EP-re lehet kötni!
Oke, csak ugye volt az okfejtes, hogy alapkovetelmeny, hogy meg ha nem is igazan hasznalhato, azert alapgepen is elinduljon legalabb. Legalabbis a szerzo nyilatkozott igy. Amugy igen, lehet nem nagy ervagas egy plusz driver, csak van egy olyan erzesem, hogy "mindent" nem lehet tamogatni azert, vagy akkor az MSX okan abba az iranyba kene menni: ott pl azert lett betoltheto driver megoldas, mert az MSX ugye messze nem egy gep, es eleg sok eleg kulonbozo megoldas van, ami tenyleg nem igazan ferne mar bele a cuccba, ha monolitikus a felepitese ... Nem vagyok en vinyo ellen nyilvan, csak megjegyeztem :-D
-
4 floppy? :-) Uh. A teljes kepernyo alatt mit ertesz, 320*200-nal nagyonn felbontas?
Naná, hogy 4 floppy! :-D Anno azért lett így, mert kicsiről kicsire és nagyról nagyra (meg persze keresztben is) kellett tudnia másolni. :-) Zozonak hála tud is! (Természetesen 5.25 -ös 1.2 és 3.5 -ös 1.44 -es "PC meghajtókról" beszélünk. :-) )
A teljes képernyőn meg azt értettem, hogy jelenleg egyfajta "ablakban" fut a rendszer. Nincs kihúzva egész képernyőre! Alul is, felül is hely van fölötte, teljesen "fölöslegesen"! Ez tulajdonképpen egy "op. rendszer" és mint ilyen fusson csak egész képernyős módban! Szerintem. :-)
-
tegnap sikerült a SymbOS-t bedöntenem az egér teszt kapcsán ;-)
a hátteret állítottam feketére, meg az egér érzékenységet növeltem meg, elmentettem.
indításnál bebootol az OS, majd amikor betöltené a fent említett beállításaimat kifagy...
fekete képernyő, felső részén fehér csíkkal ;-)
találkozott már valaki ezzel a problémával ? :-)
-
Én nem, mondjuk ilyen beállításokat még nem próbáltam :-)
Olyat csináltam, hogy átkonfigoltam Micro SD-re, meg parancsikont raktam az asztalra.
-
Kezeli a SymbOS jelenlegi változata a Mészáros Gyula-féle egérkártyához kapcsolható egeret?
;-)
-
Kezeli a SymbOS jelenlegi változata a Mészáros Gyula-féle egérkártyához kapcsolható egeret?
Még nem.
-
kezd olyan érzésem lenni mint a windóznál: van erre driver? és arra? miért nem megy windózzal ez a nyomtató??
na jó, ezek azért már nem túl gyakoriak, de 10 éve még azok voltak :)
-
kezd olyan érzésem lenni mint a windóznál: van erre driver?
Knight Driver (by Hewson, 1984)
-
Még nem.
A válaszból következtetek, hogy van rá remény a későbbiekre vonatkozóan. :lol:
-
A válaszból következtetek, hogy van rá remény. :lol:
Írta, hogy elsőként a 3.0-ás verzió kiadása jön, aztán majd a spéci EP-s dolgok.
-
Nos, megtaláltam a SymbOS magyar topicot :)
Írom, hogy én mit tapasztalok:
- Microteam kártyával nem indul.
- simán pedig hiába nyomogatom az INS billentyűt, nem működik a kurzor
- nagy változást nem látok, ugyanazok az ikonok, sehol semmi 😞
- Megint valami beállítás vagy trükközés kell? Elnézést de az átlag felhasználónak ne kelljen kitalálni dolgokat ...
- A SymCommander NEM kezeli a kiterjesztett partíciókat (ahogy ígérve lett), sőt még a G: meghajtót sem látja, mint eddig!
- A kilépésnél a 3 Shut Down pedig lehet, hogy nagy poén, de engem halálra idegesít 😞
- És hiányzik belőle Geco zenelejátszója is :(
Elnézést ha kicsit "idegesen" fogalmaztam, de régóta várjuk már és én kicsit többet vártam most ...
-
Mind ezt szerintem valaki írja át az angol topic -ba is, nagyon fontos lenne tisztázni a felsoroltakat!
(Vinyókezelés lett? A, B, C, D floppykezelés lett? Teljes képernyő lett? Képernyőpihik lettek? Stb. Egy rahedli dolog volt anno ígérve még...)
-
A sok mindent amit kerestek, az egy későbbi bővített EP verzióba van ígérve, amihez már RAM bővítés kell. Elsőként csak a sima 3.0 jött ki minden gépre.
I am afraid that it doesn't make sense to add this to the "usual" version of SymbOS (which also works on 128K machines), as it requires several changes in the kernel.
But there is still the plan to have the "expanded" EP version of SymbOS after the 3.0 release, which only runs on expanded machines (192K or more) and uses a higher screen resolution. This would always keep the #FF segment free for EXOS.
-
Oké, jogos, visszaolvastam a fórumban és látom :oops:
Egér nélkül viszont nem működik... ha a leírtak szerint megnyomom az INS billentyűt, a kurzornak működnie kellene!
Valamint az előző verzióban a SymCommander látta a G: meghajtót az SD kártyán, most pedig nem.
-
Valamint az előző verzióban a SymCommander látta a G: meghajtót az SD kártyán, most pedig nem.
Szerintem sikerült felülírni az általam beállított INI fájlt egy gyári alap verzióval :oops:
Korábban írtam:
"4 INI fájl van, a .SD végűek a normál SD kártya esetén, a .MSD végüek Micro SD és emulátor használatához.
A SYMBOS nevűek alap 128-as géphez, a SYMEXT nevűek bővített géphez, itt van asztali háttérkép, és engedélyezve van a Extended Desktop mód használata. Az aktuális konfignak megfelelőt kell bemásolni SYMBOS.INI-nek. Alapbeállítás a SYMEXT.MSD, azaz Micro SD/emulátor, bővített géppel."
Optimális esetben ezek most is ott vannak az SD kártyádon, és működnek az új verzióval is :-) (Legutóbbi SymbOS-ünk is már 3.0 volt, csak még béta)