- Karácsonyfaként világíthat a Thermaltake új CPU-hűtője
- Az USA vizsgálja a RISC-V kínai terjedésének kockázatát
- Kicsit extrémre sikerült a Hyte belépője a készre szerelt vízhűtések világába
- Egészen nagy teljesítményspektrumon fedné le a mobil piacot az AMD
- Kihívás a középkategóriában: teszten a Radeon RX 7600 XT
Hirdetés
-
Karácsonyfaként világíthat a Thermaltake új CPU-hűtője
ph Az ASTRIA 600 ARGB ráadásul a hűtési teljesítmény szempontjából sem szégyenkezhet.
-
Lenovo Essential Wireless Combo
lo Lehet-e egy billentyűzet karcsú, elegáns és különleges? A Lenovo bebizonyította, hogy igen, de bosszantó is :)
-
Xbox Game Pass [2024] - A májusi lista
gp Az elkövetkező időszakban többek között megkapjuk a Kona II Brume című játékot.
Új hozzászólás Aktív témák
-
And
veterán
Hi! A 27128-as eprom 128Kbit méretű, 16K * 8bit szervezésű, ezért elegendő neki a 14 Address-bemenet. A bin-méret is 16 kByte kell legyen a full tartalomhoz (a .bin méretéből egyébként nem biztos, hogy következtetni lehet a ténylegesen hasznos tartalomra, mert az a teljes image -et tartalmazhatja. De ez most nem tartozik ide). Az alapkérdéshez: szerintem működhet az A14-es vezeték kapcsolgatása, ha csak méretben nagyobb epromot használnál az eredeti helyett (hasonló időzítés, egyebek). A 27256-os eprom lábkiosztása kicsit más (utóbbinál a /P -vezeték helyén van az A14), de ahogy nézem, csak programozáskor / égetéskor van különbség a kezelésében. Olvasáskor a 27256 ugyanúgy működik, mint a 27128-as, a többi láb kiosztása is megegyezik a 128-as pinoutjával.
Ez a kérdés szvsz. simán elfért volna a HE-topikban, valszeg választ is gyorsabban kaptál volna
. -
And
veterán
Jobban belegondolva lehet, hogy igazad van. De alapesetben a felső területen elhelyezkedő program ''nem tudja'', hogy ő most egy nagyobb kapacitású epromban van, és nem is hivatkozik 14 bitesnél nagyobb abszolút címre, hiszen eredetileg sem akkora tárba tervezték. A kézzel kapcsolt tizenötödik addressbit létéről egyszerűen nem vesz tudomást a program, ''alatta'' pedig minden marad a régiben (hiába hivatkozik pl. az új program a 0000h címre, a hardveres címkapcsolás miatt mindenképp 4000h lesz, azaz fizikailag képtelen lesz elérni az alsó területen lévő programtárat, és benne a ''régi'' programot).
Ha másképp nem megy, még midig be lehet tenni egy egyszerű 28-lábú foglalatot vagy egy karos textool-t, és meg van oldva
. -
And
veterán
De mit jelent az, hogy ''belülről nézzük''? A programot nem az eprom futtatja, ha pedig azt egy külső egység címzi, az nem fogja tudni, hogy valójában honnan olvas. Az a lényeg, hogy nem tudjuk belülről nézni a tárat, a címzést mindig egy külső egység adja, 14 biten. A 15. címbit (A14) létezéséről nem is tud, hiszen arra eredetileg sem készítették fel.
Írtam, hogy akár igazad is lehet, de ez a futtatástól, végrehajtási módtól függ. Ha a proc v. adatfeldolgozó egység először beolvasná az egész eprom tartalmát egy ram-ba, majd a kódot onnan futtatná, akkor például lehetne ilyen gond [Mod.: vagy akkor sem..
]. Csakhogy ennek szvsz. igen kicsi a valószínűsége (a kvarcablakos epromban történő kódtárolás nyilván nem mai technika, így nyugodtan feltételezhetjük, hogy nincs ennyi ram az áramkörben). Ha viszont a proc csak utasításonként olvassa az epromot - netán az abban tárolt adatokat nem is utasításokként kezeli, csak valamilyen paraméterekként -, akkor szerintem a kézi címváltás / lapozás nem lehet probléma.
[Szerkesztve]
.
.
]. Csakhogy ennek szvsz. igen kicsi a valószínűsége (a kvarcablakos epromban történő kódtárolás nyilván nem mai technika, így nyugodtan feltételezhetjük, hogy nincs ennyi ram az áramkörben). Ha viszont a proc csak utasításonként olvassa az epromot - netán az abban tárolt adatokat nem is utasításokként kezeli, csak valamilyen paraméterekként -, akkor szerintem a kézi címváltás / lapozás nem lehet probléma.