I see that you are investing a good amount of time restoring that MB and probably are having a whale of time doing so 😀. That PAL chip is going to be a tough nut to crack here, but I see that you are willing to tackle it instead of seeking an image dump from someone, thus i'll try give my two cents (though I'm not an expert on IBM PCs/XTs by any means).

Lets assume that memory map is as follows:

FE000 - FFFFF 8KB BIOS ROM
F6000 - FDFFF 32KB BASIC ROM

ADDR reqd. for BIOS ROM (8KB) CS1 generation would be - FE000-FFFFF = 1111 1(11)X (A19 A18 A17 A16 A15 A14 A13 unused), value in parentheses is a combination of A13 and A14, that goes through 74139, when both inputs are HIGH, output at pin 9 of 74139 is LOW, otherwise it's always HIGH.

ADDR reqd. for BASIC ROM (4x8KB) CS2 generation would be - F6000-FDFFF = 1111 0(11)X or 1111 1(00)X or 1111 1(01)X or 1111 1(10)X.

Operators:

& - AND
# - OR
! - NOT

EQs:

1CS1 = A19 & A18 & A17 & A16 & A15 & !A13_A14 & !MEMR
2
3CS2 = A19 & A18 & A17 & A16 & !A15 & !A13_A14 & !MEMR # A19 & A18 & A17 & A16 & A15 & A13_A14 & !MEMR 

DACK0 is used in RAM refresh circuitry, it's not needed here.

Now address selection and RAS generation are a bit unclear to me, also I don't get that CPLD syntax with conditions, could you rewrite it in WinCUPL way and explain why you implemented such equations?

By the way, are you sure there's an Addr.8 line at pin 15 instead of /MEMW?

Thanks for your answering, SSTV2!

SSTV2 wrote on 2022-08-02, 02:24:

Lets assume that memory map is as follows:

FE000 - FFFFF 8KB BIOS ROM
F6000 - FDFFF 32KB BASIC ROM

That's right! For some reason I thought that FE000 - FFFFF 8K BIOS ROM and F8000 - FFFFF 32K BIOS ROM. I forgot about BASIC and thought it was just two different types of BIOS ROM 😀 I will redo the conditions for choosing a /CS's as you advise, thanks!

SSTV2 wrote on 2022-08-02, 02:24:

DACK0 is used in RAM refresh circuitry, it's not needed here.

Yes, DACK0 ~= /REFRESH, so when DACK0 active - this is NOT a refresh cycle and we can safely set the active level to the /OE pin on EEPROM. Otherwise, when DACK = 0, this is refresh cycle and we do not need output data from EEPROMs. I argued something like this. Anyway, I tried to remove the DACK from the CS's select expressions and it did not affect anything....

SSTV2 wrote on 2022-08-02, 02:24:

Now address selection and RAS generation are a bit unclear to me, also I don't get that CPLD syntax with conditions, could you rewrite it in WinCUPL way and explain why you implemented such equations?

Iam using ABEL dialect for PLD, this is great-grandfather modern HDL languages, it is slightly more high-level than simple boolean expressions. But of course, in the end it all comes down to them.
Why iam implemented such equations? So, i looked through the available circuits of XT computers and found in one of them a node that seemed to me similar to the signal generation MA8 MA9:

As I roughly understood, from the diagram it follows that:
if MPX (SLAD) = 0, !DACK = 0 then A8 = A8;
if MPX (SLAD) = 0, !DACK = 1 then A8 = A8;
if MPX (SLAD) = 1, !DACK = 0 then A8 = A16;
if MPX (SLAD) = 1, !DACK = 1 then A8 = A17;
This is what I tried to encode in the GAL... As it turned out, this was not true (see below).

SSTV2 wrote on 2022-08-02, 02:24:

By the way, are you sure there's an Addr.8 line at pin 15 instead of /MEMW?

I checked twice, pin 15 going to ISA bus Addr.8 signal.

And now to the good news 😀
I managed to start the system with such expressions (the /CS choice has not yet been redone):

1"INPUT PINS
2        !MEMR                              PIN 1;
3        !A13_A14                           PIN 2;
4        A15,A16,A17,A18,A19                PIN 3,4,5,6,7;
5        D0,D1,D2,D3                        PIN 8,9,11,14;
6        A8                                 PIN 15;
7        DACK                               PIN 16;
8        MPX                                PIN 17;
9
10"OUTPUT PINS
11        !CS1,!CS2                          PIN 12,13;
12        MA8,MA9                            PIN 18,19;
13        
14EQUATIONS
15
16        CS1 = A19 & A18 & A17 & A16 & A15 & A13_A14 & MEMR & DACK;
17        CS2 = A19 & A18 & A17 & A16 & A15 & (!A13_A14) & MEMR & DACK;
18
19        WHEN (MPX) THEN
20                MA8 = A17;
21        ELSE
22                MA8 = A16;
23
24        WHEN (MPX) THEN
25                MA9 = A19;
26        ELSE
27                MA9 = A18;

or in simple boolean conditions:

1CS1     = !(  !MEMR & !A13_A14 & A15 & A16 & A17 & A18 & A19 & DACK );
2
3CS2     = !(  !MEMR & A13_A14 & A15 & A16 & A17 & A18 & A19 & DACK );
4
5MA8     = !(  !A17 & MPX 
6           #   !A16 & !MPX );
7
8MA9     = !(  !A19 & MPX 
9           #   !A18 & !MPX );

This allowed me to boot into DOS, run a memory test in CheckIt, play Commander Keen 5. Like everything is working properly.

Booted with two SIMM of 256kb each, which gave a total of 512kb of memory. I also booted with four SIMM of 256kb each, which gave a total of 640kb of memory. But the configuration with three 256Kb SIMM shows some strange number, something like about 576kb of memory, that is, it takes one of the bars for 64kb. When closing J8 and starting with three strips of 256kb each, it turns out 640kb main and another 64kb window in E000-F000 (umb). And when you close J7 and start with three strips of 256kb each, you get 640kb of the main one.

It remains a mystery why, then, the ISA_A8 signal (15 pins) was put into the PAL at all, and also what the D0..D3 bits coming from port 0xE0 could control. But apparently this will remain a mystery.

Amazing work Tronix !

I was looking at the photo of the board and the photo of the board in the other vogons thread and was wondering
What use have U6, RP5 and U9 since they still seem to be missing on the photo of your board, while present on the photo of the other thread.

weedeewee wrote on 2022-08-02, 08:34:

Amazing work Tronix !

Thanks.

weedeewee wrote on 2022-08-02, 08:34:

I was looking at the photo of the board and the photo of the board in the other vogons thread and was wondering
What use have U6, RP5 and U9 since they still seem to be missing on the photo of your board, while present on the photo of the other thread.

I don't know for sure, probably just slightly different versions of the boards. U6 is 74S280 - Parity Generators/Checker and U5 - 74LS245 buffer between SIPP data bus and internal motherboard data bus. On my version of the board, the traces between the 74LS245 buffer inputs and its outputs are closed, so if you install a IC, you must first cut all eight traces between the inputs pins and outputs pins.

Perhaps my version of the board does not support parity, or perhaps it is implemented somehow differently on small logic. In any case, I don't think I'll ever run into parity errors, so I won't tamper with this schematic node.

Tronix wrote on 2022-08-02, 07:09:

Booted with two SIMM of 256kb each, which gave a total of 512kb of memory. I also booted with four SIMM of 256kb each, which gave a total of 640kb of memory. But the configuration with three 256Kb SIMM shows some strange number, something like about 576kb of memory, that is, it takes one of the bars for 64kb. When closing J8 and starting with three strips of 256kb each, it turns out 640kb main and another 64kb window in E000-F000 (umb). And when you close J7 and start with three strips of 256kb each, you get 640kb of the main one.

When you had 4x 256K chips installed, did the boot memory test mention the remaining 384K at all (might be certain BIOS version specific)? I have this same motherboard and with the 4 chips it shows 640KB + "384KB Virtual" at boot.

PTherapist wrote on 2022-08-02, 13:13:

When you had 4x 256K chips installed, did the boot memory test mention the remaining 384K at all (might be certain BIOS version specific)? I have this same motherboard and with the 4 chips it shows 640KB + "384KB Virtual" at boot.

No, i don't see "384KB Virtual" at boot screen. I dumped bios from EEPROM and will attach it to the message, but I did not find the "virtual" text string in it.

UPD: I found your post with your BIOS dump here Re: JATON JXM-10MHZ-V3, XT motherboard ,
so bios'es are different. Your BIOS have Phoenix copyright and string "Virtual RAM: ". My BIOS dos't have "virtual" string and marked as "T U R B O - X T 1989"...

UPD2: PTherapist, no chance to read/dump PAL in any way?

Tronix wrote on 2022-08-02, 13:23:

UPD2: PTherapist, no chance to read/dump PAL in any way?

All I have here is a MiniPro. Can this read PAL chips, as I don't see anything listed in the program?

Edit: nevermind, I see it requires the building of an adapter. A bit out of my league at present I'm afraid.

PTherapist wrote on 2022-08-02, 14:24:

Can this read PAL chips, as I don't see anything listed in the program?

I don't know, probably not. Thanks anyway.

Great job!

The whole picture is much clearer with that schematic at hand, based on it and 74f153 multiplexer chip, I think the generation of addr.8 and addr.9 signals or RAM should look like this:

1A8 = DACK & !SLAD & A16 
2   # DACK & SLAD & A17
3   # !DACK & !SLAD & A8
4   # !DACK & SLAD & A8
5
6A9 = DACK & !SLAD & A18
7   # DACK & SLAD & A19
8   # !DACK & !SLAD <-  
9   # !DACK & SLAD <- these two lines probably can be ignored 

*Here SLAD is address selection (LOW=lower bits, HIGH=higher bits), it originates from delay line i presume.

And, of course, when these conditions are not met, A8/A9 are at low logic levels.

Now that data latch is a complete mystery to me also, but it somehow should affect PAL's outputs.

PS. That is one great schematic collection, wish I knew about that book earlier 😁

SSTV2 wrote on 2022-08-02, 14:53:

Great job!

I think the generation of addr.8 and addr.9 signals or RAM should look like this:
...skip...

Thank you. In accordance with this scheme (from scaned paper book), yes, it should look something like this, and I did something like this before, but this did not allow any programs to load. But I will try to apply exactly your equationss for the experiment. Now i made your corrections to the /CS selecting code, everything works fine. Now my firmware looks like this:

1CS1     = !(  !MEMR & !A13_A14 & A15 & A16 & A17 & A18 & A19 );
2
3CS2     = !(  !MEMR & A13_A14 & A15 & A16 & A17 & A18 & A19 
4           #   !MEMR & !A13_A14 & !A15 & A16 & A17 & A18 & A19 );
5
6MA8     = !(  !A17 & MPX 
7           #   !A16 & !MPX );
8
9MA9     = !(  !A19 & MPX 
10           #   !A18 & !MPX );

So far everything is working great.

SSTV2 wrote on 2022-08-02, 14:53:

Now that data latch is a complete mystery to me also, but it somehow should affect PAL's outputs.

Yes, the board also has U1 DM74S287 PROM 256x4 memory, whitch generating /RAS signals. One of bit (D2) from latch enters not only PAL, but also goes directly to address A4 of that PROM. I update circuit with this traces:

I can desolder this PROM and read its contents, but I'm not sure if this is necessary. Perhaps all this was done for the sake of some support for EMS memory of some early revision, but we are unlikely to find the original software.

SSTV2 wrote on 2022-08-02, 14:53:

PS. That is one great schematic collection, wish I knew about that book earlier 😁

Also available in DjVu format if you needed: http://wiki.sensi.org/download/albom_djvu.zip

SSTV2 wrote on 2022-08-02, 14:53:

I think the generation of addr.8 and addr.9 signals or RAM should look like this:

Briliance, SSTV2, your code worked perfectly. I did it wrong before. Thank you very much!
Now final PLD equations look like this:

1CS1     = !(  !MEMR & !A13_A14 & A15 & A16 & A17 & A18 & A19 & DACK );
2
3CS2     = !(  !MEMR & A13_A14 & A15 & A16 & A17 & A18 & A19 & DACK 
4           #   !MEMR & !A13_A14 & !A15 & A16 & A17 & A18 & A19 & DACK );
5
6MA8     = !(  !A8 & !DACK 
7           #   !A17 & DACK & SLAD 
8           #   !A16 & DACK & !SLAD );
9
10MA9     = !(  !A19 & DACK & SLAD 
11           #   !A18 & DACK & !SLAD );

1"INPUT PINS
2        !MEMR                              PIN 1;
3        !A13_A14                           PIN 2;
4        A15,A16,A17,A18,A19                PIN 3,4,5,6,7;
5        D0,D1,D2,D3                        PIN 8,9,11,14;
6        A8                                 PIN 15;
7        DACK                               PIN 16;
8        SLAD                               PIN 17;
9
10"OUTPUT PINS
11        !CS1,!CS2                          PIN 12,13;
12        MA8,MA9                            PIN 18,19;
13
14EQUATIONS
15
16        CS1 = A19 & A18 & A17 & A16 & A15 & A13_A14 & MEMR & DACK;
17
18        CS2 = A19 & A18 & A17 & A16 & !A15 & A13_A14 & MEMR & DACK 
19            # A19 & A18 & A17 & A16 & A15 & !A13_A14 & MEMR & DACK;
20
21        MA8 = DACK & !SLAD & A16 
22            # DACK & SLAD & A17
23            # !DACK & !SLAD & A8
24            # !DACK & SLAD & A8;
25
26        MA9 = DACK & !SLAD & A18
27            # DACK & SLAD & A19
28            # !DACK & !SLAD 
29            # !DACK & SLAD;

It seems to me that now everything works as it should have been in the original, except for the mysterious 0xE0 port control.
Thanks everyone, especially SSTV2!

😮 impressive reverse engineering guys!

Could the mysterious 0xE0 port control be deduced from the bios that displays the 384k virtual memory message and possibly lead to the creation of a driver to use the extra memory ?

Cool!

Tronix wrote on 2022-08-02, 16:02:

I can desolder this PROM and read its contents, but I'm not sure if this is necessary. Perhaps all this was done for the sake of some support for EMS memory of some early revision, but we are unlikely to find the original software.

That PROM chip is just a fancy address decoder, most likely put there to make the UMA, that PTherapist mentioned as "384KB Virtual", available.

Tronix wrote on 2022-08-03, 07:20:

It seems to me that now everything works as it should have been in the original, except for the mysterious 0xE0 port control.

Does it detect upper memory blocks above/below the previously seen 64KB E segment now?

weedeewee wrote on 2022-08-03, 17:16:

Could the mysterious 0xE0 port control be deduced from the bios that displays the 384k virtual memory message and possibly lead to the creation of a driver to use the extra memory ?

Whoah 😳, such driver already exists, it's all down to the hardware support to access those unused segments above 640K.

SSTV2 wrote on 2022-08-04, 01:35:

weedeewee wrote on 2022-08-03, 17:16:

Could the mysterious 0xE0 port control be deduced from the bios that displays the 384k virtual memory message and possibly lead to the creation of a driver to use the extra memory ?

Whoah 😳, such driver already exists, it's all down to the hardware support to access those unused segments above 640K.

Yes, can the hardware interface be derived from the bios code, and can someone implement it in use!umbs ? 😁