Új hozzászólás Aktív témák

• #9 And veterán k.t.a. #8

  Új Válasz 2006-04-28 11:18:57 #9

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  Privát üzenet küldése

  

  And

  veterán

  válasz k.t.a. #8 üzenetére

  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]

• #6 And veterán k.t.a. #5

  Új Válasz 2006-04-27 22:00:22 #6

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  Privát üzenet küldése

  

  And

  veterán

  válasz k.t.a. #5 üzenetére

  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 .

• #4 And veterán Sytex #1

  Új Válasz 2006-04-27 21:30:38 #4

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  Privát üzenet küldése

  

  And

  veterán

  válasz Sytex #1 üzenetére

  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 .

Új hozzászólás Aktív témák