Support for 256 page frames using an extra page register

[superfury]

I've had an idea, looking at the source code of the driver and the original 2MB board schematics:

I've been looking at the Lo-tech EMS driver (in the software directory) for a bit.
I found out something: when it 'disables' a page frame (frame being IObase+0 through IObase+3), it simply writes 0xFF to the port.

Then, looking at the board diagram (https://www.lo-tech.co.uk/w/images/7/73/Lo-tech-2MB-EMS-Board-schematic.png ) I see something interesting:

• The register outputs support full 256 page register values to be decoded onto 8 memory chips, thus 4MB. But, it only connects the first 4, thus setting bit 7 in the registers effectively 'disable' the memory (mapping to chips 4-7, which aren't connected), ignoring reads (floats the bus, thus 'unmapped') and writes don't respond?

Maybe someone could patch the board with an extra storage chip to set *RAM-SELECT (active low) based on *REG0-3OE (which are the inverted frame number bit in the added register to check, basically routed to address the added new register bit from a translation chip simply wire them to the output pins on another 74AC7530 chip like the page registers?), then use it's output bits to make (using a LUT ROM chip, address being the inputs):
Bit looked up(based on REG0-3OE (what window bit to inspect) and the added 74AC7530 chip for the 4MB enabled bit to use) - RAM-A21 - *RAM-SELECT INPUT -> *RAM-SELECT OUTPUT
Default result is 1(unmapped, all other of the 8 cases)
0 - 0 - 0 -> 0 (compatibility, <128 frame indexed)
1 - 1 - 0 -> 0 (4MB page addressed and enabled)
1 - 0 - 0 -> 0 (2MB page addressed and enabled in extended mode)
The only one cases remaining is not adressed and compatibility mode past 128(which is 'unmap page frame').

RAM-SELECT inputted from the 74HCT6880W and outputted to the sRAM CHIP SELECT chip.

So basically, put the new register at base address+4 for example. Then (programming it):
For unmapping: clear bit in register and set bit 7 in the page register (in compatibility mode now, so 2MB EMS compatible, bit 7 unmaps there due to chips 4-7 not being present, so emulate that here. Added bonus: like the original board, memory is unmapped with bit 7 set (since no RAM chips respond)).
For mapping enabled frame: clear bit in register and set page number below 127(compatibility with Lo-tech EMS driver), or set the window's bit (bit 0-3 for frame 0-3)) in register and set a 4MB page frame in the corresponding page register.

Although this is just theoretical. Any thoughts?

Edit: Or maybe more simple translation logic: include the 74AC7530 4-bit outputs in the LUT as well (requiring a 11-bit address for the ROM). So the translation ROM's address pins are connected to:

• RAM-A21 (high bit used)
• *RAM-SELECT input (memory address enable)
• REG0OE (reg0 memory addressed)
• REG10E (reg1 memory addressed)
• REG2OE (reg2 memory addressed)
• REG3OE (reg3 memory addressed)
• 74AC5730 1Q (is REG0-OE enable bit)
• 74AC5730 2Q (is REG1-OE enable bit)
• 74AC5730 3Q (is REG2-OE enable bit)
• 74AC5730 4Q (is REG3-OE enable bit)
  And RAM-SELECT can also be connected to the ROM's OE and CS pins to make it output it's result when needed.

Then put the logic results I mentioned into the ROM as a 1-bit output, which is connected to the *RAM-SELECT pin on the sRAM CHIP SELECT chip.

Basically all you'd need is an extra I/O chip for mapping the 74AC5730 at IObase+4, the chip to store it (said 74AC5730 chip itself) and a 10-bit addressable ROM chip to handle the added translation step.

[hkzlab]

Hello, struggling to understand what the desired end result is here.

The original board does not add the other 4 SRAM ICs, and thus, requesting a page with RAM-A21 high, is effectively pointing into the void for writes.
But, while writes will do nothing, reads will not float the bus, at least not the ISA bus: the '245 transceiver will still get enabled, and the pullup resistors behind it will get 0xFF to appear on the bus.

This means that the board will not totally disappear from the bus when the pages are "unmapped".

I am genuinely wondering, why is there an interesting in unmapping the pages? Avoid writing garbage to the memory? If a software is doing that because it supports 2MB only, and tries to unmap a card with the full 4MB, it will just end up writing garbage to the upper, unused, 2MBs, leaving the lower ones untouched.

If protection of the content of memory is the desired end result, maybe it would be better implemented with a write protect bit on an additional IO port, disabling writes for upper and lower half of the card?

[superfury]

Yeah, that's what is happening indeed.

What I mean is an extra 4 bits in the added register at IObase+4, that, like I mentioned, disables the upper 4 chips select pins for each of the window when the bit in said register is cleared. That will have the effect of them not responding, thus pull-up on reads (0xFF) and no action on writes (preventing writing memory), thus retaining the unmapping effect on the selected window.

The pro is that:

• You'll retain compatibility with the 2MB board for unmapping using bit 7 of the register.
• Each window can be individually unmapped (bit 7 (the highest address pin) of the used window register is checked against the active window select 4 pins and others mentioned in the LUT inputs to archieve this. It basically conditionally masks the window global chip enable pin (before the chip is selected at the final chip) based on the selected lower/upper 4 windows being used and the window 4MB enable register).
• Setting the bit in the extra register at IObase+4 (bits 0-3) causes that window to map the high pages normally to 4MB instead of unmapping it, by passing through the global window enable to the 8 chip select lines normally, as in the 2MB card schematics.

If it's just a write protect, software unmapping by setting bit 7 of a window register will still read the data using only write-protect, instead of 0xFF, thus not really unmapping it. Disabling (masking) the upper 4 windows chip select for bit 7 set with 4MB register window bit cleared fixes that entirely.

The only thing I don't know is if such a LUT ROM can be used to provide the global RAM-SELECT pin translation in time for the memory address to be properly latched by the RAM chips.

Could this logic I mentioned be done without a single addressable ROM chip, using chips that do translate the chip enable in time for the RAM chips (like using multi-XOR, multi-AND gate chips etc.)?
The part of the window select vs it's bit in the 4MB enable register could be done by wiring each of the 4 window enable pins in parallel to create (((REG 0-3 OE XORed) AND 4MB register low 4 bits) OR'ed together the 4 resulting lines into one line) XORed to create an disable signal for the upper chips (but not the lower chips), so AND the result with bit 7 from the window register to apply it to the upper 4 chips only, then ORing it onto the RAM-SELECT pin to disable the chip select (reads and writes) and effectively pull up the bus on reads.

So you'd need 5 XOR gates, 5 OR gates and 5 AND gates for this unmapping logic. Though it'd require a lot of wires/traces (30 wires or traces).

[hkzlab]

Yes, I get what you want: selectively disable the upper banks.
What I don't get is the why. What is the use case? Did you find an application that refuses to work if it detects writable ram above a certain page? Or do you have some use for the fact that you need to both write-protect a page and also not be able to read from it?

[superfury]

The driver can apparently be given the instruction to disable an EMS frame window (evidenced by it's usage of 0xFF (DIS_EMS) in a page register to disable the window). Since bit 7 is driven to float the memory chips on reads and nothing responds on writes (both of the same cause: the chip enable pins aren't connected), that causes reads to return 0xFF(pullup) and writes to not have any effect.

The reset_phys_page and ramchk routines in the LTEMM driver both set this value to the page register.

reset_phys_page is called at various points in the driver, so it's obviously important behaviour to implement.

I am wondering about something, though. Are the latch registers (at 260+ and the 4MB enable register) cleared or set on powerup? Do they need some sanity on RESDRV to become cleared?

[hkzlab]

Now, it's been a few years since I dabbled into this, but, if I remember correctly, this is the reason why I limited the modified driver to 255 pages, so the 256th would be used as scratch and not cause issues when the EMS was "disabled", given that the board is never truly disabled and still occupies the bus. That page should not be accessible anyway, while going through the driver.

You sacrifice 16K, you save quite few complexity on the board, plus a small range of I/O ports.

Resetting the latches is a task better suited for the driver, not the circuitry on the card: it would add additional useless complexity: that memory is not meant to be used until the driver is loaded, so it might as well write known values to registers when setting itself up.

[hkzlab]

ISA_EMS.pdf
This is a way to implement it, occupies 4 more I/O entries and gives you a way to disable the 4 upper ram ICs independently, adds two logic ICs.
Of course you'll have to set sane values for the new latch when initializing the driver.

[superfury]

The issue there is that you either enable all or some RAM ICs for unmapped support or none.
The driver wants (and is instructed to by the OS) to enable and disable(unmap) the upper RAM ICs on a window base, not on a global base.

[hkzlab]

And that can be handled by a modified driver, which needs to be changed anyway, as the new register needs to be taken care of.
The alternative in implementing all that bunch of logic in hardware is using a GAL IC, you don't really want to have fun with ROM timing, IMO.

[superfury]

For now I've implemented that extra register and handling of it in my Lo-tech 2MB EMS memory emulation.
Basically working as I've described it (unmapping the 2MB+ range when it's addressed with the top bit clear and the extra register bit cleared). Otherwise, just enable said mapping to 2MB+.

[hkzlab]

I'll have a look later at a way to do it without inserting programmable logic and/or adding too many IC.

[hkzlab]

ISA_EMS.pdf
Here it is, added two more ICs. This should allow to set upper memory as disabled with a per-window configuration, so you can disable upper memory only for selected registers.

[superfury]

That should do it in theory.
So it operates as I've described? The register bit when set allowing 4MB page, otherwise 2MB page with >128 disabling the memory pins?

Although from what I can see the 4MB enable register is mapped to addresses base+4 through base+7 (it doesn't check the lower 2 bits of the address)?

The only thing I'm slightly concerned about is the power-on value of the latches (the 5 registers themselves). Are they power-on 0xFF or 0x00? If 0x00, there's no problem, as it defaults to 2MB EMS board compatiblity? If it's 0xFF might be a problem for the 4MB mapping register at IOport+4, since it's supposed to be cleared for compatibility?
Perhaps use the RESETDRV for initializing somehow? That needs to be page registers FFh, 4MB register 00h for compatiblity mode when RESETDRV is active.

[hkzlab]

Clearing the bit enables all the RAM banks for said register. Setting it will disable the upper banks. So you should call it a 4MB Disable register :) Decoding takes less ICs that way.

Yes, I'm totally ignoring the lower two bits, so the register is mirrored there. There are compromises to be made between number of ICs and precise decoding of the address. Saving 3 I/O ports is not really worth it. Beside, It remains to be seen if the added delay by all that decoding to disable the ram is not going to cause glitches...

I don't see the startup value of those latches in the datasheet. Taking for granted a stable value at powerup is not a good idea.

It's also not important, we're not emulating anything: the board is already using a modified driver and that memory should never be used until the driver is loaded. So the solution here is simple: set the correct value in the registers when you load the driver, depending on the parameters passed to it. If you think about it for a moment, even the original board could start pointing the windows at random locations in the memory, the situation gets rectified when the driver loads.

If the hardware were to operate independently of the OS, it would make sense to go through the effort of properly resetting every latch on the board, but given that it needs initialization... who cares?

[hkzlab]

You know, after looking at this with a fresh mind, and after having actually redrawn the schematic to add this feature... I still think it's a waste of space on the board for little to no gain.

Let me break it down.

The current situation is as follows:

• The board is initialized and handled by a driver. Software should access the additional memory going through the driver, as there is no standardized control interface for EMS.
• Currently, the driver allows 255 pages to be accessed by the software, that's 4080KB, the 256th page is not accessible unless one wants to bypass the driver. We're losing 16KB here.
• When the driver wants to disable a window, it sets it to 0xFF, which is pointing to the 256th, unused page. At that point, writes on that page can happen (from different windows too), but that data cannot be used anyway, so we're not corrupting program memory.
• Unmapping doesn't "free" the address space, as the board is going to respond to reads anyway

With your proposed change:

• We can selectively disable RAM selection for every one of the 4 windows, by setting/clearing a bit in a register and then setting the window to any page > 127 (msb set)
• We can access the whole 256 pages, in case we need to disable access, we need to use the new register
• This requires new decoding circuitry for the additional register (one register, but, more realistically, a space of 4 needs to be occupied, unless one wants to splurge on ICs or go PLD)
• This requires additional decoding circuitry to disable the RAM according to selected window and the new register value

We could simplify this a bit, by making it so that setting a bit in the new register disables the window regardless of the address it is set to. That would save some decoding logic.

But still, it's going to be a bigger, more expensive board, just to save the 16KB.
This is unless you can come up with some piece of software that actually croaks when the driver points to the unused 16KB instead of disabling the RAM altogether. That would convince me that the additional space and cost might be worth it.

The updated schematic is already in a branch (feature/reg_disable) I pushed and the board just needs to be routed now, if you are convinced otherwise and want to have a go at it though.