Engem érdekelne, hogy szerinted mikor indokolt és mikor indokolatlan a 16 bites I/O címzés, és mik a káros következmények?
Indokolatlan es rossz tervezesre vall (vagy legalabbis minimal design / olcsosag mindennek elott feeling), ha 256 port toredeke is eleg (meg gondolva az esetleges kesobbi bovitesre is amugy), megis 16 bites I/O cimeket hasznalnak, szerintem legalabbis. Abban nem vagyok biztos, de mintha a Zilog se ajanlana a 16 bites I/O cimzest Z80-on, en a gyarto velemenyeben meg csak biznek. Karos kovetkezmenyek kozott emlitendo, hogy bonyolultabb: ha konstans modon adod meg az I/O portot - pl OUT (0xB0),... - akkor ha jol emlekszem a cimbusz felso 8 bitjen az A register erteke lesz, ezt akkor kulon be kell allitani. Masreszt viszont erdekes es frappans trukk, ha van olyan helyzet 16 bites I/O cimzes eseten, ahol mondjuk a kiirni kivant adat egyben az I/O cim felso 8 bitje is, ilyet mar lattam, igaz nem EP-n. Ez pl szamomra az ugyes trukk kategoria
Az OUT (C), ... jellegu megoldasnal nyilvan a B register is feltoltendo, es gyakorlatilag majd a BC reg.par erteke jelenik meg a cimbuszon. Itt is igaz, hogy egy tovabbi registert kell kulon tolteni, masra nem tudod hasznalni (pedig lehet, hogy kene inkabb masra). Vegrehajtasi idoben is lassabb nyilvan, ha figyelembe veszed, hogy 16 bitnyi cimet kell prezentalni/elokesziteni 8 bit helyett (plusz tovabbi veszteseg, ha emiatt egy regiszterrol le kell mondanod pl egy performancia kritikus ciklus kozepen - amit masra hasznalhatnal -, igy a kod tobbi resze is csak lassab valtozatban valosithato meg). Tovabbi problema, hogy egyes opcode-ok is kvazi hasznalhatatlanok vagy legalabbis kenyelmetlenek, mivel a B-t is allitjak a peldanak okaert, igy vegrehajtasuk utan "elrontjak" a B-t, a 16 bites cimzes eseten ujra be kell allitani mindig. Gondolok itt az INI, INIR es ilyesmikre. Jo pelda erre, ha az ember megnezi a SymbOS forraskodjat (amikor meg en probaltam sajat erobol portolni EP-re disasm alapjan kb "binaris memdump patching" nagyon ronda szinten hehe), talan CPC-n volt ilyen, igy persze lassabb is, mint lehetne ...
EP eseten ugye problema, hogy valojaban 16 bites I/O cimzes nincs is, csak 14 bites
Mivel a Dave - ugy tunik - az I/O cimeknel is elvegzi a "dolgat". Ezt persze lehet a Dave bug-janak is tekineni (eleg lenne memoriahozzaferes eseten csinalnia), bar hatareset, mivel elvileg nem is eroltettek gondolom a tervezok a 16 bites I/O cimzest EP-n, lehet, ezert nem is foglalkoztak a kerdessel, es nem zavarta oket ez tulsagosan.
Ettol persze igaz (nem vitatom), hogy van amikor jol johet! Viszont eroltetni hiba, hogy mindenaron mindenhol ez legyen. Peldaul a SID dolgok kapcsan nekem tetszett az a megoldas is, ahol csak egyetlen portot foglalna peldaul az EP-n altalaban szokasos 8 bites I/O cimtartomanybol, es a SID register kivalasztasa a felso byte also 5 bitje altal tortenik (igy itt a Dave "bezavarasa" sem gond). Nyilvan nem fekete-feher a dolog!