Answering this older thread since I think I have mostly figured it out.

Page 23 of the Tandy 1000 Service Manual (also page 21 of the Tandy 1000 Technical Reference Manual) lists the logic equations for U53 Memory Address Decode. I think this is the PAL chip that needs replacing in order to use a single 1.01 BIOS ROM chip in an early 1000 that came populated with two ROM chips. These two equations are of particular interest:

ROMSC0* = RFSH* & /MEMR* & 19 & 18 & 17 & 16 & 15 & 14 & 13
ROMSC1* = RFSH* & /MEMR* & 19 & 18 & 17 & 16 & 15 & 14 & /13

By my math, these decode to 8k ranges from FE000-FFFFF and FC000-FDFFF respectively. This is entirely consistent with the 16K BIOS being split across two 8K ROM chips, and needing a PAL update to use a single 16K ROM chip. Curiously, ROMSC1*/U10 is the low addresses and ROMSC0*/U9 the high.

As for the Service Manual describing two 32K banks covering a 64k address space from F0000 to FFFFF, I speculate as follows:

* The service manual refers to the revised decoding of the newer U53 PAL
* It does indeed decode into those two ranges. It seems possible from the schematic - all needed address lines are routed to the ROM sockets.
* When the stock 16K ROM is used, it aliases over the ranges F8000-FBFFF and FC000-FFFFF, with the code presumably running in the higher range.

As I said, this is speculation, I have no other data nor looked at real hardware to confirm. As to the question of why they would support such a large range, probably because they had the option to do it with just a PAL modification.

For folks with the two-chip 1.00 BIOS who would like to upgrade to 1.01, I suspect it is possible (and easier) to just burn the 1.01 BIOS across two 8K ROMS. Or, two larger ROMS with the data replicated across the ROM.

It would however be a fun little project to come up with a 16V8 GAL program to replace the old PAL.

Actually... I looked at the U53 PAL logic and pin assignments. Tandy made use of functionality in the original PAL that a more modern GAL16v10 can not do. So no easy drop in replacement chip unfortunately.

Jayeson wrote on 2021-01-24, 03:58:

By my math, these decode to 8k ranges from FE000-FFFFF and FC000-FDFFF respectively. This is entirely consistent with the 16K BIOS being split across two 8K ROM chips, and needing a PAL update to use a single 16K ROM chip. Curiously, ROMSC1*/U10 is the low addresses and ROMSC0*/U9 the high.

For me, that's expected, but I also get why you are surprised by ROMCS0 addressing the high ROM.

A 8086-based system needs a ROM at FFFFF to be able to boot. So the BIOS in IBM compatible systems is aligned to the end of an address space. A system with a single 8 kilobyte ROM (like the original IBM PC and XT) will always have that ROM at FE000-FFFFF, so it makes a lot of sense to call a ROM at that addess the primary ROM (and assign ROMCS0 to it), and call the extra 8K at FC000-FDFFF an optional extension.

Jayeson wrote on 2021-01-24, 09:27:

Actually... I looked at the U53 PAL logic and pin assignments. Tandy made use of functionality in the original PAL that a more modern GAL16v10 can not do. So no easy drop in replacement chip unfortunately.

I was confused by this statement, as I supposed that the modern GAL devices were supposed to be a superset of the old PAL devices. The issue in this case is that Tandy used pin 9 as output on a 20-pin programmable logic chip. Today's standard programmable logic chips in DIP-20 have 8 outputs, on pins 12 to 19, whereas the old 82S153 used by tandy had ten output-capable pins, adding pin 9 and 11 as possible outputs. To make matters more complex, pin 9 uses 10 "product terms" to be combined. Modern GAL/PAL chips only allow 8 product terms for a single output pin.

There is one "modern" GAL in DIP-20 that has 10 outputs (including one on pin 9), the GAL18V10, but it has been discontinued in 2011 with no suitable replacement. And even this chip allows ten product terms only on pins 14 and 15. So indeed, there seems no possibility to use any currently available programmable chip as drop-in replacement for that 82S153 gate array. An GAL22V10 + interposer likely could do the job, though.

I also took it for granted that the 16v8 would work. In addition to what you raised, the 16v8 can't be configured with enough feedback pins to implement the equations as Tandy listed them. That could likely be worked around if it was the only issue.

I had the same thought that a 22v10 plus a small board was the best option. Unfortunately not as easy to apply versus just burning a readily available chip on an off the shelf programmer.

I was curious so I wrote up the logic for a 22v10. Works out pretty well actually, mostly 1:1 with the original pinout, just need to wire pin 14 to pin 9 and pin 12 to pin 10. That could be done with a couple of bodge wires on the chip itself after programming, then trimming back the overhanging pins. When my original 1000 arrives and if I have time, I will do some comparisons with the original logic to see if I have it right. I'm not sure I am reading the sense of the complemented inputs/outputs correctly. I am also not entirely sure Tandy's equations from the manual are 100% correct either, there was at least one typo.

https://github.com/JayesonLS/TandyProgrammabl … PalOriginal.pld

[Update]: It occurred to me that the equation for VSACC* should have had too many product terms for 22v10 pin 14, and WinCupl did indeed reduce it to 8 terms. This is because, unless I keep reading it incorrectly, there are two pairs of duplicate product terms in Tandy's published equations. This may be a transcribing error in the manuals and the real equations may need more product terms.

Jayeson wrote on 2021-01-26, 05:27:

I am also not entirely sure Tandy's equations from the manual are 100% correct either, there was at least one typo.

This is because, unless I keep reading it incorrectly, there are two pairs of duplicate product terms in Tandy's published equations. This may be a transcribing error in the manuals and the real equations may need more product terms.

To me, it seems the manual is imprecise, incomplete (by missing a whole product term) and simplified (by leaving off repeated "RFSH * !MEMR"), and it should read like this instead

1VSACC*  = RFSH* * !MEMR* * !19 * !18 * !17 * !MC3 * !MC2 * !MC1
2        + RFSH* * !MEMR* * !19 * !18 *  17 * !MC3 * !MC2 *  MC1
3        + RFSH* * !MEMR* * !19 *  18 * !17 * !MC3 *  MC2 * !MC1
4        + RFSH* * !MEMR* * !19 *  18 *  17 * !MC3 *  MC2 *  MC1
5        + RFSH* * !MEMR* *  19 * !18 * !17 *  MC3 * !MC2 * !MC1
6        + RFSH* * !MEMW* * !19 * !18 * !17 * !MC3 * !MC2 * !MC1
7        + RFSH* * !MEMW* * !19 * !18 *  17 * !MC3 * !MC2 *  MC1
8        + RFSH* * !MEMW* * !19 *  18 * !17 * !MC3 *  MC2 * !MC1
9        + RFSH* * !MEMW* * !19 *  18 *  17 * !MC3 *  MC2 *  MC1
10        + RFSH* * !MEMW* *  19 * !18 * !17 *  MC3 * !MC2 * !MC1
11        + HGMEMAC*

Yeah, that's right. 11 product terms. The 82S153 can dynamically assign any product term to one or multiple outputs, whereas modern GAL/PAL chips have dedicated product terms per output, with a limit of 8 or 10 product terms per output. On the 22V10, you should be able to assign !MEMR + !MEMW to an ununsed pin and feed that back into the VSACC equation.

The idea of the equation is that VSACC is to be asserted if the 128K on-board memory is addressed. This is the case if either the B800-BFFF range is accessed (HGMEMAC), or A19/A18/A17 (the 128K page) match MC3/MC2/MC1 (the MEMMAP bits from the system configuration register). This should only happen if either "memory read" or "memory write" is active, but "refresh" is inactive. Refreshing of the 128K is performed by video scanout and need not be performed using (ISA) refresh cycles. Refreshing of the whole video memory even is text mode where only a single page is scanned out is achieved by mapping the RAM chips in a column-major layout: Subsequent addresses are mapped to the same column in different rows (whereas the conventional mapping, which also enables fast page mode on more modern systems, map subsequent addresses to different columns in the same row). This means that after scanning out 256 columns of video, all rows have been accessed and refreshed.

Interesting info mkarcher.

According to the 22v10 datasheets, they have more product terms on the inner output pins, up to 16. Unfortunately the top and bottom outputs have only 8. Those pins are more convenient since it would allow for a fairly clean solution without an intermediate board. Also, seems that that the still-in-production Atmel/Microchip 22v10s can not be programmed with the common budget programmers. Needing a board and using dodgy remarked Xilinx chips sounds a bit less fun.

I am hoping my early Tandy 1000 comes with the older PAL and two ROM chips. I would like to confirm whether or not burning the 1.01 BIOS across two 8K ROMs works.