A000/B000 and E000 segments

[tom.storey]

Hi all.

I've been designing a RAM expansion board to go into my XT. It has a 4Mbit (512Kbyte) SRAM chip on it of which only 384K would be used to expand conventional memory, leaving 128K crying out for something to do.

Studying the memory map of the PC and XT I determined that it is possible, in varying circumstances, to (easily) find an extra 128K of space in the upper memory area depending on video adapter config and option ROM usage.

The A000 segment is reserved for an EGA video adapter, but I read that this can often be reconfigured to use B000 which would ordinarily be sliced up to cater for MDA and CGA adapters. So I've added jumpers to be able to select either A000 or B000 as the first 64K chunk.

E000 is part of the option ROM space, but if you have few of these installed, there's another potential 64K chunk of space which I've also added jumpers to enable, thereby giving me that 128K of extra possible RAM and fully utilising the entire RAM chip. Yay.

Now as for actually *using* that space, as I understand it, there is no way to tell DOS to use it on an XT - HIMEM only works in the high memory area above 1Mbyte, which doesn't physically exist on an XT. EMM386, which I don't think would even run on an 8088 (because it's not a 386...), I believe, only maps some extended memory into the upper memory space via the 386s MMU? So annoyingly, out of the box at least, it seems like there are few options to take advantage of this extra space.

So then, what would be some of the best use cases for this extra memory? I can think of a RAM drive, but I can't think of a use case for one (yet).

I'm running MS-DOS 3.3, although I've considered bumping up to 5.0 if that would make any sense. Are there any other compatible DOSes that make using this extra space easy that would be worth switching to potentially?

Your thoughts?

Thanks!

 

[Ruud]

You can use D000 and E000 for UMB using USE!UMBS and DOSMAX. Using DOS=UMB in the CONFIG.SYS enables you load, for example, a mouse driver into UMB. DOSMAX enables you to load a part of DOS from under the 640 KB border into you UMB.

 

[tom.storey]

Using D000 and E000 doesnt leave much space for option ROMs, which I plan to play around with and do some development work with in some projects. But it looks like I can leave myself about 24K worth of space in the C000 segment for that (I need to keep the first 32K free for a video BIOS, and put an XT-IDE BIOS of 8K in there as well), and that may just have to do.

I suppose having the two blocks of UMB RAM contiguous would be more useful.

 

[FreddyV]

Hi,

With 512Kb, you can even map the segment 8000 and 9000 to extend the 512Kb machines to 640Kb (Conventionnal)
May I ask you what kind of project require to develop a ROM ?

For your info, you can follow my PicoMEM Project, as my board is already able to emulate RAM, at all the possible address (It is software configurable), ROM and EMS.
This is excellent to develop BIOS without needed to program an EPROM

Move the EGA to segment B is surely not a good idea for all the application accessing directly the Video RAM, this is not really "Standard" even if it is possible.

As said by Ruud, the Memory > 512Kb CAN be used as UMB, if the software support it of course, but what is nice is that it can be used to load DOS "Drivers", then, increase the free conventionnal memory.

 

[tom.storey]

My current circuit already decodes segments 4000 through 9000 (384K) as conventional memory expansion, so that is all taken care of.

Im just looking for options to use up the remaining 128K of that RAM chip.

The design also includes a 32 pin socket to use for option ROM development. Its got a bunch of jumpers to allow configuring some of the pins to support a wide variety of ROM and RAM chips, so I should also be able to avoid needing to program any ROMs separately. It also has some switches to configure the size and location within the option ROM area that it will be present. I'll no doubt end up writing a small utility to allow me to load stuff into the ROM/RAM in that socket. All part of the fun.

Im not 100% sure what I intend to do yet, but Im an adventurous type (at least when it comes to this kind of thing), so I'll find something to do, hence I want to keep some option ROM space available.

PicoMEM looks cool, but I like to do it the old school way with logic chips etc.

 

[FreddyV]

PicoMEM looks cool, but I like to do it the old school way with logic chips etc.

I wanted a project to :
- Go Back to electronics
- Go back to C programming
- Work on emulation
- Do something really usefull for the PC community

So:
416Kb of RAM Added (every single slot of free @ taken, except the one decoded by the XTIDE Board...)
2Mb of EMS
Disk emulation based on .IMG files stored in a MicroSD. (Possible to add 4 x 4Gb disk then)

 

[Ruud]

Using D000 and E000 doesnt leave much space for option ROMs,

I didn't say you have to use it all And then you still have $C8000-$CFFFF = 32 KB for option ROMs. $Cxxxx = 64 KB if you don't use EGA/VGA.

 

[tom.storey]

I didn't say you have to use it all And then you still have $C8000-$CFFFF = 32 KB for option ROMs. $Cxxxx = 64 KB if you don't use EGA/VGA.

So, for "ultimate flexibility" I could provide jumpers to decode A000 or B000 or D000 as the first bank, and the second bank as E000.

Maybe all configurations aren't 100% useful all the time, but you've got a few to choose from based on your system configuration, software, etc etc?

More options are better than fewer options.

 

[Chuck(G)]

A couple/few years back, I posted a method for replacing the memory mapping ROM in a PC XT that was adapted to use 256Kbit DRAMs to use the upper memory block. I don't recall the details, only that it worked--I think I used a GAL22V10.

 

[Ruud]

Yep, I know. I did the same trick, only to find out that you already had done it.

The only little bummer of this method: you have to make sure that the RAM has been initialized before using USE!UMBS or you can run into parity errors. That meant changing USE!UMBS. Krill did that as well in his version.