• Please review our updated Terms and Rules here
  • From now on we will require that a prefix is set for any items in the sales area. We have created regions and locations for this. We also require that you select a delivery option before posting your listing. This will hopefully help us streamline the things that get listed for sales here and help local people better advertise their items, especially for local only sales. New sales rules are also coming, so stay tuned.

HIMEMV2 or equivillent PROM

Sure, it's safe. On a 16V8, pins 1-9 and 11 are dedicated inputs. Pins 12-19 can be assigned as input or output. Any unassigned output is high-impedance, as are any unassigned inputs.

GALs are usually named by their maximum numbers of inputs and outputs. So a 16V8 can have at most 16 inputs or 8 outputs, but obviously not both (you run out of pins). A 24-pin 22V10 can have up to 10 outputs or 22 inputs.
 
To anyone that might be following this thread, an update. Chuck say's that the GAL programmed to replicate the HIMEMV2 is on it's way to me by way of USPS. I'm so excited. I feel like a little kid waiting for Christmass. I have made the 16 to 20 pin adapter. Only took me two tries to get the solder job to look good. Good thing had some extra 20 pin low profile DIP sockets on hand. All that was required was soldering a jumper from pin 10 to pin 8, to provide ground, and trim the 4 extra pins down so that they won't interfere with the adjacent chip on th mother board.

I'll give another update when I get it working.

Have a Great Day

Greg
 
It works! Checkit3 now finds(and tests as good) 128k of "Hi RAM" in the D000h to F000h region. Now, I just need to figure out how to make use of this chunk of ram. I've been un-able to find old versions of QEMM or QRAM. I'm not sure that either of these wold work without a LIM 4 Board but I was hoping... Any ideas?
 
A couple of things occur to me.

You could simply insert the free memory in DOS's memory allocation tables and see if anyone uses it.

You could grab the source for a DOS RAMDisk or cache and hack it (if there's not such a product out there already) to use a user-specified block of memory.

I suspect that it would be simple to take a copy of the source to HIMEM.SYS and alter it to tell DOS that your 192K is simply your version of an HMA (i.e. load device drivers and TSRs up there).
 
Here are the GAL16V8 JEDEC, EQN and LOG files for anyone who wants to duplicate this. Since you'll be putting a 20-pin DIP iinto a 16-pin socket, you'll need to connect pins 8 and 10 (it's okay to include pin 9 if that makes the job easier) on the 20 pin DIP or, if you use a stacked socket, the socket. Just plug the GAL in so that pin 1 on the GAL matches pin 1 of U44 on the 5160 planar. Stick in 4 banks of 41256s and you're good to go.
 

Attachments

  • U44V2M.ZIP
    1.6 KB · Views: 24
Here are the GAL16V8 JEDEC, EQN and LOG files for anyone who wants to duplicate this. Since you'll be putting a 20-pin DIP iinto a 16-pin socket, you'll need to connect pins 8 and 10 (it's okay to include pin 9 if that makes the job easier) on the 20 pin DIP or, if you use a stacked socket, the socket. Just plug the GAL in so that pin 1 on the GAL matches pin 1 of U44 on the 5160 planar. Stick in 4 banks of 41256s and you're good to go.

Also, I'd be willing to make the adapter socket. I still have three un modified low profile 20 pin sockets on hand. I like the low profile type because the pins are a little more substantilal than the full hieght type, and they have a shoulder that stays above the socket that it is plugged into which is were the jumper is installed.

I'd be willing to provide one free of charge, including shipping, to anyone willing to help with the software side. Just PM me.
 
It works! Checkit3 now finds(and tests as good) 128k of "Hi RAM" in the D000h to F000h region. Now, I just need to figure out how to make use of this chunk of ram. I've been un-able to find old versions of QEMM or QRAM. I'm not sure that either of these wold work without a LIM 4 Board but I was hoping... Any ideas?

This really is a great piece of work coming together here. Hats off to those involved.

As it happens I have a Tandy 1400FD outside which has 768K RAM from the factory, so I guess it used a similar trick (V20 CPU). I'd be very interested to get a copy of this Checkit3 utility you mention if possible.

I think on the 1400 the idea for the extra RAM was disk cache (especially since it was floppy based). But as yet I've not been able to find really anything about it at all (let alone a driver).
 
I FOUND IT!!
After searching and scouring the internet as well as these forums, I found a handler that actually works on the XT. It's called "Use!UMBS". Awfull name, but it works. I now have 128k of UMB. I am able to load a lot of drivers and tsr's up there. With MS Network Client with Netbeui all loaded high along with a bunch of other stuff I have 576k of base memory available and there is still 11k of upper memory free!! If your interested, here's THE LINK. This is awsome. UMB on an XT without an expensive memory board!! Thanks again Chuck(G)!!

Later,

Greg
 
Great to hear it's working!

I have a Tandy 1400FD outside which has 768K RAM from the factory, so I guess it used a similar trick (V20 CPU). I'd be very interested to get a copy of Checkit3

A bit off-topic, but checkIt didn't find the extra 128K in the 1400. I also found an original Tandy DOS disk for it, but alas can't see any drivers for it on there either!
 
Great to hear it's working!



A bit off-topic, but checkIt didn't find the extra 128K in the 1400. I also found an original Tandy DOS disk for it, but alas can't see any drivers for it on there either!

I believe Checkit v 3.0 was the first one to have a memory map feature. Thats where I was able to see the "reserved" area which is the space between 640k and 1meg

PM sent
 
Update,
Although it works, it's not without glitches. First durring a cold boot, USE!UMBS,SYS loads (umb memory handler) and the display shows;

PARITY CHECK 1
?????
A0000

It then start loading drivers and such to upper memory and all works fine. However if I do a warm boot(CNTRL+ALT+DEL) then the PARITY CHECK 1 doesn't come 'till after drivers and tsr's are loaded and the system hangs and will only recover after power down. Also, at this point the display shows;

PARITY CHECK 1
?????

Note, the A0000 is not displayed as it was durring the cold boot. I figured that was pointing to the begining of EGA RAM, so I swapped out the EGA Wonder with a spare EGA Wonder and got the same results. So I tried the original IBM CGA Adapter, same thing. Next I relpaced all the PARITY RAM chips, still same results so I systematicaly replaced each RAM chip on the MOBO(those of you familliar with the insides of the 5155 know what a pain that was). So now I'm thinking it must be a timing issue or something. I wonder if there is a way to keep the system from doing the parity check on that portion of RAM.

Greg

P.S. The problem only shows up if I make a change to CONFIG.SYS or AUTOEXEC.BAT to change whats being loaded high.
So maybe the problem is that UMB is not being purged or re-initiated durring the "Three Finger Solute".
If I do a CNTRL+ALT+DEL without making changes, it reboots without the parity check coming up and all runs fine.
 
Last edited:
My guess is that the POST routines don't write memory above 640K (why would they?). So, when the next read (after a cold boot) happens, you get a parity error.

You could disable parity checking or have a dummy driver that writes the upper 128K before it aborts.
 
My guess is that the POST routines don't write memory above 640K (why would they?). So, when the next read (after a cold boot) happens, you get a parity error.

You could disable parity checking or have a dummy driver that writes the upper 128K before it aborts.

Is there a way to disable parity checking in dos, or would the BIOS need to be modified? I can't find anything in the limited DOS documentation that I have.
 
Immediately after PC power on, the contents of RAM is somewhat random. Certainly, in a good percentage of RAM addresses, the contents of the PARITY bit chip is not going to reflect the parity of the contents of RAM chips bits 0 to 7. That is why one of the things that the POST does on power up (after setting up refresh, and before enabling the NMI) is to write to all RAM addresses that are parity checked. The act of writing to each address will set the correct value into the PARITY chip.

RAM in early video cards is not parity checked, and so I agree with Chuck in that the POST is probably not doing its 'initialise parity bit' routine past the 640K mark.

And so at computer power on, after the POST, your block of RAM has a quantity of addresses where the PARITY bit is incorrect. For some of those 'parity chip contents incorrect' addresses, whatever you are loading into the RAM will perform a write to the address. No issue there, and in the act of writing, the PARITY bit gets initialised to a correct value. But in some cases, 'parity chip contents incorrect' addresses will be read before they are written. For each of those, a parity error will be generated.

A warm boot is not going to change the situation much.

As Chuck alluded to, before you access your block of RAM, some code needs to run that writes to every address in your RAM block. I'm confident that that is a fix.

Disabling the NMI will work too, but has at least a couple of disadvantages:
1. If a RAM chip later becomes intermittent, you're not going to be alerted to the fact (via a PARITY error message).
2. Can't use an 8087 (it uses the NMI).

Whichever path you choose (write all RAM, or disable NMI), it has to be done before any code reads a 'yet to be written to' address in your RAM block. And so, as Chuck suggested, a dummy driver (that writes to all your RAM block, or disables NMI) loaded early in CONFIG.SYS should be the answer.
 
Look, the guy who wrote the UMB software that you're using did a commendable job--it's well documented and the source code is included with the driver.

But I have a quibble with him requiring you to patch the addresses of your UMB areas into the driver. Far better would have been to parse it from the DEVICE= line, put them into the table, then write/test them (the way that some versions of HIMEM.SYS do).

I could probably do it in an afternoon--it's not difficult code, but I've already put in a couple of afternoons on a project that I have no use for.

If you can't recruit someone on the list with simple assembly experience, that should tell you a lot about the members of this forum (and probably a ton of others).

You might also work on learning x86 assembly yourself. There's no shortage of information out there.
 
the following code will write to the entire D000:xxxx segment. The program you will need should include all of the extra segments of RAM above the 640K limit in your system.

Code:
; Write to RAM segment
mov es,D000h ; Set target Segment address
xor ax,ax    ; Clear ax, will be the word written to RAM.
mov di,ax    ; Start at offset 0000h in target segment
mov cx,8000h ; Number of Words to write, 8000h = 32KW = 64KB
rep stosw

; Terminate program
ret
 
Last edited:
you can run program files from config.sys, at least in later versions of DOS (unless I'm slightly mistaken).
 
Back
Top