Erdekes megoldas, de ha atalakitana, hogy a 32 kB eprom helyett egy 16 kB-os eprom legyen es a masik 16 kB-ra berakna egy double ported ram chipet, akkor a hardveres levalasztas miatt megoldodna a busz versenyhelyzete es jelentosen megnone a savszelesseg a ket mikrovezerlo kozott.
Szoftverileg en forditva ulnek a lora, nem a gameboy-t szivatnam a netes adatok kezelesevel, hanem az esp32-on futna minden es mar csak a megjelenitendo kep (tile data es map frissitesek) menne at a gameboy-ra, mig visszafele a gombnyomasok mennenek egy byte-ban. Ezzel megoldhato lenne hogy az eredeti gep csak egyfajta kvazi grafikus konzolkent funkcionaljon. Az esp32-es oldalan hianyzo labszamot pedig egy spi-s i/o extenderrel lehetne feloldani, ami hagyna eleg labat a soros konzol kivezetesere is, akar usb-n is. A kartyacsatlakozon levo extra hangcsatornat pedig be lehetne kotni egy rendes DA konverterre a mikrovezerlo oldalan. A fenti elrendezesben akar arduino-s kornyezetben is lehetne programozni az esp32-t (akar usb-n at is), mig a gameboy egy nagyjabol fixnek tekintheto shared memory-s kommunikaciot hasznalo konzol szoftvert futtatna eprom-bol.
ps: A bus contention brownout-ok ellen a mostani konfiguraciojaban felrakhatott volna egy sor vedo soros ellenallast, amilyneket a zx81-eseknel is hasznaltak bus override-hoz, ez egy nem szep, de nagyon jol mukodo hack.
Informatika és tudomány
