Enterprise Forever
:HUN => Programozás => Topic started by: geco on 2024.January.09. 20:56:22
-
Nem tudtam, hogy hová tegyem, talán még az Assembly programozás lehetett volna jó hely, de inkább nyitottam egy új topicot.
Egy kicsit átdolgoztam Povi ROTA.CO-ját, sikerült egy picit gyorsítani rajta, csatolom az eredeti verziót, egy köztes állapotot, és a leggyorsabbat.
ROTAORIG.COM - az eredeti, egy képet 22-23 frame alatt állít össze
ROTANEW1.COM - köztes verzió, egy képet 16-17 frame alatt állít össze, itt csak pár apróságon módosítottam, képernyőre kirakás, a képen belüli cím kiszámítása lett átalakítva, és a szinusz táblázatból való 4 call helyére betettem 4x a rutint
ROTANEW2.COM - a leggyorsabb verzió, egy képet 13 frame alatt állít össze, itt átalakítottam a kép elhelyezkedését is, minden sor 100h-n kezdődik, így nem kell szinte semmit se számolni a képpont pozíciójához, a belső ciklusban a táblázatból való adatkinyerés hozzáadásos, kivonós számolgatása a pozíció balra/jobbra léptetésére lett cserélve, így a belső ciklust vissza számlálósra lehetett alakítani.
A csatolmány tartalmazza a forrásokat is, a sjasm-ot is, így bárki lefordíthatja a futtatható fájlokat a rotahead.bat segítségével bármikor winfos alatt (a futtatható fájlok is benne vannak a zip fájlban)
*** Attachment removed, new attachment in next post.
-
A leggyorsabb verzióban van egy kis hiba a belső ciklusban a csökkentés/növelés rossz helyre került, ezt javítottam, az új csatolmány már a javított verziót tartalmazza.
-
Itt van két újabb verzió, nem tudom, hogy ettől gyorsabbat tudok-e kreálni, egy ötletem még van, de ha gyorsabb is, akkor lehet fel kell használom még 1 szegmenst :D
ROTANEW3.COM - egy képet 8 frame alatt állít össze, egy 16 kb-os táblát használ a számításokra a 128 bájtos szinusz tábla, és és 512 bájtos érték tábla helyett
ROTANEW4.COM - egy képet gondolom 8 frame alatt állít össze, ez a leggyorsabb, lemérni nem tudom, 4 T-state-et spóroltam meg a belső cikliusban, és 6-ot a külsőben, ezzel tuti nem nyertünk egy frame-et, itt annyi a különbség, hogy az érték kinyerésére a vermet használom a HL helyett, és így megszakítás is bukó, így ebbe a verzióba nem lehetne zenelejátszót tenni, vagyis csak olyat, ami minden 8. frame-ben fut le :D :D
-
ügyes
szólhattál volna, és akkor odaadom az eredeti forrást, az kommentelve van, de még így se emlékszem, hogy működik :-D
-
ügyes
szólhattál volna, és akkor odaadom az eredeti forrást, az kommentelve van, de még így se emlékszem, hogy működik :-D
1,5 óra alatt megoldottam, ha a REXX-em nem hülyül, és nem kerül végtelen ciklusba a JP 0c00dh-n, akkor még hamarabb megvan :D
Kíváncsi vagyok, hogy a legfrissebb ötletem beváltja-e, amit várok tőle, legalább 2 frame mínuszt.
-
ha a REXX-em nem hülyül
Ki az a Rex? A felügyelőt (https://musor.tv/img/normal/5/568/Rex_felugyelo_IX_1_.jpg) ismerem :lol:
-
Kíváncsi vagyok, hogy a legfrissebb ötletem beváltja-e, amit várok tőle, legalább 2 frame mínuszt.
És akkor már csak a zoom-olás kéne megoldani (ami elvileg nem bonyi, csak egy szorzás kéne pluszba, félig működött, de szemét is lett a képen), és mehet a function demo scene-re :-D
Egyébként ez alapján csináltam, a képet is innét szedtem
https://seancode.com/demofx/
de az is lehet, h ez alapján csináltam, már nem emlékszem:
https://github.com/tuupola/esp_effects/blob/master/main/rotozoom.c
És itt az eredeti demo forrása is, ha reprodukálni akarod az eredeti zoom-olást és forgatást, talán ki lehet bogarászni
https://fabiensanglard.net/second_reality/second_reality_parts.php
-
Ki az a Rex? A felügyelőt (https://musor.tv/img/normal/5/568/Rex_felugyelo_IX_1_.jpg) ismerem :lol:
Ha minden igaz, egy IBM szkript nyelv, amit a saját operációs rendszereikben szoktak leginkább használni. Illetve az AmigaOS-ben is volt egy változata AREXX néven.
-
Ezt nem úgy szokták csinálni, hogy van egy forráskép és azt lineárisan és ciklikusan levetítik a célterületre? Ciklikusan abban az értelemben, hogy a forrás valamelyik szélén kilépve a túloldalról, a matematikailag következő mintával folytatódik a vetítés. Lineárisan pedig abban az értelemben, hogy az elforgatás és nagyítás mértékétől függő X és Y lépésközökkel kell végighaladni a forráson.
-
És akkor már csak a zoom-olás kéne megoldani (ami elvileg nem bonyi, csak egy szorzás kéne pluszba, félig működött, de szemét is lett a képen), és mehet a function demo scene-re :-D
Erre is van ötletem, ami nem is lassít sokat, abban bízom, hogy a végleges verzió zoomolással megáll 6 frame-ben.
-
Ezt nem úgy szokták csinálni, hogy van egy forráskép és azt lineárisan és ciklikusan levetítik a célterületre? Ciklikusan abban az értelemben, hogy a forrás valamelyik szélén kilépve a túloldalról, a matematikailag következő mintával folytatódik a vetítés. Lineárisan pedig abban az értelemben, hogy az elforgatás és nagyítás mértékétől függő X és Y lépésközökkel kell végighaladni a forráson.
Bocs, a quote helyett véletlenül a modify-ra böktem,
Én arra gondoltam, hogy csak az x y lépésközt állítom, a többit meg majd a forgatás szabályozza.
Alap ötletem az, hogy már most van egy koordináta táblázat y tengelyre, csinálok egyet az x-re is, és a táblázat tartalmát fogom a zoomoláshoz frissíteni, így minimális plusz utasítással megoldható a növelés, meglátjuk, hogy az elméletem mennyire válik be.
-
Ezt nem úgy szokták csinálni, hogy van egy forráskép és azt lineárisan és ciklikusan levetítik a célterületre? Ciklikusan abban az értelemben, hogy a forrás valamelyik szélén kilépve a túloldalról, a matematikailag következő mintával folytatódik a vetítés. Lineárisan pedig abban az értelemben, hogy az elforgatás és nagyítás mértékétől függő X és Y lépésközökkel kell végighaladni a forráson.
én nem tudom, hogy szokták csinálni, pont azért kerestem rá google-ban arra, hogy "rotazoomer demo effect", ami adta többek között a korábbi hozzászólásban linkelt oldalakat, ugyanazt az algoritmust használom én is, ami ott található.
-
Ki az a Rex? A felügyelőt (https://musor.tv/img/normal/5/568/Rex_felugyelo_IX_1_.jpg) ismerem :lol:
Egy tök jó nyelv, nagyon hasonlít a basicre.
-
Egy tök jó nyelv, nagyon hasonlít a basicre.
És hogyan jön össze Povi Z80 gépi kódú programjával?
-
És hogyan jön össze Povi Z80 gépi kódú programjával?
Az csinálta nekem a forrást a binárisból.
-
A leggyorsabb verzióban van egy kis hiba a belső ciklusban a csökkentés/növelés rossz helyre került, ezt javítottam, az új csatolmány már a javított verziót tartalmazza.
Gratula, jó lett!
-
Ki az a Rex? A felügyelőt (https://musor.tv/img/normal/5/568/Rex_felugyelo_IX_1_.jpg) ismerem :lol:
[attachimg=1]
-
Gratula, jó lett!
Kofi
-
Az csinálta nekem a forrást a binárisból.
Na és azt hogyan?
-
Na és azt hogyan?
Írt REXX-ben egy Z80 disassemblert? Talán.
-
Írt REXX-ben egy Z80 disassemblert? Talán.
Igen, kiegészítve azzal, hogy a kódon "futás" közben generálja a forrást.
-
Igen, kiegészítve azzal, hogy a kódon "futás" közben generálja a forrást.
Hohó! :shock: Az emulátor rész mennyire teljes? Csak Z80-at emulál, vagy hardvert operációs rendszerrel, memória menedzsmenttel és megszakításokkal is?
-
Hohó! :shock: Az emulátor rész mennyire teljes? Csak Z80-at emulál, vagy hardvert operációs rendszerrel, memória menedzsmenttel és megszakításokkal is?
Áááá, sokkal egyszerűbb, halad a kódon, először feloldja az adott pozícióban az utasítást, utána ha JP/JR/CALL volt, akkor elugrik arra a címre, RET esetén meg vissza a visszatérési címre, feltételes JR/JP-nél is elugrik az adott címre, és megjegyzi a visszatérési értéket is, hogy arra is járjon, regiszterekkel, és egyéb utasításokkal nem foglalkozik, így a JP (HL)-lel se tud mit kezdeni, a lényeg az, hogy bejárja az egész utat, ami egy adott indulási ponttól elérhető, természetesen mindent nem talál meg, ezért megadható extra induló cím.
Természetesen a kimenettel lesz még ténykednivaló, de nagyságrendekkel kevesebb, mintha egy disassemblált kódból probálnék forrást készíteni, és nekem kényelmesebb, és gyorsabb is, mint mint a visszafejtő programok használata.
-
Áááá
Akkor ez majnem olyan, mint a Spectrum basic converter, csak nem Spectrumról konvertál?
Valamelyik Enterpressben volt már amúgy szó erről, a Commodore programok átírása kapcsán, mint pl. Rescue from Zylon.
-
Akkor ez majnem olyan, mint a Spectrum basic converter, csak nem Spectrumról konvertál?
Valamelyik Enterpressben volt már amúgy szó erről, a Commodore programok átírása kapcsán, mint pl. Rescue from Zylon.
Nem. Ez Z80-as gépi kódú programokat elemez, végigköveti a vezérlésátadásait és assembly forráskódot állít elő belőle. geco minden bizonnyal ezt használja a ZX Spectrum és Amstrad CPC programok átírásánál. A Commodore programokhoz emlékeim szerint egy másik ilyesféle eszközt készített és használ, ami 6502-es gépi kódot dolgoz fel hasonló módon és generál belőle Z80 assembly forrást.
-
Honnan lehet letölteni ezt a progamot?
-
Honnan lehet letölteni ezt a progamot?
Legfőképp sehonnan :D
Itt ficeg a vinyómon, de ehhez fel kell tenni egy REXX interpretert a gépedre, és nem az a user friendly fajta, a kódban kell megadni pár dolgot.
-
Már gondolkoztam, hogy írni kellene egy ilyen programot Windowsra, ami szépen elnevez minden ugrást. Mint a legtöbb reverse engineering program windowsra. Aztán az ember átnevezi az ugrás cimkéket, ha felismerte, és akkor a program is mindenütt átírja.
Egy dolgot nagyon nehéz kezelni, ha a gépi kód átírja saját magát. Erre egy példa:
cimke-01: LD HL, 01532h (ez egy többször felhasználható rutin aminek a paraméterét itt adjuk meg)
...
RET
...
LD HL, 02340h
LD (cimke-01),HL
CALL cimke-01
Ez a x86-os világban tiltott dolog. A Z80-nál pedig előszeretettel használják.
-
Ez a x86-os világban tiltott dolog. A Z80-nál pedig előszeretettel használják.
Nem lenne pontosabb azt állítani, hogy azokon a Neumann processzor architektúrákon, ahol (utasítás)gyorsítótárazás történik általában* nem támogatott**, máshol általában igen?
* Érdekes módon az Apollo CPU-nál (a 68060 FPGA továbbfejlesztése lelkes amatőrök által) ezt emlékeim szerint megoldották. A mikrovezérlőknél, ahol az adatok és programkód címtere teljesen elválasztott, pedig elvi lehetőség sincs a megvalósításra.
** Szerintem semmi sem akadályozza meg ilyen kód írását, csak semmi hatással sem lesz a futásra.
-
Hogy is volt. x86-nál védett módban az operációs renszdszer a valamekkora méretű virtuális memóriaszeleteket flag bittel jelöli, hogy az utasításmemória, nem adatmemória. Emiatt nem módosítható, és nem tölthető be adatként sem, mert lineáris a memóramodel (kétszer nem fordul elő egymás után). Olyat tehet hogy átmásolja vagy kicsomagolja magát a program az adatmemóriába, de a Data-Execution-Prevention (DEP) miatt nem hajthatja végre. (Azt hiszem az WinXP után ezt már default be is volt állítva).
Mindez arra van kitalálva, hogy a rosszindulatú programok ne tudják magukat kicsomagolni, és aztán ezt a kicsomagolt kódot végrehajtani. A vírusellenőrzés régen mintákat keresett a fájlokban, amit a becsomagolás elfedett, így túl későn lett felismerve. Ma már sandboxban engedik tevékenykedni a programot, és amennyiben kicsomagolás után felismeri a rosszindulatú kódot, akkor a gépen el sem indítja.
Megjegyzem, nekem nem létezik más CPU csak a x86/64 és a Z80 :D
-
https://en.wikipedia.org/wiki/W%5EX
Közben megtaláltam ezt a cikket. Furcsa, olyan mintha a google monitorozná, hogy miket csinálok, és úgy dob utána videókat, mintha segíteni akarna.