Enterprise Forever
:HUN => Hardver => Topic started by: Zozosoft on 2013.May.16. 17:07:46
-
Ezt az SD kártyát annyit emlegetted már...
Tudsz valami értelmes Z80 által is kezelhető megoldást rá? Mert önmagában valami rémálom :-(
Én olyat szeretnék, hogy x portra kiküldöm, hogy az n. szektort kérem, és utána az y porton beolvasható 512 bájt.
Innentől max 10 perc alatt menne vinyóként az EXDOS-sal! :-)
-
Ezt az SD kártyát annyit emlegetted már...
Tudsz valami értelmes Z80 által is kezelhető megoldást rá? Mert önmagában valami rémálom :-(
Én olyat szeretnék, hogy x portra kiküldöm, hogy az n. szektort kérem, és utána az y porton beolvasható 512 bájt.
Innentől max 10 perc alatt menne vinyóként az EXDOS-sal! :-)
Hat egy command-ot kell kikuldeni konkretan, par byte. Ez nem is baj. A baj az az, hogy SPI buszon megy, ami soros. Ez magaban nem gond meg, mivel 20MHz kornyeken siman megy, sot a gyorsabb kartyak (a class megjeloles a kartyakon) meg gyorsabban is. Viszont ezt ugye software-bol Z80-on megcsinalni ... nem lesz gyors :) Eppen azon elmelkedek egy ideje mar, hogy lehetne csinalni SPI-ra soros/parhuzamos atalakitot, hogy hw-bol menjen. Sajnos ilyet "keszen" nem talaltam :( Jelenleg arra jutottam hogy kell egy parallel-to-serial es egy serial-to-parallel shift regiszter (74-es IC-k kozott van ilyen ami meg pufferelt is, meg minden ami kell), illetve vmi, ami elallitja a CLK-t es 8 bit utan leall. Par IC-bol tuti ossze lehetne dobni, csak epp sajnalom hogy nincs vmi "SPI interface" jellegu mar kesz IC.
-
A baj az az, hogy SPI buszon megy, ami soros.
Na ez az :-(
epp sajnalom hogy nincs vmi "SPI interface" jellegu mar kesz IC.
Ha jól tippelem valami PIC-es cucc kéne.
-
Na ez az :-(
Ha jól tippelem valami PIC-es cucc kéne.
En mondjuk AVR-t tennek, nem PIC-et de ja :) Csak epp motoszkal a kisordog bennem, hogy MCU nelkul megcsinalni, "mezei" 74xx IC-kbol :) Bar lehet, hogy felesleges a mazoista hozzaallasom.
Masik ami eszembe jutott: USB mass storage protocol :) Elonye, hogy utana pendrive, telefon, digitalis fenykepezogep, illetve barmi ami implementalja az USB storage "szabvanyt" kezelheto lenne. Hatranya: USB az kb lehetetlen, hogy "hobbybol" megoldod, ahhoz kepest a SPI az gyerekjatek. Viszont vannak cel IC-k amit erre hegyeztek ki, pl a FT232 vagy mi a neve, az epp sima sorost csinal belole (mondjuk azt meg vmi SIO-ra kene kotni ugy es lassu is lesz) vagy letezik/letezhet mas hasonlo IC parhuzamos interface-szel. Egyetlen baja, hogy imho azok nem host USB-k, nekunk meg az kene ehhez ... Lehet az SD kartya meg mindig egyszerubb. Vagy kell egy USB-t is tudo MCU, ami megy host (de legalabb OTG?) modban, mondjuk ez passz, hogy kisebbek kozott van-e ilyen egyaltalan, csak az ezerlabu szornyeknel lattam, ott viszont mar ethernet is van rajta neha pl.
-
Nah, talaltam is valami gyanus (?) kinai (?) IC-t, a neve, CH375. Egyetlen IC, alig kell kore par kondi, stb, es 8 bites parhuzamos adatbuszon ket I/O portot felhasznalva tud host-kent viselkedni USB storage cuccosok szamara (pendrive, egyes okostelefonok mp3 lejatszok es fenykepezogepek stb). Elvileg sok mast is tudna amugy a leiras szerint.
Ilyen modul formaban egesz baratsagos (http://www.electrodragon.com/?product=ch375-module-reading-and-writing-u-diskusb-communicate).
Illetve nemi PDF formatumu leiras rola: ITT (http://wch-ic.com/download/down.asp?id=13) Mondjuk kicsit kihivas letolteni a PDF-t default az URL-re valami kulimaszt akart a browser megjeleniteni, normalis parancssoros wget-el lehozva, majd utana pdf viewer nezve jo lett.
Persze vannak ketsegeim h hasonlo IC-t lehet-e szerezni (vagy modult?) nalunk ... A PDF szerint nem lehet nagy cucc block read/write hasonlo dolgokat implementalni aztan ezzel. Viszont pl megy 5V es 3.3V felallasban is, igy meg az SD kartyaknal jellemzo jelszint illesztessel sem kell pl kulon foglalkozni.
-
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 ...
-
Kérdés: hogyan működnek az SD to IDE adapterek? Ott nincs WAIT meg ilyenek :-) Az lényegében pont azt csinálja ami nekünk kéne csak 16 biten. (Bár ha tudná a 8 bites IDE-t...)
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
Úgy, hogy a vezérlő portjai piszkáljuk csak memória bájtokként.
-
Kérdés: hogyan működnek az SD to IDE adapterek? Ott nincs WAIT meg ilyenek :-)
WAIT alatt arra gondolsz, amikor WAIT-elem szegeny Z80-at? Az csak azert kell mert nem celhw logikai halozat, hanem sw-bol (AVR programmal) csinalom a dolgokat, igy persze minden komplikaltabb, mintha HW-bol osszerakod, megfelelo logikai halozat egy ASIC-ban, FPGA-ban stb. Elvileg ha az AVR eleg gyors, akkor ez nem is kell egyaltalan.
Azt viszont nem teljesen ertem, hogy ki lehet-e kerulni azt a varakozast, ami pl a block read/write-ra kell, ez meg egy IDE disknek se megy, hiszen nem nulla ido alatt csinalja meg, ott is varnod kell, hogy a muvelet vegrehajtodjon. Ez nyilvan igaz egy SD kartyara is.
Amugy amit leirtam az kb uaz ahogy egy IDE disk is mux, ott is - gondolom - van a disken buffer, ahova/ahonnan az ottani vezerlo aztan tovabbitja az adatot. Max ott nem egy altalanos celu MCU-val oldjak meg, ezert nincs szukseg kulonosebb trukkozesre a host fele valo kommunikacio soran, de lenyegeben hasonloan mukodhet. Egy SD-IDE konverter gondolom pont ilyesmit csinal szinten amit en akarok, csak epp szinten valami cel megoldas lehet ami hw-bol tudja a lenyeget, es nem sw-esen kell megirni, ami okozhat sebesseg problemakat. Pont ezert is vetettem fel a 74xx IC-kbol osszerakott "celhw" otletet, ott nem lenne ilyen gond :)
Az lényegében pont azt csinálja ami nekünk kéne csak 16 biten. (Bár ha tudná a 8 bites IDE-t...)
Igen, de nekem nem csak SD kartya miatt kell, hanem masra is kell SPI busz, majd pl ethernethez :) Annak meg ugye nem sok koze van az IDE-hez, amde a fenti megoldasba viszont egyszeruen beleillesztheto (nyilvan SPI interface-es ethernet controllerre gondolok, ami speciel van is nekem).
Úgy, hogy a vezérlő portjai piszkáljuk csak memória bájtokként.
Na ezt viszont nem ertem. Tehat odadugsz vmit a cartridge helyere szepen. Ez EP szamara memoriakent latszik, tudja irni/olvasni. Viszont az MCU-nak is kell tudnia irni olvasni, es az igazan nem szerencses, ha egy idoben probaljak meg ezt tenni (hacsak nem dual port ram). Most akkor lehet, hogy a Z80 orajelehez kene szinkronizalni (vagy tudomisen) az MCU hozzafereset, hasonloan ahhoz, hogy a nick es a Z80 is egyszerre hasznalja a vram-ot. Ehhez mar kicsit kevesnek erzem magam jelenleg meg legalabbis.
-
nem lenne olcsóbb megoldani ezt egy teljes számítógéppel?
13 ezer ft-s tablet pl...
persze hogy hogyan lenne összekötve ep-vel azt nem tudom :)
de ha emu fut rajta akkor minden meg van oldva :)
-
nem lenne olcsóbb megoldani ezt egy teljes számítógéppel?
13 ezer ft-s tablet pl...
persze hogy hogyan lenne összekötve ep-vel azt nem tudom :)
de ha emu fut rajta akkor minden meg van oldva :)
Na igen, de ilyen elven ep128emu-ba bele kell irni barmit, es kesz. Csak hianyzik az "igazi cucc" feeling :)
Masreszt, talan meglepo, de "rendes" szamitogeppel egyaltalan nem egyszerubb, ha mint periferiat akarod hasznalni! Vegulis egy MCU is egy szamitogep, ott legalabb kvazi orajel pontossagra tudod, mire szamits. Ellenben egy PC egy modern multitasking OS-szel (legyen az windows, linux, macos x, vagy barmi) total alkalmatlan erre, mivel ott egy process pl kap egy idoszeletet aztan akar egy szazad - tized masodpercig is nem az ove a control. Amikor arrol van szo, hogy egy 4MHz-es Z80 egy orajelciklusat kell elcsipned akkor ez bizony _nagyon_ komoly gond :) Egy modern szamitogep max kozvetlen hw programozassal (vagy olyan OS-el ahol ez nem gond, pl DOS) oldhato meg. Ilyen szempontbol egy AVR meg mindig sokkal jobban precizebb idozites tekinteteben :) Egy atlag PC-vel (ideertve az "atlag OS-t" hozza) - legyen az akar 3GHz-es is - egyszeruen keptelenseg ilyen pontos idoziteseket tartani ami mar akar 1MHz-es AVR_rel is megy.
Masreszt, ez az egesz MCU dolog ugy kerul a kepbe, hogy idealis esetben ert az ember az FPGA-khoz, vagy netan tud gyartani ASIC-et stb, es csinal egy celaramkort mint amilyen a Nick pl, utana azt nem kell programozni. MCU-t azert hasznalunk, mert amator szinten meg mindig azzal a legegyszerubb megoldani ilyen feladatokat, minden mas lehetoseg nagyon komplikaltsagot szul, vagy olyan tudast/eszkozot/technologiat igenyel amit legtobb ember nem tud biztositani, hacsak nem tomegtermek keszul, aminek kedveert megtervezik/legyartjak a celaramkort pl 10ezer peldanyban, ahol mar persze megeri.
En ugy vagyok vele, hogy itt az MCU mint "glue" (ragaszto, stb) szerepel, lehetoleg minimalis dolgot csinaljon, olyat, amit meg lehetne oldani proramozast nem kivano "fix logikai halozattal" is, csak amator szinten nem. Ha mar arrol van szo, hogy a periferia maga tobb dolgot csinal mint az EP (pl egy full PC) az kb olyan feeling mint az ethernet eseten beszeltuk, hogy csinalja a PC, oszt egyszerusitett soros porti protokollon kapja az EP. Ezze az a baj h a vegen az EP-t az ember ledegradalja egy billentyuzette meg egy megjelenitove a PC szamara akkor mar majdnem ... Az igazi feeling szerintem ott van, ha mindent az EP csinal lehetoleg, es max a "glue logic" miatt kell beilleszteni valamit a kepbe, pl az AVR-t, mert azon van hw SPI busz. Persze, mint irtam epithetne az ember egy SPI-parallel illesztot, csak az egy tenyleg szep alkatreszhalom lenne, mennyisegben, es teruletben sem feltetlen szerencses ...
-
Jó, ezt értem, de pl tök poén lenne egy olyan rendszer, ahol az EP magnó jelet ad ki (save) és magnó jelet fogad (load) egy sima akármilyen tabletről. Úgy értem nem a sima magnó kód kezelné ezt persze, hanem egy spéci. Kiadja a jelet hogy kérem az adott fájt, a pc meg lecsipogja neki :)
-
Jó, ezt értem, de pl tök poén lenne egy olyan rendszer, ahol az EP magnó jelet ad ki (save) és magnó jelet fogad (load) egy sima akármilyen tabletről. Úgy értem nem a sima magnó kód kezelné ezt persze, hanem egy spéci. Kiadja a jelet hogy kérem az adott fájt, a pc meg lecsipogja neki :)
Ez már lényegében kész. (http://enterpriseforever.com/egyeb-temak/tapeserver/)
Csak le kell fordítani más rendszerre.
-
Igen, de nekem nem csak SD kartya miatt kell, hanem masra is kell SPI busz, majd pl ethernethez :)
Ethernet ügyben ezt a cuccot ajánlotta Bruce. (http://www.wiznet.co.kr/Sub_Modules/en/product/Product_Detail.asp?cate1=&cate2=&cate3=&pid=1028#tab)
-
Azt viszont nem teljesen ertem, hogy ki lehet-e kerulni azt a varakozast, ami pl a block read/write-ra kell, ez meg egy IDE disknek se megy, hiszen nem nulla ido alatt csinalja meg, ott is varnod kell, hogy a muvelet vegrehajtodjon. Ez nyilvan igaz egy SD kartyara is.
IDE-nél arra van várakozás, hogy a szektor(ok) bekerüljenek a vinyó puffer memóriájába. A vezérlő gép és a puffer között nincs várakozás (legalábbis a mi szintünkről nézve, ami PC-s oldalról nézve kb XT kategória).
PC-n ugye DMA-val megy az átvitel, ebből vannak az egyre gyorsabb és gyorsabb verziók.
-
Jó, ezt értem, de pl tök poén lenne egy olyan rendszer, ahol az EP magnó jelet ad ki (save) és magnó jelet fogad (load) egy sima akármilyen tabletről. Úgy értem nem a sima magnó kód kezelné ezt persze, hanem egy spéci. Kiadja a jelet hogy kérem az adott fájt, a pc meg lecsipogja neki :)
Ilyen van mar, minap volt rola szo :) Abban az esetben konyebb a dolog mivel hangkent jon, a hangkartyanak meg annak OS driverenek stb is van puffere, illetve egyiranyu, nincs szukseg mikroszekundumban (vagy alatta) merheto pontossagra, egyik oldal elkezdi nyomni, a masik jobb esetben fogja, es kesz, semmi "parbeszed" :)
-
Na ezt viszont nem ertem. Tehat odadugsz vmit a cartridge helyere szepen. Ez EP szamara memoriakent latszik, tudja irni/olvasni. Viszont az MCU-nak is kell tudnia irni olvasni, es az igazan nem szerencses, ha egy idoben probaljak meg ezt tenni (hacsak nem dual port ram).
Nem, nincs semmi közbülső RAM!
Arról van szó, hogy mondjuk legyen a vezérlőbigyónak két portja.
Ez lehet mondjuk a 00h és 01h I/O címen.
De lehet úgy is, hogy mondjuk a cartridge 64K címtartományának az utolsó két bájtja lesz az, azaz EP felöl nézve a 07h szegmens 3FFEh és 3FFFh bájtjain.
Így működik a MICROTEAM féle Commodore floppy illesztő, ilyen lett volna az SMD Team EPROM égető is.
Vagy pl Spectrum-on a SpeccyDos is így éri el a WD-t. (http://www.ep128.hu/Sp_Konyv/SpeccyDos_Referencia.htm#5)
-
IDE-nél arra van várakozás, hogy a szektor(ok) bekerüljenek a vinyó puffer memóriájába. A vezérlő gép és a puffer között nincs várakozás (legalábbis a mi szintünkről nézve, ami PC-s oldalról nézve kb XT kategória).
PC-n ugye DMA-val megy az átvitel, ebből vannak az egyre gyorsabb és gyorsabb verziók.
Jaja, DMA stimt, csak ez most felejtos :) Hacsak nem a cartridge-es otlet, az vegulis DMA lenne, hisz a CPU-tol fuggetlenul valaki mas ir/olvas memoriabol/-ba.
Amugy meg mindig nem teljesen ertem, amit en ecseteltem ott sincs varakozas, ha az MCU buffereben (SRAM-jaban van), onnan kiolvashatod varakozas nelkul. Mint irtam, az a WAIT-es dolog azert kell csupan mert nincs celIC arra hogy az adatatvitelt szervezze, igy az AVR ehhez lassu lehet :( foleg turbos gepnel biztosan. Ha ez nem lenne limitacio semmi varakozas nem lenne! Ezert nem teljesen ertem miert mondod ezt, ahogy IDE eseten is IN-ekkel beolvasod a blokkot (most tekintsunk el a 16 bit miatti elterestol ...), az en vazlatomban is IN-ekkel olvasod be, sok kulonbseg nincs. Max ha az AVR nem eleg gyors ehhez akkor kell sajna a WAIT, hogy legyen eleg ideje az MCU-nak rapakolni a buszra a kov byte-ot ... Esetleg a varakozas kikerulheto, ha az MCU nem sajat RAM-jaba (pl olvasast nezzuk most) pakol, hanem egy portjara kotott FIFO tarba, de akkor megint kell egy spec RAM tipus, bar fifo ram olcsobb talan azert meg mindig mint a dual port ram :D
-
Nem, nincs semmi közbülső RAM!
Arról van szó, hogy mondjuk legyen a vezérlőbigyónak két portja.
Ez lehet mondjuk a 00h és 01h I/O címen.
De lehet úgy is, hogy mondjuk a cartridge 64K címtartományának az utolsó két bájtja lesz az, azaz EP felöl nézve a 07h szegmens 3FFEh és 3FFFh bájtjain.
Így működik a MICROTEAM féle Commodore floppy illesztő, ilyen lett volna az SMD Team EPROM égető is.
Vagy pl Spectrum-on a SpeccyDos is így éri el a WD-t. (http://www.ep128.hu/Sp_Konyv/SpeccyDos_Referencia.htm#5)
Jaaa ... de akkor itt tok ugyanazok a problemak lesznek, mint IO-nal hogy tul lassu hozza az AVR :) En pont arra gondoltam, hogy ez a memorias jatek azert lenne szep, mert MCU _berina_ RAM-ba, amit EP olvas, igy EP utana akar nem szekvencialisan is hozzaferhet ha nem kell neki pl az ossz byte! Sot megteheti h a beolvasott sectorban atir 1-2 byte-ot aztan azt mondja h ezt ird vissza, oreg az MCU-nak. Igy EP szempontjabol sokkal kevesebb muvelet volt. En azt hittem te arrol beszlesz h kvazi DMA-t csinalunk az MCU-nkbol.
Ha te ugy ertetted, hogy kvazi olyat akarsz mint C64-en (ott maskepp nem is megy) hogy egy adott IO chip/akarmi egy adott _memoria_ cimen latszik kvazi, akkor mostmar ertem mire gondolsz. Csakhogy akkor megint problema a fenti AVR "lassusag" az idozites stb, sot tok uaz, csak IOREQ helyett MREQ (na jo cartridge-n ugye CARTRD vagy mi, de most mind1) jel hasznalando fel, viszont az MCU reszerol tokeletesen ugyanaz a helyzet, ugyanazon problemakkal. Legalabbis elso olvasatra ....
-
Egyébként lehet, hogy inkább Compact Flashben kéne gondolkozni, az nem IDE módban használva megy 8 bitesen is. Spectrumon már meg van oldva. (http://www.sinclair.hu/hardver/periferia/zxcf/)
-
amúgy cloud!!! az a divat! nem holmi kártyák meg flashok
wifi kell az EP-re, és mindent elérhetünk vele :)
-
amúgy cloud!!! az a divat! nem holmi kártyák meg flashok
wifi kell az EP-re, és mindent elérhetünk vele :)
Hat a szamtech teruleten hasznalt cloud-rol van szo, annak mi koze a wifihez? Szerintem nem sok, vagy max ugyanannyi mint egy cat5e RJ45 kabelnek :) Amugy a "vezetekes" ethernet (IEEE802.3) es a wifi (IEEE802.11) azert valahol koszonoviszonyban vannak, elvileg megolhato lenne wifi-zes is vhogy. Na de azert lassuk be, vicces is lenne a status sorban az IS-BASIC felirat mellett pl jelerosseg csikokat bamulni :-D
-
ja a wifi csak azért jutott eszembe mert egyre több helyen látom a wifis cloud eléréssel kapcsolatos dolgokat
vagy akár wifis winyó meg ilyesmik
-
ja a wifi csak azért jutott eszembe mert egyre több helyen látom a wifis cloud eléréssel kapcsolatos dolgokat
vagy akár wifis winyó meg ilyesmik
Megint off-topic lesz, csak nem ertem mi koze a wifinek a cloudhoz, cloud kb az, hogy adatait szolgaltatasaid nem helyben tartod hanem a "felhoben", amit persze altalaban vezetekkel osszekapcsolt szerverek alkotnak vegulis, es mind1 az is, hogy te mivel ered el. Max egy dolog ugrik be: van egy wiki szolgaltato ahol a cegnev az h "The Cloud" :) :)
-
Ethernet ügyben ezt a cuccot ajánlotta Bruce. (http://www.wiznet.co.kr/Sub_Modules/en/product/Product_Detail.asp?cate1=&cate2=&cate3=&pid=1028#tab)
Na ez egy erdekes cucc :) Mar talalkoztam vele anno, marmint weben. Eppen irtam volna, hogy minden ilyen "szarert" horribilis osszegeket kernek, akkor mar inkabb megcsinalom magam, az 1000Ft alatti alkatreszkoltseggel, amde igy rakeresve 20 dollar sot kicsit alatta is kaphato (igaz, nem nalunk ...), cserebe mar keszen van, 8 bites modban is mux, stb stb. Ami figyelemre melto benne amugy az az, hogy hw szinten implementalja a tcp/ip-t stb, tehat nem neked kell EP-n megoldani. Mondjuk ilyenkor elgondolkodom hogy megint ott tartunk, hogy van egy EP-nel joval erosebb "szamitogep" a rendszerben, szegeny EP szinte nem is csinal semmit, jo-e ez stb. Hiszen ez - ha az adatlapra jol emlekszek - egy 150MHz-en futo MCU szeruseget integral es van talan 128K belso RAM-ja stb ahhoz, hogy ezt meg tudja tenni. Igaz, ha mindenezt az ember o maga akarja megcsinalni, az szep nagy munka, ha egyaltalan van ideje vele foglalkozni, hogy valaha is elkeszuljon.
Btw vicces lenne, mert elvileg a SERIAL: stb mintajara mar lehetne gondolkodni abban hogy LOAD "HTTP:LGB.HU/TESTPROGRAM" :) vagy hasonlo, a :// is OK lehet mondjuk, bar erdemi kulonbseget imho nem nagyon okozna. Es akkor azonnal webrol toltenel be pl egy basic programot. Igazabol az SD kartya ertelmen is gondolkodtam mar: ha ilyesmiket megold az ember (ok EXDOS szintu block layeres dologhoz nem HTTP kene de pl custom UDP serverrel nem lenne nagy cucc - hasonloan pl a TFTP nevu protokolhoz - nem, nem FTP ...), akkor hasznalna vmi hattertarat neten at, akar tobb ezer kilometerrol, minek ehhez egy fizikai adathordozo oda, igy meg PC-vel adatcsere sem problema tobbe pl.
Kerdes, hogy ilyet lehet-e valahogy szerezni.
-
Egyébként lehet, hogy inkább Compact Flashben kéne gondolkozni, az nem IDE módban használva megy 8 bitesen is. Spectrumon már meg van oldva. (http://www.sinclair.hu/hardver/periferia/zxcf/)
Igen a CF tökéletes lenne szoftverileg, memória módban olyat is tud, hogy a szektor regiszter memóriának látszik, és LDIR-rel lehet másolni.
Csak a fizikai csatlakozása igen kretén :-( csak felületszerelt foglalat van hozzá, házilag kezelhetetlenül apró lábakkal :evil:
Ha meg mondjuk egy 44 pines IDE átalakítóra raknánk, azon nem biztos, hogy be vannak kötve a nem IDE módhoz kell lábak :smt017