Forums before death by AOL, social media and spammers... "We can't have nice things"
|    comp.lang.asm.x86    |    Ahh, the lost art of x86 assembly    |    4,675 messages    |
[   << oldest   |   < older   |   list   |   newer >   |   newest >>   ]
|    Message 3,844 of 4,675    |
|    Bart to James Harris    |
|    Re: Accessing addresses which have no RA    |
|    06 Apr 19 14:15:08    |
      From: bc@nospicedham.freeuk.com              On 06/04/2019 10:07, James Harris wrote:       > On 06/04/2019 00:38, Edward Brekelbaum wrote:       >> In ring 3, you'll seg fault.       >       > That's if running under an OS, presumably. But I guess it would be       > different if running on a bare machine (the case in point) where valid       > memory address ranges have not been set up in GDT/LDT or page tables.       >       >>       >> In ring 0, you should get all ones (IIRC). The transaction goes down       >> the ISA bus and times out.       >       > For some reason I, too, would most expect a read would get all ones       > back, but I am not sure why. Perhaps it's based on the idea of a bus       > which is carried off a computer by an edge connector. In such a case       > IIRC computers used pull-up resistors on bus lines to provide signal       > stability. Any line which was to be read as zero had to be driven low.              In the TTL devices I used to use, if nothing was put onto the bus lines,       they would be tri-stated, and generally floated high.              Although that could not be relied upon.              I remember having video memory for a 128x128 x 4-bit display (8KB total)       accessed as 128x128 x 8-bit (16KB range). The top 4 bits of each access       were considered garbage.              In this example, the address was decoded and I could have chosen to pull       those bits up or down. In yours I think the address is not even decoded.              What results to you actually get?              --- SoupGate-Win32 v1.05        * Origin: you cannot sedate... all the things you hate (1:229/2)    |
[   << oldest   |   < older   |   list   |   newer >   |   newest >>   ]
(c) 1994, bbs@darkrealms.ca