[Samuraj]

...szerintem meg okosságot mondanék, csak továbbra is fenntartom az állitást, hogy 8bites kompatibilitás miatt van igy. Hirtelen arra gondoltam, hogy lehetne cimbusz*adatbusz-nyi táras gépet épiteni az IA32 cpu köré, de sajnos maga a processzor igényli és számitja az adatokat 8bites jelleggel, pl a GDT-ben adott szegmens keresésekor. De alapvetően a CS:IP is 8 bitesen "gondolkodik" amikor az utasitásért nyúl, mert van 1bájtos, de 6-8bájtos utasitás is. Jó tudom, tömbökben olvassa be, nem egyesével (illetve a 8088 egyesével).
A tankönyvvel semmi újat nem mondtatok.
286: Az okézsoké, hogy a szegmens leiró ugyanaz, mint a 386-osban és a base address 32bites (illetve 24), ez igy tök jó, De a DS:[SI] offszettje továbbra is 16bites, amivel csak 64kbyte blokk cimezhető. A 20bites 1b/4Kb granularity flag az effektiv cimszámitásnál nem játszik, az továbbra is bájtos. Csupán a határt szabja meg a szegmensnek. Érdekes ez a 20bites megoldás. 1b sűrűségnél az [ESI] 32bittjéből csak az alsó 20-at engedi, ha a felső 12 valamelyike 1-es, vagyis a szegmens határon túlra cimzett, akkor általános védelmi hiba. Ha 4Kb sűrűség van, akkor az ESI felső 20bittjét teszteli csak, igy 4Gb-ig lát. Az effektiv address egyébként a leiró base address+ESI szimpla összegzésével áll elő. Ezután teszteli a limitet. ...(ötlet-amit nem ir6ok le)...
Az intel aszondja, jobb a base addresst is - nemhogy 4bájt - 16 bájt határra pakolni, ami azt jelenti, hogy x0000h-val kezdődék.
Visszatérve a 286-osra. Igen, a base address tényleg ellát 16megáig, de az offszet továbbra is 16bites, vagyis 1 szegmens 64Kbyte lehet. A másik variáció, hogy a 1b/4Kb sűrűséget értelmezi máshogy, és... de ez sem jó, most rájöttem. Persze 16bites offszettnél a 4Kb-s 20bites limiter is értelmetlen, mert 16bitet hova maszkoljon. Jó majd belenézek a 286-os iozébe ha nagyon unatkozok.
És tisztába vagyok a cimzéssel, csak ti nem értitek, mit akarok mondani. Kikérem magamnak! Megsértődtem!
A 32Gb tár egy jó elgondolás volt, e hiányába viszont a rendszerben van ez a 8bites cimkonverzó, ami valamellyest teljesitmény visszafogó. Nem baj, ha nem értetek 1et, tényleg könyvet lehetne erről irni, de most ettől eltekintek.

[Sparow2]

Idézet: Samuraj - Dátum: 2010. 03. 20. 12:17

...szerintem meg okosságot mondanék, csak továbbra is fenntartom az állitást, hogy 8bites kompatibilitás miatt van igy. Hirtelen arra gondoltam, hogy lehetne cimbusz*adatbusz-nyi táras gépet épiteni az IA32 cpu köré, de sajnos maga a processzor igényli és számitja az adatokat 8bites jelleggel, pl a GDT-ben adott szegmens keresésekor. De alapvetően a CS:IP is 8 bitesen "gondolkodik" amikor az utasitásért nyúl, mert van 1bájtos, de 6-8bájtos utasitás is. Jó tudom, tömbökben olvassa be, nem egyesével (illetve a 8088 egyesével).

Mivel szükség van megcímezni nem csak 4-gyel osztható memóriacímen lévő byte-okat is, ezért amit írsz nem kivitelezhető.

Idézet: Samuraj - Dátum: 2010. 03. 20. 12:17

A tankönyvvel semmi újat nem mondtatok.

Ehhez képest elég fura dolgokat írtál

Idézet: Samuraj - Dátum: 2010. 03. 20. 12:17

286: Az okézsoké, hogy a szegmens leiró ugyanaz, mint a 386-osban és a base address 32bites (illetve 24), ez igy tök jó, De a DS:[SI] offszettje továbbra is 16bites, amivel csak 64kbyte blokk cimezhető.

286-os descriptorokban csak 16 bites a szegmens limitje: max. 64KiB lehet egy-egy szegmens.
Ezért elegendő a 16 bites regiszerekkel megcímezni.
Az még 16 bites CPU volt.

Idézet: Samuraj - Dátum: 2010. 03. 20. 12:17

A 20bites 1b/4Kb granularity flag az effektiv cimszámitásnál nem játszik, az továbbra is bájtos. Csupán a határt szabja meg a szegmensnek.

Igen.
De nem is mondtam mást én sem.

Idézet: Samuraj - Dátum: 2010. 03. 20. 12:17

Érdekes ez a 20bites megoldás. 1b sűrűségnél az [ESI] 32bittjéből csak az alsó 20-at engedi, ha a felső 12 valamelyike 1-es, vagyis a szegmens határon túlra cimzett, akkor általános védelmi hiba. Ha 4Kb sűrűség van, akkor az ESI felső 20bittjét teszteli csak, igy 4Gb-ig lát.

Miért csak a felső 20 bitjét???
Granuláris szegmensnél is beállíthatok 1 MB-nál kisebb limitet. Csak nem byte-os, hanem 4KiB-os lépésekben. Lehet akár 4 KiB-os szegmens, ha akarom.
És byte-os limitnél is a limithez kell hasonlítani az offszetet (ahogy írtad: ESI), nem elegendő azt nézni, hogy a felső 12 bit értéke 0 legyen, hiszen nem biztos, hogy 1 MB a limit, lehet kevesebb.

Bizonyára csak kényszerből lett ilyen a megoldás, mert nem fért el a descriptorban 32 bites limit.

Idézet: Samuraj - Dátum: 2010. 03. 20. 12:17

Az effektiv address egyébként a leiró base address+ESI szimpla összegzésével áll elő. Ezután teszteli a limitet. ...(ötlet-amit nem ir6ok le)...
Az intel aszondja, jobb a base addresst is - nemhogy 4bájt - 16 bájt határra pakolni, ami azt jelenti, hogy x0000h-val kezdődék.

A 16 byte határnál csak az utolsó hexa számjegy 0. Amit Te írtál, az 64KiB-os határ.

Idézet: Samuraj - Dátum: 2010. 03. 20. 12:17

Visszatérve a 286-osra. Igen, a base address tényleg ellát 16megáig, de az offszet továbbra is 16bites, vagyis 1 szegmens 64Kbyte lehet. A másik variáció, hogy a 1b/4Kb sűrűséget értelmezi máshogy, és... de ez sem jó, most rájöttem. Persze 16bites offszettnél a 4Kb-s 20bites limiter is értelmetlen, mert 16bitet hova maszkoljon. Jó majd belenézek a 286-os iozébe ha nagyon unatkozok.

A 286-osnál nem volt még granularity (1b/4Kb): ott byte határt lehetett mondani 16 biten: azaz minden szegmens maximális mérete 64KiB volt.
Logikus is valamennyire, hiszen nem voltak 32 bites regiszterek, amivel megcímezhető lett volna a 64KiB fölötti rész.

Idézet: Samuraj - Dátum: 2010. 03. 20. 12:17

És tisztába vagyok a cimzéssel, csak ti nem értitek, mit akarok mondani. Kikérem magamnak! Megsértődtem!

Értem, hogy mit akarsz mondani.
De a Te módszereddel csak minden 4-gyel osztható címet lehetne megcímezni.

Idézet: Samuraj - Dátum: 2010. 03. 20. 12:17

A 32Gb tár egy jó elgondolás volt, e hiányába viszont a rendszerben van ez a 8bites cimkonverzó, ami valamellyest teljesitmény visszafogó. Nem baj, ha nem értetek 1et, tényleg könyvet lehetne erről irni, de most ettől eltekintek.

Jó elgondolás volt, csak a valóságban nem így működik
Nincs semmiféle címkonverzió ... A 386-os CPU 4 byte-os adatokat olvas be egyszerre, a "konverzió" csak annyi, hogy a memória felé a címbusz alsó 2 bitje mindig 0, ezáltal a memória mindig 4-gyel osztható címeket kap, ahonnét visszaad 32 bitet. (Persze a processzorban megvan az a két bit is, hiszen belül már csak a szükséges részt --adott byte, word, vagy az egész dword-- használja fel a kapott 32 bitből)

Amit írsz, abból látszik, hogy a tudásod elég homályos, halovány az x86-os címzés pontos minkéntjében. Valami dereng, de kevered a valóságot saját Magad által kitalált vagy kigondolt dolgokkal.
Így nem fogsz tudni okosat mondani, mert ha nem látod pontosan a részleteket, akkor egy rossz ötlet is tűnhet jónak.

Szerkesztette: Sparow2 2010. 03. 20. 23:34 -kor

[Samuraj]

nagyon kapós!

Szerkesztette: Samuraj 2010. 03. 21. 14:05 -kor

[Samuraj]

Na, csak nem állhatom, hogy vissza ne szóljak, ha már annyit irtál.

Idézet: Sparow2 - Dátum: 2010. 03. 20. 23:31

Mivel szükség van megcímezni nem csak 4-gyel osztható memóriacímen lévő byte-okat is, ezért amit írsz nem kivitelezhető.

Mért akarsz mindenképpen megcímezni bájtokat is? SHL, SHR, ROR, ROL oszt majd a program kiszedi magának. (már kicsit elvonatkoztatok az x86-tól persze, még mielőtt odakeveredne). Továbbá nem csak a memóriát, hanem az i/o portokat is át kell gondolni, az pedig x86ban igencsak őrzi a régi 8bites dolgokat, ráadásul indexelt cimzéssel.

Idézet: Sparow2 - Dátum: 2010. 03. 20. 23:31

286-os szegmens maximális mérete 64KiB volt.

Akkor csak jól gondoltam én is.

Idézet: Sparow2 - Dátum: 2010. 03. 20. 23:31

Miért csak a felső 20 bitjét??? Lehet akár 4 KiB-os szegmens, ha akarom.

Mert ezt irják intelék. Talán ők tudják jobban. Igen 4Kb a legkisebb szegmens amit beállithatsz (granular flag set), igy az ESI offszet maximálisan x00000FFFh lehet, a felső 20 bit bármelyike 1, akkor GP hiba van. Azt, meg hogy az offszet xFFFh vagy épp x8DAh vagy akármi más, szükségtelen tesztelni a védelmi mehanizmus szempontjából, mert igy is ugy is belefér a keretbe.

Idézet: Sparow2 - Dátum: 2010. 03. 20. 23:31

És byte-os limitnél nem elegendő felső 12 bit értéke 0 legyen. A 16 byte határnál csak az utolsó hexa számjegy 0. Amit Te írtál, az 64KiB-os határ.

Igen ennyire nem akartam részletezni én se (tankönyv effektus). 16byte eltévesztve, amit irtam az binárisan négy 0.

Idézet: Sparow2 - Dátum: 2010. 03. 20. 23:31

Értem, hogy mit akarsz mondani. Nincs semmiféle címkonverzió ... a "konverzió" csak annyi, hogy a memória felé a címbusz alsó 2 bitje mindig 0, ezáltal a memória mindig 4-gyel osztható címeket kap, ahonnét visszaad 32 bitet.

Nasszóval itt a trükk, 2 illetve 3 bites (pentium 64bit data bus) cim eltolás. Eszembe juthatott volna nekem is. Akkor mégis igazam volt, hardweresen 4, 8 bájtokban van a cimzés, csak a szoftver kompatibilitás ragadt meg 1 bájton. Én azon merengtem, hogy szoftveresen is át lehetne-e ezt lépni, de már irtam, hogy az utasításkészlet és a címzés kódolás (szoftveres) eléggé rögzített (pl push, pop). Tényleg, ha aszondom neki, push ds, akkor ezt a 16bites adatot hogy rakja el a 64bitesen (már pentiumozunk) cimzett memóba, mindenképpen lefoglal neki 8 bájtot és jóvilág? Nyilván nem fogja állandóan "töredezettség mentesiteni", hogy most berakja a 2 bájtot, legközelebb, ha ismét lesz 2 vagy 4 bájtos push, akkor visszaolvassa az előbbi 8bájtot, hogy azon belüli 2bájthoz hozzáillesszen még néhányat helytakarékossági céllal - remélem értitek.

Idézet: Sparow2 - Dátum: 2010. 03. 20. 23:31

Ehhez képest elég fura dolgokat írtál Amit írsz, abból látszik, hogy a tudásod elég homályos, halovány. Valami dereng, nem fogsz okosat mondani.

Az ilyen beszólások létjogosultságára már utaltam. Ebből az írásodból látszik, hogy okosabb szeretnél lenni (persze ugyanígy én is) vagy a másikat akarod lehúzni.

[Telcontar]

Idézet: Samuraj - Dátum: 2010. 03. 21. 14:03

nagyon kapós!

Csodálkozol? 500 MB-os a proci. Meg 100 MHz-es!!!

[Sparow2]

Idézet: Samuraj - Dátum: 2010. 03. 21. 15:44

Na, csak nem állhatom, hogy vissza ne szóljak, ha már annyit irtál.

Mért akarsz mindenképpen megcímezni bájtokat is? SHL, SHR, ROR, ROL oszt majd a program kiszedi magának. (már kicsit elvonatkoztatok az x86-tól persze, még mielőtt odakeveredne). Továbbá nem csak a memóriát, hanem az i/o portokat is át kell gondolni, az pedig x86ban igencsak őrzi a régi 8bites dolgokat, ráadásul indexelt cimzéssel.

Végülis mondhatták volna, hogy a 386-os CPU-kon nem 8 bit egy byte, hanem 32.
De nem érdemes ezért felborítani a kompatibilitást.

Idézet: Samuraj - Dátum: 2010. 03. 21. 15:44

Mert ezt irják intelék. Talán ők tudják jobban. Igen 4Kb a legkisebb szegmens amit beállithatsz (granular flag set), igy az ESI offszet maximálisan x00000FFFh lehet, a felső 20 bit bármelyike 1, akkor GP hiba van. Azt, meg hogy az offszet xFFFh vagy épp x8DAh vagy akármi más, szükségtelen tesztelni a védelmi mehanizmus szempontjából, mert igy is ugy is belefér a keretbe.

Ez csak a 4KiB-nál van így.
Ha a limit mondjuk 0xab8afff, akkor ugyanúgy kell összehasonlítani, hogy kisebb vagy nagyobb ...

Idézet: Samuraj - Dátum: 2010. 03. 21. 15:44

Nasszóval itt a trükk, 2 illetve 3 bites (pentium 64bit data bus) cim eltolás. Eszembe juthatott volna nekem is. Akkor mégis igazam volt, hardweresen 4, 8 bájtokban van a cimzés, csak a szoftver kompatibilitás ragadt meg 1 bájton.

Nem ... hardveresen is meg tudsz címezni egy-egy byte-ot.
Azt mondod, hogy az X. byte töltődjön az akkumlátor regiszterbe, és az odakerül. Teljesen függetlenül attól, hogy a memóriabusz hány bites, vagy hogy a memóriabusz szervezése miatt ehhez be kell olvasni 4 (vagy több) byte-ot.

Idézet: Samuraj - Dátum: 2010. 03. 21. 15:44

Én azon merengtem, hogy szoftveresen is át lehetne-e ezt lépni, de már irtam, hogy az utasításkészlet és a címzés kódolás (szoftveres) eléggé rögzített (pl push, pop). Tényleg, ha aszondom neki, push ds, akkor ezt a 16bites adatot hogy rakja el a 64bitesen (már pentiumozunk) cimzett memóba, mindenképpen lefoglal neki 8 bájtot és jóvilág? Nyilván nem fogja állandóan "töredezettség mentesiteni", hogy most berakja a 2 bájtot, legközelebb, ha ismét lesz 2 vagy 4 bájtos push, akkor visszaolvassa az előbbi 8bájtot, hogy azon belüli 2bájthoz hozzáillesszen még néhányat helytakarékossági céllal - remélem értitek.

Azt hiszem, értem, mit mondasz ...
Ott a cache, ami annyi byte-ot ír ki egyhuzamban, vagy olvas, amilyen széles a tartalma, ezért a főmemóriába sosem kerül csak egyetlen byte.

Idézet: Samuraj - Dátum: 2010. 03. 21. 15:44

Az ilyen beszólások létjogosultságára már utaltam. Ebből az írásodból látszik, hogy okosabb szeretnél lenni (persze ugyanígy én is) vagy a másikat akarod lehúzni.

Nem azért mert szeretnék okosabb lenni.
Hanem ezért, mert valóban nagyon fura dolgokat írtál.
Azért jópár dolgot nem úgy írtál le, ahogy valójában van.
Meg rajtam volt az "én majd megmondom" hangulat is. De semmi olyat nem "húztam le", amit jól írtál, csak amiket rosszul.

Szerkesztette: Sparow2 2010. 03. 22. 00:10 -kor

[ace22]

Idézet: Telcontar - Dátum: 2010. 03. 18. 19:28

ace22 is hasonló projekten dolgozik, csak ő még stílusosabb készletet akar. https://forum.hwsw.h...tyle_emoticons/default/redface.gif) A procikat már beszerezte hozzá.

Nos, nalam mar a tabla is procikbol all (majd egyszer): szurke (P I) es fekete (PPGA), a vezer es a kiraly "aranysapkas" ill. fekete sapkas IBM procikon...

PEter

[Sparow2]

Idézet: ace22 - Dátum: 2010. 03. 22. 08:08

Nos, nalam mar a tabla is procikbol all (majd egyszer): szurke (P I) es fekete (PPGA), a vezer es a kiraly "aranysapkas" ill. fekete sapkas IBM procikon...

PEter

A gyalogok meg 4004-esek?

[Samuraj]

Idézet: Sparow2 - Dátum: 2010. 03. 21. 23:47

Ez csak a 4KiB-nál van így.
Ha a limit mondjuk 0xab8afff, akkor ugyanúgy kell összehasonlítani, hogy kisebb vagy nagyobb ...

Ezt gondold át újra. A limit eleve 20bites= 0xab8af vagy 0x8afff. n*4Kb-nál is igen, összehasonlít, de mint mondtam csak az offszet felső 20bitjét figyeli, az alsó 12 mindegy micsoda, az adott 4Kb-s darabba belefér, most mindegy hogy 4Kb szegmens vagy n-szer 4Kb.
1byte-ot is be tudok tölteni akárhonnan az ax-be (1bájt az al-be), oké, de azt a procin belül rakja oda (szoftveresen - szerk: jó, a procin belül az még hardweres, csak a szoftveres kompatibilitásra utalok), míg a memóriából a prociba 8bájtban kerül a cucc (hardweresen). Na mindegy, szerintem értjük egymást, legfeljebb a megfogalmazás nem mindig világos, mert igyexek én is tömören. A többi meg már részlet kérdés. Amiket elsőre irtam, abban valamellyest keveredett a valóság, találgatás, illetve fejlesztő szándékú elképzelés. A többi procifajtát sajnos nem ismerem csak az IAx86-ot, majd bepótolom.

Szerkesztette: Samuraj 2010. 03. 22. 10:59 -kor

[Samuraj]

Viszont végre megjött egy rakás P2, P3 proci, celeron mind - slot-pga kártyástul. Ebben sem szenvedek már hiányt.
939-es 3000+ athlonok 1500ft-ért mennek mostanában zsinórba.

[Sparow2]

Idézet: Samuraj - Dátum: 2010. 03. 22. 10:57

Ezt gondold át újra. A limit eleve 20bites= 0xab8af vagy 0x8afff. n*4Kb-nál is igen, összehasonlít, de mint mondtam csak az offszet felső 20bitjét figyeli, az alsó 12 mindegy micsoda, az adott 4Kb-s darabba belefér, most mindegy hogy 4Kb szegmens vagy n-szer 4Kb.

32 bites, bár csak 20 bit van eltárolva.
De tudom már mit mondasz, eddig félreértettem.

Idézet: Samuraj - Dátum: 2010. 03. 22. 10:57

1byte-ot is be tudok tölteni akárhonnan az ax-be (1bájt az al-be), oké, de azt a procin belül rakja oda (szoftveresen - szerk: jó, a procin belül az még hardweres, csak a szoftveres kompatibilitásra utalok), míg a memóriából a prociba 8bájtban kerül a cucc (hardweresen). Na mindegy, szerintem értjük egymást, legfeljebb a megfogalmazás nem mindig világos, mert igyexek én is tömören.

Értem ... az zavar Téged, hogy a memória nem byte címzésű.

[Samuraj]

Igazából nem zavar, csak kezdett furcsa lenni ez a stikli, és a könyvek erről mélyen hallgatnak.

Viszont feltámadt az egyik iP3/733, amit elvileg megsütöttem és le is van sarkazva rendesen! Az athlon-t is felkéne támasztani, az is "csak" megsült.

[ace22]

> Viszont feltámadt az egyik iP3/733, amit elvileg megsütöttem és le is van sarkazva rendesen! Az athlon-t is felkéne támasztani, az is "csak"
> megsült.

Hoppa! Nekem is feltamadt ket Athlon XP-m, fel ev pihenes utan. Az egyik azota is szolgalatban van. Vajon tul hamar artuk fel a remenyt, vagy letezhet valamilyen regeneracios folyamat "kicsit" meggyilkolt procikban?

PEter

[Telcontar]

Idézet: ace22 - Dátum: 2010. 03. 24. 08:24

> Viszont feltámadt az egyik iP3/733, amit elvileg megsütöttem és le is van sarkazva rendesen! Az athlon-t is felkéne támasztani, az is "csak"
> megsült.

Hoppa! Nekem is feltamadt ket Athlon XP-m, fel ev pihenes utan. Az egyik azota is szolgalatban van. Vajon tul hamar artuk fel a remenyt, vagy letezhet valamilyen regeneracios folyamat "kicsit" meggyilkolt procikban?

PEter

Nem hinném, hogy az AMD nagy titokban már ott tartott 7 éve is, hogy nanorobotokkal voltak felszerelve a chipjei, amik aztán a lezúzott sarkokat a törmelékből meg innen-onnan összeszedegetett üvegcserepekből újraépítenék.

Mai nyereményem ellenben egy AMD Am486DX5-133W16BGC chip, fekete színű szignálással. Valami Advantech kártyapécével (procikártyával?) együtt lőttem, utóbbi sem piskóta darab: van rajta procifoglalat, BIOS, 1 db 72 pines DIMM foglalat, 1 IDE, 1 floppy, 1 printer, 1 soros csatlakozó és 1 PS/2-es port, egy Tadiran Lithium gombelem leszedhetetlenül rágyógyítva, meg még két tüskesor (az egyik a hátlap felé kivezetve), amiknek a funkciójára még nem sikerült rájönnöm. Az egész nagyjából feleakkora, mint egy µATX alaplap, és fizikailag beleillik a 16-bites ISA foglalatba.

[g@by]

Nem annyira kulonleges cucc, csak mivel kurva dragak voltak, nalunk nem volt annyira elterjedt.
Nekunk is volt egy rakas p3-p4-es.
Robo akarmiknek hivtak oket, igy keress ra.
Talan lapom meg mindig van hozza.
Van rajta 8 slot, ennyi kartyat lehet beledugni, es allitolag osszeadodik a teljesitmenyuk.

[NEUROFiRE]

Idézet: g@by - Dátum: 2010. 03. 25. 00:23

Nem annyira kulonleges cucc, csak mivel kurva dragak voltak, nalunk nem volt annyira elterjedt.
Nekunk is volt egy rakas p3-p4-es.
Robo akarmiknek hivtak oket, igy keress ra.
Talan lapom meg mindig van hozza.
Van rajta 8 slot, ennyi kartyat lehet beledugni, es allitolag osszeadodik a teljesitmenyuk.

Portwell Robo* kartyaitok voltak, a backplane-en nem 8 slot van, hanem tobb, es _egy_ SBC kartyat lehet beletenni, a tobbi slotba pedig normal kartyakat, miny egy akarmilyen PC-be.
Ha tobb SBC-t teszel bele, akkor a teljesitmeny nem osszeadodik, hanem kivonodik (nem mukodik egyik sem, ill. nagyon jo esetben talan az egyik elindul valamennyire, aztan vagy lerohad vagy nem).

Mac-ekkel miven? :D

[alvaro]

Idézet: Sparow2 - Dátum: 2010. 03. 16. 21:28

A Prince nem ment CGA-n normális grafikával???

De ment, nekem volt CGA-m, később azt a monitort küldtem meg S3 trióval 640*480 16 biten, interlaced-ben. Kicsit reszelni kellett a 3D4/3D5 és társai regiszterekkel (debugoltam hozzá a BIOSt néhány videomódváltás erejéig), meg forrasztani hozzá egy 9->15 tűs átalakítót, de ment vele a QPV meg a win3.1
Akkor még nem telt másik monitorra, na

[g@by]

Idézet

Portwell Robo* kartyaitok voltak, a backplane-en nem 8 slot van, hanem tobb, es _egy_ SBC kartyat lehet beletenni, a tobbi slotba pedig normal kartyakat, miny egy akarmilyen PC-be.
Ha tobb SBC-t teszel bele, akkor a teljesitmeny nem osszeadodik, hanem kivonodik (nem mukodik egyik sem, ill. nagyon jo esetben talan az egyik elindul valamennyire, aztan vagy lerohad vagy nem).

Te nagyonsetet.
Csak tudom mar hany slot van rajta.
Egyebkent tobbfele volt belole.
Es nem, nem egy kartyat lehet beletenni.
A nokiatol jottek a cuccok, es mindegyik slot televolt kartyakkal.
Gondolom ott nem voltak annyira hulyek hozza a rendszergazdak.
Na mind1, inkabb szijjal le.

[Joci]

Idézet: Telcontar - Dátum: 2010. 03. 24. 23:21

Nem hinném, hogy az AMD nagy titokban már ott tartott 7 éve is, hogy nanorobotokkal voltak felszerelve a chipjei, amik aztán a lezúzott sarkokat a törmelékből meg innen-onnan összeszedegetett üvegcserepekből újraépítenék.

Mai nyereményem ellenben egy AMD Am486DX5-133W16BGC chip, fekete színű szignálással. Valami Advantech kártyapécével (procikártyával?) együtt lőttem, utóbbi sem piskóta darab: van rajta procifoglalat, BIOS, 1 db 72 pines DIMM foglalat, 1 IDE, 1 floppy, 1 printer, 1 soros csatlakozó és 1 PS/2-es port, egy Tadiran Lithium gombelem leszedhetetlenül rágyógyítva, meg még két tüskesor (az egyik a hátlap felé kivezetve), amiknek a funkciójára még nem sikerült rájönnöm. Az egész nagyjából feleakkora, mint egy µATX alaplap, és fizikailag beleillik a 16-bites ISA foglalatba.

Jók ezek a kártyák, nekem van vagy' 4-5db ilyen, de működésre nem tudtam bírni őket, ja, igaz, hogy nem is nagyon próbáltam

Olyasmi, mint itt az első négy kártya, nem?

Vitázni meg szerintem kár rajta, hogy hány slot meg összeadódnak e, nem lényeg... kb. kismillió megoldás és rendszer volt.

Szerkesztette: Joci 2010. 03. 25. 08:48 -kor

[Sparow2]

Idézet: Samuraj - Dátum: 2010. 03. 23. 22:42

Igazából nem zavar, csak kezdett furcsa lenni ez a stikli, és a könyvek erről mélyen hallgatnak.

Pedig nem titok. Ezért érdemes word ill. dword határra illeszteni a 2 ill. 4 byte-os adatokat, hogy lehetőleg kerüljék az "átlógást".

Idézet: Samuraj - Dátum: 2010. 03. 23. 22:42

Viszont feltámadt az egyik iP3/733, amit elvileg megsütöttem és le is van sarkazva rendesen! Az athlon-t is felkéne támasztani, az is "csak" megsült.

- Kelj fel és járj, Lázár!
- De hát ő nem Lázár, hanem a Szabó bakter!


Arra vigyázz, hogy egyáltalán nem biztos, hogy jól működik a "feltámadott" processzor.
Ha tudtad, akkor nem szóltam