Enterprise Forever
:HUN => Hardver => Topic started by: endi on 2013.April.17. 10:59:31
-
Két dolog régóta érdekel, amit emuval nem tudok megnézni.
1: IM2 esetén egyes EP-n egyik IM2 cím byte-ra valami random értéket adnak. Ilyen volt az én EP-m is, ezért az IM2-t használó programok nem működtek nálam (néhány átirat volt ilyen).
2: egyik demómban pixelenkénti vízszintes scrollt csináltam, de persze egy hw trükkel, ami valszeg gányolás és nem lehet semmire se használni, itt is csak 1 sorra működött és az alatta lévő pár sort "elgörbítette". De ki tudja, lehet hogy valamit lehet kezdeni vele. :)
-
1) Alap EP-n az üres adatbusznak nincs meghatározott értéke, ezért tök véletlenszerű mi látszik rajta, az alkatrészek szórásán múlik. Turbós gépeken általában jobban előjön.
Ez azoknál az IM2-es programoknál okoz gondot, ahol nincs a teljes 256 bájtos táblázat kitöltve.
Ugyanezen okból az EXOS 2.3 RAM tesztje érzékelhet fantom hibás RAM szegmenseket.
A MICROTEAM és Mészáros féle bővítéseken általában van felhúzó ellenállás rakva az adatbuszra, ami biztosítja a nem használt állapotban a bitek 1-re húzását.
2) gyanítom, hogy a szinkronjellel csinált valamit, ami megbolondította a hagyományos CRT működését.
-
1) Alap EP-n az üres adatbusznak nincs meghatározott értéke, ezért tök véletlenszerű mi látszik rajta, az alkatrészek szórásán múlik. Turbós gépeken általában jobban előjön.
Ez azoknál az IM2-es programoknál okoz gondot, ahol nincs a teljes 256 bájtos táblázat kitöltve.
Jah, ha jol tudom ezzel trukkoznek Speccy-n is: ott ugye fixen ROM van (marmint 48-as gepen, ahol lapozhato a memoria, az passz) alul, tehat nem tudsz sajat int handlert csinalni a ROM-ot teljesen kikerulve. Ott olvastam olyanrol, hogy IM2 modot allitnak be, az adatbuszos problemat pedig kicselezik azzal, hogy 256 byte-nyi memoriaterulet barmelyik resze "fel van keszitve" h esetleg oda kerul a vezerles. Vagy hasonlo, nem tudom pontosan, speccy-s dolgokban vagyok csak igazan amator ... Ha jol tudom, akkor az I regiszter viszont megadja a memoriacim felso 8 bitjet, csak az also 8-al van gond, mert ugye az jonne az adatbuszrol IM2 modban. De javitsatok ki, ha tevednek ...
-
Spectrumon azt szokták trükközni, hogy odaállítják az I-t, ahol sok FFh van a Romban, így FFFFh lesz a megszakítási cím, ide raknak JP-t aminek a ROM első bájtjai lesznek a paramétere.
A gond a 128-assal jött, ahol a korábban üres területek fel lettek használva, így eltűntek az eddig felhasznált FF-ek. Ezért volt egy csomó játékkal inkompatibilis a Spectrum 128.
Későbbi modellekbe nagyobb ROM-ot rakott az Amstrad, amiben már egy az egyben benne volt az eredeti 48-as ROM, és ezt használja 48-as módban, megoldva ezt a gondot.
-
Spectrumon azt szokták trükközni, hogy odaállítják az I-t, ahol sok FFh van a Romban, így FFFFh lesz a megszakítási cím, ide raknak JP-t aminek a ROM első bájtjai lesznek a paramétere.
A gond a 128-assal jött, ahol a korábban üres területek fel lettek használva, így eltűntek az eddig felhasznált FF-ek. Ezért volt egy csomó játékkal inkompatibilis a Spectrum 128.
Későbbi modellekbe nagyobb ROM-ot rakott az Amstrad, amiben már egy az egyben benne volt az eredeti 48-as ROM, és ezt használja 48-as módban, megoldva ezt a gondot.
Mondjuk ehhez kepest a primo ROM-jat disasm-olgatva szerencsesebb megoldas, hogy reset-kor a RAM-ba rak ugrasi cimet, es mindig azt hasznalja aztan (oda ugrik INT-kor), igy akar user is atirhatja, ha nagyon akarja valami miatt :) Mindazonaltal amikor eloszor olvastam a fenti spectrumos trukkrol (amit azota felig el is felejtettem mar) nagyon tetszett, hogy mindent megoldanak valahogy azert okos emberek, akkor is, ha a keszitok nem gondoltak ra, hogy megoldhato legyen :)
Ja es, btw felhuzo ellenallasok nelkuli adatbusz: asszem vmi commodore PET-eknel volt anno meg problem, hogy van kapacitasa a buszrendszernek. Ha kiirsz egy byte-ot egy nem letezo cimre, majd visszaolvasod azonnal, megvan a byte, mivel az adatbusz "tarolja" kapacitasa okan :) Ez allitolag tenyleg komoly fejtores volt anno, a RAM meret detektalasnal, bar nem teljesen ertem, mert ugye a visszaolvasashoz olvastak a szukseges opcode-ot is, tehat az adatbusz elvileg mar reg nem uazt tartalmazta utoljara, de azert erdekes. Tanulsag: digitalis technikaban nem szerencses ha valamit "lebegni" hagyunk ...
Olyan fura trukkokrol nem is beszelve, hogy nehany emulatorgyulolo programozo (EP-n/Speccyn nem tudom van-e ilyen, C64-en nem is ritka ...) igen durva trukkot eszelt ki emulator tesztelesere, pl a fentihez hasonlo az aramkorok nem-digitalis jelleget probalja tesztelni, ezzel lefulelve ha valami emulatoron probalkozik es nem valodi gepen. Nem tudom ez miert jo valakinek, csak gyanitom, hogy pl programjaiknak visszafejteset akarjak nehezebbe tenni stb, ahol az emulator persze nagy segitseg lehet, foleg ha monitor, miegymas is van benne ugye ...
-
1) Alap EP-n az üres adatbusznak nincs meghatározott értéke, ezért tök véletlenszerű mi látszik rajta, az alkatrészek szórásán múlik. Turbós gépeken általában jobban előjön.
Ez azoknál az IM2-es programoknál okoz gondot, ahol nincs a teljes 256 bájtos táblázat kitöltve.
Ugyanezen okból az EXOS 2.3 RAM tesztje érzékelhet fantom hibás RAM szegmenseket.
A MICROTEAM és Mészáros féle bővítéseken általában van felhúzó ellenállás rakva az adatbuszra, ami biztosítja a nem használt állapotban a bitek 1-re húzását.
2) gyanítom, hogy a szinkronjellel csinált valamit, ami megbolondította a hagyományos CRT működését.
Na de ezek az említett átiratok mégiscsak bizonyos gépeken fagytak, nem? Csak nem terjedtek volna el ha úgy általában minden gépen fagynak. Azt értem hogy nem az IM2 használatával volt a baj, hanem a rossz használatával, azaz fel kellett volna tölteni a táblázatot rendesen.
Tehát mégiscsak léteznek "rossz" EP-k, az enyém ilyen volt.
De még érdekesebb kérdés, hogy ha bármiféle zaj jön innen, azt nagyon szeretném látni. :) Nem tudna valaki egy igazi gépen csinálni egy videót vagy egy képet amin látható ez a zaj, pl. egy basic program kiírja amit leolvas erről a portról (vagy mi ez). De még érdekesebb lenne hangot kiadni asm programmal. :)
A demóm: valaki megnézheté azért! Hátha használható valamire a trükk. Az Orkmega3-ban a DEMO3H.DAT-ot kell futtatni.
-
A buborékhalas részen van, és csak real gépen látszik?
-
A buborékhalas részen van, és csak real gépen látszik?
igen, a scrollozódó szöveg ha felül van akkor a teteje kicsit eltolódik
-
amúgy a topik címét módosítani kéne: Amit (még) csak az igazi hw tud
:)
-
Erre gondoltál?
>CC80 FF 0E 0B 35 5C 9E 00 00
>CC88 40 FF 00 00 00 00 00 00
>CC90 FF 00 64 64 B0 9E 00 00
>CC98 40 FF 00 00 00 00 00 00
>CCA0 FF 0E 0B 35 04 9F 00 00
>CCA8 40 FF 00 00 00 00 00 00
Itt érdekes módon a 202. sorban egy szinkron sor van, amúgy a képernyő 255 sorból áll, és az LPT vége is érdekes, nem megszokott szinkron rész.
és itt az LPT vége:
>CFE0 FF 0E 0B 35 58 93 00 00
>CFE8 C9 FF 00 00 00 00 00 00
>CFF0 F2 12 3F 00 00 00 00 00
>CFF8 19 00 00 00 00 00 00 00
>D000 FC 10 00 3F 00 00 00 00
>D008 99 00 00 00 00 00 00 00
>D010 DA 93 3F 00 00 00 00 00
>D018 99 00 00 00 00 00 00 00
Sajnos nem értek hozzá, de remélem István megszakérti :) , ezek tűntek fel az LPT-ben.
Annyit látok még, hogy CC90-es részen a bal margó ha 16-ra van állítva, akor a jobb margó 16-ról felmegy 1D-re, majd vissza, és utána a bal margó 64-re áll, a jobb felmegy 64-ről 6B-re, majd vissza, és kezdődik minden előlröl, közben LD1 módosul, aminek nem tudom, van-e hatása sync módban.
-
húú hát én biztos gondoltam valamire akkor amikor csináltam, de most már nem gondolok semmire :D
nem emlékszem már erre...
-
Annyit látok még, hogy CC90-es részen a bal margó ha 16-ra van állítva, akor a jobb margó 16-ról felmegy 1D-re, majd vissza, és utána a bal margó 64-re áll, a jobb felmegy 64-ről 6B-re, majd vissza, és kezdődik minden előlröl, közben LD1 módosul, aminek nem tudom, van-e hatása sync módban.
A monitor a rövid (néhány karakteres) szinkron jelet vízszintes szinkronként értelmezi, ezért csúsznak el az utána következő sorok, de ennek a mértéke monitor függő. Az LD1-nek elvileg nem kéne, hogy legyen hatása, de ezt nem ellenőriztem valódi gépen.
-
hm akkor ez bukta?
-
Ezt (http://enterpriseforever.com/hardver/nick/msg34003/#msg34003) a - lebegő adatbusz használatával a vízszintes pozíciót olvasó - programot talán itt is érdemes említeni, mert jelenleg csak igazi gépen fut hibátlanul (ep128emu-n egy Lua script javítja).
-
ide illik: a magnó remote :)
van róla topik is :)
-
A TOGGLE SPEAKER és talán a SET TAPE LEVEL, SET TAPE SOUND sem értelmezhető emulátoron. Vagy nem tudom, a magnós mentés milyen, mert nem azt használom.
Elvileg a PRINTER: eszköz sem csinál semmit emulátoron, a LLIST-nek, LPRINT-nek sincs külön értelme, vagy nem tudom pontosan.
Egy ötlet: A TOGGLE REM1 és REM2 (F4 funkcióbillentyű) helyére be lehetne tenni emulátoron alapból valami más, gyakran használt parancsot. De kinek mi gyakori? :D
-
Elvileg a PRINTER: eszköz sem csinál semmit emulátoron, a LLIST-nek, LPRINT-nek sincs külön értelme, vagy nem tudom pontosan.
Erre raktam be LUA scriptet, amivel fájlba lehet menteni ami a nyomtatóra menne.
-
az jutott eszembe, hogy valaki nem kísérletezik EP-vel (azaz nem emuval), hogy esetleg lehetnek nem dokumentált, vagy fel nem fedezett dolgok?
vagy ezt már aki a kapcsolási rajzot átnézte (van ilyen?), tudja, hogy nem lehetnek?
portokat írogatni, nem használt biteket próbálgatni... :)
-
az jutott eszembe, hogy valaki nem kísérletezik EP-vel (azaz nem emuval), hogy esetleg lehetnek nem dokumentált, vagy fel nem fedezett dolgok?
vagy ezt már aki a kapcsolási rajzot átnézte (van ilyen?), tudja, hogy nem lehetnek?
portokat írogatni, nem használt biteket próbálgatni... :)
Szerintem István megtalált mindent az EP128emu fejlesztése közben, és utána a Nick portok olvasását.
-
Ez a kép talán beleillik ebbe a topikba. Egyszer csak így indult el az EP, pedig semmiféle memóriabővítés nincs benne. Nem kísérletezgettem, hogy mit csinál ilyenkor, nehogy baja legyen, inkább kikapcs-bekapcs, és visszatért a megszokott 131072 bájt. Ilyet az Emu nem tud. :)
-
Egyszer csak így indult el az EP, pedig semmiféle memóriabővítés nincs benne.
Egyszer nekem is volt ilyen, minimum 20 éve, hogy valami not working bájtokat írt ki induláskor, következő induláskor már újra jó volt. Nem tudom, összefügg-e, előtte leesett a szekrényről a gép. De akkor meg maradandó károsodása lenne, szóval nem biztos, hogy összefügg.
-
A SPOKE 255,16380,0 elrontja a rendszert (itt már volt erről szó) (https://enterpriseforever.com/egyeb-temak/minden-egyeb/msg71917/#msg71917). Ilyenkor egy TEXT után csak a reset segít, de az sem egyből. Miután lement a memóriateszt, a legvégén elakad. Ennél az elakadásnál igazi EP-n a képernyő elkezd csíkozódni, emulátoron nincs csíkozódás. Ha jól emlékszem, a FATAL WP ERROR (nem tudom, hogyan lehet előidézni) is ilyen, emulátoron nem csíkozódik a kép, igazi gépen igen. Talán az INTERNAL CHECKSUM ERROR is ilyen, amit egyébként fogalmam sincs, hogyan idéztem elő anno igazi gépen, mert a ROM-ban nem történt változtatás, és ez csak egyszeri hiba volt. Mellesleg érdekesek is ezek a nem basic-ből megjelenő hibaüzenetek, amik a status sorban jelennek meg, és igazi gépen csikozódik a képernyő. Nem tudom, hány ilyen hibaüzenet létezik még, és hogyan idézhetők elő. A Load error - Re-starting system üzenetről sem írnak sehol semmit, ha jól tudom - ez a Cassette CRC error extrémebb változata lehet.
"Amit csak az igazi hw tud" témához kapcsolódik, hogy a Soundtracker 2.1 programban, ha a digi hangminta a legfelső oktávban nagyon magas hangot szólaltatott meg, az persze hamisan szólt igazi gépen, míg emulátorban ott az eggyel lejjebbi hang szól helyette.
Ebbe a tokiba tartozik még az is, hogy a Nick melegedésével egyes gépeken pixelhibák jelennek meg. Erről külön topikban volt részletesen szó.
-
A Haluska féle HWP ?
Másolás elleni védelem?