Breathing new life into 1981 IBM 5150

[modem7]

Basically I am wondering if this trick can be used on a 5160 or 5155. I am guessing no as it doesn't have the granularity in the switches like a 5150 motherboard has.

In sizing conventional memory, the IBM motherboard BIOS in the 5155/5160 operates differently to that of the 5150. Is simply 'takes a look', but per step 17 at [here], limits its search to 640 KB.
However, the use of 704K.COM is expected to get around that. See post #22 at [here].

Reminder: Only suitable if MDA/CGA video card in use. Memory map.

Parity

The other thing that the aforementioned step 17 does, is appropriately set/reset the parity bit of each address. And only up to address 640 KB. And so if the card being used to populate the 640-704K address space has parity circuitry (RAM for parity + associated circuitry), then either:
Option #1: Turn off the card's parity checking. Undesirable
Option #2: Use something to appropriately set/reset the parity bit of each address in the 640-704K address space.

Failure to do either will result in: PARITY CHECK 2 error the first time that software (DOS or other) reads an address in the 640-704K address space where the content of the parity bit does not match with the parity of the data bits at the address.

I remember that Chuck(G) created some software to do option #2.

 

[Eudimorphodon]

Failure to do either will result in: PARITY CHECK 2 error the first time that software (DOS or other) reads an address in the 640-704K address space where the content of the parity bit does not match with the parity of the data bits at the address.

I was temporarily confused by this but, oh, I get it, yes; if you had a parity-checking memory card you need to write memory before you read it, otherwise you've only got a 50-50 chance the random power-on noise in the RAM chips is going to have matching parity. FWIW, I would *guess* that the "704K.COM" program does this? It seems it would have to.

Of course, these days all memory expansion cards are based on SRAM and nobody builds parity checking into them, so it'd be a non-issue.

 

[modem7]

I was temporarily confused by this but, oh, I get it, yes; if you had a parity-checking memory card you need to write memory before you read it, otherwise you've only got a 50-50 chance the random power-on noise in the RAM chips is going to have matching parity. FWIW, I would *guess* that the "704K.COM" program does this? It seems it would have to.

I found 704K.ZIP at [here]. Within it is a document, and that document includes, "Write data to the upper 64K". Probably just zeroes.

I remember that Chuck(G) created some software to do option #2.

I wonder what this software is that I am thinking of.

 

[VERAULT]

Thanks for all the input. I ended up watching @Trixter 's video about breaking the 640k barrier again and used his MBR patcher to get 704kb: http://ftp.oldskool.org/pub/youtube/dos640k/

So it worked after a reboot. But then whenever I power cycle the machine the MBR is corrupted and wont boot. This happens every time. I am using DOS 5.0.

An FDISK /MBR does not repair the drive and I need to repartition and format the drive and copy all the files over from a backup.

 

[modem7]

Thanks for all the input. I ended up watching @Trixter 's video about breaking the 640k barrier again and used his MBR patcher to get 704kb: http://ftp.oldskool.org/pub/youtube/dos640k/

I can see that it won't be suitable if the RAM placed in the 640-704KB memory space does parity checking.

( The patch inserts 'alter the RAM figure in the BDA' code into the MBR, but does not write to each address in the 640-704KB memory space. )

So it worked after a reboot. But then whenever I power cycle the machine the MBR is corrupted ...

How did you determine that the MBR "is corrupted", or is that an assumption ?

... and wont boot.

What are the symptoms ?

 

[VERAULT]

Dos could not see the partition anymore. Ironically my windows pc could still browse the files (sd card). I have to create a new partition and format it then start over.

 

[modem7]

Dos could not see the partition anymore. Ironically my windows pc could still browse the files (sd card). I have to create a new partition and format it then start over.

Revisiting earlier posts, I see at post #112 that you got 704K going successfully in your early 5150.

Is it the case, that this problem is happening on the same computer; you are simply experimenting with different ways for DOS to see 704 KB ?

Or have you moved to a different computer? If so, which computer? And where is the RAM up to 704 KB being supplied from?

 

[Quagmire]

Dos could not see the partition anymore. Ironically my windows pc could still browse the files (sd card). I have to create a new partition and format it then start over.

I have some thoughts about that partition but it's 12:45 in the morning and they're muddled.

 

[VERAULT]

Revisiting earlier posts, I see at post #112 that you got 704K going successfully in your early 5150.

Is it the case, that this problem is happening on the same computer; you are simply experimenting with different ways for DOS to see 704 KB ?

Or have you moved to a different computer? If so, which computer? And where is the RAM up to 704 KB being supplied from?

As per post 119 and 120 I am wondering how to get the same effect on a 5160 motherboard (the 5150 is still working fine).

 

[modem7]

As per post 119 and 120 I am wondering how to get the same effect on a 5160 motherboard (the 5150 is still working fine).

Okay. Symptoms in post #125 are for a 5160 of yours. You have RAM all the way up to 704 KB, and not overlapping ?

As for getting 704K recognised:

704K.COM

Expected to work, unless something loaded/run earlier than 704K.COM needs to know about the 704 KB.

This patch assumes that RAM in the 640-704K address space is functional. The POST is only testing the RAM as high as 640 KB.

Trixter's MBR patcher

It is expected to work if;
1. RAM in the 640-704K address space does not contain parity checking circuitry; and
2. The 5160's POST found/discovered 512 KB or greater of conventional memory.

Re 1. Because the code patched into the MBR does not {write to every address in the 640-704K address space}. May cause a PARITY CHECK error message at some point.

Re 2. Revealed by examination of the code patched in. If less that 512 KB, the patch makes DOS believe that 448 KB is installed, not 704 KB. To be fair, the patcher documentation specifically refers to one of the requirements being '640K low DOS RAM'.

This patch assumes that RAM in the 640-704K address space is functional. The POST is only testing the RAM as high as 640 KB.

This patch also relies on the 5160's 640 KB of RAM being functional. Example. Faulty RAM at address 256 KB, and faulty in a way that results in the 5160's POST not reporting a 201 error. User does not notice that 5160's POST now only counts as high as 256 KB. POST records in the BDA that 256 KB of 'successfully tested by POST' RAM exists. The POST decides to boot from the hard drive, passing execution to the 'patched' boot code in the MBR. Due to point 2 above, the patch in the MBR results in DOS thinking that 448 KB of 'successfully tested by POST' RAM exists. Something is going to 'fall over' when it attempts to use the faulty RAM.

 

[VERAULT]

Okay. Symptoms in post #125 are for a 5160 of yours. You have RAM all the way up to 704 KB, and not overlapping ?

As for getting 704K recognised:

704K.COM

Expected to work, unless something loaded/run earlier than 704K.COM needs to know about the 704 KB.

This patch assumes that RAM in the 640-704K address space is functional. The POST is only testing the RAM as high as 640 KB.

Trixter's MBR patcher

It is expected to work if;
1. RAM in the 640-704K address space does not contain parity checking circuitry; and
2. The 5160's POST found/discovered 512 KB or greater of conventional memory.

Re 1. Because the code patched into the MBR does not {write to every address in the 640-704K address space}. May cause a PARITY CHECK error message at some point.

Re 2. Revealed by examination of the code patched in. If less that 512 KB, the patch makes DOS believe that 448 KB is installed, not 704 KB. To be fair, the patcher documentation specifically refers to one of the requirements being '640K low DOS RAM'.

This patch assumes that RAM in the 640-704K address space is functional. The POST is only testing the RAM as high as 640 KB.

This patch also relies on the 5160's 640 KB of RAM being functional. Example. Faulty RAM at address 256 KB, and faulty in a way that results in the 5160's POST not reporting a 201 error. User does not notice that 5160's POST now only counts as high as 256 KB. POST records in the BDA that 256 KB of 'successfully tested by POST' RAM exists. The POST decides to boot from the hard drive, passing execution to the 'patched' boot code in the MBR. Due to point 2 above, the patch in the MBR results in DOS thinking that 448 KB of 'successfully tested by POST' RAM exists. Something is going to 'fall over' when it attempts to use the faulty RAM.

So just to be clear I am using the lo-tech 1mb ram board same as the 5150 that is why I asked if the tricks for the 5150 would work on a 5155/5160 : https://www.lo-tech.co.uk/wiki/Lo-tech_1MB_RAM_Board.
Here are the settings on the board, xtide, and 1mb ram board. And I dont believe that sram card uses parity unless I am mistaken.




I can try 704k.com just to post results.

 

[VERAULT]

Ok I tried out 704K.com

I select my bootable SD card from the XT IDE menu as seen here:





It starts to load the 704K.com file and then brings me back to the XT IDE menu, this time the "FC-1307 SD to CF Adapter V" Is missing and it only has 80h.









Then it says the system is loaded with 704K of ram. It tests fine. And I can reboot now. Is this the normal behavior of the 704K.COM program?

 

[modem7]

So just to be clear I am using the lo-tech 1mb ram board same as the 5150 that is why I asked if the tricks for the 5150 would work on a 5155/5160 : https://www.lo-tech.co.uk/wiki/Lo-tech_1MB_RAM_Board.
Here are the settings on the board, xtide, and 1mb ram board. And I dont believe that sram card uses parity unless I am mistaken.

I took a look at the circuit diagram. I can confirm that there is no parity generation+checking capability.

I select my bootable SD card from the XT IDE menu as seen here:

An 'ancient' version of the XTIDE Universal BIOS.

Ok I tried out 704K.com

I should point out that I have never used any of these 704K solutions. 640K ought to be enough for anybody.

It starts to load the 704K.com file and then brings me back to the XT IDE menu, this time the "FC-1307 SD to CF Adapter V" Is missing and it only has 80h.

I don't know why it would do that. Maybe an upgraded XTIDE Universal BIOS will fix that (and other issues).

Then it says the system is loaded with 704K of ram.

Good confidence because the 704K.COM documentation includes, 'Verification that 704K is actually installed in the system.'
But that could just be a check that RAM exists at addresses 640KB and 704KB-1, rather than checking all addresses in the 640-704K address space.
You could use the RAM checking capability in CheckIt to get better confidence of that address space.

Is this the normal behavior of the 704K.COM program?

From what you wrote, 704K.COM, after doing something (presumably adjusting the RAM amount figure in the BDA), does a warm boot.
If so, that might be an attempt to deal with the 'something loaded/run earlier than 704K.COM needs to know about the 704 KB.' that I wrote of in post #130.

 

[VERAULT]

An 'ancient' version of the XTIDE Universal BIOS.

Unless 704k.com was written after the xtide bios on my card I see no reason to uodate. I'm of the "if it aint broke dont fix it" mindset.

Updating things for no reason is a fools errand.

 

[modem7]

So it worked after a reboot. But then whenever I power cycle the machine the MBR is corrupted and wont boot. This happens every time. I am using DOS 5.0.
An FDISK /MBR does not repair the drive and I need to repartition and format the drive and copy all the files over from a backup.

How did you determine that the MBR "is corrupted", or is that an assumption ?

Dos could not see the partition anymore. Ironically my windows pc could still browse the files (sd card). I have to create a new partition and format it then start over.

Because you are using a RAM card with no parity generation+checking, it appears to me that Trixter's MBR patcher is the better method to use.
If you want to revisit that, consider the following.

I have enhanced the TESTMBR tool. In its enhanced menu are some options that can be used to see if the MBR is different after a power cycle.

1. Use Trixter's MBR patcher, but do not power cycle yet.
2. TESTMBR - [A] Advanced menu
3. TESTMBR - [C] Make a temporary copy of the first sector
4. TESTMBR - [G] Write the copy to file MBR.BIN
5. Power cycle.
6. TESTMBR - [A] Advanced menu
7. TESTMBR - [C] Make a temporary copy of the first sector
8. TESTMBR - [H] Compare the copy to file MBR.BIN

If the MBR is not what got 'damaged', you will see "All 512 bytes are the same" (otherwise a message telling you how many bytes are different).

 

[VERAULT]

Thank you. I will give it a try when I am back in the country and have time.