Home-made memory expansion board prevents booting from floppy disks?

[tom.storey]

Hi all,

Ive made my own memory expansion for an XT that brings it up to 640KB and gives me a further 128KB to play with as upper memory blocks. The memory expansion seems to work fine, and I can run the machine from it all day without any issues, including with the upper memory blocks.

But it seems that I am unable to boot from floppy disks when I have my memory expansion installed. The machine otherwise runs fine with the memory expansion present. I can boot off the XT-IDE adapter, and run all kinds of software all day, CheckIt reports no problems, things like that.

In a recent thread (https://forum.vcfed.org/index.php?t...ve-no-longer-wants-to-read-any-disks.1241676/) I had hit an issue trying to boot from some floppy disks that I had made in the past and initially thought this might have been my drive flaking out, or perhaps the media going bad, but I am now starting to think that this issue was also caused by this memory expansion problem.

The biggest issue at the moment is when I try to boot a DOS 5.0 floppy disk, the floppy drive goes into some kind of machine gun mode where it has obviously hit the end of its travel, but it keeps trying to go further. Im worried that if this continues it will damage the drive. Once booted from the XT-IDE adapter that I have installed in the machine, I can access the floppy disks just fine and there are no issues, so it seems like it is something related to the early stages of booting from a floppy disk.

Does anyone have any ideas what I should start to look at to figure out why this is happening? I have an oscilloscope and logic analyser if there are specific signals that I should monitor.

Attached is a copy of the schematic of the memory expansion. The data bus is buffered on to and off of the board via a 74HCT245 that is part of the prototype board that I have created. The direction of that buffer is controlled by the MEMR/ signal, and the tri-state outputs are controlled by the MEMEXP_DECODED/ signal. Most other signals used on the board are also buffered by some 74HCT245's whos direction and tri-state are completely static.

I have an original memory expansion board that came with the computer, and when this is installed it boots just fine from the floppy, so Im wondering what I have done wrong.

Thanks all!

 

[GiGaBiTe]

If the floppy drive works when booting from XT-IDE, but not when you directly boot from the floppy, I'd suspect the stack pointer being sent off into lala land and the CPU tries to execute nonsense and crashes.

If the floppy head is knocking on the stop, the CPU probably crashed in a loop trying to read data from the disk. I've had this happen with bad floppy media, and bad system memory.

 

[tom.storey]

I can read/write the floppy if I boot from XT-IDE into DOS with the memory expansion enabled and in use, no worries.

I can boot from a floppy if my memory expansion is simply disabled (i.e. card still present in the system).

But that same floppy that will boot without the memory expansion wont boot with the memory expansion. So bad media seems a bit out of the question by my reckoning? I did also try two disks - one that I formatted with the /s option, and the other which is the first DOS 5.0 installation disk.

Im not sure if the CPU has crashed, because the machine gunning will happen in bursts a couple of times before I think it then reboots (unless that is a feature of the floppy controller and not software running on the CPU). But Im not really game enough to try it again to find out if that was the case due to fears of damaging the drive (or at least I'd like to minimise this as much as practically possible), but Im fairly sure I recall it happening a few times over at least the first time.

 

[Eudimorphodon]

Attached is a copy of the schematic of the memory expansion. The data bus is buffered on to and off of the board via a 74HCT245 that is part of the prototype board that I have created. The direction of that buffer is controlled by the MEMR/ signal, and the tri-state outputs are controlled by the MEMEXP_DECODED/ signal. Most other signals used on the board are also buffered by some 74HCT245's whos direction and tri-state are completely static.

I have a couple questions/observations about this expansion board.

1. Why do you have an enable jumper for Bxxxx? There is actually no situation in which this entire block is safe to use; If you have MDA in the machine you shouldn't use the bottom half of it (MDA only has only 4K of RAM, but it's my recollection it's not entirely decoded), with CGA you shouldn't use the upper half (Only 16K starting at B8xxxx... BUT true CGA compatibles are also not completely decoded so that memory repeats at BCxxx), Hercules (can) use the the whole thing, and EGA/VGA cards also use this area for their CGA backwards compatible graphics modes and text mode. If your card had circuitry to cut this block in half to use only the bottom half when a CGA card is installed that could be useful, but that's about it.
2. Just out of curiosity, why do you have the DACK0 line connected to the 74LS138? I guess strictly speaking maybe it's fine that you're disabling RAM during DMA0 cycles since so far as I'm aware that should only be for RAM refresh, but so far as I'm aware there's also no *need* for you to do that? (Reading this explanation of how it works you would need to care about this signal if you were doing a DRAM-based RAM expansion, but a SRAM based one just isn't going to care; the worst possible case I could imagine is you might actually output a byte onto the bus based on the dummy read cycle if your SRAM was in the bottom 64K, but even that wouldn't really matter?) Anyway, yeah, this is the first time I've seen that on an XT RAM expansion using SRAM. (I was going to say I didn't implement that on my Tandy 1000 memory cards, but I suppose that's a non sequitur because my 1000s don't even have DMA controllers. But the very popular Lo-Tech 1MB-style cards don't watch that line either.)

I don't think either one of those observations has anything to do with the problem you're seeing, although I was kind of wondering about the DMA thing for a minute because you can get floppy problems if you have memory which is incorrectly disabled during DMA because the decoder in front of it is (incorrectly) tracking the AEN signal according to the same rules you'd apply to an I/O device. (This was a weird edge case that was discovered when using the memory mapper inside an RTL8019 network card normally meant to decode boot ROMs to drive a SRAM instead for a small upper memory block. With this limitation you can't load "dos data" high because DOS will place the floppy data buffer into RAM which will go to sleep during the FDC's DMA cycles.)

On a machine where you *haven't* loaded DOS data high I'd think the floppy DMA buffer would be in low memory (IE, RAM on the motherboard) unless the BIOS specifically temporarily locates it at the top of (conventional) memory during the initial program load? So I'd think even if there were some weird edge case DMA problem it wouldn't happen at boot time?

Is this only with DOS 5.0 specifically? IE, have you tried anything either older or newer? I have a vague memory that the original release of DOS 5.0 had a few XT-centric bugs in it, but I don't have anything specific to point to off the top of my head. (... wait, just peeked into that other linked thread, now I'm really confused.)

This "machine gun" noise: I know this is a really stupid suggestion, but it's not possible by any chance you somehow imaged an 80 track image onto a 40 track disk, is it?

 

[Svenska]

Can you boot off a Gotek (or a different drive)? Testing with one would at least prevent damage to disks or drives.

Are you sure that your board does not cause a bus conflict? If the floppy controller is too slow in taking data off the bus, your SRAM might drive into its outputs, causing all kinds of issues. Or maybe your board does respond when it shouldn't, and you normally don't notice because it overlaps the internal memory?

What happens if you remove the XT-IDE? Can you boot off the floppy then?

 

[tom.storey]

...

1. It's mainly because I had 128K left over in the RAM chip, and I just gave myself as many options as possible to allocate that to chunks of upper memory. Whether you can use them just depends on your configuration and maybe what you intend to do. BXXXX might not be possible to use ever, at least not as a 64K block, but if that's the case then ignore it because it'll never be used if you don't place a jumper to enable it, and perhaps I'll take it out if parts of it are always used by a video card of any type. You can only ever enable EXXXX as one block and AXXXX or BXXXX or DXXXX as the other. I use A and E in my machine because I only have an MDA card, and I'm keeping D free for the time being to play around with some option ROM development.

2. It just ensures that my memory expansion never decodes during a refresh, since I am using SRAM it doesn't need to know about any of that. The '138 is also qualified by either MEMR or MEMW being active (low), so it should never decode for an IO operation either. The decoding is specifically based on memory accesses to addresses from 40000-9FFFF and optionally any upper memory blocks you have enabled. Maybe this isn't strictly necessary, but I put it in there just to be sure.

I have a CF card with DOS 3.3 on it, and I was having some strange issues booting from a DOS 3.X bootable floppy at one point, which I'm sort of thinking may have been related to this issue. I can always fire up DOS 3.3 and make a bootable floppy and give it a try with and without my memory expansion. As I recall that floppy simply failed to boot, but it didn't cause the drive to go all machine gun, that seems to be a DOS 5.0 bootable floppy behaviour.

For the number of tracks, I was able to boot the floppy once I removed my memory expansion and successfully install DOS 5.0 off them, so I don't think so?

 

[tom.storey]

Can you boot off a Gotek (or a different drive)? Testing with one would at least prevent damage to disks or drives.

Are you sure that your board does not cause a bus conflict? If the floppy controller is too slow in taking data off the bus, your SRAM might drive into its outputs, causing all kinds of issues. Or maybe your board does respond when it shouldn't, and you normally don't notice because it overlaps the internal memory?

What happens if you remove the XT-IDE? Can you boot off the floppy then?

Unfortunately I don't have access to another drive nor do I have a Gotek. I'm a loner in my circle of friends and the only one into this kind of thing haha.

I've spent some time with my logic analyser looking at the decoding behaviour, and since it only responds to memory accesses by design, and this issue only happens at boot time (I can read/write floppys just fine once booted in to DOS whether my memory expansion is enabled or not) I don't believe that my card is conflicting with something else on the bus. I'd expect it to happen under DOS when trying to access the floppy as well if it were?

Removing the XT-IDE makes no difference, I can boot just fine off a floppy with the XT-IDE installed if I disable my memory expansion, even if I leave my board in the machine. I just have to disable my memory via it's disable jumper.

There's something very boot-time-specific that is happening.

 

[tom.storey]

Ugh and now I remember that for some reason I cant format floppys from my DOS 3.3 installation. It complains about track 0 being bad. That is with my memory expansion removed, too.

 

[Eudimorphodon]

For the number of tracks, I was able to boot the floppy once I removed my memory expansion and successfully install DOS 5.0 off them, so I don't think so?

Doh! Yeah, missed that part.

2. It just ensures that my memory expansion never decodes during a refresh, since I am using SRAM it doesn't need to know about any of that.

That’s the thing, though; I don’t think the page register is ever incremented by refresh cycles? The DMA controller in the PC only has 16 address lines, the other four are latched into a 74670 and need to be updated by the CPU to change which 64k block the DMA controller can access. I don’t think anything ever updates the page register during DMA cycles because it’s not necessary. (You only need to increment the RAS address for a refresh, that’s on the lowest address bits, and the motherboard circuitry activates RAS for all banks at once. Therefore just having the DMA controller spin on repeat through a single 64k block does the needful.) So… unless the page register for the DMA controller happens to be set to something besides zero any memory expansion card that decodes a RAM address higher than 0x10000 would never act on a refresh cycle because it’s out of range of your decode anyway.

And, as noted, I don’t think anything would care even if the dummy cycle produced a read output; nothing is listening anyway.

The '138 is also qualified by either MEMR or MEMW being active (low), so it should never decode for an IO operation either.

So… why? The RAM chip stays externally dormant even if CE is low if neither memory read/write is active. There’s no harm for the decoding to go active during I/O cycles.

Is all the logic on your board actually LS? This seems like a long shot to me but I am vaguely wondering if it’s possible your decode circuitry has enough steps you’re hitting some gray area in signal propagation times.

(I made a conceptually similar board to yours for my Tandy 1000EX; using a 512K SRAM to backfill 384k of low memory plus 128k of upper memory with jumper options for moving that upper block around. (The decode details were somewhat different because of unique oddities with the 1000’s memory map, but again, basically similar.) With my board I basically had two independent decodes, a really basic NAND gate system for the 384k block and a more elaborate system using a ‘138 that did double duty to decode an option ROM. It worked, but when I evaluated adding more logic to it to give it “higher resolution” decoding I started worrying about signal propagation, so… for the ‘ultimate’ version I learned how to program GALs and used one of those instead.)

 

[tom.storey]

So why?

The MEMEXP_DECODED/ signal goes towards enabling a data bus buffer on my prototyping board, not just CS for the RAM. So that ensures the decoder only reacts to memory accesses too, and thus prevents the buffer from potentially enabling when it shouldn't. There may be some eccentricities in my design while I learn all of this stuff.

There's no LS at all, it is a mixture of HC, HCT and the odd AHCT because that's all I have. The parts are only specified as LS because that's what I grabbed out of the KiCad library and I haven't bothered to change them for a prototype project.

But all of the signals interfacing with the system bus are buffered via HCT245s.

RAM cycle times are suuuuper long in the XT compared to other things I've worked with, and SRAM is asynchronous for address selection, so my gut feeling is that timing should be pretty relaxed in respect to the rising edges at the end of the cycle, especially given my RAMs are 55ns parts - definitely not so for DRAM though, there are generally quite strict timings for address setup and hold in respect to RAS and CAS.

I have plenty of GALs and have used them in various other projects, but sometimes it's nice to do something with pure logic gates.

 

[tom.storey]

Here's a couple of pictures of the prototype board (mostly) all made up. There's a lot more to it than the memory expansion like a little debug display that I can write to during software development (kind of like those POST analysers), an RTC, and another socket that takes a variety of ROM and RAM chips that I can use for option "ROM" development projects.

It may only be about as good as wire wrap for signal integrity, but it's doing the job other than this pesky issue.

 

[Svenska]

Unfortunately I don't have access to another drive nor do I have a Gotek. I'm a loner in my circle of friends and the only one into this kind of thing haha.

I highly recommend you to get a Gotek and put FlashFloppy on it. Doing so is well worth the effort, even if you otherwise prefer to avoid modern niceties. For a very long time, I ignored their existance, but it has been immensely helpful many times since.

I've spent some time with my logic analyser looking at the decoding behaviour, and since it only responds to memory accesses by design, and this issue only happens at boot time (I can read/write floppys just fine once booted in to DOS whether my memory expansion is enabled or not) I don't believe that my card is conflicting with something else on the bus.

Measure, don't guess. You have a lot of decoding circuitry - are you sure that all setup and hold time requirements are kept?

As an unrelated example: The TMS9918A video chip is designed around 16Kx1 DRAM chips. While it should be almost trivial to use a modern 32Kx8 SRAM instead, actual working circuitry requires careful insertion of delays (inverters) to stay within the timing envelope required by all parts. The designer of that solution did a quite nice write-up on the issue: https://cdn.hackaday.io/files/5789247676576/9918-SRAM.pdf.

I'd expect it to happen under DOS when trying to access the floppy as well if it were?

Maybe yes, maybe no. I have an AT clone with notoriously poor floppy performance during boot. Loading DOS is extremely slow, but as soon as the "Starting MS-DOS..." text appears, performance is suddenly perfectly normal. Minix 2.0.4 also suffers from the same performance issues (reading the four installation disks takes more than half an hour), while Minix 2.0.2 works fine.

While I do not understand the details, floppy disk transfers before DOS is loaded can behave very differently from floppy disk transfers while DOS is running.

Removing the XT-IDE makes no difference, I can boot just fine off a floppy with the XT-IDE installed if I disable my memory expansion, even if I leave my board in the machine. I just have to disable my memory via it's disable jumper.

In that case, the XT-IDE is at least very unlikely to be the problem.

 

[Eudimorphodon]

The MEMEXP_DECODED/ signal goes towards enabling a data bus buffer on my prototyping board, not just CS for the RAM. So that ensures the decoder only reacts to memory accesses too, and thus prevents the buffer from potentially enabling when it shouldn't. There may be some eccentricities in my design while I learn all of this stuff.

Typical way you would handle this would be to wire the direction signal on the buffer so unless MEMR is asserted the buffer points ‘in’ towards the RAM. Then it shouldn’t be clashing with anything else on the bus if CE comes on. Still don’t have to make CE contingent on it.

(If you have both IO and RAM devices behind a common buffer then of course you have to combine both MEMR and IOR.)

RAM cycle times are suuuuper long in the XT compared to other things I've worked with, and SRAM is asynchronous for address selection, so my gut feeling is that timing should be pretty relaxed in respect to the rising edges at the end of the cycle, especially given my RAMs are 55ns parts - definitely not so for DRAM though, there are generally quite strict timings for address setup and hold in respect to RAS and CAS.

I’d generally agree that those SRAMs seem to be pretty forgiving, and, yeah, if your XT is running at the regular 4.77mhz clock you should have tons of time (250ns-ish). Just pointing out that this additional complexity is there compared to some ”proven” designs like the lo-tech 1MB.

Maybe there isn’t anything logically “wrong” with the design, but it is complicated, and it is on a hand wired board. Are you sure it’s not just “flaky”/noisy? In my experience “disk errors” are very likely to be memory errors. Maybe it works “better” after booting from the XTIDE because the floppy buffers are hitting different memory. Do you have a memory test program you can use for an overnight soak?

I have plenty of GALs and have used them in various other projects, but sometimes it's nice to do something with pure logic gates.

For the final version of my Tandy 1000 card I had to fit three ‘4008 SRAMs, a flash chip, a DS1215 phantom clock chip, a 16552 dual UART, oscillators for both, a 44 pin laptop IDE connector plus support circuitry to turn it into an XT-CF, three 62 pin headers, a 7 position DIP switch, two 74LS670s, a couple ‘245 buffers, two RS232 level shifter chips, and two 9 pin serial connectors (everything through hole) into a 3.5 inch by six inch space along with the decode logic, so discrete gates were not an option.

 

[tom.storey]

Typical way you would handle this would be to wire the direction signal on the buffer so unless MEMR is asserted the buffer points ‘in’ towards the RAM. Then it shouldn’t be clashing with anything else on the bus if CE comes on. Still don’t have to make CE contingent on it.

(If you have both IO and RAM devices behind a common buffer then of course you have to combine both MEMR and IOR.)



I’d generally agree that those SRAMs seem to be pretty forgiving, and, yeah, if your XT is running at the regular 4.77mhz clock you should have tons of time (250ns-ish). Just pointing out that this additional complexity is there compared to some ”proven” designs like the lo-tech 1MB.

Maybe there isn’t anything logically “wrong” with the design, but it is complicated, and it is on a hand wired board. Are you sure it’s not just “flaky”/noisy? In my experience “disk errors” are very likely to be memory errors. Maybe it works “better” after booting from the XTIDE because the floppy buffers are hitting different memory. Do you have a memory test program you can use for an overnight soak?

That's pretty much every I've done, IOR and MEMR are ANDed to form the direction, and each decoder feeds into basically a big AND gate to form the OE for the data bus buffer. Devices like the debug displays and RTC are IO based while the memory is .. memory.

I suppose I can try getting rid of the whole tri-stating bit and leave the buffer constantly enabled, but I figured I could try and keep the board just a little quieter by disabling it when it wasn't in use.

As for testing I ran several passes over it with the memory test feature of CheckIt and it gave me no errors. I've also used it for the last week or two on a daily basis to play around writing some software using Quick BASIC (7.1) and Turbo C (during compilation it seems to consume most available memory so it should all be getting exercised in a much more random fashion than a probably very linear memory test). I've also installed an upper memory manager to move some stuff up into the AXXXX and EXXXX segments. Nothing is seeming to misbehave or crash so far except booting from floppys.

So flaky I think no? But I don't have any way to test the noise. I'd imagine it isn't great due simply to the method of construction, how much that effects the floppy drive I couldn't say as that's a bit beyond my skills and knowledge. A PCB with ground planes would certainly be much better, but I've got to prototype first before going down that potentially expensive route.

I have a 68k project planned that I'm hoping to build onto a 100x160 eurocard style PCB, specifically something that can plug into a VMEbus backplane that I have (but without all of the VMEbus complexity). That will have a couple of UARTS, a couple of MB of DRAM, and an Ethernet controller, all tied together with a CPLD running most of the show including DRAM refresh. Will be a fun project but it's going to be a tight fit I think, and in half expecting to need a 6 layer PCB.

But simulations for the CPLD logic (written in Verilog) look promising so far. If I can get that to work I'll get my port of FreeRTOS+TCP running on it.

 

[Eudimorphodon]

I suppose I can try getting rid of the whole tri-stating bit and leave the buffer constantly enabled, but I figured I could try and keep the board just a little quieter by disabling it when it wasn't in use.

It’s fine to tri-state the buffer when nothing behind it is enabled (IE, combining all the device selects behind it), but you’re also qualifying the decoder on one of memr/w being pulled, so… just seems kind of redundant, I guess?

ISA timing diagrams generally show that address bus state should be stable (and in the case of a write, data lines should have the desired data) before the command lines are pulled low. (And, fwiw, the lines should be stable briefly after the command line is deasserted.) If you let the CE decoder for the RAM chip follow the address independently of the control line you’re going to present the SRAM with a cycle that matches the ‘4008 datasheet’s model for a “WE controlled write cycle”. What you’re presenting it with this qualification is closer to the ‘CE controlled cycle’ but not exactly. It’s probably fine, but…

 

[tom.storey]

It’s fine to tri-state the buffer when nothing behind it is enabled (IE, combining all the device selects behind it), but you’re also qualifying the decoder on one of memr/w being pulled, so… just seems kind of redundant, I guess?

It is done to ensure that I have a guaranteed address on which to decode from. Maybe I bring too much 68k designer thought process with me since Ive done way more hardware design around the 68k before coming to the PC, but I do like the idea of having a stable address from which to decode peripherals (this is what AS/ would give you on a 68k, but the PC doesnt quite have an equivalent).

ALE doesnt quite cut it (the DMA controller doesnt toggle it for example, which would mean by boards cant participate in DMA transfers), and I am led to believe it is probably a bit buggy on the PC and XT anyway (by Sergey here: https://forum.vcfed.org/index.php?threads/ale-pin-b28-of-the-isa-bus.1241431/post-1296459).

And since the MEMEXP_DECODED/ signal also causes the buffer to be enabled, my thinking is that I don't want the buffer inadvertently enabling due to address bus transitions (as fleeting as they would be in reality).

So since ALE is out, the next best thing is to use MEMR/ and MEMW/. And hey, I cant be too wrong because even IBM themselves use this same basic "technique" to decode BXXXX for the memory on the MDA video card.

It was only a single wire to desolder, so I gave it a try, but it made no difference to booting from a floppy.

To change the behaviour of the tri-stating circuitry I will need more space for some more chips, so I'll probably need to look at building up a second board with just the memory expansion to test that on its own. My proto board is inspired by IBMs proto board, and they also disable the data bus buffer when nothing on the board is decoded, so Ive basically just followed their lead on that.

 

[tom.storey]

Measure, don't guess. You have a lot of decoding circuitry - are you sure that all setup and hold time requirements are kept?

I am measuring, hence Ive been digging around with my logic analyser looking at everything that I can think of with my current knowledge. But thats why Im asking for more ideas as to what to look at to try and figure out whats going on, I am far from an expert at PC hardware and its quirks, but Im also not a complete n00b at logic design.

Which setup and hold times specifically are you thinking about?

 

[tom.storey]

Ok, so heres probably the biggest smoking gun that I can find. I had an idea to probe both my own cards decoding logic, and the decoding logic of the floppy controller at the same time and it looks like both of them are being decoded at the same time. It looks like this is in relation to a DMA transfer. This happens right about the time that the drive is going into machine gun mode.

But while the floppy controller is doing an IO read, memory is being written to, so there shouldnt be a conflict on the data bus causing corruption at least.

I can also see an earlier DMA based transfer, but not to my memory expansion.

No idea if this is related or what though, I think this may just be normal DMA behaviour.

 

[tom.storey]

Ok yes, this is how DMA works between IO and memory. One outputs and the other inputs. I guess I need to adjust my thinking away from fully memory mapped to separate address spaces.

Only memory to memory will require two separate operations via the DMA controller.

Back to the drawing board I suppose.

 

[Eudimorphodon]

Ok, so heres probably the biggest smoking gun that I can find. I had an idea to probe both my own cards decoding logic, and the decoding logic of the floppy controller at the same time and it looks like both of them are being decoded at the same time. It looks like this is in relation to a DMA transfer. This happens right about the time that the drive is going into machine gun mode.

This seems like a pretty hot smoking gun that something about a DMA memory cycle vs. a CPU driven cycle is causing a problem. What that is is a good question. I have heard at least that DMA cycles as implemented in the PC can have tighter/less forgiving margins, which is why DMA transfers sometimes are problems for bad rotgut clones, but I don’t know any specifics there.

So since ALE is out, the next best thing is to use MEMR/ and MEMW/. And hey, I cant be too wrong because even IBM themselves use this same basic "technique" to decode BXXXX for the memory on the MDA video card.

I took a look at the schematics for the CGA card and, yes, you’re right that RAM decode is gated on MEMR/W. I guess for me the difference is that on that card that decode isn’t actually directly controlling the read/write cycles to the dynamic RAM, it’s a massive clocked state machine. In your design the decode delay is directly going to result in CE state lagging WE by “a while” on both assertion and de-assertion, and if you look on page #6 of the ‘4008 datasheet the graphs imply that with a “CE controlled write” (which is the mode you’re running in if WE is asserted first) WE should stay low *at least until CE goes high*. With your design CE lags WE, so it follows that there’s going to be a few nanoseconds here where CE lingers low *after* WE has already transitioned. Which is technically out of spec for that access mode?

Again, my gut feeling is that these chips are forgiving enough for this, but if you let CE just follow an unqualified address decoder you’re going to get the ”WE controlled write” waveform exactly.

(As for worrying if you’re going to trash the bus by asserting CE on the buffer while addresses might still be in flux, well, you could still separately qualify it on the read signals as well as collective chip select, going full belt plus suspenders, but remember, ISA doesn’t apply the read/write controls until after the address bus should be stable; check the timing diagrams. So if your buffer direction defaults to “incoming” then worst case you’ll load the data bus *on your card* for a few nanoseconds during decode. No harm no foul.)