Enterprise Forever
:HUN => Programozás => Topic started by: MrPrise on 2008.September.29. 11:56:12
-
A Z88DK (http://www.z88dk.org/) egy C keresztfordító Z80-hoz, azaz PC-n lehet segítségével Z80 alapú gépekre programokat írni C-ben. Az assembler-en és a linker-en kívül számos lib tartozik hozzá amelyek a szabványos C könyvtárakat implementálják a különböző Z80 alapú gépekre. Azt írják, hogy nagyon egyszerűen lehet új gépre portolni ezeket. A készítők remélik, hogy egy nap a Z88DK az összes olyan Z80 alapú gépet támogatni fogja amelyekről elegendő információ érhető el és persze kellő érdeklődés mutatkozik iránta.
Jelenleg (http://www.z88dk.org/wiki/doku.php/targets) több mint 30 különböző Z80-as gépet támogat többé-kevésbé. Sajnálatos módon az Enterprise hiányzik a listáról.
Ha nagyon unatkozunk talán meg lehetne nézni ezt, feltéve, hogy van igény arra, hogy lehessen EP-re C-ben írni programokat PC-n.
-
Most, hogy kiderült, hogy az Endi által talált új Spectrum játék ebben irodott, éppen ideje felhozni ezt a témát :-)
-
hogy derült ki? mi? hol? és ez miben jobb mint az sdcc?
-
hogy derült ki?
Meg kell nézni a comp.bat-ot :-)
és ez miben jobb mint az sdcc?
Fogalmam sincs, C-ben utoljára úgy 13 éve programoztam, valami Borland Turbo C-ben vagy micsodában :oops:
-
Odáig már eljutottam, hogy elõ kéne állítani egy ep_clib.lib-et...
De hogy a fenébe lesz a libsrc-ben elszórt asm fájlokból .lib?
-
Hat en ugyan SDCC- vel nyomulok, de elotte sokmindennel megprobaltam, de valamiert massal nem sikerult, ezzel a z88dk -val sem.
Persze simen lehet, hogy csak turelmetlen voltam.
Viszont ahogy szamomra kiderult, nem igazan nagy jelentosegu dolog a C forditas EP- re, ameddig standard memoriaju EP- ben gondolkodunk,
ugyanis iszonyat memoriakat emeszt fel egy C- rol forditott program.
Az biztos, hogy egy elmeny C- ben vegezni el olyan unalmas dolgokat mit az LPT felallitasa, meg ugy egyebkent mindent, aminek nincs komoly sebessegigenye,
de sajnos pillanatok alatt lesz a forditott programunk 16 vagy 32 kbajt hosszu... Es raadasul a lapozast ezek a forditott programk nem tamogatjak tudtommal.
De meg ha tamogatnak is, akkor is csak sok-sok kilo/mega bajtos EP- ken fogunk tudni megfeleloen komplex programot irni.
Tehat ( ha igaz hogy az SDCC jo referencianak, es mas forditok nem generalnak mondjuk tizedakkora kodot ) annak az eselye,
hogy egy demot, vagy akarmilyen alkalmazast C- bol forditsuk ep- re, sztm igen kicsi.
Csak egesz kis programjaink fognak beferni a 64K- s cimteruletre.
Nem lehet hogy az a jatek amit a z88dk -nak tulajdonitasz, az valojaban olyan mint az en demom:
C- ben van irva az LPT/HW inicializalas, aztan meg teljes inline assembly- ben az osszes tobbi, mert se eleg gyors, es ami fo, se eleg kicsi nem lenne, ha C- ben irtam volna ?
Szal a z88dk- t csak arra hasznaljak, hogy inline assembly- t forditsanak Pc- rol z80- ra ?
-
Szal a z88dk- t csak arra hasznaljak, hogy inline assembly- t forditsanak Pc- rol z80- ra ?
Nem, maga a játék forrása kb 70%-ban C-bõl áll, ami persze rengeteget hivatkozik az elõre elkészített Spectrumos lib-ekre, ahol assemblyben megírt eljárásokat hívogat. A sprite kezelés meg ilyesmi az mind ilyen.
Itt a saját hozzáadott assembly kódjuk nagyrészt a 128-as zenelejátszó, és ahhoz tartozó memórialapozás.
-
akkor nemtom... fel tom dobni a demom forrasat, parszaz sor lehet C- ben, es tobb int 2000H hosszura fordul... hat az rengeteg.
-
Helló,
Engem speciel érdekelne ez a C dolog EP-re, de az SDCC kapcsán...
Az Amstrad-osok már összelőttek valamit alája, saját crt0 file, meg effélék.
EP-n hogy áll a dolog...?
-
Nem tudom,
én próbálok SDCC -vel valamit bénázni, de azért nem mondanám nagy framework -nek,
mert épphogy megírtam pár vackot, aztán valahogy hosszúnak és lassúnak találtam a fordított kódot,
és inkább akkor az assembly -re fókuszáltam mégis, de azért persze C -ből indul és persze az inicializálásban engedek magamnak továbbra is C kódot,
de mivel most (már pár éve ... :)) fejlesztek egy játekdemót, azt pld. át tudom dobni,
az bekapcsol egy LPT -t, meg futtat rajta pár pixelt most csillagmozgáskezdemény gyanánt ...
Annyit meg tudsz spórolni vele, hogy nem kell bogaraszd az átkozott compiler flag -eket vagy ilyesmit egyből ...
De összegészében igazából sztm csak az hasznos benne, hogy PC -n fordul, és emuban futtatja egyből le a programot, a C fícsőrök már csak egy kis hab ahogy én látom ...
De persze ha valaki kideríti, hogy mégsem, csak még 2 flag -et be kell kapcsolni ... az nem volna kutya.
-
valahogy hosszúnak és lassúnak találtam a fordított kódot,
Ez igaz, de full assemblyben neki esni a dolgoknak nem kezdőknek való.
Sokaknak jól jönne valami BASIC-nél jóval nagyobb teljesítményű, de azért magas szintű nyelv amivel önnállóan futó EP programot lehetne előállítani.
A Turbo Pascal pl nem lenne rossz, de az IS-DOS azaz CP/M alatt futó programot eredményez.
Nézegettem valamelyik C cuccban nyomulnak Spectrumosok meg CPC-sek, van egy csomó kész eljárás (grafikus rutinok, sprite mozgatás, stb) persze assembly betétekkel, de a programozni vágyó szempontjából ezek készek, csak meg kell hívni. Egy csomó új játék készült ezzel a rendszerrel.
Jó lenne ilyen EP-re is.
fejlesztek egy játekdemót, azt pld. át tudom dobni,
Ez szerintem többeket is érdekelne, pl engem is :oops:
-
Ez szerintem többeket is érdekelne, pl engem is (http://enterpriseforever.com/Smileys/phpbb/ds_icon_redface.gif)
Oksa, összepakolom.
-
Helló,
Engem speciel érdekelne ez a C dolog EP-re, de az SDCC kapcsán...
Az Amstrad-osok már összelőttek valamit alája, saját crt0 file, meg effélék.
EP-n hogy áll a dolog...?
sdcc-hez en is jatszottam ilyennel, irtam crt0-t, stb, de egyes sdcc bug-ok miatt (amit azota sem javitottak pedig report-oltam) elment tole a kedvem (mindenfele post precessing scripttel program orvosolni, automatizaltan atalakitva az assembly outputjat az sdcc-nek), meg amugy is inkabb csak a kivancsisag vezerelt, mivel asm rulZ :)
-
megoldás: EP Plus...
írni bele egy sprite kirakót asmban, betöltőt és kész, marha komoly cuccokat lehetne vele basicben csinálni
persze nem 50fps-eseket :)
az IXL c. specy játékot Laser Basicben csináltuk, az hasonlót tud (még akkor nem volt EP-m)
WOS-on fent van
-
sdcc-hez en is jatszottam ilyennel, irtam crt0-t, stb
Ameddig eljutottál azt nem rakod fel?
-
Ameddig eljutottál azt nem rakod fel?
Ha megtalalom, akkor de :) Remelem nem a regi gepen volt, amin befuccsolt a disk ...
-
Megtalaltam, eddig jutottam (http://ep.lgb.hu/sdcc/). Azert csak ovatosan, teljesen gaz az egesz (forditani barmit meg UNIX/Linux szeru kornyezetben lehet vele csak igazan). Pl benne vannak nyomdafesteket nem turo filenevek pl f*szom es hasonlok (ezert kulon bocs, magamnak csinaltam, most meg nem volt idom Makefile-t stb modositgatni, vegignezni a linkelest, ilyesmi) ... Raadasul mindenfele debug/teszt celzattal olyasmik is bekerulnek a forditott kodba, amire amugy semmi szukseg nem lenne, csupan hex viewerrel neztem a kodot, hogy mi hova kerul, es hasonlok. Mellekeltem linket az oldalon, ahol az JSep webemuval meg is nezheto azonnal a printf.com eredmenye, ha valaki nagyon nem tudna elkepzelni :-) A printf.c -ben az az strstr fuggveny is tesztelesi cellal van csak benne igazabol, nincs ra szukseg :)
Leszamitva az ilyen anomaliakat, latszik, hogy 3826 byte a printf.com, ami soknak tunik (az is), de ne feledjuk, hogy a printf implementacio az iszonyat sok mindent jelent. A leheto legegyszerubb C program (kb ures, a minimal.c, a zip letoltese utan) az csak 228 byte hosszusagu kodot eredmenyez. Ennek jo resze amugy persze maga a crt0 implementaciom, a hozza kell string-ekkel, stb, itt az sdcc altal forditott kod talan egyetlen egy RET -ben realizalodik :-)
Nem tudom, ez hasznos-e igy barkinek, de mivel Zozo irta, hogy igazan lehetne publikalni amig eljutottam vele, hat megtettem. Esetleg egyszer ha lesz idom (hahahahahaaa!) akkor tovabb reszelem a dolgot, hogy kisse normalisabb legyen. Felteve, ha szerintetek van ertelme, es kell valakinek. En csak a kihivas miatt csinaltam, hogy EP-re lehet-e C-ben fejelszteni, de egy Hello world! utan eleg is volt belole :)
-
Masik erdekesseg, amit pl nem tudtam: sdcc allitolag tamogatja a memorialapozast. Nem mintha probaltam volna, csak eppen nezem mi valtozott az sdcc-ben miota utoljara "jatszottam vele", es ezert a doksijat atfutottam. Ja, es a legujabb SVN verzio ugy tunik 14%-al kisebb kodot eredmenyez, mint amit utoljara hasznaltam.
-
Ja, es a legujabb SVN verzio ugy tunik 14%-al kisebb kodot eredmenyez, mint amit utoljara hasznaltam.
Lehet, csak ahogy én használni kezdtem, úgy az új verziók nem mennek ... Tehát mittomén 2 évvel ezelőtt volt az SDCC, akkor az kilökött valami "intel hex" vagy miabigyó formátumot, arra valami külön tool -t kellett ráeresszek, és az csinált belőle binárist, meg azt hiszem ott még valami offszetelést is csinálni kellett benne valami kapcsolóval.
És akkor tudomisén fél éve gondoltam váltok az újra, és nem működött az újjal ... Én meg nem kezdtem megint 3 napig molyolni, hogy miért nem megy vele most megint.
Úgyhogy azóta is a 2 éves (megkerestem az utolsót amivel még jó) verziót használom ...
-
Lehet, csak ahogy én használni kezdtem, úgy az új verziók nem mennek ... Tehát mittomén 2 évvel ezelőtt volt az SDCC, akkor az kilökött valami "intel hex" vagy miabigyó formátumot, arra valami külön tool -t kellett ráeresszek, és az csinált belőle binárist, meg azt hiszem ott még valami offszetelést is csinálni kellett benne valami kapcsolóval.
Jah, nalam is azert bonyolult a Makefile, sot en meg meg is toldom egy manualis assembly igazitos script-el ami az altalam mar ecsetelt sdcc bugot probalja orvosolni, igy nemikepp soklepcsos a dolog :) Ja, es a szegmensek is kisse modosultak, ahogy az inicializalt valtozok/konstansok kezelese is, volt az a randa ginit, hogy kodot allitott el ehhez!!! Ez mondjuk elsore meglepo, amde ne feledjuk, hogy sdcc pl MCU-kat is megeceloz, ahol ugye a code/data memoria elesen el van kulonitve, es nem is egyszeru maskeppen csinalni (Harvard-architektura; vs Neumann).
És akkor tudomisén fél éve gondoltam váltok az újra, és nem működött az újjal ... Én meg nem kezdtem megint 3 napig molyolni, hogy miért nem megy vele most megint.
Hat nem tudom mire gondolsz, ami hirtelen beugrik (de lehet, hogy tevedek) az pl az, hogy .rel nevvel illeti az "object" formatumat (ami valojaban vmi ihex szeru cucc), regen viszont .o volt a default ertelmezes.
-
Hat nem tudom mire gondolsz, ami hirtelen beugrik (de lehet, hogy tevedek) az pl az, hogy .rel nevvel illeti az "object" formatumat (ami valojaban vmi ihex szeru cucc), regen viszont .o volt a default ertelmezes.
Ja, addig eljutottam az újjal, hogy lecseréltem a kiterjesztéseket, és akkor már lefordult a bináris megint, de mikor futtattam elszállt. És azt már nem kezdtem nézegetni, hogy miért, vissza a régi, és majd ecce ...
-
Ezt mostanában többször is megfigyeltem PC-s körökben, hogy a kompatibilitás az sokadlagos szempont a fejlesztésnél, és egy adott forráshoz négy tizedesre meg kell jegyezni, hogy melyik fordító verzióhoz készült...
-
Ezt mostanában többször is megfigyeltem PC-s körökben, hogy a kompatibilitás az sokadlagos szempont a fejlesztésnél, és egy adott forráshoz négy tizedesre meg kell jegyezni, hogy melyik fordító verzióhoz készült...
Minek folyton új verzióra áttérni? Ezt csak az amatőrök csinálják.
-
Minek folyton új verzióra áttérni? Ezt csak az amatőrök csinálják.
Tevedes. Akkor van igazad, ha _csak_ a verzioszam novekedese miatt teszi az ember kvazi "automatikusan" es gondolkodas/valodi igeny nelkul. Viszont lehetnek olyan dolgok, amik ezt indokoljak.
-
Tevedes. Akkor van igazad, ha _csak_ a verzioszam novekedese miatt teszi az ember kvazi "automatikusan" es gondolkodas/valodi igeny nelkul. Viszont lehetnek olyan dolgok, amik ezt indokoljak.
komoly projektek közben nem szoktak verziókat váltani, minek? hiszen tudták, hogy az adott verzióra építik a projektet
mi indokolná? kis verzióváltások nem, ott nem jön be olyan fontos dolog. nagyok meg ritkábbak
persze sokmindentől függ ez
én pl egy ősrégi blenderrel is jobban és gyorsabban dolgozok mint a sok nyavajgó blender user akik folyton új ficsöröket akarnak, de közben tök lassan dolgoznak, ha egyáltalán csinálnak valamit
-
Vagy esetleg csak azt tudod, hogy az adott program mivel készült, letöltöd az aktuálisat, aztán szenvedsz, mert x.y.z verzióval ezelötti kéne hozzá, csak éppen nem tudni...
Ez volt az ep128emu-val is, amíg István fel nem raktam a komplett fejlesztési környezetét, csak szenvedtünk hiába...
-
komoly projektek közben nem szoktak verziókat váltani, minek? hiszen tudták, hogy az adott verzióra építik a projektet
mi indokolná?
Pl mint pont az sdcc project-nel is, kozben jottem ra, hogy az ujabb verziok nemely tekintben sokkal jobbak, igaz van amiben viszont maskeppen viselkedik :) Most nem arrol beszelunk, hogy van egy X eve aktivan futo project, ami valamire epul, aztan Kiss Pistike kitalalja, hogy ujabb verziot kene hasznalni, mert reggel azt almodta meg :) Van ahol celszeru a valtas, az sdcc Z80 portja pl jelentosen atalakul, nem egy kiforrott technika, tehat kotelezo kvazi kovetni, ha nem akarsz egyuttelni a hibakkal, nem elegge optimalis koddal stb. Nyilvan mas lenne a helyzet, ha mar 100 eve kesz lenne, es csak kisebb finomsagos valtoznanak. Eleg beszukulten gondolkodsz, hidd el vilaghiru projectben is reszt vettem mar, ez nem ilyen fekete/feher, ahogy ezt te elkepzeled :)
-
Na itt az én vackom is, Zozo kérésére.
Jómagam nem hinném, hogy ez bármire is jó lehet, azon kívül amire készült. És arra is csak nekem.
Azoknak akik nem akarnak assembly -ben mártózkodni, azoknak ez nem jó semmire, mert hát hiába tudnak C -ben programozni, ha inputjuk és outputjuk meg semmi nincs. Persze hívhatnak EXOS -t ki és bemenetnek, de ahhoz már megint assembly kell. Ha valaki az EXOS hívásoknak csinálna C wrapper -eket, akkor már használható lenne magas szinten (C) akármire is.
Azoknak meg akiknek nem taszajtó az assembly, és pont multimédiát (demo, game) akarnának programozni EP -n, azok nem hinném hogy az én framework -ömmel akarnának molyolni, azok megcsinálják maguknak.
De ha Zozót érdekli, akkor hát itt van.
Használat.
A cucc winre van készítve, csak Win7 64 -gyel tesztelve, nem multis.
A csomag tartalmaz binárisokat is, amiket le lehet tölteni a netről ha az ember nem azt akarja használni ami be lett zippelve, illetve az egyik binárist én írtam, annak meg ott van a forrása, és le lehet fordítani, ha nem jó az, ami be lett csomagolva. A víruskeresőm uptodate verziója nem jelzett a csomag tartalmán problémát, de hát a netről van, mindenki vesse saját biztonsági intézkedései alá.
A használat 3 lépésből áll.
1, Fel kell telepíteni az ep128emu2 aktuális verzióját a default path -ra. Aki nem oda teszi, annak át kell írnia a script -ekben a hivatkozásokat rá.
2, A csomag tartalmát kitömöríteni egy olyan path -ra, ami nem tartalmaz felkiáltójelet és space -t, majd futtatni kell a build.cmd -t abból a könyvtárból, ahol van. Ez lefordítja a build.cmd mellett lévő forrásokból az EP binárist, és lefuttatja azt az emulátorban. Helyes végeredményként mozgó kék pöttyöket és egy vibráló sprite kezdeményt kell látni.
3, Utolsó lépésként pedig örülni kell, hogy mennek a kék pöttyök ...
UI: Az sdcc lib könyvtárból töröltem a pic16 könyvtárat, mert az volt a legnagyobb, és az EPF nem engedett akkora attachment -et.
UI2: Mikor lefut az EP program az emuban, akkor bevált egy a futtatáshoz szükséges emu konfigurációt. Akinek az emu konfigurációja hosszadalmas, az mentse el magának az emuból a build.cmd futtatása előtt.