Inkabb ide irok SD ugyben
Most komolyan elkezdtem gondolkodni ... Van ugye az otlet, hogy a cartridge helyere, azaz kb memoriakent lehet cimezni a dolgokat, nem IN/OUT. Ez szep, sot tobb szempontbol egyszerubb is, amde a komoly gond az, hogy kene dual port RAM hozza, hogy az MCU es az EP egyszerre matasson a RAM-ban, vagy maskepp nem tudom hogy lehetne
Pedig az otlet amugy jo, ui I/O portokon at vannak azert gondok. Ha pillanatra az idozitest, stb el is felejtjuk: attol nem tekinthetunk el, hogy azert azt szinte lehetetlen megoldani, hogy az SD kartya altal adott adatokat direktben az MCU "tovabbitsa" az EP fele, mert tutira nem lehet osszehozni a hozzaferes utemet pontosan. Pedig az MCU amugy hw-bol kepes SPI-ra stb, szoval jo lenne. Marad tehat a megoldas, hogy az MCU szepen lebeszeli az SD kartyaval, igy az adatforras vagy a cel (read/write) az MCU sajat SRAM-ja. Ezzel nincs is gond, mert egy block belefer (ATmega8-nak pl 1K SRAM-ja van a belesejeben). Viszont igy az egesz igencsak elbonyolitodik, ui pl block irasnal elobb az EP kiirja az "MCU-ba", ha az megvan, akkor o meg az SD kartyara. Olvasasnal nyilvan logikusan ugyanigy, csak forditva. Tenyleg szep lenne a memorias otlet, azaz az MCU irja bele az EP-vel kozosen hasznalt RAM teruletre, akkor nincs buffereles, meg tokolodes hogy ket ponton is figyelni kell mikor megy/jon az adat, meg a varakozas az "atjatszasok" eseten, stb. Neztem dual port SRAM-ot, haaat nem olcso kifejezetten, "ezerlabu" IC (veletlenul se DIP persze), es nem is igazan latom, hogy konnyu lenne ilyet szerezni.
Szoval lehet marad megis az IO portos ... A fenti problemakkal egyutt. Otletem a kovetkezo (legyszi javits ki Zozo, ha valahol tevednek!). Szoval ha az IORQ aktiv (low active, de most ettol tekintsunk el, csak aktivot irok, ami ebben az esetben persze logikai nulla amugy) es mellette az RD vagy a WR is az (lasd a low active kitetelt, tobbet nem irom le), illetve ha a cimbusz A7-A1 labai a megfeleloek nekunk (A0 kell, mert ket portot hasznalunk), akkor "nekunk szol" a dolog. Ez igy korrekt? Csak az IORQ-t nezni nem eleg, mert az pl ha jol remlik az M1-el egyutt pl INT ACK, szoval tok mas. Nu, ebben az esetben generalunk egy select jelect ebbol magunknak, es ezt azonnal fel is hasznaljuk, hogy egy flip-flop segitsegevel WAIT jelet generaljunk a Z80 fele, kozben viszont megy az MCU fele mint INT0, azaz ott egy interrupt lesz belole, amire AVR pl eleg gyorsan reagal. Namost, ez arra jo, hogy a WAIT hw-bol beall (MCU nelkul) igy tutira nem csuszok le a valaszrol a Z80 fele. Persze, tudom hogy WAIT-nal azert vegtelensegig nem lehet huzni, mert addig pl nincs memoria frissites, de sokaig nem is kell. Ugynais az MCU interrupt kezeloje csak annyit csinal voltakeppen hogy megnezi az A0-t (melyik port) es hogy RD vagy WR. Ezek alapjan olvas/ir byte-ot EP busz felol/fele a sajat SRAM-jaba/bol. Ezek utan vege is az interrupt-nak elotte meg az MCU szol a flip-flopnak h engedje mar el a WAIT-et. Igy a WAIT max "biztonsagi tartalak", talan meg beleferne anelkul is nem turbos gepen, de ki tudja ...
Ezek utan az MCU foprogramja csinal mindent kvazi async modon, pl sd block write eseten SRAM-jaban pufferelt blockot szepen kiirja, ha kesz beallit az SRAM-jaban egy valtozot, hogy ready, ennyi. Az mar az EP oldalrol feladat, hogy varsz a muvelet vegeig, az emlitett MCU interrupt handleren at kiolvashato EP altal h kesz van-e. Egesz pontosan, ha az A0=0, akkor WR-re az a command register, RD-re a statusz (kesz van-e a muvelet). A0=1 eseten az adatregiszterrol beszelunk, RD eseten olvasod az MCU SRAM-jat szepen sorban, WR eseten irod (azaz pl sd block write elott adatregiszteren at feltoltesz 512 byte-ot MCU-ba plusz a block szamat, aztan mondod a command registeren az MCU-nak hogy legyszi ird mar ki SD-re a buffert, utana EP-n meg varsz a statusz regisztert nezve, hogy vege legyen a muveletnek. Block readre: adatregiszteren kiirod a block szamat csak, command regiszteren megadod az sd block read numerikus parancskodjat, status regiszteren nezed mikor vege, utana 512-szer olvasod az adatregisztert, es ott a block-od)
Na, nagy vonalakban, a reszleteket mellozve, kb idaig jutottam a gondolatmenetemben, de mivel Z80-hoz emlitesre melto hw-t meg nem epitettem, ez egyaltalan nem tuti, hogy jo igy. A fenti leiras alapjan ez lassunak tunik, de valojaban nem veszes: az MCU hw szinten SPI-t nyom, amit max az orajele felevel kepes, ha 8MHz-es clockot feltetelezunk neki, akkor tehat az elemleti nyers sebesseg az 4mbit/sec az avr es az sd kartya kozott (nyilvan ez hulyseg, mert 512 byte-ra ok, de setup time, stb is van), ami 500kbyte/sec lenne (mint irtam ez persze egy teljesen mesterkelt adat). Tehat a szuk keresztmetszet biztosan az lesz, hogy I/O portokon at az MCU buffere es az EP kozott at kell vinni az adatokat (melleseleg amugy a modern SD kartyak kepesek 4MHz-re rohogve, de azert hozzateszem h a szabvany azt mondja hogy az SD inicializalasa soran csupan 400KHz-el szabad vele SPI-t jatszani mert az garantalt, amit minden oskovulet kartya ismer, modern SD kartyak 20MHz vagy folotte is mennenek, azt mar az AVR nem fogja tudni viszont).
Ez a bonyolultsag az oka amugy annak, hogy mar azon is gondolkoztam, hogy sima 74xx IC-kbol kene epiteni egy SPI interface-t. Ha shift registereket hasznalsz, stb, akkor egesz gyors lenne, viszont "kozvetlen" vezerles van a kezedben SPI szinten (megis parhuzamos lesz!) nincs puffereles, miegymas. Csakhat az hw szinten azert kisse nagyobb alkatresz temeto lenne ...