ENTERPRISE KLUB
2019. május 25., 1055 Budapest, Nyugati tér 9. 14-19 óráig
Részletek
Welcome, Guest. Please login or register.


Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.


Messages - Z80System

Pages: [1] 2 3 4 5 6 7 8 ... 221
1
Történelem / Re: Mire gondolhattak az EP tervezői?
« on: 2019.May.11. 22:31:17 »
Ez volt a korabeli divat ...

25 négyzetméter alatt a tervezők nem érezték elég komolynak a konfigurációt ...

A C64 -es tervezők arca égett, mikor 2 dobozzal meg egy din kábellel megoldották ...

Tök gagyi hatása volt ... eltörpült az asztalon ... alig látszott ...

Egy repülőteret se fedett le ... de még egy vacak focipályát se ...

2
Hardware / Re: SymbiFace3 is near your Enterprise...
« on: 2019.February.17. 09:25:53 »
Quote
The answer is YES :-D

Most probably, the question for this answer was about EXOS and not SymbOS.

Am I correct ?

So yes, the storages can be used by SymbOS,
but maybe the question was about ordinary EXOS/EXDOS usage for loading ordinary (not SymbOS based) stuff (,as well).

3
Hardver / Re: HID kezelés ReLoaded (Enter the RPi)
« on: 2018.December.02. 15:36:49 »
Nem, a sima Raspbian az nem realtime.

A nanosleep -ről meg kiderült, hogy ha 0 -át adsz neki, RPi -n az akkor is 80+ mikroszekundum lesz,
ami ugye már csak max 12.5 KHz önmagában ...

Remélem hogy mérni azért ennél nagyobb felbontással tudok majd időt mikor generálgatom a jeleimet,
de végülis mindegy, elég gyors lesz mindenképp ...

4
Hardver / Re: HID kezelés ReLoaded (Enter the RPi)
« on: 2018.December.02. 13:46:40 »
Na, végre megint hekkeltem.

Műxik az RPi GPIO kivezetés, level konvertálás művelet, amire egyrészt abból következtetek,
hogy 5V -os jelet tudok kapcsolgatni (műszar szerint) az RPi -ből C++ kóddal,
és még mindíg működik az RPi ... :)

Sebesség érdekes dolog ... egyenlőre nem a direkt IO periféria regiszteren keresztüli kapcsolgatást választottam,
hanem egy bcm2835 nevű (az RPi periféria IC nevéről elnevezve) könyvtárral babrálom a GPIO -t,
amivel üres loop -ban 10 MHz -es frekit tudtam előállítani (még sebesség optimalizálást sem állítottam be a C++ fordítóban),

ami bőven sok, mert nekem a freki egyrészt nem is kell stabil legyen, mert élvezérelt a PS/2 protokol,
masreszt max 100 KHz -es jellel tervezem küldeni az EP PS/2 bemenetet.

Viszont mikor elő akartam állítani egy 100 KHz -es jelet, akkor meghívtam a fenti könyvtárból egy olyan függvényt
(ami valami "nanosleep" -en alapul mellesleg), ami miroszekundumos léptékű sleep -et nyújt,

amivel nem tudtam 7 KHz felé menni, hiába állítottam 1 mikroszekundumra a bemenetét ... :)

Szal magának a mikroszekundumos sleep függvénynek van egy akkora késleltetése, hogy 7 KHz -re limitálja a max frekit ...


Most ez vagy egy nagyon béna mikroszekundumos sleep függvény, vagy nem tudom mi a retek van ... :)


Másik érdekesség, hogy a freki nagyon nem stabil, a freki mérő digitális műszer pörög fel/le mint a bolond ...
Ami mondom nem lesz baj itt most nekem, de az Arduino -n ez nem így volt, ott szép stabil frekiket lehetett kimérni.


Szóval mostmár csak a lényeg hiányzik az input HUB progihoz, a periféria bemenet/kimenet függvényeket összegyűjtöttem.


5
Hardver / Re: HID kezelés ReLoaded (Enter the RPi)
« on: 2018.November.18. 21:51:45 »
És íme ni :

22161-0

22163-1

6
Hardver / Re: HID kezelés ReLoaded (Enter the RPi)
« on: 2018.November.18. 21:24:35 »
Ja, és bájdövéj összeheggesztettem az RPi és az EP PS/2 bemenete közé hiányzó kábelt ... :)

Szóval haladtam kérem ! :)


Az egér kábelt még nem csináltam meg, mert rájöttem hogy ez a szerelési minőség nekem nem lesz jó,
ahogy eddig összeraktam a cuccokat ... :oops:


Most akkor így készvan a HW heggesztés ahhoz,
hogy tudjam írni az RPi -re a HID HUB programot,
és ha kész van a billentyűzet és játékvezérlő kód,
akkor az egér kezelést sztm. már megírom hátratett kézzel is ...


Aztán pedig újraheggesztek mindent ... :evil:


Az EP oldalon túl nagy lett a kábelköteg az EP alaplap alatt,
valamint túl gyenge a PS/2 anya csatlakozó, egyszer nem vigyázok,
azonnal letörik.

Az RPi oldalon ez a felül kábelezés hazavágta az egészet,
és PS/2 apa csatlakozóknak meg olyan szemetet sóztak rám,
hogy egyszerűen nem lehet ráhúzni a csatlakozó magra a külső borítóköpenyt,
mert túl szoros ...


Szóval EP oldalon újra kell heggeszteni szupervékony szalagkábellel,
meg szereznem kell valahonnan frankó erősre kivezetett PS/2 anyát,

RPi oldalon meg szereznem kell olyan panelt ami ledupláz egy 2X20 -as tüskesort kétoldalas nyákon,
és akkor annak az egyik feléhez kell heggesszem tüskesorral az én panelemet, akor nem lesz kábelezés felül,
meg keresnem kell rendes PS/2 apa csatlakozókat.

7
EP128Emu / Re: ep128emu2 RPi build
« on: 2018.November.18. 20:49:14 »
Most akkor ha szereznék ilyen RPi -hez való kompozit video kábelt,

vagy esetleg egy RGBHV SCART kimenet kártyát,

akkor el lehetne kezdeni kísérletezni a TV -immel ... :)


Vagy pedig má milyen meta lenne az,
ha miután ily módon generáltunk egy 15 KHz -es EP jelet,
akkor azt valami scaler -en keresztül valami modern VGA monitorra tolnánk ... :smt042  :ds_icon_cheesygrin: :smt043

8
EP128Emu / Re: ep128emu2 RPi build
« on: 2018.November.18. 20:40:44 »
És íme ni :

22159-0

9
EP128Emu / Re: ep128emu2 RPi build
« on: 2018.November.18. 20:15:22 »
Persze mindez nem akadályozná meg azt, mait én akarok:

Nekem a legkisebb ablakméret is elég,
és ugye azt akarom rendes 15 KHz -es display -en jeleníteni meg ...

Persze a keretekkel még majd meggyűlne a bajom,
de valószínűleg ha beleteszem a fullscreenbe váltást mindjárt az elején,
inicializálás környékén, akkor jó lesz ...

(Hiszen a menü 3 fázisú ablakméret változtatását elfogadja HW GL módban is,
valamint nekem igazából mégcsak be se kell kapcsoljam a HW módot,
mert 240p -ben elmegy CPU -val is 45 % -al ...)


Ki tudja egyébként használni a magokat az emu elvben ?
(Ki kéne tudja, ha az RPi -n a CPU mérőke nem teljesen sz**,
és azt jelzi, hogy kihasználja 85% -ra nagy ablak méretnél ...)


10
EP128Emu / Re: ep128emu2 RPi build
« on: 2018.November.18. 20:08:31 »
Ja, és persze ha a HW gyorsítás nélküli módon futtatom,
akkor működik az F9 fullscreen, de az 1280 -as felbontásomon az jelenleg használhatatlanul lassú
(még 0 -ás grafikai minőségnél is),

ha pedig alárakom a hardver gyorsítást, akkor itt sem veszi észre az alkalmazás ablak mérete hogy "kiváltották fullscreenbe",
marad azon ami utoljára volt beállítva a menüből. (Ilyenkor az ablak kerettel való átméretezésre sem reagál a renderelt kép.)


11
EP128Emu / Re: ep128emu2 RPi build
« on: 2018.November.18. 20:03:19 »

Na jól van, ez is simán ment a normál desktop Ubuntu build után. (IstvanV a király!)

(Csak itt még össze kellett hekkelni a curl -t is, mert addig nem voltak ROM -ok ...)


Viszont nem éppen rózsás a helyzet ...


Hardveres OpenGL támogatás mellett
(ha a Raspbian -ban bekapcsolom hogy hardver desktop GL legyen az OS alatt, ne a GLES),

akkor ugyan a CPU terheltség nem lesz nagy nagyobb ablakokban sem,
de maga a képfrissítés sebessége és a reszponzivitás leesik ha bármi nagyobb grafikai minőséget állítok be 0 -nál
(még a dublabuffer is lassít ... :)),

ha pedig nem kapcsolom be a hardver GL -t a Raspbian alá, akkor még 0 -ás grafikai minőség mellett is jelentős a CPU terhelés,
legkisebb ablakméretben 45%, közepesen 75%, nagyon 85%.

Az emu közben végig azt mutatja hogy 100% -on fut.


A hangot egyből kikapcsoltam, azzal most nem akartam vacakolni,

viszont valamiért a billentyűzet sem működik jól,
valamiért szinte csak az alfanumerikus billentyűkkel lehet gépelni,
a jelekkel nem ... még nem jöttem rá miért ...
(ha kézzel beállítom, akkor működik a többi billentyű is).


12
EP128Emu / Re: ep128emu2 RPi build
« on: 2018.November.18. 17:52:59 »
Hopp ... hát ez váratlanul egyszercsak lefordult ... :)

De legalábbis úgy tűnik ... :)

Pedig csak a kötelező csomagokat tettem fel, és csak az FLTK -t fordítottam forrásból.
(Mert ha nem forrásból telepítettem az FLTK -t,
akkor miután már YES -t mondott az FLTK -ra a scons script az elején,
azután egy tömören informatív "NO" sorral leáll ... :))

Eléggé más lett a menü fontja, viszont a fullscreen hiba megmaradt ... :(

Na akkor most átmegyek egy RPi -s topikba, megpróbálom akkor lefordítani arra is ...
(Hátha vak tik is talál szeget ...)

13
EP128Emu / Re: ep128emu2 RPi build
« on: 2018.November.18. 17:45:27 »
Mielőtt még tele blogolnám az ep12emu topikot, nyitottam egy sajátot az RPi build -nek ...

14
EP128Emu / Re: ep128emu2 RPi build
« on: 2018.November.18. 16:20:35 »
Na eddig annyit sikerult elérnem vmware/ubuntu parossal,
hogy lefusson az elore leforditott binaris ... :)

Megy rendesen, OpenGL effektekkel is,

de az F9 -cel mikor fullscreen -ben kéne lennie,
akkor csak eltünteti a rendszer menüket,

de nem méretezi az ep128emu2 ablakát teljes képernyősre,

hanem hagyja akkorán mint amekkora volt,
és továbbra is látszik a többi ablak a desktop -on
(kivéve rendszer menük, rendszer bar -ok) ...

Ez valami ismert bug linux -on, vagy mi ?

15
EP128Emu / Re: ep128emu2 RPi build
« on: 2018.November.18. 15:02:11 »
Oh, tankju, de meg az odebb lesz mire szukseg lesz ra ... :)

Eloszor megprobalom leforditani egy sima Ubuntu -n megint,
mert korabban meg azon sem sikerult ... :oops:

Es ha azon mar lefordult, akkor majd johet a Raspbian build ...


De Intel assembly optimalizacio nincs akkor az ep128emu kodban ?
(Mittomen CPU emulacional, vagy valami ...)


Mert ha van benne (nem opcionalis) Intel assembly,
akkor eselyem se lenne leforditani ARM -re ... :)


Pages: [1] 2 3 4 5 6 7 8 ... 221