old skool: totale geheugenadressering 8086?

[Dakoina]

Ik ben student Ingenieur ICT en ik ben voor de moment Microcomputers aan het blokken. Ik zit wel met een vraag (aangezien we geen al te beste docent voor dit vak hadden), namelijk:

hoeveel geheugen kan ik met een oude 8086 cpu aanspreken? is dit 1Mb?
( aangezien 20bit adresbus (adreslijnen) > 2^20 = +- 1.000.000bits) of is het eigenlijk meer en is dit een gewoon voorbeeld?

probleem is dat ik alles een beetje door elkaar haal door de huidige stand van zaken in de h/w wereld

(PS: u mag een link leggen met huidige technologie, hetgeen ook handig kan zijn voor mij om te begrijpen)

[star-saber]

www.sandpile.org

daar vind je een heleboel

[ Voor 48% gewijzigd door star-saber op 10-01-2004 11:50 ]

[Verwijderd]

Houd het maar op 640KiB, daar houdt het echt op.

[Dakoina]

alvast bedankt voor de vlugge reacties

het aantal adresseerbare adressen is dus duidelijk afhankelijk van de adresbus breedte thx

[ Voor 96% gewijzigd door Dakoina op 10-01-2004 12:06 ]

[star-saber]

dat lijkt me duidelijk.
adres bus heet niet voor niets adresbus

[Rataplan]

Verwijderd schreef op 10 januari 2004 @ 11:50:
Houd het maar op 640KiB, daar houdt het echt op.

Houd het maar op 1 MB De bovenste 360KB zijn absoluut aanspreekbaar, je kan er alleen geen programma's in uitvoeren (alhoewel...); je hardware bepaalt de mogelijkheden.

quote: http://www.infokomp.no/techinfo/doc/DosMemory.htm

Conventional Memory is the memory range between 0 and 640KB, which is directly accessible to DOS applications. DOS and TSRs begin loading at the bottom area of memory and work their way up.

Upper Memory (UMB for upper memory blocks) is memory between 640KB and 1MB. This memory begins at segment A000h, and is directly accessible from real mode, just "reserved" by the original PC design.

Video buffers comprise the first 128KB of [UMB] memory. The first 64KB (A000-AFFF) is typically used by EGA/VGA graphics modes. The next 32KB is the monochrome video text buffer (B000-B7FF), followed by 32KB for the color text video buffer (B800-BFFF). (The different buffer addresses were intended to allow color and monochrome systems both reside in the same system.)

Other ranges of upper memory are used by other adapters (like network cards), and the PC's BIOS. The BIOS area is normally the top 64KB (F000-FFFF), although some systems use a 128KB BIOS (like PS/2s) (E000-FFFF).

The left-over memory can be used for various purposes. On a 386 system, the 386 processor's paging techniques are used to map extended memory (memory beyond the 1MB limit, we'll get to it shortly) into the upper memory area, so that it can be addressed by the processor in real mode (or really virtual 8086 mode). On a 286 system, an expanded memory board can be installed, which installs physically addressable memory into this range of upper memory.

...heb vroeger heel wat naar b800:xxxx gestuurd

[ Voor 28% gewijzigd door Rataplan op 10-01-2004 13:09 . Reden: thanks, IE :( ]

[Verwijderd]

Is het trouwens niet zo dat die oude bakken een 16bits adresbus hadden een 4 bits tegelijk ophaalden? Dus effectief 20bits konden adresseren? Zoiets was het wel.

[lameeuw]

Max geheugen is idd 1 Mb bij de 8086/8088. De breedte van de adresbus is 20 bits, de databus is 8 (8088) of 16 (8086) bits.

[PD2JK]

Ik heb hier een oude boekje (Intel MCS-86 Product Description, February 1979) over o.a. de 8086 en onder het kopje Memory Organization staat:

The processor provides a 20-bit address to memory which locates the byte being referenced. The memory is logically organized as a linear array of 1 million bytes, addressed as 00000(H) to FFFFF(H). The memory can be further logically divided into code, data, alternate data, and stack segments of up to 64K bytes each, with each segment falling on 16-byte boundaries.

Hoop dat je er wat aan hebt, anders is het wel leuk om te weten

[ Voor 6% gewijzigd door PD2JK op 10-01-2004 13:53 . Reden: typo ]

[Rataplan]

Verwijderd schreef op 10 januari 2004 @ 13:16:
Is het trouwens niet zo dat die oude bakken een 16bits adresbus hadden een 4 bits tegelijk ophaalden? Dus effectief 20bits konden adresseren? Zoiets was het wel.

Het maximale bereik van een 16 bits bus is 64KB. Een adres op een 8086 bestaat uit twee words (16 bits), segment en offset. Daarvan wordt het segment vier bits geleftshift en bij de offset opgeteld. Het is in deze architectuur dus heel goed mogelijk om twee verschillende adressen te maken die dezelfde geheugenpositie adresseren!

Voorbeeldje: positie rechtsboven op een scherm is B800:004F. Deze byte kan je ook bereiken via B7FF:005F, B801:003F, B802:002F, ... verzin er zelf nog maar wat. Er zijn per adres 4096 mogelijkheden

[Verwijderd]

de 8086 heeft een 20 bits addresbus en kan dus 2^20 oftwel 1048576 bytes, 1024KB ook wel 1 Megabyte genoemd addresseren. de 8086 heeft dus een -processoraddressspace- van 1MB.

vanuit de processorhardware is dit de beperking, hier kun je ook wel weer omheen met hacks als memorybanking (EMS/XMX waren, voordat het door software op de PC AT geemuleerd werd, ISA uitbreidingskaarten met extra geheugen die in de processor addresspace gemapped konden worden).

de DOS bovengrens van 640KB heeft te maken met hoe IBM de memorymap van de IBM PC destijds bedacht heeft. tussen 640KB en 1MB was gereserveerd voor memory mapped IO devices en BIOS e.d. het is dus een beperking van de computerarchitectuur IBM PC en niet van de 8086 processor.

de 8086 is een 16 bits processor, de programcounter is 16 bits hoe kan de processor dan meer dan 2^16, meer dan 65536 Bytes, oftewel meer dan 64KB, aanspreken? dit werkt met een "kludge" bedacht door Intel ingegeven door het begrip "compatibility", het begrip dat zo belangrijk is geweest in de groei en dominantie van de x86 architectuur...

het is "opgelost" door de 20 bits adresspace in te delen in 'segmenten' van 64KB groot. de 16 bits programcounter kan binnen dit 64KB segment elk byte adresseren. de plaats van het segment in de 20 bits processor addresspace wordt bepaald door het code segmentregister ook 16 bits groot. maar dan heb je toch een 16+16 = 32 bits addresspace ipv een 20 bits address space? nee daar het intel niet voor gekozen (het blijft een kludge he) de segmenten zijn niet disjunct maar overlappen. op elke 16 byte grens (een paragraaf genaamd in sommige x86 assemblers) begint een nieuw segment. bijvoorbeeld:

segment: 20 bits adres (decimaal)
0:0
1:16
2:32
3:44
n:n*16

dus stel ik wil byte 64K + 1 oftwel '65537' addresseren dan moet eerst het segment bepaald worden door te kijken hoe vaak '16' past in '64K + 1' : 65536 +1 / 16 = 4096. 4096 *16 levert dan de startadres van het segment op: 65536. de programcounter moet nu binnen dit segment de waarde '65536 + 1 - 65536' oftewel 1 hebben. dus 65537 komt overeen met CS:IP: 4096:1.

maar je kunt 65537 ook addresseren als CS:IP 4096-1:1+16 = 4095:17. want 4095*16 + 17 = 65537.

dezelfde segmentering wordt voor alle x86 pointer registers toegepast (stack, data). in de processor hardware implementatie overigens wordt het 16 bits segmentregister 4 bits naar rechts geschoven en dan opgeteld bij het pointer register (CS>>4 + IP).

real mode addressering wordt nog steeds ondersteunt door de modernste x86 derivaten waaronder de pentium 4 en de k8...

[Dakoina]

bierbuik, ge hebt eigenlijk een 10tal pagina's uit mn cursus mooi samengevat op 1 pagina zou ik zegge ik dat dat mijn mede brugjaar studenten u daar dankbaar voor zullen zijn


en reply @Rippie:
ik weet niet onmiddellijk wat ge wil duidelijk maken maar de 8086 had 16adreslijnen waarbij er nog eens 4extra adreslijnen komen die ook nog voor iets anders konden gebruikt worden. Dus effectief 20 adreslijnen. 16 adreslijnen worden gezamenlijk - multiplexed - ook gebruikt voor het gebruik als DATAlijnen. Maar het zijn de adreslijnen die de grootte van maximaal aanspreekbaar geheugen bepalen.

[koraks]

...heb vroeger heel wat naar b800:xxxx gestuurd

Haha, ja, dat waren nog eens tijden. Kon je ongestraft vanuit je assembly-progje tekst in het videogeheugen 'machinegunnen' Later nog eens voor de grap zo'n progje proberen te draaien in Win9x, maar dat resulteerde (zoals verwacht) in allerlei alarmerende waarschuwingen in de trant van "Dit programma heeft geprobeerd een ongeldige bewerking uit te voeren...enz"