pan069 wrote:

Great! Thanks for the heads up, much appreciated!

Oh, maybe for the simm memory to work, the DIP memory shouldn't be installed, could that be an option? I mean, there doesn't seem to be an explicit jumper.

There are DIP and SIMM variants of bank 0 and 1. So you can use bank 0 for DIP, and bank 1 for SIMM, for example, or vice versa. But putting memories in both DIP and SIMM sockets of the same bank is wrong.

@root42 I see. There is a bit more "matching" required to pair a CPU & FPU. So... The way I understand it, in synchronous mode the CPU waits for the FPU to finish and in asynchronous mode the FPU can execute instructions in tandem with the CPU. Not sure how they sync back together in async mode, i.e. when the CPU needs a calculated result from the CPU. Would that also not be something you'd have to cater for in software...? Setting a jumper to select the mode on the board to select the mode seems like a very definitive choice.. Anyhow, I've never done any FPU programming before and clearly I don't know enough about it (yet)...

So, with a 16Mhz CPU, you can match an 16/8Mhz FPU? Or is that not how it works?

PS: I noticed in your signature your ET4000. I have the VLB version (ET4000/W32), had it since the yearly nineties, still my favourite video card: https://imgur.com/a/M1Dc7t9

retardware wrote:

There are DIP and SIMM variants of bank 0 and 1. So you can use bank 0 for DIP, and bank 1 for SIMM, for example, or vice versa. But putting memories in both DIP and SIMM sockets of the same bank is wrong.

Ah. That makes sense. So the DIP installed kinda acts like the "jumper" i couldn't find. This might make my life easier since I want to install 4 megs anyway. Hmm, it also means I don't have to trouble shoot the DIP issues... Actually, maybe I do that anyway as I might want to change the memory config in the future.

By the way, should I leave the parity chips? I assume they would stay regardless if DIP or simm is installed...

Thanks!

pan069 wrote:

By the way, should I leave the parity chips? I assume they would stay regardless if DIP or simm is installed...

Banks must be either left empty or fully populated. So the parity chip of the DIP banks you use have to be there, but on the banks you use with SIMMs there must not be a DIP parity chip inserted.

Note the "0" and "1" between the SIMM sockets. This shows you which ones belong to bank 0 and 1, respective. So you can be sure to avoid inserting both SIMMs and DIPs into the same bank.

OK. So when using simm instead of DIP for a bank, the onboard parity chip for that bank also needs to removed. The simm would have it's own parity chip onboard. Thanks!

There is only one exception: only if you use 8-bit SIMMs (they exist but are rare) it makes sense to use an additional DIP parity chip. You can recognize these 8-bit SIMMs by their chip count (8, 4 or 2). Parity-equipped modules have either 9, 6 or 3 chips.

There's seems to be always an exception 😀

Just checked, I have 4 x 1mb simms. Each stick has 3 chips on it, one chip has a different number of pins, that one would be the parity chip.

Great. Learning a lot here. Thanks everyone!

@Predator99 I managed to do some tests. This is what happened:

- Removed the FPU.

- Removed the DIPS/parity chips from bank 1. Booted, 512Kb reported. I can't seem to find a memtest (base mem) for a 286 so I go by what's reported. System seems to work fine, no weird crashes when posting.

- Removed the DIPS/parity chips from bank 0 and inserted the chips from bank 1 (i.e. swapped the chips). Booted, 512Kb reported. No weird crashes. System seems to run fine.

- Reinserted the chips that where originally in bank 0, into bank 1. Booted, 640Kb reported. We're missing 384Kb... No weird crashes experienced.

- Removed parity chips. Booted, 640Kb reported. No weird crashes experienced.

- Removed all DIP/parity chips, inserted a 1mb simm. Booted, no post. Probably requires both slots for bank 0 (simm) to be filled.

- Added another 1mb simm into bank 0. Booted, posting, 1664Kb reported... Hmmm, still missing 384Kb...

There is basically 384Kb missing, between 640 and 1024. Could be another problem with the board. I can't see any physical damage (front or back). So, not sure....

I'm going to run the extended memory test which you mentioned in another thread [1]. I will first run it with 2mb installed and then again with 4mb.

I'll update here...

UPDATE

So, I ran "testext.exe" for over 30 mins (is that program supposed to end or does it just keep going? Weird...) and there were no errors found in the 1 meg extended memory.

I have added the other 2mb in bank 1 and post is now reporting 3712Kb, was expecting that, sill 384Kb missing. I have started textext.exe again and will let it run for an hour or so, 30 passes done and no errors so far.

[1] ISA XMS/EMS Memory Extension / Expansion cards: Now Running without Driver / Documentation :-)

The 384kb is the memory between 640kb and 1meg. The chipset does not expose memory in this area to the CPU.

Many boards will remap this memory, either automatically or through BIOS, so the entire memory is accessible, but some won't. It generally isn't a fault.

Its indeed interesting. I have attached a hard drive and installed DOS 6.22 and when I do "mem" I get the following:

1Memory Type               Total =   Used  +   Free
2----------------------  -------   -------   -------
3Conventional               640K       18K      622K
4Upper                        0K        0K        0K
5Reserved                   384K      384K        0K
6Extended (XMS)           3,072K       64K    3,008K
7----------------------  -------   -------   -------
8Total memory             4,096K      466K    3,630K

So, "Total memory" is 4,096K = 4mb... It's interesting how "upper" is 0K but "reserved" is still 384K. Hmmm.....

canthearu wrote:

Many boards will remap this memory, either automatically or through BIOS, so the entire memory is accessible, but some won't. It generally isn't a fault.

What's even more interesting, my Headland HT12/A-based Octek Fox II board has a BIOS option that states that memory relocation works only for 1MiB configs. And indeed, it gives 384k of extended memory with 1MiB (DIPs) and 3072k with 4MiB (SIMMs). Not that typical 286 programs need the full 4MiB that much.

So you didnt find a defective memory at all? Then it was simply a connection problem that you solved by reinserting the chips.

Yes, and I agree you dont have to worry about the "missing" 384k. I found this in many 486 boards and was very confused at the beginning that the BIOS doenst count the whole amount.

pan069 wrote:

- Reinserted the chips that where originally in bank 0, into bank 1. Booted, 640Kb reported. We're missing 384Kb... No weird cra […]
Show full quote

- Reinserted the chips that where originally in bank 0, into bank 1. Booted, 640Kb reported. We're missing 384Kb... No weird crashes experienced.
- Added another 1mb simm into bank 0. Booted, posting, 1664Kb reported... Hmmm, still missing 384Kb...
There is basically 384Kb missing, between 640 and 1024. Could be another problem with the board. I can't see any physical damage (front or back). So, not sure....

I have added the other 2mb in bank 1 and post is now reporting 3712Kb, was expecting that, sill 384Kb missing.

I think I already told you where the 384KB go, and even mentioned the exact number. Post a photo of your BIOS and I'll tell you what to change, or search for a setting similar to "memory relocation" and disable all shadowing. You don't have bad memory, you have "bad" settings. (bad for seeing the whole 1MB)

The thing with the Headland chipset based mobos I know of is that they did not get drivers that let the common user use its capabilities fully.

I used Headland (later bought by LSI) 486 based mobos myself. Their chipset documentation was very good and I had written my TSR that enabled the 4k memory windows I wanted in the A000-F?FF range, and set them read-write, and then chained them into DOS' internal UMB block list. This was necessary because, as I already said, there were no drivers that did this.

I hope I'll find the files when I sift through my old CDs soon... that would work with minor changes on the 286 chipset too.

Edit:
I think it was also possible to remap the unused windows of that 384kB range after the end of contiguous memory... let's hope my TSR's source files didn't already land in the data nirvana...

I like the combo TSR+Headland chipset, because that way it was unneccessary to use EMM386 just for having UMB. You all know EMM386 has some overhead (adding virtualization level in memory access slows down over real mode. There were also EMM386 replacements like MICEMM386 that used undocumented processor features to implement memory mapping in real mode, without the virtualization penalty. But sadly it was not very compatible)

konc wrote:

Post a photo of your BIOS and I'll tell you what to change

There is a photo on page 1 of this thread. On the BIOS it says:

1(c) 1986, AMI
2286 BIOS SETUP (not sure if it says, 0DD, ODD or 0D0..)
3S/NO 703534

Not sure what the T.B. stands for...

By the way, I don't have a CMOS battery attached and when I started it cold from being turned off over night, the CMOS settings where obviously lost, but the memory counter went back up to 702K. It only ever does this the first time on cold boot. Every other time it just reports 640K... You'd assume that CMOS defaults would work well for the board...

pan069 wrote:

There is a photo on page 1 of this thread. On the BIOS it says:

🤣 🤣 I mean a photo of the setup program, of your screen, where we can see the options.
Anyway, does you BIOS look like this? (photo borrowed from another user's thread)
If so, set "Bios shadow option" to disabled and "Memory relocation" to enabled. Then after moving up and down with the arrow keys on the menu a bit, you'll see than the "Ext. memory size" will show your missing 384KB and during POST you'll be seeing the full 1MB.
If your BIOS is slightly different look for similar settings.

pan069 wrote:

You'd assume that CMOS defaults would work well for the board...

You are making the assumption that these aren't good settings.

🤣 🤣. I see, you meant photo of "CMOS settings" rather a photo of the BIOS... Got lost in translation I guess... 🤣

Yes, that's indeed very similar to my CMOS setup, my setup doesn't have the "0 Wait State Option". Currently pumped with work, I will give those settings a go and see what happens.

However, from what you're saying, the post screen should either show 640K or 1024K depending on settings. But mine shows 704K from cold boot after CMOS was cleared/lost. Now, it's 64K difference but when going into CMOS settings it will say "Base memory size: 640K" and "Extended memory size: 0". Maybe it's not the defaults that are wrong but just reporting of it. I'm sure you agree that's very confusing either way...

pan069 wrote:

🤣 🤣. I see, you meant photo of "CMOS settings" rather a photo of the BIOS... Got lost in translation I guess... 🤣

Yes, that's indeed very similar to my CMOS setup, my setup doesn't have the "0 Wait State Option". Currently pumped with work, I will give those settings a go and see what happens.

However, from what you're saying, the post screen should either show 640K or 1024K depending on settings. But mine shows 704K from cold boot after CMOS was cleared/lost. Now, it's 64K difference but when going into CMOS settings it will say "Base memory size: 640K" and "Extended memory size: 0". Maybe it's not the defaults that are wrong but just reporting of it. I'm sure you agree that's very confusing either way...

It's not actually, keeping shadowing off and memory relocation on (I hope you have this option) will show the full 384KB of extended memory. If you you start changing shadowing options "bios", "video", "both" each setting will reserve some memory (bios x, video y, both x+y), so you'll see 1024-x or 1024-y or 1024-x-y. It's not bad to have shadowing enabled, in fact it helps performance, I'm just trying to make you see your missing 384KB so that you give up on the memory problem idea. Forget what you see on the first boot without battery and bios options not set, it's irrelevant. Focus on what you see after saving.

In addition to what @konc says, I think it is very interesting that your BIOS after a cmos reset shows 704k.
If you did not notice already: it apparently mapped and counted the A000-AFFF range as hardware RAM.
This was quite usual back then, when it was not used that commonly as hires framebuffer area like today.
I would not be amazed if it turns out that you have a patched BIOS that already does some part of what you want to achieve 😀

In the early PC age there were several cards that added RAM in the 640k+ area, and it was common to use the A000 range as DOS RAM, resulting in a count of 704k (= 640+64).

Hey, thanks everyone for chipping in and sharing info! Very much appreciated. I'm going to try out the advice provided here. I'm just a bit swamped with work at the moment, probably won't get to this until the weekend. I'll report back asap.