I seem to recall reading a thread about this bit too long ago.
My understanding is that you cannot go above the 640KB limit.

On the Juko ST motherboard, you can use the additional 384KB as a RAMDrive by loading a small utility in your Config.sys file.

I don't think you can do much in pure software, but you can get ISA cards with EMS memory, such as the AST Rampage. That way, I believe an XT class machine could theoretically support at least 8 MB.

Of course, the catch is that software needs to explicitely support EMS memory for it to do anything. Many older PC games did. Windows 3.0 does, too, so a V20 with a few megabytes of EMS might actually make for a usable Windows system... That might be a fun thing to do with an XT 😁

There is a way of being able to use some of the reserved memory provided you are using a color monitor as one of my old instructors was doing this for business clients back in the era that were using the machines for cad.

Sure you can go over the 640KB barrier, it's just an arbitrary line that IBM drew between the area usable for DOS and the area for BIOS and memory-mapped devices.
The 8088 has a 20-bit address bus, so it can address the full 1 MB.
You use memory beyond 640KB all the time: the video memory is mapped there. There's nothing stopping you from storing any data or even code in that memory.
Other devices could put memory there just as well (ISA cards with BIOS extensions will map their ROM there, and certain cards, such as network cards, may have a packet buffer there).
I have a Philips clone that actually has 768 kB of memory on the motherboard instead of 640k. Sadly, it isn't documented where this memory is mapped.
The main problem here is: DOS and applications don't expect memory to be there, so you can't allocate it with regular DOS APIs.
You have to 'know' it's there, and either just use it, or create your own memory manager for that part of memory.

You mainly don't go beyond 640k on an 8088 because most systems didn't have more than 640k (memory was expensive, early motherboards didn't even take the full 640k, and you needed expansion cards).

Hi Deksor, it depends how you define to "go over the 640KB barrier".
As the others said well before, EMS and UMB memory are possible with a bit of extra hardware.
But the 808x and NEC V20/30 do only have 20 external address lines, so 1MB is the maximum the CPU can "see".
That doesn't meant that 640KB has to be the limit, though. If you have a CGA card, you can get 736KB of DOS memory (didn't OS/2 had a setting for that ?).
If you do have got an Hercules, you can have 704KB at least. Without graphics hardware (CTTY) you can get something like ~900KB of DOS memory.
- Provided that the XT machine has memory at that location. An UMB card could provide it, for example.
XMS memory (!= extended memory) could also be possible, if an EMS-XMS driver existed (like EMM286 in reverse, but using an EMS board).

Well since I don't own any ISA board with RAM (except one that seems to be for older 8088s that doesn't normally support 640KB of ram) I was wondering if I couldn't use the one that is physically on the motherboard. Each bank is 512KB but there's 384KB of ram that is "lost" and so I wondered if there was any way to use it ...

I don't own any CGA card unfortunately and I don't think I do own a hercule card. However I think I have one or two MDA cards

Ah, I see. If you can find the driver for the mainboard, you can make use of that memory.
If not, have a look at that EMS board from lo-tec. https://www.lo-tech.co.uk/wiki/Lo-tech_2MB_EMS_Board
That one should provide enough RAM for most programs using EMS memory.
As far as I know, there's even a TSR that provides UMBs via EMS, but I haven't tried it myself.
It's named eemram26.arj and can be found at http://www.dcee.net/Files/Utils/ .

There are also other utilites, you should check out. 😀 If you're in the possession of a VGA card, no problem.
Classic ISA VGAs do have a mode utility to switch to EGA or CGA (or Hercules), if needed. Speaking of CGA, there's something really ironic to it:
In order to fully comply with the VGA standard, clone cards have to implement a "broken" CGA compatibility (in VGA mode):
For example, in native VGA mode, the second palette (red, green and yellow) isn't available (bit 5 in CGA's colour control register at $3D9 is ignored).
So if you want to play 80s games in an authentic way, a VGA card with a mode utility is really nice to have. ^^
Except for Composite-CGA, maybe. There, a real CGA card with an old-school NTSC monitor is probably a better choce.

Edit: If you've got some real MDA cards, check out my older thread at Umbherc.sys requirements ?
I failed (-for now-), but maybe you could get that driver working. Or the version for the orginal MDA (no graphics). 😀
The drivers are named umbherc.sys and umbmono.sys and did ship with some releases of IBM's PC-DOS also.
Note that they expect an CGA card installed. Don't know if this works with an VGA card in CGA-mode, too.
More about them can be read at http://www.robvanderwoude.com/dosmem.php
Edit: Some fixes, parts of the post re-written.

Jo22 wrote:

Speaking of CGA, there's something really ironic to it:
In order to fully comply with the VGA standard, clone cards have to implement a "broken" CGA compatibility (in VGA mode):
For example, in native VGA mode, the second palette (red, green and yellow) isn't available (bit 5 in CGA's colour control register at $3D9 is ignored).

Isn't this just because VGA doesn't implement the CGA mode and palette registers ($3D8 and $3D9) at all? It's compatible with CGA at the BIOS and memory-layout level, just not at the register level IIRC. If you use the BIOS call (int 0x10 with ah=0x0b) to set the palette, it works fine.

reenigne wrote:

Jo22 wrote:

Speaking of CGA, there's something really ironic to it:
In order to fully comply with the VGA standard, clone cards have to implement a "broken" CGA compatibility (in VGA mode):
For example, in native VGA mode, the second palette (red, green and yellow) isn't available (bit 5 in CGA's colour control register at $3D9 is ignored).

Isn't this just because VGA doesn't implement the CGA mode and palette registers ($3D8 and $3D9) at all? It's compatible with CGA at the BIOS and memory-layout level, just not at the register level IIRC. If you use the BIOS call (int 0x10 with ah=0x0b) to set the palette, it works fine.

I think you're right. Sorry, I should have been more precise about it.
I thought about CGA support purely at the hardware level, because of best compatibility with early DOS games (hence the quotation marks).
I assumed some of them skipped the BIOS altogether in order to gain better performance, instead of mixing BIOS calls with low-level stuff.
But I'm curious, why weren't these registers implemented on the VGA in the first place ?

Jo22 wrote:

I thought about CGA support purely at the hardware level, because of best compatibility with early DOS games (hence the quotation marks).
I assumed some of them skipped the BIOS altogether in order to gain better performance, instead of mixing BIOS calls with low-level stuff.

Some did, but it was very rare. Off the top of my head, the only games I can think of that did this were Digger, an obscure Asteroids clone called Astro-dodge that reprogrammed the CRTC for a 256x200x4 mode, and the "More color" mode in California Games (I'm sure there are others).

Jo22 wrote:

But I'm curious, why weren't these registers implemented on the VGA in the first place ?

Probably because it was quite difficult to do. VGA was much more sophisticated than CGA, but its register bis still correspond to raising or lowering particular lines of internal logic. To emulate CGA at a register level, each CGA port write would have had to be translated to a series of VGA port writes across multiple different blocks or even chips. It would have been a lot of extra transistors for something that was rarely needed since almost all software was "well-behaved" and used the BIOS for these functions.

use it as uppermemory, I use a version of USE!UMB which I hardcoded to the ununsed romspace, I think C800-EFFF. 160kb for upper ram to loadhi stuff into.

reenigne wrote:

Probably because it was quite difficult to do. VGA was much more sophisticated than CGA, but its register bis still correspond to raising or lowering particular lines of internal logic. To emulate CGA at a register level, each CGA port write would have had to be translated to a series of VGA port writes across multiple different blocks or even chips. It would have been a lot of extra transistors for something that was rarely needed since almost all software was "well-behaved" and used the BIOS for these functions.

Wasn't this decision already made with EGA though?
The assumption that most software uses the BIOS seems wrong, because my recollection is that virtually all CGA games I ever ran on VGA would not show the correct palette, because they use the register instead of the BIOS call.
But if I recall correctly, EGA doesn't support the CGA palette registers either. In which case IBM probably just stuck by their earlier decision, since they had already redefined the CGA-standard to a BIOS-only thing with EGA, and were probably expecting game developers to clean up their act.
Which they never did, because instead they would just add EGA and/or VGA support to their games, so people would only run the CGA version on EGA/VGA cards for the novelty factor.

I would argue that by the time VGA came around, it wasn't THAT difficult anymore to emulate CGA at the register level, since many early VGA clones already did this.

Jo22 wrote:

- Provided that the XT machine has memory at that location. An UMB card could provide it, for example.
XMS memory (!= extended memory) could also be possible, if an EMS-XMS driver existed (like EMM286 in reverse, but using an EMS board).

Yikes, just found out that it really did (at least for int15h)! 😳
Way back in 1986, AST Research shipped EMS boards with REX.SYS, an Extended Memory Emulator.
I wonder, if it used the EMS calls, could it also have worked on 8-Bit Rampages with 1MiB address space ?

E.3 Extended Memory Emulator - REX.SYS
REX interfaces with the REMM program to make Rampage 286 expanded memory act like extended memory.
This allows you to use AST's fASTdisk, SuperDrive, and SuperSpool (also IBM DOS 3.x VDISK.SYS utility with the "/E" option) to
create RAM disks or a print spooler in Rampage 286 expanded memory which emulates extended memory.
[..]
REX intercepts calls on read-only memory basic input/output system (ROM BIOS) functions designed for extended memory
use, and interfaces them to the REMM software so that they can use Rampage 286 expanded memory As with applications
that use the REMM software, program code portions of the SuperPak programs must reside in the 640 KB of PC-AT memory.
However, data associated with SuperPak utilities can use Rampage 286 expanded memory.

Very sorry to re-open an old thread, but sounds like BloodyCactus had a nice way of using UMB with an 8088 class PC - however Googling "USE!UMB" I can't find any references to this method (only the HIMEM.SYS and EMM386 which needs a 286 class PC) - can you give more details on how to set this up? Sorry if this is a total n00b question to ask, but I really want to test the UMB selection method of a custom 8088 based PC I'm building and didn't realise this was a kida complicated thing in a 8088 based PC!

BloodyCactus wrote on 2017-05-31, 17:06:

use it as uppermemory, I use a version of USE!UMB which I hardcoded to the ununsed romspace, I think C800-EFFF. 160kb for upper ram to loadhi stuff into.

mogwaay, nono good of you, otherwise I wouldn't have known about this thread. 😀

anyway...
Super PC/Turbo XT BIOS 3.1

from the .asm file

MAX_MEMORY = 640 ; Maximum conventional memory allowed in KB (with EGA/VGA)
;MAX_MEMORY = 704 ; (with Mono/Hercules)
;MAX_MEMORY = 736 ; (with CGA)

Hello!

I think is possible to map RAM in the UMB, 640-1024kb area (9FFF-FFFF). But keep in mind that these parts of these are used by devices like, video card, floppy/hard disk controller, etc. There are unused areas on most machines with DOS based OS. On 386 and latter is possible to map the unused areas with the combination of HIMEM and EMM386 or with commercial software such as QEMM or 386MAX, that memory can be used to store device drivers and free memory from the conventional 640kb memory area.
In general is possible to get from 96kb to 224kb of memory for loading device drivers, depending on the hardware configuration and software used.

On 8088/86 NEC V20/V30 extra hardware is required. Old 8 bit EMS ISA boards can usually map only a 64kb memory area such, as D000-DFFF, to transfer data to EMS memory, not UMB. Some high end cards like the Intel Above Board 8 and Orchid RamQuest 8/16, are 16-bit EMS cards that can provide EMS and UMB memory for loading drivers, and also supports 8-bit transfers required by XT systems.
UMB only boards exist, that provides UMB memory when used with DOS 5.0 or later and a software such USE!UMB.

Here is an example, I found, of the hardware:
https://monotech.fwscart.com/MicroRAM_640K_UM … 4_19914752.aspx.

On 286 system is possible to map UMB, with that UMB card or some 16-bit EMS board, some 286 machines may include a chipset with shadow RAM support that can be mapped as UMB like the NEAT/LEAP/SCAT with the QRAM 2.0 software.

Hi all,

I found my answer in the end USE!UMB is actually USE!UMBS and I found this video by Al's Geek Lab on YouTube a really nice into to using it on an XT class machine, he also uses the Monotech ram card.

https://youtu.be/bdRXqfhpV1Q

I got my machine to show 624k of conventional free, so v happy with that as proves my UMB switching is working on my homebrew 8088 pc!

If you have mda or CGA there are small utilities to have more than 640k base Ram

you can use the tools I wrote to replace use!umbs and such.

(copy from another post I wrote)

I also wrote something similar for my tandy sx + xt machines. umb is designed to work with himem.sys which has the umb api in it.

https://bloodycactus.com/files/umb.zip

works nicely with mcbexp which allows you to add memory to the MCB chain when you know the ram blocks exist.

https://bloodycactus.com/files/mcbexp.zip