• Please review our updated Terms and Rules here

RAM : 736KB on IBM PC 5150

Just to be clear, it is recognizing this memory with no additional drivers or software? Nice.

I recall a shareware program for 286/386 era computers that could map in extra memory using chipset or video tricks to get 736k, but this would disable the use of VGA graphics.
 
So... on the RAM card, are you enabling the whole 704k-768k block? (The switches indicate that it does RAM in 64k sections.) Assuming you're using a CGA card 16k of that at B8000 is going to be conflicting with the video RAM. For writes it's not going to matter much, but when you read from the conflicting area both the video card and the RAM card will be driving the bus down for every "0". In theory at least you'll be subjecting some components on the motherboard to a little additional stress.
 
you'll be subjecting some components on the motherboard to a little additional stress.

I don't see how that's possible. The only electrical stress issue would be if a high side and low side driver are turned on at the same time causing a low impedance path between 5V and GND (aka a short). Since the CGA window cannot be panned around, it should have the same value recorded as any other main memory shadowing it in the same address space - for addresses written at least once before read. Two low side drivers (or high side drivers) in parallel only improves signal integrity. Can you elaborate?
 
Last edited:
I don't see how that's possible. The only electrical stress issue would be if a high side and low side driver are turned on at the same time causing a low impedance path between 5V and GND (aka a short). Since the CGA window cannot be panned around, it should have the same value recorded as any other main memory shadowing it in the same address space - for addresses written at least once before read. Two low side drivers (or high side drivers) in parallel only improves signal integrity. Can you elaborate?

Strictly speaking I feel like you're right that most of the time it's not going to cause an issue. But as you note, *if* one of the RAMs were to somehow get out of sync with the other (let's say one develops a bad bit and gets stuck high or low) then there's basically a short. Wouldn't there also potentially be an issue if a read cycle were to happen before any writes, say after a power cycle, where the contents of the RAM chips might be random? Granted I don't think that situation will persist for very long so, eh?

(Re: my earlier post where I suggested it might "always" be subjecting the components to additional stress... yeah, I had a think about that and it's probably not true, unless there's some kind of edge case weirdness induced by the gate switching/settling/output enable times for the two banks of RAM likely being *substantially* different. Just generally speaking, though, it's probably best as a general rule to fully decode your bus? I dunno.)
 
Last edited:
Who is any user?

Kevin Flynn?

For the record, there are device drivers for enabling this if your particular PC's BIOS doesn't let you do it. (One of them is simply called "704k.com".)

And of course you can't do it with EGA or VGA because those use the A0000-AFFFF space for their graphic video buffers, which would conflict with a hardwired memory block. (And since paging *is* a thing here there's less doubt about this being a genuine source for bus contention.) But as mentioned, there were drivers that could let you either map EMS memory into this space (assuming you had an EEMS or LIM 4.0 card with the required memory mapping hardware or a 386 or better CPU) or literally just use the memory on the VGA card, although the latter tended to be slow compared to real RAM. (I played with this once on a 286 that didn't have any other memory mapping hardware.) Doing this would limit you to CGA video modes, which is kind of a rough tradeoff.

Also note that if you have a Hercules or MDA card the limit's going to be 704k contiguous because their video buffers start at B0000, not B8000.
 
If I categorise users of my website into beginner, intermediate, and advanced, then I consider more than 640K of conventional memory to be an advanced subject, one that if documented, requires the documentation to be at an adequate level.
For example, for what needs to be achieved, would expanded memory be better ?
For example, if the conventional memory past 640K is dynamic RAM, will the motherboard refresh it ?
For example, will the conventional memory past 640K conflict with the fitted video card ?
For example, if the conventional memory past 640K has a parity bit, how do I appropriately set/reset the parity bit before the memory gets read by DOS/programs/drivers ?

If my SW2 settings table included settings for above 640K, some beginner and intermediate users might venture into the '>640K conventional' territory in ignorance. Presently, I have no plans to add '>640K conventional' documentation to my website. Such users can always do the research themselves, which includes reading books, searching the internet, searching these forums, or posing a question to these forums.
 
Two low side drivers (or high side drivers) in parallel only improves signal integrity. Can you elaborate?
In a past IBM PC family support role, I have seen 'weirdness' caused by users unintentionally overlapping RAM ([example]). No, I cannot further explain 'weirdness'; it was too long ago. The lesson was 'do not do it - it may or may not cause problems'.

And in the day, I do not recall PC magazines suggesting overlapping all RAM as a way of providing some fault tolerance for important users (i.e. to cater for a RAM card failing, and failing in a way that results in it no longer driving the data bus). Perhaps there was a known reason for not doing so in PC family computers !
 
(i.e. to cater for a RAM card failing, and failing in a way that results in it no longer driving the data bus). Perhaps there was a known reason for not doing so in PC family computers !
Having placed two RAM ICs in the same memory range and one fails by not driving the bus anymore, then the other one one covers this loss and the computer won't notice this. But there two good reasons not to do this:
- one IC fails and keeps pulling its output to (L) or pushing it to (H) all the time. Then a) you will read invalid data and b) there is a good risk in destroying the other IC as well.
- What data do these ICs contain after power-up? If you read it it before a write, you run the risk that one outputs a (L) and the other an (H) on the same line. The read action will be short but do it enough times and something will break. First writing to the ICs is the solution but do you know if your BIOS does write to the ICs before reading them?
 
@modem7

I also hope not to add SW2 setting for this on your site.
Because this is unofficial SW2 setting on IBM 5150 motherboard.

So IBM didn't mention this setting.
 
Last edited:
Strictly speaking I feel like you're right that most of the time it's not going to cause an issue. But as you note, *if* one of the RAMs were to somehow get out of sync with the other (let's say one develops a bad bit and gets stuck high or low) then there's basically a short.

The problem is easier to hit than that. The CGA has 16kB of RAM but decodes 32kB of addresses (0xb8000-0xbffff). The CGA's RAM is mapped twice (one copy from 0xb8000-0xbbfff and another from 0xbc000-0xbffff). So if you write different values into 0xb8000 and 0xbc000 and then read back the first one, the CGA will give you a different value from the expansion RAM.
 
The CGA's RAM is mapped twice (one copy from 0xb8000-0xbbfff and another from 0xbc000-0xbffff).

I'd noticed that my Tandy 1000 double-maps the CGA memory (when running "normal" CGA modes, not its 32k video modes), I didn't off the top of my head know if real CGA cards did that. So, yeah, if there's any software out there that actually hits that phantom page then you're asking for trouble having RAM from the expansion card sitting behind it.

If you really want 736k instead of 704k from one of those Lo-Tech 1-meg-analogous cards I'd suggest cutting the trace leading from the 74LS138 to the 704-768k dip switch and dead-bugging somewhere on the board a 74LS08 AND gate that combines the '138's output with address line A14. That'll enable only the bottom half of that 64k block.
 
For the record, there are device drivers for enabling this if your particular PC's BIOS doesn't let you do it. (One of them is simply called "704k.com".)

Some DOS versions won't let this work even if it's valid. I did the same thing (added 64K to A000 in my 5160) but IBM PC DOS 2000 refuses to work (I can't remember if it hangs on the reboot, or if it simply doesn't use the extra).

MS-DOS 3.3 not only works, but some products (QRAM) can change/patch it during CONFIG.SYS execution. On an AT&T 6300 + AST EMS board + MS-DOS 3.3 + QRAM, it maps RAM into A000 and the first half of B000, giving me 736K DOS RAM.
 
Some DOS versions won't let this work even if it's valid. I did the same thing (added 64K to A000 in my 5160) but IBM PC DOS 2000 refuses to work (I can't remember if it hangs on the reboot, or if it simply doesn't use the extra).

I wonder if this is related to an issue I've seen with the same DOS on the Tandy 1000's with DOS loaded high; if I run a piece of software that uses the Tandy graphics modes (which requires changing the top of the DOS memory space downwards at least 16k from the boot state) "something" gets clobbered with DOS'es memory management because running "mem /c" will no longer show the contents of UMBs, and commands like "loadhigh" no longer work. Drivers and whatnot loaded high previously continue to work, but I will say non-scientifically the computer gets a little "crashy". (I generally reboot after running Tandy graphics programs just to be safe.)
 
..if there's any software out there that actually hits that phantom page then you're asking for trouble having RAM from the expansion card sitting behind it.

You would have to write twe different values - one to the main CGA window and a different one to the aliased window / back to back - then read from either. It's a very contrived use case. I doubt even a memory pattern tester would ever do that. Anything that would, would be a test program inspired form this thread. Even then, it's not a zero impedance short. It would have the resistance of the traces/connectors from one opposing driver (CGA card) to the other (memory chip) + the ESR of the transistors themselves.

At any rate, it's moot. I disagree it would harm anything by doubly mapping RAM like this.

Some DOS versions won't let this work even if it's valid. I did the same thing (added 64K to A000 in my 5160) but IBM PC DOS 2000 refuses to work (I can't remember if it hangs on the reboot, or if it simply doesn't use the extra).

Are you sure it's a DOS issue and not just a BIOS scan issue? I'm pretty sure most of not all DOS versions always trust the top RAM value in the BDA (via Int 12h) for the limit of memory they can use. Even if there is more RAM detected there, you'd want DOS not to use it if BIOS has it reserved for other purposes (like the MDA adapter!) For example, the PCjr BIOS limits it's scan and thus BDA reporting to 640K - even when a side-car adds more.
 
Last edited:
Are you sure it's a DOS issue and not just a BIOS scan issue? I'm pretty sure most of not all DOS versions always trust the top RAM value in the BDA (via Int 12h) for the limit of memory they can use.

It's not a BIOS scan issue because the BIOS stops at 640k on the system I'm testing. The use of the extra memory is changing the BDA value and soft-rebooting. IBM PC DOS 7 just hangs when I do that. I'll test other DOSes to see what happens.
 
So, yeah, if there's any software out there that actually hits that phantom page then you're asking for trouble having RAM from the expansion card sitting behind it.

I know of at least one piece of software that does... 8088 MPH. It's quite useful if you're reprogramming the CRTC start address register - no matter which address corresponds to the top left, you have a contiguous range of addresses corresponding to the screen.
 
At any rate, it's moot. I disagree it would harm anything by doubly mapping RAM like this.

I'm sold that's unlikely to physically harm anything and I'll agree it's probably a "contrived" use case that someone would write to location X in the CGA space and then read the same cell from address X+16k (and care that it's different), but *technically* it is a compatibility-breaking condition, so it seems like from that standpoint it's pretty hard to argue that having overlapped RAM is in any way a "best practice".
 
Back
Top