van 64 MB >128 MB waardevolle upgrade ?
Wesley
Ik wil mijn huidige computersysteem uitbreiden van 64 MB EDO werkgeheugen
naar 128 MB.
Is dit een waardevolle upgrade en is het zijn geld waard? Heeft iemand
ervaring mitet soortgelijke configuratie ?
Ik heb een pentium 200 mmx processor met een Sojo moederbord met daarop
een Intel VX chipset.
Ik heb 512 KB cache en volgends mijn moederbord instructie boekje moet
dit technisch gezien gaan.
Heeft er iemand mischien ook 4 x 72pins 32 edo ram te koop voor mij of
kun je me een adres nooemen waar dit goedkoop te bestellen is.
Alvast bedankt voor jullie reactie,
Wesley
Saturn
waarschijnlijk weet is EDO best traag. Ik denk niet dat het een waardevolle
upgrade zal wezen
Je koopt tenslotte "oud" geheugen.
John Beton
> naar 128 MB.
>
> Is dit een waardevolle upgrade en is het zijn geld waard? Heeft iemand
> ervaring mitet soortgelijke configuratie ?
activiteit bij die bezigheden en wat heb je er voor over?
> Heeft er iemand mischien ook 4 x 72pins 32 edo ram te koop voor mij of
> kun je me een adres nooemen waar dit goedkoop te bestellen is.
http://www.mycom.nl
http://surf.to/pcbuy
gaat je ongeveer 250 a 300 piek kosten.
gjknol
een kans dat je betrekkeleijk trage EDO geheugen helemaal niet meer vooruit
te branden is
gerrit
Wesley heeft geschreven in bericht ...
>Hallo Allemaal,
>
>Ik wil mijn huidige computersysteem uitbreiden van 64 MB EDO werkgeheugen
>naar 128 MB.
>
>Is dit een waardevolle upgrade en is het zijn geld waard? Heeft iemand
>ervaring mitet soortgelijke configuratie ?
>
>Ik heb een pentium 200 mmx processor met een Sojo moederbord met daarop
>een Intel VX chipset.
>
>
>Ik heb 512 KB cache en volgends mijn moederbord instructie boekje moet
>dit technisch gezien gaan.
>
>Heeft er iemand mischien ook 4 x 72pins 32 edo ram te koop voor mij of
>kun je me een adres nooemen waar dit goedkoop te bestellen is.
>
Golgafringram
Je pc wordt langzamer.
--
Er is een theorie die luidt dat als er ooit iemand precies ontdekt waar het
heelal voor is en waarom het er is, dat het dan onmiddellijk zal verdwijnen
en worden vervangen door iets nog bizarders en onverklaarbaarders.
---
Er is een andere theorie die luidt dat dit al gebeurt is.
---
Maurice Janssen
>Je zal waarschijnlijk geen SDRAM kunnen instaleren. Maar zoals je
>waarschijnlijk weet is EDO best traag. Ik denk niet dat het een waardevolle
>upgrade zal wezen
>Je koopt tenslotte "oud" geheugen.
Onzin. Als je nu veel swap nodig hebt dan is het uitbreiden van het
geheugen zeker zinvol.
EDO is misschien iets trager dan SDRAM, het is altijd nog vele malen
sneller dan je harde schijf.
Maurice
--
Maurice Janssen | The best way to accelerate
| a computer running Windows
mau...@warp.xs4all.nl | is at 9.8 m/s^2
dutc...@the-pentagon.com
wesl...@dolfijn.nl (Wesley) wrote:
Ik meen mij te herinneren dat de VX chipset maar tot 64 mb geheugen
kan cachen; al het geheugen boven de 64 mb wordt dan traaaaaaaaaaag.
Is het geld naar mijn mening niet waard. Ook moet je mobo de zgn
'OS2 on board memory > 64 mb' functie in de bios ondersteunen. Als
dat niet het geval is waarschijnlijk dat cache-probleem aan de hand.
> Hallo Allemaal,
>
> Ik wil mijn huidige computersysteem uitbreiden van 64 MB EDO werkgeheugen
> naar 128 MB.
>
> Is dit een waardevolle upgrade en is het zijn geld waard? Heeft iemand
> ervaring mitet soortgelijke configuratie ?
>
> Ik heb een pentium 200 mmx processor met een Sojo moederbord met daarop
> een Intel VX chipset.
>
> Ik heb 512 KB cache en volgends mijn moederbord instructie boekje moet
> dit technisch gezien gaan.
>
> Heeft er iemand mischien ook 4 x 72pins 32 edo ram te koop voor mij of
> kun je me een adres nooemen waar dit goedkoop te bestellen is.
>
> Alvast bedankt voor jullie reactie,
> Wesley
>
-----------== Posted via Deja News, The Discussion Network ==----------
http://www.dejanews.com/ Search, Read, Discuss, or Start Your Own
DvS
>Hallo Allemaal,
>
>Ik wil mijn huidige computersysteem uitbreiden van 64 MB EDO werkgeheugen
>naar 128 MB.
>
>Is dit een waardevolle upgrade en is het zijn geld waard? Heeft iemand
>ervaring mitet soortgelijke configuratie ?
>
>Ik heb een pentium 200 mmx processor met een Sojo moederbord met daarop
>een Intel VX chipset.
>
>Ik heb 512 KB cache en volgends mijn moederbord instructie boekje moet
>dit technisch gezien gaan.
Volgens mij kunnen die intel chipsets niet meer dan 64Mb afcachen.
Resultaat zou dus wel eens een trage pc kunnen zijn.
Dieko
__________________________
For reply by email
Please change the ?? in nl
in my e-mail address.
Maurits
>Volgens mij kunnen die intel chipsets niet meer dan 64Mb afcachen.
>Resultaat zou dus wel eens een trage pc kunnen zijn.
Nee, iets wat steeds weer opduikt in de NG. .. niet gecache dram is
veel sneller dan een swapfile op de HD.
Maurits
joris
Toch niet dat een PC trager wordt als er meer dan 64 MB ram op zit ???
Ik heb zelf 128 MB, kan ik mijn dan systeem sneller maken door 1 Dimm er uit
te halen ??
Ik heb overigens een ABIT TX5 met intel 430 TX chipset.
>Volgens mij kunnen die intel chipsets niet meer dan 64Mb afcachen.
>Resultaat zou dus wel eens een trage pc kunnen zijn.
>
flat...@technologist.com
Het geheugen boven de 64 Mb wordt niet gecached bij de intel TX
chipset. Windows 9x wordt bovenin het geheugen geladen, en dus in het
niet gecachete gedeelte. Daar wordt het dus trager van.
Draai maar eens een benchmarkje, haal er 64 Mb uit en draai die
benchmark nog eens.
Walter
>chipset. Windows 9x wordt bovenin het geheugen geladen, en dus in het
>niet gecachete gedeelte. Daar wordt het dus trager van.
>
>Draai maar eens een benchmarkje, haal er 64 Mb uit en draai die
>benchmark nog eens.
Okee, je PC wordt langzamer. SO WHAT? Het scheelt zegge en schrijve maar 30
procent bij bepaalde toepassingen en dat is nog altijd stukken sneller dan
het wachten op je harddisk als die naar de swapfile gaat schrijven.
Als voorbeeld: Op mijn oude Pentium133 heb ik met Photoshop gewerkt met 32
MB ram en grote foto's (18 MB). Dat gaat dus voor geen meter. Bepaalde
bewerkingen gingen in 5 minuten of zo, en dat is dus echt te gek. Na het
installeren van NOG EENS 32 MB werd het al wat beter (1 minuut), en met NOG
EENS 32 MB erbij (dus totaal nu 96 MB) ging het eindelijk goed (10
seconden). Het oude VX moederbord cachte maar tot 64 MB. Ik heb nooit iets
gemerkt van de vertraging die de laatste 32 MB erbij had moeten opleveren.
De harddisk hield eindelijk op met pruttelen, hoera! De beeldopbouw van de
foto ging ook stukken sneller omdat de foto niet meer steeds vanaf harddisk
afgehaald hoefte te worden. Nu is Photoshop (een van de eerdere versies) een
hopeloos programma dat eigenlijk wel 500 MB kan gebruiken, want na een tijd
werken gaat de PC TOCH WEER naar de harddisk heen en weer schrijven. Maar
goed, het ging hier om een voorbeeld. Later ontdekte ik dat ik de swapfile
van de PC gewoon uit kon zetten toen ik eenmaal voldoende geheugen erin had
zitten.
Moraal van dit verhaal: Meer geheugen werkt soms prima.
Walter
DvS
wrote:
>DvS heeft geschreven in bericht <368f6aee...@news.wxs.nl>...
>
>>Volgens mij kunnen die intel chipsets niet meer dan 64Mb afcachen.
>>Resultaat zou dus wel eens een trage pc kunnen zijn.
>
>Nee, iets wat steeds weer opduikt in de NG. .. niet gecache dram is
>veel sneller dan een swapfile op de HD.
Ja, dat is ook zo, maar windows gebruikt ram op een andere manier dan
een swapfile. De swapfile wordt zo snel mogelijk weer vrij gemaakt,
terwijl ram gewoon wordt doorgebruikt bij het openen en sluiten van
apps.
Windows 95/98 zit al vrij snel boven de 64 Mb als er meer fysieke ram
is en binnen de kortste keren draaien een heleboel windows
systeemfiles in het trage ram. Dat gebeurt bij 64Mb ram + swapfile
niet. Daar zal windows zo snel mogelijk de systeem bestanden naar ram
overbrengen.
Het verhaal is misschien niet helemaal volledig, maar volgens mij is
in het algemeen windows draaien met nietgecachte ram aanzienlijk
trager dan met een swapfile.
Het zou leuk zijn als die bovenste 64Mb als swapfile kon worden
ingesteld. Helaas kan dat niet.
Beetje vreemd idee, maar het zou zeer snel werken.
Het zou een aardige oplossing zijn voor de tx/vx bordjes: 64Mb ram
basis en bijv. 192Mb ramdisk-swapfile. Edo ram wordt toch steeds
makkelijker tweedehands te koop.
De Hoog & Linde
>Nee, iets wat steeds weer opduikt in de NG. .. niet gecache dram is
>veel sneller dan een swapfile op de HD.
Vreemd dat diverse testen toch het tegenovergestelde bewijzen, tot
14 %
Gegroet Ben
De Hoog & Linde
>Wat wil dit Cachen zeggen ???
Het cache-geheugen zit tussen de processor en je werkgeheugen.
Deze cache zorgt ervoor dat alle gegevens die je processor snel nodig
heeft uit het geheugen wordt "klaargezet" zodat de processor het niet
zelf hoeft op te halen uit het werkgeheugen. Dit is dus sneller.
Maar onder andere de moederborden met de Intel TX-chipset cachen maar
tot 64 mb, daarboven moet de processor zelf alles halen >> langzamer
blijkt uit testen.
Gegroet Ben
J.P.C. Overvoorde
> On Sat, 2 Jan 1999 18:41:54 +0100, wesl...@dolfijn.nl (Wesley) wrote:
>
> >Hallo Allemaal,
> >
> >Ik wil mijn huidige computersysteem uitbreiden van 64 MB EDO werkgeheugen
> >naar 128 MB.
> >
> >Is dit een waardevolle upgrade en is het zijn geld waard? Heeft iemand
> >ervaring mitet soortgelijke configuratie ?
> >
> >Ik heb een pentium 200 mmx processor met een Sojo moederbord met daarop
> >een Intel VX chipset.
> >
> >Ik heb 512 KB cache en volgends mijn moederbord instructie boekje moet
> >dit technisch gezien gaan.
> Volgens mij kunnen die intel chipsets niet meer dan 64Mb afcachen.
> Resultaat zou dus wel eens een trage pc kunnen zijn.
>
> Dieko
Alleen de HX cached meer als 64 Mb. De later door Intel geproduceerde chipsets
cachen niet meer dan 64 Mb omdat Intel simpelweg van de Socket 7 afwilde en
daarmee dus een upgrade afdwingt. Dus mocht je nog een "oer" HX board hebben,
heb je mazzel.
Hans
Maurits
De Hoog & Linde heeft geschreven in bericht
<368eacbe...@news.euro.net>...
Dan lees je de verkeerde testen.
De beweging van de lees/schrijfkoppen in een moderne harddisk zijn
minstens 50 maal trager als het standaard SDRAM.
In de praktijk is een machine met meer RAM veel sneller, ook als de
chipset niet meer dan 64Mb kan cachen, omdat de swapfile dat minder
of niet gebruikt wordt.
Maurits
Maurits
>Alleen de HX cached meer als 64 Mb. De later door Intel geproduceerde
chipsets
>cachen niet meer dan 64 Mb omdat Intel simpelweg van de Socket 7 afwilde en
>daarmee dus een upgrade afdwingt. Dus mocht je nog een "oer" HX board
hebben,
>heb je mazzel.
Maar ik dacht niet dat die chipset EDO en SDRAM ondersteund, da's weer
een nadeel. En op sommige borden moet een extra TAG ram geplaatst worden
een Asus T2P4 met HX set had daar bij bepaalde series een aparte voet
( CELP module) voor.
Maurits
Nightmare
Als je grote tot zeer grote bestanden bewerkt, inderdaad. Maar voor
huis-tuin-en-keuken toepassingen vertraagt het behoorlijk. De HX
chipset kan wel cachen tot 512 MB, maar deze ondersteunt weer geen
UDMA enzo...
Burns
Mb kan cachen of geldt dit alleen voor de later geproduceerde HX boarden.
>
>Alleen de HX cached meer als 64 Mb. De later door Intel geproduceerde
chipsets
>cachen niet meer dan 64 Mb omdat Intel simpelweg van de Socket 7 afwilde en
>daarmee dus een upgrade afdwingt. Dus mocht je nog een "oer" HX board
hebben,
>heb je mazzel.
>
> Hans
>
>
Timoer
>ervaring mitet soortgelijke configuratie ?
ja en ja. Kan wel... Hij casht alleen het geheugen boven de 64 MB niet (net
als de TX). Maar met 128 wordt je pc sowieso sneller...
Maurits
Burns heeft geschreven in bericht <76nde4$ng8$1...@pascal.a2000.nl>...
>Uit jouw verhaal begrijp ik dat de LX (later geproduceerd dan de HX) maar
64
>Mb kan cachen of geldt dit alleen voor de later geproduceerde HX boarden.
Het geldt voor de 430 serie chipset dus voor de Pentium Classic en MMX,
niet voor de Pentium II chipset,
De HX kwam al eerste, vrij snel gevolgd door de VX en de TX.
Daarna was voor Intel het slot 7 gebeuren finito. AMD ging echter gewoon
door
ook al door de copyrights op slot-1. In het kielzog van AMD gingen VIA en
ALI
door met de ontwikkeling van nieuwe chipsets voor socket-7 incluis AGP,
100 Mhz bus.
Maurits
Dutchman
7 moederborden (ook gewone dus) kunnen tot 128 of zelfs 256 mb cachen.
Intel Lx en vroege BX chipsets tot 512 mb, de nieuwste gaan waarschijnlijk
tot 1 gigabyte.
Dutchman
Dutchman
Johannes Alberts
Maurits schrieb in Nachricht
>een nadeel. En op sommige borden moet een extra TAG ram geplaatst worden
ik had een p5hx-b mobo van elitegroup met 512KB cache. Toch was de cacheable
area maar 64MB groot omdat het geen plaats voor het TAG ram had.
mvg JOhannes
DvS
>>Moraal van dit verhaal: Meer geheugen werkt soms prima.
>>Walter
>
>Als je grote tot zeer grote bestanden bewerkt, inderdaad. Maar voor
>huis-tuin-en-keuken toepassingen vertraagt het behoorlijk.
Exact.
Uitsluitend voor fotofanaten en scannerfetisjisten is er voordeel.
Ljouwe
Ik heb een GigaByte GA-586DX moederbord met HX chipset. Ik heb er ook
128 mb in zitten, maar heb de TAG niet uitgebreid, weet ook niet of
dat kan. Wordt er nu 128 of slechts 64 mb ge-cached. Wie weet iets
over dit bord.
Rob Janssen
>>Volgens mij kunnen die intel chipsets niet meer dan 64Mb afcachen.
>>Resultaat zou dus wel eens een trage pc kunnen zijn.
>Nee, iets wat steeds weer opduikt in de NG. .. niet gecache dram is
>veel sneller dan een swapfile op de HD.
Je vergeet even dat die extra 64MB gewoon als werkgeheugen gebruikt gaat
worden, niet als swapfile. Heb je pech dan komt een zeer veel gebruikt
gedeelte van je applicatie en/of je operating system nou net in dat trage
geheugen terecht.
Je zou hooguit een RAMDISK kunnen installeren die op de een of andere
manier dat trage geheugen voor zich claimt en waar je dan je swapfile
opzet, dan is het wel snel.
Rob
--
+----------------------------------+--------------------------------------+
| Rob Janssen pe1...@amsat.org | WWWhome: http://www.pe1chl.demon.nl/ |
| AMPRnet: r...@pe1chl.ampr.org | AX.25 BBS: PE1CHL@PI8WNO.#UTR.NLD.EU |
+----------------------------------+--------------------------------------+
John Beton
>
> Je zal waarschijnlijk geen SDRAM kunnen instaleren. Maar zoals je
> waarschijnlijk weet is EDO best traag. Ik denk niet dat het een waardevolle
> upgrade zal wezen
Zoveel scheelt dat dus echt niet he, dat merk je dus never te nooit niet
bij standaard windoos gebruik!!!
John Beton
>
> Volgens mij kan de VX Chip set maar 64 Mb geheugen cachen en je loopt dan
> een kans dat je betrekkeleijk trage EDO geheugen helemaal niet meer vooruit
> te branden is
Nog zo iemand: ONZIN!!
John Beton
>
> Niet doen, de VX chipset kan maar 64 Mb cachen.
> Je pc wordt langzamer.
Is niet waar. BULLSHIT!!!!
John Beton
> een swapfile. De swapfile wordt zo snel mogelijk weer vrij gemaakt,
> terwijl ram gewoon wordt doorgebruikt bij het openen en sluiten van
> apps.
> Windows 95/98 zit al vrij snel boven de 64 Mb als er meer fysieke ram
> is en binnen de kortste keren draaien een heleboel windows
> systeemfiles in het trage ram. Dat gebeurt bij 64Mb ram + swapfile
> niet. Daar zal windows zo snel mogelijk de systeem bestanden naar ram
> overbrengen.
Absolute flauwekul!
Ik heb een TX chipset en draai al ruim een jaar met 128MB EDO. ALLE
testen die ik gedaan heb met 64 en 128MB (ik wilde het echt zeker weten)
kwamen er op neer dat die bak wel degelijk sneller wordt.
Marc
>
> On Sun, 03 Jan 1999 09:04:30 GMT, bl...@anywhere.com (Nightmare) wrote:
>
> >>Moraal van dit verhaal: Meer geheugen werkt soms prima.
> >>Walter
> >
> >Als je grote tot zeer grote bestanden bewerkt, inderdaad. Maar voor
> >huis-tuin-en-keuken toepassingen vertraagt het behoorlijk.
>
> Exact.
> Uitsluitend voor fotofanaten en scannerfetisjisten is er voordeel.
Nog nooit van muziekfreaks gehoord? 100 MB wave files bewerken e.d. :)
Nightmare
wrote:
Oja das waar. Ben je er toevallig zelf zo een ? :-)
DvS
wrote:
Merkwaardig.
Nou zeggen benchmarks ook niet alles.
Heb je de test ook wel eens gedaan nadat je de pc al een tijdje had
lopen, na openen en afsluiten van een aantal grote programma's?
Het kan best zijn dat het een tijdje duurt voordat er systeem
bestanden boven de 64Mb terechtkomen. Tot die tijd merk je voordeel
omdat er niet geswapt hoeft te worden.
Verder lijkt het me dat bij 64Mb ram het starten en stoppen van progs
langer duurt (omdat er geheugen vrijgemaakt moet worden), maar het
gebruik verder sneller gaat (omdat het programma (grotendeels) in snel
ram loopt.
De vraag is wel belang het test programma toe kent aan deze gegevens.
Ik merk bij mijn 64Mb eigenlijk al heel wijnig swapactiviteit. Ik denk
dat windows eerder wat lager geheugen vrijmaakt (niet gebruikte
modules). Dat kost wat tijd. Bij 128Mb gebeurt dat dus niet. Daar
wordt het programma gewoon lekker snel in traag ram gepoot...
Maurits
<36907448...@news.worldonline.nl>...
Er zit 512 Kb cache op dat bord en met een 8bits breed TAG Ram kan die niet
meer dan 128 Mb cachen. De cachable area kan je makkelijk testen met
ctcm16m.zip op http://www.heise.de/ct/ftp/pcconfig.shtml
Mooi bordje,dual pentium scsi onboard, zuinig op wezen ;-)
http://www.giga-byte.com/gigabyte-web/index.htm
Maurits
joris
en mijn systeem (430TX/233MMX) werd inderdaad sneller bevonden met 64MB ram
dan
met 128MB ram.
Kennelijk is het wel degelijk zo dat het 64MB cache verhaal op enige
waarheid berust.
Zoniet dan graag een beargumenteerd verhaal waarom niet !!
DvS
Oh, da's waar. Moet ik ook nog worden als ik lp's ga overzetten naar
cd.
Johannes Alberts
Maurits schrieb in Nachricht <76o81l$m2m$1...@news.telekabel.nl>...
>Ljouwe heeft geschreven in bericht
>>Ik heb een GigaByte GA-586DX moederbord met HX chipset. Ik heb er ook
>>128 mb in zitten, maar heb de TAG niet uitgebreid, weet ook niet of
>>dat kan. Wordt er nu 128 of slechts 64 mb ge-cached. Wie weet iets
>>over dit bord.
>Er zit 512 Kb cache op dat bord en met een 8bits breed TAG Ram kan die niet
>meer dan 128 Mb cachen. De cachable area kan je makkelijk testen met
>
>ctcm16m.zip op http://www.heise.de/ct/ftp/pcconfig.shtml
>
Hi,
"makkelijk" misschien bij Ljouwe (geheugen = cacheable area). Maar _AFAIK_
test ctcm alleen hoeveel geheugen op het mobo gecached is.
mvg JOhannes
P.S. kan iemand ctcm op een mobo met weinig geheugen en een grote cacheable
area testen om mijn _AFAIK_ te bevestigen?
Golgafringram
>> Niet doen, de VX chipset kan maar 64 Mb cachen.
>> Je pc wordt langzamer.
>
>Is niet waar. BULLSHIT!!!!
Kunt u iets genuanceerder zijn ?
VX=Max 64 Mb
HX=Max 256 Mb
TX=Max 64 Mv
Golgafringram
>omdat er niet geswapt hoeft te worden.
Waarom verzin je deze klinkklare onzin.
Om interressant te te doen ?
Of om geleerd over te komen ?
Jammer dat je geen enkel inzicht hebt in het functioneren
van windows.
Het geheugen wordt namelijk van boven naar onder aangesproken.
Daarnaast wordt er gepaged gewerkt hetgeen inhoudt dat
windows waar mogelijk steeds grote vrije stukken geheugen
aanspreekt en evt tijdelijk wegzet naar de swapfile.
Het beeld dat jij schildert komt er op neer dat windows
netjes van "onder" naar "boven" zijn data in het geheugen plaatst.
Dat is dus beslist niet het geval daar er op deze wijze al direct
een geheugen overflow zou ontstaan.
Windows "plaatst" zijn data zodanig in "groepen" dat deze
redelijk eenvoudig kunnen worden gewisseld met de swapfile
Dat houdt dan wel in dat er dus een block-allocate plaatsvindt.
Een nadeel hiervan is trouwens dat, vooral door 16bit software,
er snel een overflow naar onder toe plaatsvindt, resultered in
de zeer bekende fatale uitzonderings fout.
De uitzondering kan zelfs tot in de stack toe lopen en het
effect daarvan is denk ik wel bekend, ondanks de melding dat
het programma werd afgesloten werkt er niets meer naar
behoren en moet je volledig opnieuw opstarten, als het
al geen harde reset moet zijn.
Juist op dit punt wordt er bij M$ het meest verbeterd en dat
is bij win98 tov 95 duidelijk te merken.
Golgafringram
30
>procent bij bepaalde toepassingen en dat is nog altijd stukken sneller dan
>het wachten op je harddisk als die naar de swapfile gaat schrijven.
>Als voorbeeld: Op mijn oude Pentium133 heb ik met Photoshop gewerkt met 32
>MB ram en grote foto's (18 MB). Dat gaat dus voor geen meter. Bepaalde
>bewerkingen gingen in 5 minuten of zo, en dat is dus echt te gek. Na het
>installeren van NOG EENS 32 MB werd het al wat beter (1 minuut), en met NOG
>EENS 32 MB erbij (dus totaal nu 96 MB) ging het eindelijk goed (10
>seconden). Het oude VX moederbord cachte maar tot 64 MB. Ik heb nooit iets
>gemerkt van de vertraging die de laatste 32 MB erbij had moeten opleveren.
Je kunt zonder moeite nog wat andere dingen doen
om windows wat op te stoken.
-Allocate een permanente swapfile op een separate partitie.
(iets groter dan 2,5 keer je fysieke geheugen)
-Zet de spindown uit van de harde schijven.
Maurits
>Je kunt zonder moeite nog wat andere dingen doen
>om windows wat op te stoken.
>-Allocate een permanente swapfile op een separate partitie.
Een swapfile op een andere drive is sneller, data ophalen
met hetzelfde stel lees/schrijfkoppen niet.
Maurits
Walter ter Maten
>Ik heb inderdaad gebenchmarked met o.a. Wintune en Norton systeminfo,
>en mijn systeem (430TX/233MMX) werd inderdaad sneller bevonden met 64MB ram
>dan
>met 128MB ram.
>Kennelijk is het wel degelijk zo dat het 64MB cache verhaal op enige
>waarheid berust.
>Zoniet dan graag een beargumenteerd verhaal waarom niet !!
't is maar wat je test natuurlijk, spelletjes maken bijna geen gebruik
van dat cache gehuegen. Bureau applicaties weer wel..
>
>
>
>
>>Absolute flauwekul!
>>
>>Ik heb een TX chipset en draai al ruim een jaar met 128MB EDO. ALLE
>>testen die ik gedaan heb met 64 en 128MB (ik wilde het echt zeker weten)
>>kwamen er op neer dat die bak wel degelijk sneller wordt.
>>
>>
>
--------------------------------------------------
Walter ter Maten
ICQ: 2929133
Boekverslagen: http://www.IAEhv.nl/users/termaten/netscape/boekvr.htm
It's nice to be important, but it's more important to be nice.
J.P.C. Overvoorde
Op een aparte partitie, vooraan de hd. Is bij de meeste hd's het snelste
gedeelte.
Hans
Edwin van Waes
JB> EDO.
Met een TX chipset van -INTEL-?
Of met een 'TX-PRO' chipset ?
JB> ALLE testen die ik gedaan heb met 64 en 128MB (ik wilde
JB> het echt zeker weten) kwamen er op neer dat die bak wel
JB> degelijk sneller wordt.
i...@ergens.in.nl
wrote:
Qua doorvoer inderdaad het snelste gedeelte, maar niet qua
toegangstijd.
J.F. van Baarlen <baa...@tn.tudelft.nl>
John Beton
> en mijn systeem (430TX/233MMX) werd inderdaad sneller bevonden met 64MB ram
> dan met 128MB ram.
> Kennelijk is het wel degelijk zo dat het 64MB cache verhaal op enige
> waarheid berust.
> Zoniet dan graag een beargumenteerd verhaal waarom niet !!
jaar geleden dat ik er 128MB in heb gezet dus precies alles weten doe ik
ook niet meer. Wel is het systeem in de praktijk merkbaar sneller. Het
verschil tussen 64 en 128 (bij de memory tests) was ovrigens bijna te
verwaarlozen bij Wintune etc... In de praktijk is AL het geheugen
sneller dan een swap-file en daar toe je het toch voor.
John Beton
> >> Niet doen, de VX chipset kan maar 64 Mb cachen.
> >> Je pc wordt langzamer.
> >
> >Is niet waar. BULLSHIT!!!!
>
> Kunt u iets genuanceerder zijn ?
Waarom?
>
> VX=Max 64 Mb
> HX=Max 256 Mb
> TX=Max 64 Mv
Dat klopt maar het is zeker niet waar dat je computer er trager van
wordt, hij wordt gewoon sneller (waarschijnlijk minder veel sneller dan
als het wel gecached zou worden maar hij wordt sneller.)
John Beton
> >> Uitsluitend voor fotofanaten en scannerfetisjisten is er voordeel.
> >
> >Nog nooit van muziekfreaks gehoord? 100 MB wave files bewerken e.d. :)
Nog wat: Video bewerking (doe maar met 48 meg, ik ga toch voor 128 en
hoger...)
3d modelleren :autocad en 3d Studio: Wil je echt niet draaien op 64 Meg.
John Beton
Dutchman wrote:
>
> Let wel: sommige (alle 'nieuwere') Via en Ali chipsets voor socket
> 7 moederborden (ook gewone dus) kunnen tot 128 of zelfs 256 mb cachen.
> Intel Lx en vroege BX chipsets tot 512 mb, de nieuwste gaan waarschijnlijk
> tot 1 gigabyte.
En van die ALI en VIA chipsets wordt weer beweerd dat ze mijlen ver
achter blijven bij die Intel bordjes.
Cyberfaze
John Beton wrote in message <3691074B...@tue.nl>...
En een WinNT server met een dial-up server + IIS?
Marcel
+-----------------------------------------+
| http://www.cyberfaze.demon.nl
| -----------------------------------------+
| Cyberfaze FTP / WWW (ISDN)
| (050) 5267744.
| Log in: gast password: gast
| http://192.168.100.4
| Zet de proxy UIT!
+----------------------------------------+
Andre van de Wijdeven
John Beton wrote in message <36910813...@tue.nl>...
>> Let wel: sommige (alle 'nieuwere') Via en Ali chipsets voor socket
>> 7 moederborden (ook gewone dus) kunnen tot 128 of zelfs 256 mb cachen.
>> Intel Lx en vroege BX chipsets tot 512 mb, de nieuwste gaan
waarschijnlijk
>> tot 1 gigabyte.
440LX en 440BX chipsets ondersteunen natuurlijk helemaal GEEN cache, want
dat zijn chipsets voor de Pentium-2 en Celeron en die hebben de L2 cache op
de CPU.
Oude Pentium-2's kunnen maar 512MB cachen, de nieuwste (met "Katmai" erop)
kunnen net als de Celeron 4GB cachen. De komende jaren is dat voldoende
(elke 3 jaar verdubbelt de hoeveelheid geheugen).
-- Andre
--
Anthony de Vries
John Beton wrote:
Het verschil zit er evenvoudig in of je het extra geheugen ook gebruikt.
Met die extra 64MB is je totaal aan geheugen _gemiddeld_ iets langzamer dan
daarvoor, simpelweg omdat een deel niet gecached wordt.
Wanneer je dus _totaal geen behoeft_ had aan dat extra geheugen, wordt je systeem
dus inderdaad langzamer.
Benchmarks laat je i.h.a. draaien zonder dat andere programma's bezig zijn, en
vragen meestal niet erg veel geheugen, en bepalen dus deze situatie.
In de praktijk heb je dat extra geheugen om zwaar swappen te vermijden. In dat
geval is je computer veel en veel sneller dan met de helft geheugen. Dat het
geheugen an sich een paar procent langzamer is geworden is totaal verwaarloosbaar
met het verlies als je de harddisk moet aanspreken voor de swapfile.
Die situatie wordt door benchmarks meestal niet getest.
Anthony.
Anthony de Vries
John Beton wrote:
> > >> Exact.
> > >> Uitsluitend voor fotofanaten en scannerfetisjisten is er voordeel.
> > >
> > >Nog nooit van muziekfreaks gehoord? 100 MB wave files bewerken e.d. :)
>
> Nog wat: Video bewerking (doe maar met 48 meg, ik ga toch voor 128 en
> hoger...)
Meer dan 64MB is totaal nutteloos. Dat geheugen wordt praktisch niet
gebruikt. Slechts de CPU en Harddisk zijn belangrijk.
Anthony.
Anthony de Vries
John Beton wrote:
> Dutchman wrote:
> >
> > Let wel: sommige (alle 'nieuwere') Via en Ali chipsets voor socket
> > 7 moederborden (ook gewone dus) kunnen tot 128 of zelfs 256 mb cachen.
> > Intel Lx en vroege BX chipsets tot 512 mb, de nieuwste gaan waarschijnlijk
> > tot 1 gigabyte.
>
> En van die ALI en VIA chipsets wordt weer beweerd dat ze mijlen ver
> achter blijven bij die Intel bordjes.
Door wie? Vrijwel alle tests laten juist het omgekeerde zien.
Anthony.
Peter den Haan
>'t is maar wat je test natuurlijk, spelletjes maken bijna geen gebruik
>van dat cache gehuegen. Bureau applicaties weer wel..
Natuurlijk. Daarom was de oude Celeron zo'n fan-tas-tische processor en
hebben alle spelletjesfanaten meteen zo'n ding gekocht (dat-ie flink te
overclocken viel was een bijkomstigheid).
- Peter
--
see Reply-To for e-mail address http://thef-nym.sci.kun.nl/%7Epieterh/
Peter den Haan
>Golgafringram wrote:
>
>> Niet doen, de VX chipset kan maar 64 Mb cachen.
>> Je pc wordt langzamer.
>
>Is niet waar. BULLSHIT!!!!
In jouw geval, met jouw software, werd-ie niet langzamer, dus verkoopt
iedereen die daarvoor waarschuwt "bullshit". Zeg, die nick van jou,
slaat die toevallig op de voor gedachtenprocessen gebruikte substantie?
Bertus Bouwplaats Blubber
Die ouwe bordjes he, de socket 7, die zijn veel trager dan die TX
bordjes. Daarom werd ook overal aangeraden om die TX toch te nemen (al
kon hij maar 64MB cachen, dan nog was hij veel sneller dan die ALI en
VIA chipsets.) Dit heeft onderandere in de PCM en wat andere bladen
gestaan, ook in vele ng's en ik geloof ook bij Tomshardware.
Bertus Bouwplaats Blubber
> Het verschil zit er evenvoudig in of je het extra geheugen ook gebruikt.
> Met die extra 64MB is je totaal aan geheugen _gemiddeld_ iets langzamer dan
> daarvoor, simpelweg omdat een deel niet gecached wordt.
> Wanneer je dus _totaal geen behoeft_ had aan dat extra geheugen, wordt je systeem
> dus inderdaad langzamer.
> Benchmarks laat je i.h.a. draaien zonder dat andere programma's bezig zijn, en
> vragen meestal niet erg veel geheugen, en bepalen dus deze situatie.
>
> In de praktijk heb je dat extra geheugen om zwaar swappen te vermijden. In dat
> geval is je computer veel en veel sneller dan met de helft geheugen. Dat het
> geheugen an sich een paar procent langzamer is geworden is totaal verwaarloosbaar
> met het verlies als je de harddisk moet aanspreken voor de swapfile.
> Die situatie wordt door benchmarks meestal niet getest.
Kijk en dat bedoel ik nou. In de praktijk zal je bak NOOIT trager worden
door meer geheugen (als je het niet nodig hebt zul je het er ook niet
bij willen zetten lijkt me.) Hier ben ik het zeker wel mee eens.
chinoushisuureichan
Sun, 03 Jan 1999 01:40:45 +0100 deze tekst in het bericht
<368EBC8D...@tue.nl>
| > Volgens mij kan de VX Chip set maar 64 Mb geheugen cachen en je loopt dan
| > een kans dat je betrekkeleijk trage EDO geheugen helemaal niet meer vooruit
| > te branden is
| Nog zo iemand: ONZIN!!
Wijs de fouten aan, argumenteer en verbeter...
iq
--
Ik drink niet, ik vloek niet en ik wed niet en
wedden we godverdomme om een bak bier dat dit waar is?
Bertus Bouwplaats Blubber
> >> Je pc wordt langzamer.
> >
> >Is niet waar. BULLSHIT!!!!
>
> In jouw geval, met jouw software, werd-ie niet langzamer, dus verkoopt
> iedereen die daarvoor waarschuwt "bullshit". Zeg, die nick van jou,
> slaat die toevallig op de voor gedachtenprocessen gebruikte substantie?
Er wordt gewoon een verkeerd advies gegeven. Ik vertel gewoon de andere
kant van het verhaal. In de praktijk zal je computer met meer geheugen
nooit trager worden, daar gaat het de mensen toch om die meer dan 64 MB
willen. Natuuurlijk is gecached geheugen sneller dan niet gecached, maar
dat wil nog steeds niet zeggen dat niet gecached geheugen traag is.
Alles beter dan een swapfile! Mensen die er over denken om 128 MB op een
TX chipset de prikken doen dat echt niet omdat notepad zo traag is. Ik
ga er vanuit dat zij veel met grote bestanden werken en dus extra
geheugen goed kunnen gebruiken. Maar zeg nou zelf eens, noem mij een
programma dat merkbaar trager wordt met meer dan 64MB?
Gerbrand van Dieijen
wesl...@dolfijn.nl says...
> Hallo Allemaal,
>
> Ik wil mijn huidige computersysteem uitbreiden van 64 MB EDO werkgeheugen
> naar 128 MB.
>
> Is dit een waardevolle upgrade en is het zijn geld waard? Heeft iemand
> ervaring mitet soortgelijke configuratie ?
>
> Ik heb een pentium 200 mmx processor met een Sojo moederbord met daarop
> een Intel VX chipset.
>
Dat cachen moet je nu wel duidelijk wezen, je systeem kan sneller worden
(als je geheugen vretende apps gebruikt), maar ik zou gewoon een gehele
system-upgrade doen, nieuw moederbord, nieuwe prosessor (PII 300 ofzo),
100MHz SDRAM (128MB of 256MB dimm), kost wel meer, maar je hebt er veel
meer aan. Zulke kleine upgrades zijn een stuk minder leuk (je merkt er
minder van).
--
Groeten,
Gerbrand
€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€€
ICQ-UIN: 19345450
bezoek mijn homepage: http://www.twisted.demon.nl
Rik
<Ant...@arago.utwente.nl> wrote:
>
>
>John Beton wrote:
>
>> > Ik heb inderdaad gebenchmarked met o.a. Wintune en Norton systeminfo,
>> > en mijn systeem (430TX/233MMX) werd inderdaad sneller bevonden met 64MB ram
>> > dan met 128MB ram.
>> > Kennelijk is het wel degelijk zo dat het 64MB cache verhaal op enige
>> > waarheid berust.
>> > Zoniet dan graag een beargumenteerd verhaal waarom niet !!
>> Bij mij werd die bak met dezelfde prog sneller. Het is nu ongeveer een
>> jaar geleden dat ik er 128MB in heb gezet dus precies alles weten doe ik
>> ook niet meer. Wel is het systeem in de praktijk merkbaar sneller. Het
>> verschil tussen 64 en 128 (bij de memory tests) was ovrigens bijna te
>> verwaarlozen bij Wintune etc... In de praktijk is AL het geheugen
>> sneller dan een swap-file en daar toe je het toch voor.
>
>Het verschil zit er evenvoudig in of je het extra geheugen ook gebruikt.
Maar iemand merkte op dat windows bovenin het geheugen wordt
geladen...klopt dat dan niet?
>Met die extra 64MB is je totaal aan geheugen _gemiddeld_ iets langzamer dan
>daarvoor, simpelweg omdat een deel niet gecached wordt.
>Wanneer je dus _totaal geen behoeft_ had aan dat extra geheugen, wordt je systeem
>dus inderdaad langzamer.
>Benchmarks laat je i.h.a. draaien zonder dat andere programma's bezig zijn, en
>vragen meestal niet erg veel geheugen, en bepalen dus deze situatie.
>
>In de praktijk heb je dat extra geheugen om zwaar swappen te vermijden. In dat
>geval is je computer veel en veel sneller dan met de helft geheugen. Dat het
>geheugen an sich een paar procent langzamer is geworden is totaal verwaarloosbaar
>met het verlies als je de harddisk moet aanspreken voor de swapfile.
>Die situatie wordt door benchmarks meestal niet getest.
>
>
>Anthony.
Gr. Rik.
----------------------------------------------------------------
Remove: "Mapson" in email-adress to reply!
Peter den Haan
>Kijk en dat bedoel ik nou. In de praktijk zal je bak NOOIT trager worden
>door meer geheugen (als je het niet nodig hebt zul je het er ook niet
>bij willen zetten lijkt me.)
Kijk en dat bedoel _ik_ nou: dit soort algemene uitspraken zijn vrijwel
altijd onzin. Ook nu. Kijk, stel ik gebruik PhotoShop en da's toch best
aan het swappen. Prik er 64MB bij, presto, alles twee keer zo snel (zou
twee-en-een-half zijn als alle geheugen gecached zou zijn). Dan ontdek
ik dat al mijn andere applicaties 10-20% langzamer zijn geworden. Kan.
Gloep.
- Peter
Merijn Bosma
>geladen...klopt dat dan niet?
helaas klopt dat wel...
dat is ook het argument waar de meeste mensen over struikelen...
als je windows kon vertellen niet helemaal bovenin te gaan zitten
was er al geen probleem meer...
Merijn Bosma
Anthony de Vries
Merijn Bosma wrote:
Nou dacht ik dat slechts een heeeel klein stukje bovenin werd geladen.
Om te zorgen dat Win32 minder makkelijk te porten is naar bijvoorbeeld
OS/2.
Anthony.
Anthony de Vries
Bertus Bouwplaats Blubber wrote:
Ach, kom nou! Die TX was juist helemaal niet erg snel. Tom raadde de TX ten
zeerste af, en daar was Intel helemaal niet zo erg blij mee.
Anthony.
DvS
Ik had ooit (heeel lang geleden) een 486 op een bord dat maar 16Mb kon
cachen. Dat ontdekte ik dus toen ik er 32 inprikte. Het hייft me wat
moeite gekost om de oorzaak te vinden zeg!
Die gebeurde er (bij 32Mb) namelijk:
Opstarten van win95 verliep volkomen normaal tot bijna het eind van de
procedure. Ineens verliep alles in slowmotion. Ook alles wat ik verder
nog deed.
Inderdaad bijna geen swappen, maar trבבg!
Gauw er weer uitgehaald dus en maar weer met 16Mb gaan draaien. Dat
swappen (meestal alleen) bij afsluiten en starten van software was mee
te leven.
Ik kreeg dus de indruk dat windows NIET bovenin laadt, maar onderin
begint (opstarten verliep normaal). Op een gegeven moment was dan de
16Mb vol en kwam de rest in ongecached geheugen terecht (laden
langzaam).
Dieko
__________________________
For reply by email
Please change the ?? in nl
in my e-mail address.
Marco F.E.J. Frissen
>
> Hallo Allemaal,
>
> Ik heb een pentium 200 mmx processor met een Sojo moederbord met daarop
> een Intel VX chipset.
>
SIMM, hoewel ik die nooit gezien heb).
Of het een nuttige upgrade is hangt helemaal van je OS af. Win95
adresseert maximaal 64Meg, en die ander 64 hangen er dan maar bij.
Gebruik je Linux, WinNT of BeOS kun je er wel van profiteren, mits je
ook zoveel draait dat je geheugen ook echt gebruikt wordt.. kan me iets
indenken als audio/video manipulatie.
Just my 5 (euro)cents,
Marco
--
Marco F.E.J. Frissen fris...@ce.philips.nl
-----BEGIN GEEK CODE BLOCK-----
Version: 3.1
GCS d+ s+:+ a- C++ ULS+++ P+(+++) L++ E--- W++ N++ o K+ w--- O- M V-
PS++(+) PE Y+
PGP++ t+ 5 X+ R- tv+ b+ DI(++) D+ G++ e++ h--- r+++ y+++**
-----END GEEK CODE BLOCK-----
Does the Little Mermaid wear an algebra?
William C. Actus
>Wesley wrote:
>>
>> Hallo Allemaal,
>>
>Of het een nuttige upgrade is hangt helemaal van je OS af. Win95
>adresseert maximaal 64Meg, en die ander 64 hangen er dan maar bij.
.. voor de n-de maal dezelfde zever .. lezen mensen nooit wat ??
good grief ..!
Oenck Taa'G
> geen idee of je MB dit kan.. zal wel, mijn 486 kon al tot 256M (4*64M
> SIMM, hoewel ik die nooit gezien heb).
>
> Of het een nuttige upgrade is hangt helemaal van je OS af. Win95
> adresseert maximaal 64Meg, en die ander 64 hangen er dan maar bij.
PARDON!!!
Win95 draait gewoon met 128Mb hoor, een tijdje geleden deden deze geruchten
ook al de ronde, maar het licht niet een Win95 maar aan de gebruikte chipset
( Intel TX, deze kan maar 64 Meg cachen).
Oenck Taa'G
Anthony de Vries
Oenck Taa'G wrote:
En zelfs dan hangt die 64Mb er niet zomaar bij, maar werkt het gewoon, zij het
niet gecached.
Anthony.
Dennis
Oenck Taa'G <Oenc...@the-pentagon.com> wrote:
>> geen idee of je MB dit kan.. zal wel, mijn 486 kon al tot 256M (4*64M
>> SIMM, hoewel ik die nooit gezien heb).
>>
>> Of het een nuttige upgrade is hangt helemaal van je OS af. Win95
>> adresseert maximaal 64Meg, en die ander 64 hangen er dan maar bij.
> PARDON!!!
> Win95 draait gewoon met 128Mb hoor, een tijdje geleden deden deze geruchten
> ook al de ronde, maar het licht niet een Win95 maar aan de gebruikte chipset
> ( Intel TX, deze kan maar 64 Meg cachen).
En zelfs dan worden de andere 64 MB gewoon gebruikt, alleen trager!
Dennis.
--
E-mail @ work : Dennis...@ehv.ce.philips.com
E-mail @ home : dennis...@pts.nl
Homepage : http://home.wirehub.net/~pts00192
Bertus Bouwplaats Blubber
Premiere wel eens gedraait op 64MB, nou ik ga echt voor die 128 als je
het niet erg vind!
J.P.C. Overvoorde
Lijkt mij toch prettiger om Premiere, Photoshop en co. met zo veel mogelijk RAM
te draaien. Ooit wel eens Illustrator met 48 Mb geprobeerd te draaien? Gaap......
Hoeveel RAM je ook hebt, het zal zelden gebeuren, dat het niet volledig gebruikt
wordt. Tevens vult Windows het RAM van boven naar onderen. Heb je 128 Mb RAM,
worden eerst de laatste segmenten gevuld, aflopend naar onderen, dus daar wordt
zeker wel gebruikt van gemaakt :-) En zeker voor de ultieme bewerking: een
RAMdisk aanleggen, zodat rendering van muziek razendveel sneller gaat dan via een
HD en een RAMdisk voor printerspooling, gaat toch wel wat beter bij het printen
van 40 Mb plaatjes.
Hans
Gerbrand van Dieijen
says...
> geen idee of je MB dit kan.. zal wel, mijn 486 kon al tot 256M (4*64M
> SIMM, hoewel ik die nooit gezien heb).
>
> Of het een nuttige upgrade is hangt helemaal van je OS af. Win95
> adresseert maximaal 64Meg, en die ander 64 hangen er dan maar bij.
> Gebruik je Linux, WinNT of BeOS kun je er wel van profiteren, mits je
> ook zoveel draait dat je geheugen ook echt gebruikt wordt.. kan me iets
> indenken als audio/video manipulatie.
>
Windows 95/98 is 32bit, dus die zou gewoon tot 4GB kunnen adresseren.
Windows 3 kon maximaal 64MB adresseren, omdat het 16bit was. BeOS is
overigens 64Bit, dus die kan eh, heel veel geheugen adresseren. Dit
laatste is vooral nuttig omdat BeOS voornamelijk/alleen voor gravische
doeleinden wordt gebruikt.
Ik hoor trouwens wel vaker dat Windows 95 maar tot 64MB kan, hoewel dit
in theorie niet zo is, zou ik toch wel willen weten of iemand een
praktijkvoorbeeld heeft van Windows 95 met meer dan 64MB, voor de
zekerheid (of een document van Microsoft).
Anthony de Vries
J.P.C. Overvoorde wrote:
> Bertus Bouwplaats Blubber wrote:
>
> > > > > >> Exact.
> > > > > >> Uitsluitend voor fotofanaten en scannerfetisjisten is er voordeel.
> > > > > >
> > > > > >Nog nooit van muziekfreaks gehoord? 100 MB wave files bewerken e.d. :)
> > > >
> > > > Nog wat: Video bewerking (doe maar met 48 meg, ik ga toch voor 128 en
> > > > hoger...)
> > >
> > > Meer dan 64MB is totaal nutteloos. Dat geheugen wordt praktisch niet
> > > gebruikt. Slechts de CPU en Harddisk zijn belangrijk.
> >
> > Premiere wel eens gedraait op 64MB, nou ik ga echt voor die 128 als je
> > het niet erg vind!
Ja, ik heb inderdaad Premiere op 64MB gedraaid. Ik heb namelijk een Miro DV300 en IBM
9GB 10.000 toeren schijf voor DV videobewerking. Dat werkt dus uitstekend.
Absoluut totaal GEEN ENKEL PROBLEEM! Premiere gebruikt relatief weinig geheugen.
Complete 1 uurs banden gemaakt, met stapels overgangen, en stapels kleine stukjes,
compleet door elkaar gehusseld.
Als je met 64MB problemen hebt met Premiere, dan ligt dat aan de instellingen of
programma's van de rest van het systeem, NIET aan Premiere zelf.
> Lijkt mij toch prettiger om Premiere, Photoshop en co. met zo veel mogelijk RAM
> te draaien.
Premiere niet. Photoshop kan het inderdaad nodig hebben, afhankelijk van het werk
dat je er mee doet. Bitmaps staan in vrijwel iedere programma tekenprogramma (met
als grote uitzondering: Colorworks van SPG) zonder compressie in het geheugen.
Als er dan ook nog bewerkingen op moeten worden uitgevoerd moet je tot 4 maal zoveel
geheugen hebben, als het oorspronkelijke plaatje.
Voor plaatjes op een website kun je perfect met 32Mb uit, voor werk met meer pixels,
bijvoorbeeld voor grote posters, schieten de geheugen eisen inderdaad heel hard
omhoog.
> Ooit wel eens Illustrator met 48 Mb geprobeerd te draaien? Gaap......
Ja. En met 32, 64, en met 128 MB. Illustrator is zo'n programma dat geheugen
nodig heeft, naar gelang van de grootte van je werk, EN naar gelang je andere
programma's er tegelijk naast gebruikt. Adobe Dimensions staat er bij mij
bijvoorbeeld vrijwel constant naast open.
> Hoeveel RAM je ook hebt, het zal zelden gebeuren, dat het niet volledig gebruikt
> wordt.
Dat denk je dan verkeert. Die situatie komt vrij vaak voor op mijn twee 128MB
systemen.
Verder wil het ook helemaal niets zeggen als er uberhaupt data in je geheugen staat.
De hoeveelheid ram die je nodig is, wordt bepaald door de fysieke geheugeneisen van
je programma. Zolang je programmatuur niet bij het normale gebruik gaat swappen, heb
je voldoende geheugen. In de meeste gevallen staat er dan nog eens eenzelfde
hoeveelheid data in de swapfile, maar dit wordt nooit allemaal op hetzelfde moment
gebruikt. Zaken die niet gebruikt worden, hoeven ook niet in het fysieke geheugen te
staan.
>Tevens vult Windows het RAM van boven naar onderen. Heb je 128 Mb RAM,
> worden eerst de laatste segmenten gevuld, aflopend naar onderen, dus daar wordt
> zeker wel gebruikt van gemaakt :-)
Helaas, zo simpel werkt Windows dus niet.
> En zeker voor de ultieme bewerking: een
> RAMdisk aanleggen, zodat rendering van muziek razendveel sneller gaat dan via een
> HD en een RAMdisk voor printerspooling, gaat toch wel wat beter bij het printen
> van 40 Mb plaatjes.
Laten we gelijk een 1 GB ramdisk aanleggen als vervanging voor je harde schijf.
Starten Windows en Illustrator ook veel sneller op.
Oh... en ook nog een 20 GB ramdisk voor mijn DV data. Dat maakt het ook veel
makkelijker om mijn filmpjes te monteren. Kan ik tenminste realtime werken....
Anthony.
William C. Actus
>In article <36946723...@ce.philips.nl>, fris...@ce.philips.nl
>says...
>
>
>> Of het een nuttige upgrade is hangt helemaal van je OS af. Win95
>> adresseert maximaal 64Meg, en die ander 64 hangen er dan maar bij.
................;;
>Ik hoor trouwens wel vaker dat Windows 95 maar tot 64MB kan, hoewel dit
>in theorie niet zo is, zou ik toch wel willen weten of iemand een
>praktijkvoorbeeld heeft van Windows 95 met meer dan 64MB, voor de
>zekerheid (of een document van Microsoft).
.. er wordt hier wel meer onzin verkocht als waarheid .. en die is
komeetgebonden ttz die komt periodiek terug ...
mmx200 met 128 meg voor de aanmaak van A0 presentatieposters (op
wetenschappelijke congressen ea) die varieren in bestandgrootte van 120
tot 180 meg ... werkt feilloos ..
FWIW
Arno Stet
(Gerbrand van Dieijen) wrote:
>Windows 95/98 is 32bit, dus die zou gewoon tot 4GB kunnen adresseren.
>Windows 3 kon maximaal 64MB adresseren, omdat het 16bit was. BeOS is
Waar komt die conclusie nou weer vandaan?
Gerbrand van Dieijen
> >Windows 95/98 is 32bit, dus die zou gewoon tot 4GB kunnen adresseren.
> >Windows 3 kon maximaal 64MB adresseren, omdat het 16bit was. BeOS is
>
> Waar komt die conclusie nou weer vandaan?
>
32bit=4miljard
16bit=32K, maar met segmenten dus tot 64MB
Wat is er dan mis met mijn redenatie?
--
Gerbrand van Dieijen
ICQ-UIN: 19345450
Visit my homepage: http://www.twisted.demon.nl
Gerbrand van Dieijen
>
> .. er wordt hier wel meer onzin verkocht als waarheid .. en die is
> komeetgebonden ttz die komt periodiek terug ...
>
> mmx200 met 128 meg voor de aanmaak van A0 presentatieposters (op
> wetenschappelijke congressen ea) die varieren in bestandgrootte van 120
> tot 180 meg ... werkt feilloos ..
>
Dacht ik het niet.
Wie heeft dat trouwens ooit verzonnen? Een linux-freak? Een Apple-
evangelist. Of gewoon een dom iemand?
chinoushisuureichan
tekst in het bericht <MPG.110158f59...@news.demon.nl>
| 32bit=4miljard
| 16bit=32K, maar met segmenten dus tot 64MB
Met 32 bit kun je getallen maken tot => 2^32 - 1 (de 0 is nl. ook
een positie) 4 294 967 295. Bij 16 bit is dat 2^16 - 1 => 65 535, en
dus niet ergens in de 32-duizend. Alleen als je ook negatieve getallen
toelaat kun je gaan van -32768 tot 32767.
iq
--
Mooie vrouwen herken je aan hun uiterlijk
http://www.fist.org
Anthony de Vries
Arno Stet wrote:
> On Thu, 7 Jan 1999 21:02:22 +0100, news....@twisted.demon.nl
> (Gerbrand van Dieijen) wrote:
>
> >Windows 95/98 is 32bit, dus die zou gewoon tot 4GB kunnen adresseren.
> >Windows 3 kon maximaal 64MB adresseren, omdat het 16bit was. BeOS is
>
> Waar komt die conclusie nou weer vandaan?
Van een foutive berekening, waar K en M door elkaar worden gehaald?
16 bit => 64 kilobyte (is dus niet 64 megabyte!!!)
20 bit => 1 megabyte
24 bit => 16 megabyte
32 bit => 4 gigabyte
De oude 16bit 8086 processoren hadden een 20 bit geheugenaanwijzing !
Vanaf de 386 kan er tot 32bit geheugen worden aangesproken. Er staat me
iets van een 16MB limiet van de 286 bij de geest, dus ik vermoed dat die
24bit geheugenadressen had.
Eventuele geheugen limieten van windows3.1, hebben dus niets met 16 en
32bit te maken.
Anthony.
Arno Stet
(Gerbrand van Dieijen) wrote:
>In article <36964d4...@news.demon.nl>, remove_u@reply_.to says...
>
>> >Windows 95/98 is 32bit, dus die zou gewoon tot 4GB kunnen adresseren.
>> >Windows 3 kon maximaal 64MB adresseren, omdat het 16bit was. BeOS is
>>
>> Waar komt die conclusie nou weer vandaan?
>>
>32bit=4miljard
>16bit=32K, maar met segmenten dus tot 64MB
>
>Wat is er dan mis met mijn redenatie?
>
Ten eerste snap ik niet hoe je met 16 bits aan 32KB komt (adressen met
een sign bit?) ten tweede snap ik niet hoe je dan aan 64 MB komt
(=2048*32kb wat op 11+16=27 bits zou komen), ten derde werkt een 386+
in real mode met segment/adres paren (waarmee je tot 1 MB komt) of in
enhanced mode met segment selector/adres combinaties waarmee je de
volledige 4 GB beslaat.
Rob Janssen
>Arno Stet wrote:
>> On Thu, 7 Jan 1999 21:02:22 +0100, news....@twisted.demon.nl
>> (Gerbrand van Dieijen) wrote:
>> >Windows 95/98 is 32bit, dus die zou gewoon tot 4GB kunnen adresseren.
>> >Windows 3 kon maximaal 64MB adresseren, omdat het 16bit was. BeOS is
>> Waar komt die conclusie nou weer vandaan?
>Van een foutive berekening, waar K en M door elkaar worden gehaald?
>16 bit => 64 kilobyte (is dus niet 64 megabyte!!!)
>20 bit => 1 megabyte
>24 bit => 16 megabyte
>32 bit => 4 gigabyte
>De oude 16bit 8086 processoren hadden een 20 bit geheugenaanwijzing !
>Vanaf de 386 kan er tot 32bit geheugen worden aangesproken. Er staat me
>iets van een 16MB limiet van de 286 bij de geest, dus ik vermoed dat die
>24bit geheugenadressen had.
>Eventuele geheugen limieten van windows3.1, hebben dus niets met 16 en
>32bit te maken.
Inderdaad, zo zit het. Maar wat Windowsgebruikers met "16 en 32 bit"
bedoelen heeft niks te maken met de breedte van de adressen. Eigenlijk
bedoelen ze met 16 bit de "protected mode" van de processor, waarbij
deze een 24 bit adres kan genereren.
Rob
--
+----------------------------------+--------------------------------------+
| Rob Janssen pe1...@amsat.org | WWWhome: http://www.pe1chl.demon.nl/ |
| AMPRnet: r...@pe1chl.ampr.org | AX.25 BBS: PE1CHL@PI8WNO.#UTR.NLD.EU |
+----------------------------------+--------------------------------------+
Arno Stet
wrote:
>bedoelen ze met 16 bit de "protected mode" van de processor, waarbij
>deze een 24 bit adres kan genereren.
Dat zou dan een limiet van een 286 specifieke versie van Windows zijn,
die heeft (tot eind jaren '80) wel bestaan maar draaide gewoon
dezelfde applicaties als alle andere toenmalige windows versies.
Rob Janssen
"16 bit" dat IS een limiet van de 286 versie, die ze nog steeds meeslepen.
Microsoft heeft een gigantische angst om over te stappen naar "meer bits"
of "meer adresruimte".
En als ze het eindelijk aandurven dan moet er nog een dik marketing stempel
op om aan te geven hoe geweldig het allemaal is dat het ze toch gelukt is.
Dat is door de jaren zo geweest, en nog steeds is het zo dat als je NT
op een Alpha draait dit een 32-bit OS is ipv de 64 bits mode die de Alpha
gewoon aanbiedt en die andere systemen op de Alpha wel supporten.
Nu zitten ze al te puzzelen op een truuk om met 32 bits toch meer dan 4GB
memory te adresseren onder NT, ipv gewoon naar 64 bits over te gaan.
De geschiedenis herhaalt zich, exact dezelfde ramp hebben we al eerder
gezien toen PC operating systems koste wat het kost in "real mode" moesten
blijven draaien en Microsoft het "extended memory" bedacht om meer dan
1MB te kunnen adresseren.
Con Hennekens
wrote:
>Microsoft heeft een gigantische angst om over te stappen naar "meer bits"
>of "meer adresruimte".
>En als ze het eindelijk aandurven dan moet er nog een dik marketing stempel
>op om aan te geven hoe geweldig het allemaal is dat het ze toch gelukt is.
Ja... waar zou dat aan liggen? Een beetje een vastgeroest idee.
>Nu zitten ze al te puzzelen op een truuk om met 32 bits toch meer dan 4GB
>memory te adresseren onder NT, ipv gewoon naar 64 bits over te gaan.
>De geschiedenis herhaalt zich, exact dezelfde ramp hebben we al eerder
>gezien toen PC operating systems koste wat het kost in "real mode" moesten
>blijven draaien en Microsoft het "extended memory" bedacht om meer dan
>1MB te kunnen adresseren.
In plaats van de koe bij de horens te vatten, gaan ze zitten
voortborduren op oude technologie. waarschijnlijk om de economische
levensduur van dat wat ze al hebben te verlengen. Of dat op termijn
werkt...? Je zou verwachten dat innovatie de deur van het afgesloten
tijdperk ook niet dicht hoeft te gooien, plus dat je wellicht een
nieuwe doelgroep aanspreekt. Maar ja. Zal wel onzin wezen, wat Gates
is niet voor niets schatje rijk geworden....
Con
--
Groeten uit Wessem
----- When the tide is high, my tie gets tight. ----
Rob Janssen
>On Tue, 12 Jan 1999 10:19:33 GMT, nom...@pe1chl.demon.nl (Rob Janssen)
>wrote:
>>Microsoft heeft een gigantische angst om over te stappen naar "meer bits"
>>of "meer adresruimte".
>>En als ze het eindelijk aandurven dan moet er nog een dik marketing stempel
>>op om aan te geven hoe geweldig het allemaal is dat het ze toch gelukt is.
>Ja... waar zou dat aan liggen? Een beetje een vastgeroest idee.
Het ligt aan het vastklampen aan "binary compatability" tot in het
absurde. Onder de nieuwste Windows moet je nog steeds van CP/M80 naar
MSDOS 1.1 geconverteerde tekstapplicaties kunnen draaien.
Het gekke is dat "de gebruikers" die "antieke programma's" helemaal niet
willen zien.
Robert-Jan Veldhuizen
wrote:
>Con Hennekens <cte...@plex.nl> wrote:
>>On Tue, 12 Jan 1999 10:19:33 GMT, nom...@pe1chl.demon.nl (Rob Janssen)
>>wrote:
>
>>>Microsoft heeft een gigantische angst om over te stappen naar "meer bits"
>>>of "meer adresruimte".
>>>En als ze het eindelijk aandurven dan moet er nog een dik marketing stempel
>>>op om aan te geven hoe geweldig het allemaal is dat het ze toch gelukt is.
>
>>Ja... waar zou dat aan liggen? Een beetje een vastgeroest idee.
>
>Het ligt aan het vastklampen aan "binary compatability" tot in het
>absurde. Onder de nieuwste Windows moet je nog steeds van CP/M80 naar
>MSDOS 1.1 geconverteerde tekstapplicaties kunnen draaien.
>
>Het gekke is dat "de gebruikers" die "antieke programma's" helemaal niet
>willen zien.
Misschien een bepaalde categorie gebruikers wel? Tenslotte gebruiken
veel bedrijven zelfs ook nog steeds software van *voor* QDOS, bijv. uit
de jaren zestig.
--
Robert-Jan/Zorba
"All a little pathetic, sad even?
Now grow up, go out, and get a life!" - D.I.(1999)
Arno Stet
wrote:
>Arno Stet <remove_u@reply_.to> wrote:
>>On Mon, 11 Jan 1999 10:50:13 GMT, nom...@pe1chl.demon.nl (Rob Janssen)
>>wrote:
>
>>>bedoelen ze met 16 bit de "protected mode" van de processor, waarbij
>>>deze een 24 bit adres kan genereren.
>
>>Dat zou dan een limiet van een 286 specifieke versie van Windows zijn,
>>die heeft (tot eind jaren '80) wel bestaan maar draaide gewoon
>>dezelfde applicaties als alle andere toenmalige windows versies.
>
>"16 bit" dat IS een limiet van de 286 versie, die ze nog steeds meeslepen.
>
Nee, van de 8086 versie, waar in principe alle 16 bits windows
software gewoon op draait. AFAIK zijn er alleen real mode en Enhanced
mode applicaties dus snap ik nog steeds niet waar die 24 bit/16 MB
limiet vandaan zou komen.
>De geschiedenis herhaalt zich, exact dezelfde ramp hebben we al eerder
>gezien toen PC operating systems koste wat het kost in "real mode" moesten
>blijven draaien en Microsoft het "extended memory" bedacht om meer dan
>1MB te kunnen adresseren.
>
Voor die tijd had je toch al lang LIM-EMS waarvan Microsoft maar 1 van
drie van LIM was (Lotus en Intel de andere twee). Ik denk bovendien
dat als het aan MS gelegen had iedereen al veel sneller op Windows
over was gestapt. MS had DOS al zo'n beetje dood verklaard maar
massa's gebruikers blijven er met extenders en alles vandien aan vast
houden.
Anthony de Vries
Arno Stet wrote:
> On Tue, 12 Jan 1999 10:19:33 GMT, nom...@pe1chl.demon.nl (Rob Janssen)
> wrote:
>
> >Arno Stet <remove_u@reply_.to> wrote:
> >>On Mon, 11 Jan 1999 10:50:13 GMT, nom...@pe1chl.demon.nl (Rob Janssen)
> >>wrote:
> >
> >>>bedoelen ze met 16 bit de "protected mode" van de processor, waarbij
> >>>deze een 24 bit adres kan genereren.
> >
> >>Dat zou dan een limiet van een 286 specifieke versie van Windows zijn,
> >>die heeft (tot eind jaren '80) wel bestaan maar draaide gewoon
> >>dezelfde applicaties als alle andere toenmalige windows versies.
> >
> >"16 bit" dat IS een limiet van de 286 versie, die ze nog steeds meeslepen.
> >
> Nee, van de 8086 versie, waar in principe alle 16 bits windows
> software gewoon op draait. AFAIK zijn er alleen real mode en Enhanced
> mode applicaties dus snap ik nog steeds niet waar die 24 bit/16 MB
> limiet vandaan zou komen.
Dat komt omdat je 16bit code, en 16bit geheugen adresruimte door elkaar haalt.
De 8086 had al een 20bit geheugen adres ruimte. Dat levert die 1MB op,
waarvan alleen de onderste 640 KB direct bruikbaar is als werkgeheugen. Daar
komt ook de segmentering vandaan, die je in 16bit applicaties aantreft. De
maximale grootte van een aangesloten stuk geheugen dat je met 16bit adresseert
is 64KB. Wil je meer geheugen aanwijzen, dan heb je tweemaal 16bit nodig.
Een processor met een 24bit geheugenadres ruimte, en nog gewoon 16bit code, is
niet zo'n rare stap dus t.o.v. de 8086 met 20bit. Vandaar de 286.
Pas bij de 386 wordt het weer gelijk getrokken, en zijn beide onderdelen
32bits. Maarja... de huidige MS software is nog steeds niet zover dat ze alle
mogelijkheden van de 386 gebruiken, laat staan de nieuwere generaties.
> >De geschiedenis herhaalt zich, exact dezelfde ramp hebben we al eerder
> >gezien toen PC operating systems koste wat het kost in "real mode" moesten
> >blijven draaien en Microsoft het "extended memory" bedacht om meer dan
> >1MB te kunnen adresseren.
> >
> Voor die tijd had je toch al lang LIM-EMS waarvan Microsoft maar 1 van
> drie van LIM was (Lotus en Intel de andere twee). Ik denk bovendien
> dat als het aan MS gelegen had iedereen al veel sneller op Windows
> over was gestapt. MS had DOS al zo'n beetje dood verklaard maar
> massa's gebruikers blijven er met extenders en alles vandien aan vast
> houden.
Dat gedoe met extenders doet Windows zelfs nu nog steeds, dus dat lijkt me niet
een erg valide argument. Wie van de extenders af wilde, moest gewoon OS/2
gebruiken.
Technisch gezien zijn die geheugen extenders natuurlijk verschrikkelijk, maar
in de praktijk was de situatie juist ongekeert. Dos programma's waren lekker
klein, en kon je met weinig geheugen soepel draaien. OS/2 en Windows, hadden
juist veel zwaardere systeem eisen, zonder dat de consument daar zoveel van
terug zag.
Anthony.
Arno Stet
<Ant...@arago.utwente.nl> wrote:
>Een processor met een 24bit geheugenadres ruimte, en nog gewoon 16bit code, is
>niet zo'n rare stap dus t.o.v. de 8086 met 20bit. Vandaar de 286.
Zoals ik al aangaf, ik ben nog nooit een Windows programma
tegengekomen dat daartoe in staat is (24 bit pointers in real mode
code?) maar misschien heb jij een goed voorbeeld?
>Pas bij de 386 wordt het weer gelijk getrokken, en zijn beide onderdelen
>32bits. Maarja... de huidige MS software is nog steeds niet zover dat ze alle
>mogelijkheden van de 386 gebruiken, laat staan de nieuwere generaties.
>
Welke spectaculaire mogelijkheden van de 386 heeft MS al die jaren
laten liggen?
>Dat gedoe met extenders doet Windows zelfs nu nog steeds, dus dat lijkt me niet
>een erg valide argument. Wie van de extenders af wilde, moest gewoon OS/2
>gebruiken.
>
Het kan niet waar zijn, weer zo'n aahanger van het Windows is een DOS
extender geloof, ze zijn nog steeds niet uitgestorven.
>Technisch gezien zijn die geheugen extenders natuurlijk verschrikkelijk, maar
>in de praktijk was de situatie juist ongekeert. Dos programma's waren lekker
>klein, en kon je met weinig geheugen soepel draaien. OS/2 en Windows, hadden
>juist veel zwaardere systeem eisen, zonder dat de consument daar zoveel van
>terug zag.
>
Lekker ja, vooral met spelletjes, en iedereen zijn eigen drivers
ontwerpen voor beeld, geluid etc. die natuurlijk weer incompatible
waren met de helft van de hardware. Overigens is het vrij logisch dat
je minder geheugen nodig hebt als je geen OS hebt geladen en alleen de
noodzakelijke code voor een spelletje o.i.d.
Rob Janssen
>On Wed, 13 Jan 1999 09:34:36 +0100, Anthony de Vries
><Ant...@arago.utwente.nl> wrote:
>>Een processor met een 24bit geheugenadres ruimte, en nog gewoon 16bit code, is
>>niet zo'n rare stap dus t.o.v. de 8086 met 20bit. Vandaar de 286.
>Zoals ik al aangaf, ik ben nog nooit een Windows programma
>tegengekomen dat daartoe in staat is (24 bit pointers in real mode
>code?) maar misschien heb jij een goed voorbeeld?
Volgens mij zijn alle DOS-extender programma's (bijv gemaakt met DOS/16M)
hier voorbeelden van. Of er ook Windows programma's gemaakt zijn met
dergelijke extenders weet ik niet.
>>Pas bij de 386 wordt het weer gelijk getrokken, en zijn beide onderdelen
>>32bits. Maarja... de huidige MS software is nog steeds niet zover dat ze alle
>>mogelijkheden van de 386 gebruiken, laat staan de nieuwere generaties.
>Welke spectaculaire mogelijkheden van de 386 heeft MS al die jaren
>laten liggen?
Een voorbeeld: virtualisatie van hardware interfaces. Het is in een
Windows omgeving kennelijk niet mogelijk om een (DOS) programma te laten
geloven dat er op I/O adressen 3F8-3FF een 16550 UART te vinden is, terwijl
dit in werkelijkheid niet zo is (of er daar wel een UART zit maar niet
degene die je door het programma wilt laten aanspreken).
Hier lopen de gebruikers van domme DOS programma's die rechtstreeks de
COM poorten aanspreken tegenaan. "Telebankieren" programma's vallen
meestal in die categorie. Met dergelijke programma's is het dan niet
mogelijk om een "MODEM" te benaderen wat niet fysiek bestaat maar wordt
geemuleerd met een clever stukje DSP software en een ISDN kaart.
De 386 support dit echter WEL: je kunt opgeven dat het benaderen van
bepaalde I/O poorten moet worden afgevangen en omgeleid naar een stukje
software. Linux DOSEMU kan dit bijvoorbeeld.
Anthony de Vries
> On Wed, 13 Jan 1999 09:34:36 +0100, Anthony de Vries
> <Ant...@arago.utwente.nl> wrote:
>
> >Een processor met een 24bit geheugenadres ruimte, en nog gewoon 16bit code, is
> >niet zo'n rare stap dus t.o.v. de 8086 met 20bit. Vandaar de 286.
>
> Zoals ik al aangaf, ik ben nog nooit een Windows programma
> tegengekomen dat daartoe in staat is (24 bit pointers in real mode
> code?) maar misschien heb jij een goed voorbeeld?
ALLE dos programma's in real mode, gebruiken 20bit geheugen toekenning. Dat doe je
door twee 16bit pointers te combineren. Gebruik je maar 1 pointer, dan kun je
maximaal 64 KB adressen. Dat is dus 1 segment. Vandaar ook dat in veel
programmeertalen die 64KB limiet duidelijk terugkomt. Zo zie je in Turbo Pascal
bijvoorbeeld dat (in real mode) een variabele maximaal 64KB groot mag zijn, en dat
de stack maximaal 64KB groot is. Dat zijn simpelweg de grenzen waar je met 1 pointer
kan komen. Die zijn dus relatief t.o.v. het segment waarin je zit.
De 286 protected mode werd niet door windows gebruikt, echter wel door OS/2 1.x
> >Pas bij de 386 wordt het weer gelijk getrokken, en zijn beide onderdelen
> >32bits. Maarja... de huidige MS software is nog steeds niet zover dat ze alle
> >mogelijkheden van de 386 gebruiken, laat staan de nieuwere generaties.
> >
> Welke spectaculaire mogelijkheden van de 386 heeft MS al die jaren
> laten liggen?
De protected mode.
Nee, windows draait NIET in protected mode. Het is officieel gezien de virtuele
mode van de chip. Lijkt erg op de protected mode, met dat verschil, dat de
hardware adressen niet geremapped zijn. Ieder willekeurig programma kan dus nog
steeds rechtstreeks naar de hardware schrijven, zolang je maar weet op welk adres
het zit.
Ieder willekeurig programma kan dus ook ieder ander willkeurig programma's laten
crashen.
In de echte protected mode zijn die adressen losgekoppeld. Een willkeurig programma
kan dan fysiek niet naar de hardware schrijven. (Hardware drivers wel uiteraard,
maar die zitten in een andere beschermings ring) Dan zijn de programma's dus fysiek
van elkaar gescheiden.
In OS/2 bestaat die optie voor protected mode wel. Standaard draait dat net als
Windows in virtuele mode. Echter, zet je de optie "protectonly=yes" in de
config.sys, dan gaat OS/2 volledig in protected mode. Dat heeft gelijk tot
consequentie dat het absoluut onmogelijk is om Dos en Windows programma's te
draaien.
In de volksmond wordt echter met protected-mode alles bedoeld wat geen real-mode is,
en zodoende verbasterd de uitdrukking een beetje.
>Dat gedoe met extenders doet Windows zelfs nu nog steeds, dus dat lijkt me niet
> >een erg valide argument. Wie van de extenders af wilde, moest gewoon OS/2
> >gebruiken.
> >
> Het kan niet waar zijn, weer zo'n aahanger van het Windows is een DOS
> extender geloof, ze zijn nog steeds niet uitgestorven.
Wat betreft het concept waar we nu over aan het praten zijn, dus de aansturing van
het geheugen, is windows95 niet anders dan een spelletje dat de Dos4GW extender
gebruikt.
> >Technisch gezien zijn die geheugen extenders natuurlijk verschrikkelijk, maar
> >in de praktijk was de situatie juist ongekeert. Dos programma's waren lekker
> >klein, en kon je met weinig geheugen soepel draaien. OS/2 en Windows, hadden
> >juist veel zwaardere systeem eisen, zonder dat de consument daar zoveel van
> >terug zag.
> >
> Lekker ja, vooral met spelletjes, en iedereen zijn eigen drivers
> ontwerpen voor beeld, geluid etc. die natuurlijk weer incompatible
> waren met de helft van de hardware. Overigens is het vrij logisch dat
> je minder geheugen nodig hebt als je geen OS hebt geladen en alleen de
> noodzakelijke code voor een spelletje o.i.d.
Het voordeel van hardware drivers was er inderdaad wel. Maar in eerste instantie
was daar nog weinig sprake van. Beelscherm drivers waren niet zo interressant,
aangezien iedereen in tekstmode werkte. Wilde je meer, dan kon je met de VGA en VESA
standaard ook goed genoeg uit de voeten.
Zelfde geld voor printers, die in het begin ook redelijk standaard waren. Die
noodzaak van meer standaard drivers bestond dus eigenlijk nog niet zo erg, aangezien
de aansturing vrij standaard was.
Zodoende was dat te weinig reden om op één van beiden over te stappen. Dat er juist
een ram-prijzenoorlog ontketent werd op het moment dat OS/2 werd geintroduceerd, had
ook nogal wat invloed. 4MB ram was plotseling extreem duur, en dan stap je
natuurlijk niet zo snel over.
Wat betreft zaken als spellen is windows, eigenlijk tot het moment van DirectX 5.0
totaal nutteloos geweest. Geluidsdrivers waren allemaal simpel genoeg dat iedereen
die gewoon in het programma inbakte, en datzelfde gold voor de Video kaart, die
eerste standaard VGA, en daarna standaard VESA waren.
Op dit moment is voor velen de situatie zelfs nog simpeler. Bijvoorbeeld vrijwel
iedere geluidskaart die bestaat, is hetzij Soundblaster Pro, hetzij Soundblaster 16
compatible. Daar heb je op zich dus echt geen standaard windows driver voor nodig.
En 3dfx heeft een zodanig groot markt aandeel, dat als er geen DirectX5 was geweest,
alle toekomstige kaarten gewoon 3dfx compatible waren geworden, net zoals dat
vroeger met geluidskaarten is gebeurt.
Anthony.
Anthony de Vries
Rob Janssen wrote:
> >>Pas bij de 386 wordt het weer gelijk getrokken, en zijn beide onderdelen
> >>32bits. Maarja... de huidige MS software is nog steeds niet zover dat ze alle
> >>mogelijkheden van de 386 gebruiken, laat staan de nieuwere generaties.
>
> >Welke spectaculaire mogelijkheden van de 386 heeft MS al die jaren
> >laten liggen?
>
> Een voorbeeld: virtualisatie van hardware interfaces. Het is in een
> Windows omgeving kennelijk niet mogelijk om een (DOS) programma te laten
> geloven dat er op I/O adressen 3F8-3FF een 16550 UART te vinden is, terwijl
> dit in werkelijkheid niet zo is (of er daar wel een UART zit maar niet
> degene die je door het programma wilt laten aanspreken).
> De 386 support dit echter WEL: je kunt opgeven dat het benaderen van
> bepaalde I/O poorten moet worden afgevangen en omgeleid naar een stukje
> software. Linux DOSEMU kan dit bijvoorbeeld.
Dit is de oorspronkelijk protected mode. Die zat al in de 286.
In de 386 komt de virtuele mode, die vrijwel hetzelfde is, maar waar geen
virtualisatie van hardware interfaces zit. Alle hardware adressen zitten waar je
denkt dat ze zitten.
Daarom kun je ook switchen tussen real en virtuele mode (hetgeen iedereen onterecht
ook protected mode noemt). Nu is het ook gelijk duidelijk waarom daar in je 286 een
reboot voor nodig was. Je kon wel van real naar protected mode, maar niet zomaar
eventjes terug.
Het was dus niet de 286 die een hersenbeschadiging had, zoals Mr. Gates dat
uitdrukte, maar juist de software die op zo'n vreemde manier tussen 2 modes ging heen
en weer springen zoals windows dat doet.
Anthony.
Rene Kellenbach
>> Welke spectaculaire mogelijkheden van de 386 heeft MS al die jaren
>> laten liggen?
>
>De protected mode.
>Nee, windows draait NIET in protected mode. Het is officieel gezien de virtuele
>mode van de chip.
Windows (ik neem even aan dat je over Win95/Win98 praat) loopt voor
een groot deel wel degelijk in protected mode (en voor een deel nog
steeds niet, helaas). De 'virual 8086' mode is gewoon te beperkt,
omdat je daarmee nog steeds niet van die ellendige segmentering
af bent. Ik kan inder Win95/98 echter in C++ gewoon een array
van 20 MBytes maken, iets wat alleen maar in protected mode kan.
>Lijkt erg op de protected mode, met dat verschil, dat de
>hardware adressen niet geremapped zijn. Ieder willekeurig programma kan dus nog
>steeds rechtstreeks naar de hardware schrijven, zolang je maar weet op welk adres
>het zit.
Windows doet wel degelijk aan port trapping: als bv. een DOS programma
direct een COM poort wil accessen, dan worden alle I/O operaties
getrapt, en afgehandeld met een COM poort emulator.
Probeer maar eens vanuit een tweetal DOS-boxen gelijktijdig een
programma op te starten dat een COM poort direct aanstuurt (bv.
Telix of zo). Het eerste programma zal dan prima werken, terwijl
het tweede programma helemaal geen COM poort kan vinden: de
I/O trapping van Windows zit hier dan tussen, en die neemt maatregelen
om conflicten te voorkomen.
>In de echte protected mode zijn die adressen losgekoppeld.
In virtual 8086 mode kun je de adressen ook loskoppelen: je kunt
bv. ieder programma zijn eigen, 8086-compatible geheugenruimte
geven, en je kunt ook alle I/O poorten virtualiseren.
>Wat betreft het concept waar we nu over aan het praten zijn, dus de aansturing van
>het geheugen, is windows95 niet anders dan een spelletje dat de Dos4GW extender
>gebruikt.
Dat is wel erg kort door de bocht....
Rene
Rene Kellenbach
>> De 386 support dit echter WEL: je kunt opgeven dat het benaderen van
>> bepaalde I/O poorten moet worden afgevangen en omgeleid naar een stukje
>> software. Linux DOSEMU kan dit bijvoorbeeld.
>
>Dit is de oorspronkelijk protected mode. Die zat al in de 286.
De protected mode van de 286 was heel beperkt. De 286 ondersteunt
_geen_ I/O trapping, en kan dus geen I/O verkeer afvangen en
virtualiseren. Die mogelijkheid heb je pas vanaf de 386.
>Daarom kun je ook switchen tussen real en virtuele mode (hetgeen iedereen onterecht
>ook protected mode noemt). Nu is het ook gelijk duidelijk waarom daar in je 286 een
>reboot voor nodig was. Je kon wel van real naar protected mode, maar niet zomaar
>eventjes terug.
Die mogelijkheid was er wel degelijk: achteraf is gebleken dat Intel
voor het debuggen van de 286 een aantal ongedocumenteerde instructies
had ingebouwd om vanuit protected mode terug te springen naar real
mode. (dus zonder harde reset via de keyboard controller).
>Het was dus niet de 286 die een hersenbeschadiging had, zoals Mr. Gates dat
>uitdrukte
Persoonlijk denk ik dat de protected mode van de 286 te beperkt was om
een goed operating systeem op te laten draaien. Daarnaast kende de 286
geen virtual mode om een 8086 na te bootsen, hetgeen zou betekenen dat
iedereen bij een echt 286 operating systeem al zijn oude software zou
moeten weggooien, om helemaal opnieuw te beginnen. Ik denk dat Intel
gewoon eieren voor zijn geld heeft gekozen, en de virtual 8086 mode
vanaf de 386 heeft geintroduceerd om de overgang van de industrie
gemakkelijker te maken. Dat heeft enerzijds de overgang wat soepeler
gemaakt, maar ook vertraagd, vermoed ik.
Rene