ZX Spectrum helyett mikrogepfejlesztes

[Foltos]

Sziasztok,

Nos akkor ujabb osszefoglalo a konkretizalodas iranyaban:

1. A rendszem modulokra epul.
2. Ahol lehet es erdemes ujraprogramozhato (FPGA jellegu)
aramkoroket alkalmazunk. 
3. Az alaplapon lesz PC kompatibilis BUS (ISA es/vagy PCI).
	-Akkor tehat legyen PCI BUS.
	-Az alaplapon lesz jelentos meretu kozos RAM (min 32 MB).
	-Implementalunk valamilyen kis sebessegu, egyszeru system bust.
4. CPU kartyakat hasznalunk. Az alaplap CPU fuggetlen lesz.
	-A CPU kartyan lesz RAM az adott CPU igenyeinek megfelelo
	 meretben.
5. A rendszert multiprocesszorosra tervezzuk.
	Ez a pont a fentiek fuggvenyeben talan mar felesleges...

Nehany ujabb otlet:
Erdemes lenne az alaplapi ram melle FPGA -val egygy DUAL-PORT -jellegu
RAM vezerlot tenni. Az FPGA atprogramozasaval erdekes lehetosegek tarhaza
nyilik meg :) Pl. igenytol fuggoen kialakithato RAM is ebben az FPGA -ban ami
helyet biztosithat a valaki alltal emlitett FLAG -eknek.

Talan a BUS vezerlest is erdemes lenne FPGA -val megoldani. Igy akar
menetkozben valtoztathato lenne a cim, es az adatbusz szelessege. 
Persze csak egymas rovasara. Vagy ez ertelmetlen? Lehetne pl. adott
slot -ot PCI -rol CARDBUS -ra atprogramozni. Ha jol tudom nem allnak 
tul messzire egymastol (a CARDBUS a PCMCIA PCI -hez kitalalt utodja).

Masrezt konkretizalni kellene lassan, milyen egysegeket kell megvalositani. Aztan raterhetnenk egyesevel az egysegek konkret megvalositasanak modjara is. Igy szep lassan konkretizalodna a dolog.

Velemenyek?

Udv:
	Foltos
> 
> Koszi az osszefoglalot, valoban ideje. Megprobalom en is osszefoglalni a
> dolgokat, ahogy eddig megertettem. Javaslom valoban fixaljuk le, ami eddig
> stabil: (Ha valamit rosszul ertettem, jelezzetek.)
> 
> - Gep modularis, architekturajaban tamogatja a multiprocis uzemmodokat.
> - Az alaplapon csak a meghajto, rendszerbusz, esetleg (meg megvitatando) a
> programozhato orajelgencsi, esetleg par FPGA van, ami busz-illesztesi
> segedfunkciokat lat el. (Pl. lehetne par szal nem definialt bit, amiken az
> egyes specko cuccosok kesobb kommunikalhatnanak, meghozza az 
> FPGA-k szerint,
> de ez is csak egy otlet, szinten merlegelendo, hogy mit nyerunk/vesztunk
> vele.)
> 
> -A buszrendszer: lesz egy gyors busz (szivem szerint 64-bites adatbusz,
> illetve valamekkora cimbusz, amit meg fixalni kellene. A sebesseget
> ugyszinten. Megfontolando itt esetleg lejjebb adni, s importalni ('kis
> kiegeszitessel'... :))) ) egy komplett PCI-buszt. Ugyanis igy a csak
> PCI-kartyak ebbe bedughatok, valamint a bika fejlesztesek a bovitett
> valtozat extrait is hasznalhatnak egyuttal. Ezt alaposan at kellene
> gondolni!!)
> Tovabba lesz egy kulon, lassu buszrendszer, amivel mondjuk max. 256db
> FPGA-t, vagy sajat fejlesztesu 'cel-mikrovezerlot'/pl. ami Z80-as hulladek
> anyagbol tervezettrol mar irtam/  lehet felprogramozni/kezelni/monitorozni
> menet kozben. Eleg lesz vajon ennyi, vagy vegyuk a cimzest inkabb
> 16-bitesre? :)
> 
> -Lesznek kartyak pluszban. A magam reszerol egyelore igenytelen vagyok,
> nekem a sima S3VIRGE is megfelelne a PCI- buszon. Hangban meg egy 
> vibrator.
> (vibra16) Persze ha valaki beadja a kozosbe egy jobb fejleszteset, esetleg
> lehet jobb is. :)))
> 
> - A cpu modul megint kemeny dio. Tobb memoriat javasoltok ra, 
> igazatok van. 
> Ellenben az alaplapon (van kulon kartyan) en nem tennek 128-nal kevesebb
> RAM-ot. Esetleg egy akkurol is lehetne mukodtetni, igy pl. idonkent a
> rendszer 'csak ugy, miert is ne...' lementhetne a pillanatnyi allapotait
> ide. Vagyis egy lefagyas, kiakadas eseten pl. egy BOOT-utani 
> menubol lehetne
> valasztani: 'Bocs, kiakadtam, mert az oprendszerrel valamami bibi volt ...
> de van egy mentes az 5-perccel ezt megelozo allapotomrol. Kered
> visszatolteni??? Esetleg futtassak egy debuggert a masik CPU-kartyarol???'
> :))) 
> Ezenkivul ha multiproc alkalmazasban gondolkodunk, akkor a fontosabb
> adattablazatokat, adatbazisokat, feldolgozas alatt levo hatalmas kepeket,
> hangmintakat, videoanyagokat is tobb kartyanak kell elerni. Ilyenkor a kis
> kozos RAM a rendszer halala lenne. 
> Nem tudom, elfogadjatok -e vedelmere a fenti ervelesem? :)
> 
> - Megszakitasi rendszer: Marha kenyes dolog. Az a bibi, hogy ugye sokfajta
> CPU-t kellhet egyutt hasznalni. Az egyik erre, a masik arra lett 
> kihegyezve.
> A leirt mocis irq-que remek dolog, meg talan PC-n is megy 
> itt-ott, ahol jobb
> munkat vegeztek a programozok. Ellenben fontos lenne egy plusz korrekt,
> legalabb 256, de inkabb 65536-vonalas /csak elvi limit, ne ajuldozzatok!
> :))) / IRQ kidolgozasa. Sokat gyorsitana ugyanis mindenen, ha nem kellene
> sakkozgatunk ezzel!
> Javaslatom: Mint a Z80-nal, meg igen sok procinal is hasznaljak: A
> megszakitast kezelje egy cel-aramkor, ami pl. itt allhat FPGA-bol
> termeszetesen. (Indulaskor a felprogramozasok idejere a CPU-kartyan egy
> primitiv kis celhardver blokkolna persze, ameddig elkerulhetetlen.) Ez az
> FPGA lanc szepen korrektul n-darab bemenetet adna, amin johet az esemeny.
> Ezutan a sinen jon egy INT jel, majd szepen a sinre az FPGA-k 
> altal rateve a
> megszakitasi cim. Elvileg tehat kizarolag az FPGA-k szama, illetve a
> felprogramozas modja fogja meghatarozni a megszakitasok szamat, prioritasi
> sorrendjet, stb. Megtehetjuk pl azt is, hogy bizonyos megszakitasi
> kombinaciok specialis elofordulasa egy teljesen mas megszakitasi rutin
> hivasat eredmenyezze! Ilyen tudomasom szerint a vilagon sincs... :) 
> 
> Ez elsore jo vadnak tunik, de nezzunk csak ra egy peldat!:
> 
>  A printer hibat jelez, de kozben (kiszolgalas elott) jon egy masik
> megszakitas a hangkartya buffere felol, hogy eppen kiurult. Ugyanakkor a
> tarsproci is szol egy INT-vel, hogy kerne ujabb adatot a kozos teruletre,
> mert vegzett, ja es kozben a digitalizalo kartya is szol egy masik
> vezeteken, hogy ideje buffert uriteni, mert mar a masik felszegmens is
> csaknem tele... Vagyis alapveto gond, hogy a kozponti procinak egy merev
> priorotasi sorrend most nem optimalis. Ellenben ha van egy 
> harmadik proci a
> rendszerben, akkor egyszeruen a foproci villamgyorsan atszervezheti a
> teendoket, ha az FPGA-halozat ezt jelzi naki, vagyis azt a megszakitast
> aktivalja, amely a 'veszhelyzet' nevu rutint fogja meghivni. A 
> rutin szepen
> atutemezi a feladatokat a procik kozott, netan a felesleges taszkokat (pl.
> DOOM 3D atmenetileg lejegeli) esetleg az emlitett BOOT-LCD-n informalja a
> kezelot, hogy ami sok az sok, tessek kicsit lejjebb venni a 
> terhelesen, mert
> hamarosan instabilla valhatna a rendszer, emiatt kicsit ezt es 
> ezt a taszkot
> most felfuggesztette... :) Ezutan szepen a megszakitasokat ujrautemezi, s
> megy minden tovabb, mintha semmi sem tortent volna. Ha esetleg az
> alaprendszer (mondjuk egy hatterben futo fuggetlen FPGA-s rendszer
> megallapitasa szerint) mukodese megvaltozik, mert mas tipusu szoftvereket
> toltottunk be a mamoriaba, akar intelligens modon szepen egy tablazatban
> keszit egy kis statisztijkat, majd meghivja a foproci 
> szerviz-INT-jet, s az
> ott levo rutin a szervizbuszon keresztul kifaggattja az FPGA-kat, 
> hogy mi a
> bibi, majd a statisztikak alapjan ujraszervezi a prioritasokat.
> 
> >Valoban nem atlathato elsore, de egy alaplapra integralt HW manager
> >talan atlathatja. Ugy is valakinek ki kell osztania az eroforrasokat.
> 
> No, valami ilyesmit gondoltam 'intelligensebb' megszakitasi alrendszer
> cimszo alatt csinalni. :))) Szerintem ezt is vitassuk meg, mert nagyon
> nagyon erdekes lehetosegek vannak benne!
> 
> Azutan nem egyeztunk meg az elso proci tipusaban. Jelenleg 
> versenyben: Z80,
> 68Kxx, Pentium, stb. Melyik legyen???
> 
> Periferiak: LPT, PS2mouse+tapperpad, USB, IRDA.
> 
> Hattertar: CDWRITER-t javaslok, de CDROM-ot mindenkeppen. (A writer lassan
> alapcucc lesz, vagyis erdemes lesz szamitani ra. Mondjuk a hardvernek
> mindegy: IDE es kesz. :))) ) HDD sem art szerintem.
> Azutan lesz egy smart-adapter. Szivem szerint az alaplapra ratennem, mert
> innen menne a BOOT-extend funkcio is. Vagyis a BIOS-ROM-nal fejlettebb
> rendszert lehetne betolteni. Sot! Egyszerre ugye tobb proci 
> rendszere fennt
> lehetne. Ha nem talal az adott CPU-kartyan a proc semmit, akkor mindig
> mehetne a moka teljesen a kartyan levo EPROM-bol. :)
> Javasolnek egy opcionalis masik SMART -foglalat beepiteset is emiatt, s
> akkor az egyik smart maradna cserelheto BOOT-extender, mig a masik affele
> FLOPPY-utod. Esetleg lemezrol lemezre COPY is mehetne a 'maniakusoknak'.
> :))) (Vagyis javaslom: legyen ket SMART-meghajto.)
> 
> Halozat: Feri preferalta ugyan a RTL8019-est, mert lehet olcson kapni, bar
> ISA. Nos, az RTL 8029 ugyanaz, de  PCI-ban. Akar halokartyarol is 
> lekaphato,
> ha boltban nem kapsz.
> 
> Az oprendszer nagyjabol osszeallt, eloszor vsz. LINUX lesz rajta, 
> ugy latom.
> Azutan majd lehet agyalni tovabb, ha kell.
> 
> BOOT-interpreter:
> 
> >Ezzel csak egy baj van, hogy a nem processzor fuggetlen. Vagy nem a kesz
> >kodot kell a FLASHbe tenni csak a forras egy tokenizalt valtozatat, amit
> >online fordit be maganak az aktualisan alkalmazott proci (egyfajta BASIC
> >jellegre gondoltam - persze celiranyos utasitasokkal - , mint anno a
> >SPECTRUMnal. Vegulis innen idultunk :)))
> >VFX.
> 
> Szerintem egyszeruen zsenialis otlet volt, de lattam, hogy leszavazta'tok,
> mert bonyi lenne. Ellenben javaslok egy kompromisszumos megoldast:
> Minden CPU-kartyan legyen egy szabvany rutinkonyvtar. A 'TOKEN'-ek makroi
> szepen egymas alatt letarolva, illetve egy forditasi indextabla tabla egy
> fix cimen. (pl. $100-tol...) Auz 'interpreter' igy csupan annyi 
> lenne, hogy
> a tablazat altal mutatott rutinokat hivogathatna sorban, amig mondjuk a
> kodveg jel meg nem erkezik. Ekkor folytatna a rendszer a 
> BOOT-olast. Ez eleg
> korrektnek latszik, raadasul gyorsan atirhato lenne barmely proci 
> kodjara a
> BIOS, mert a rutinok egyszeruek volnanak, ugyes rendszerbe szervezve
> kitalalva. Igy nem bonyi, meg mukodne is korrektul a tobbfajta procival az
> egesz!
> 
>  >Fantaziaban nics hiany ugy latom :)))
> >UDV. VFX.
> 
> 
> Miert is volna? Vegulis egy ilyen jo csapattal csak szarnyalhatnak a
> gondolatok! :)
> 
> >Nalam igy vagy ugy, de egy ilyen masina biztos keszulni fog. elobb vagy
> >utobb. (ahogy magamat ismerem -> utobb).
> 
> Nalam ugyanez, de egyre jobban verszemet kapok az otletektol! :) Vegulis
> errol szol a dolog: tanulunk belole, meghozza mar a tervezesnel. Szerintem
> ha most valaki egy olloval elvagna a temat, mar akkopris megerte, annyi
> otlet gyult ossze. Viszont nem vagta el senki, tehat folytassuk 
> csak tovabb!
> :)))
> 
> Bocs a tobbiektol, hogy nev szerint nem mentem vegig mindenki hasznos
> eszrevetelen, annyi volt. Csak az ido az oka. Par kort meg ezzel ugyis
> futunk, nem? :)
> 
> 
> Udv.:
> 		Norbi.
> 
> 
> 
> 
>