wierd_w wrote on 2024-07-14, 02:41:

Any ideas why they treat the HMA / Upper Memory Area that way?

Just to got the terms cleared up. We are not talking about the memory range usually called "HMA", which is the first 65520 bytes past the 1MB "limit". The HMA is part of the "extended memory" (everything past the 1MB limit). Upper Memory Area or Adapter Area (adapter's segment) is the technically correct term for the 384K in the 1MB address space that is reversed for "not main memory". Anecdote: See footnote 1. The Adaptec 1542CF treats the HMA the same way as any other extended memory, and uses 16-bit cycles.

Jo22 wrote on 2024-07-14, 03:08:

Not sure about SCSI. Did SCSI host controllers perform any buffering etc? SCSI datawith via popular 50 pin connector was 8-Bit anyway, at least.

Yes, every SCSI host adapter that supports synchronous SCSI needs to have some kind of buffer. At least in hindsight, the name "synchronous" SCSI is kind of confusing. I think "pipelined" would have been better than "synchronous". The whole point of synchronous SCSI is that one party can rely on the other party to be able to buffer some bytes that get sent at a fixed frequency negotiated beforehand (that's how the name "synchronous" came to be). Instead of acknowledging each byte as it gets received via the SCSI bus, synchronous SCSI uses the acknowledge signal to notify when a byte has been drained from the buffer. The sending device can then count how many bytes in the buffer are currently free. Typical buffer/window sizes for synchronous SCSI are 8 or 16 bytes (narrow) or 8 or 16 16-bit words (wide).

To find a SCSI controller without any kind of buffering, you would need to go to something as basic as an NCR 53c80 chip. Event the "successor" of that chip, the NCR53c400 which uses the same core logic (but adds extra stuff to it to integrate a nice ISA interface) adds a buffer that can be accessed using 16 bit I/O. The Adaptec 6260/6360/6370 family (used on the 1520/1522 variants) is similar in capabilities to the NCR53c400.

jakethompson1 wrote on 2024-07-14, 02:49:

is the "C" a cost-reduced design and they made an oversimplification when cost-reducing?

jakethompson1 wrote on 2024-07-14, 02:47:

As to why physical UMB addresses were hardwired as 8-bit, I don't know. If the system were set up so that some 8-bit memory cards erroneously had MEMCS16# asserted anyway, wouldn't the user have already encountered that issue during boot, long before the SCSI card gets into the picture?

Likely yes. I currently don't know whether MEMCS16# is decoded by the 1542CF at all, or they just use the "UMA = 8-bit" heuristic as replacement for it. And to be fair, I have to admit that I don't actually know what the special control bit in the busmaster DMA engine does. I only know it is set for the UMA, and it is like the cause for the flawed interaction with the TopCat hardware EMS.

Probably it is actually fine (according to the spec) for a 16-bit card to not support 8-bit writes to odd bytes through the low 8 bits because of the byte steering (aka byte swapping) logic that is supposed to be on the main board. 8-bit DMA to 16-bit memory will break without byte steering/swapping support, as the 8-bit DMA channels will just ignore MEMCS16# (and I expect 16 bit DMA channels to ignore MEMCS16# as well, and just expect the availability of 16-bit DMA).

Referring to that "Intel ISA specification" document again (there just was a discussion about the it in another thread), it confirms that 16-bit DMA to an 8-bit resource is "illegal" (see table 6.4.2) and it also explicitly says so in chapter 5.2: ("DMA channels 5-7 only support 16-bit I/O resources", "the use of 8-bit memory resource with a 16-bit I/O resource is not allowed."). Furthermore, the byte swapper (which is part of the "platform" aka mainboard) should kick in when the "bus owner" (the processor or a bus master) issues an 8-bit cycle to an 8-bit address (see table 6.4.1). This is confirmed to apply to busmaster cycles in chapter 5.3, sub-chapter "bus-owner mode": "NOTE: If the add-on card begins an access as 16-bit in size, and MEMCS16# or IOCS16# is not enabled, then the cycle is completed as 8-bits. The platform byte swapper will port the 8-bit byte between D<15..08> and D<07..00> as determined by SBHE# and A0". Furthermore, that documents seems to warn against running 8-bit cycles in the same note, although according to the spec, they should work: "If the add-on card begins an access as 8-bit in size, then the platform must support the appropriate byte swapping. Traditionally not all platforms have supported 8-bit add-on cards as bus owners.". Maybe the later sentence just refers to MASTER# only being available on the 16-bit extension part, but maybe it also implies that there are platforms that can't handle 8-bit bus-master cycles correctly. So a mainboard with hardware EMS that does not support 8-bit busmaster DMA into it is non-compliant.

Footnote 1: German MS-DOS translated "high memory area" as "oberer Speicherbereich", and "upper memory area" as "hoher Speicherbereich", which is exactly opposite to the English terms. According to German Wikipedia, MS reversed this decision in Windows 9x.

I was wondering why you mentioned the HMA, when it seemed you were talking about UMA. 😜

I usually call it "The Adapter Rom Region". The 384k above the 640k base memory that normally is left unmapped, and or, is populated by things like the System ROM, and any video or disk controller roms present.

Sphere478 wrote on 2024-07-14, 05:36:

So there is an issue with my TI SXL2 66 on my 386 motherboard with clock doubling. Locks the system whenever I enable it. Apparently it is said that it has to do with the dma of the aha 1542 Scsi controller I am using.

I don't understand how the busmaster DMA by the 1542 is affected by the processor doubling the clock internally. The bus interface is supposed to stay the same way whether clock doubling is enabled or disabled. The whole busmaster DMA stuff is supposed to happen on the mainboard only (exception: L1 cache coherency), so the core clock is supposed to be irrelevant. Due to the L1 cache coherency involved in this: Can you try whether disabling the L1 cache will solve the issue? Of course, you do not want to permanently run a SXL2 system wth L1 disabled, this is just for testing whether L1 might be involved somehow.

Yeah, like I said, I don’t understand it but apparently it’s a known issue. If you follow the interposer thread, I might dig the machine out and play with it before too long.

mkarcher wrote on 2024-07-14, 10:45:

Footnote 1: German MS-DOS translated "high memory area" as "oberer Speicherbereich", and "upper memory area" as "hoher Speicherbereich", which is exactly opposite to the English terms. According to German Wikipedia, MS reversed this decision in Windows 9x.

Even in English it was always confusing as "loading DOS high" meant the HMA, while loadhigh and devicehigh actually meant UMBs.

By the way, I read that the LHA archiver almost got named LH until they heard about the command in the then-upcoming MS-DOS 5.0.

mkarcher wrote on 2024-07-14, 10:45:

Footnote 1: German MS-DOS translated "high memory area" as "oberer Speicherbereich", and "upper memory area" as "hoher Speicherbereich", which is exactly opposite to the English terms. According to German Wikipedia, MS reversed this decision in Windows 9x.

I second this.

I think it's because the German term had been coined early, in a time before the HMA had been in use by MS-DOS itself.

So when HMA was being used, the literal translation into German was already being taken.

There's an possible explanation being mentioned here (German, with screenshots):
https://www.dosforum.de/viewtopic.php?f=12&t=11677

Novell DOS 7 did call HMA the "Unterer Zusatzspeicher" (translates to lower extra memory, lower extended memory etc).

Edit: German MS-DOS 7 adapted the English terminology.

jakethompson1 wrote on 2024-07-14, 02:49:

Is it possible this is a mistaken compatibility fix for the reverse issue with the "B" version, or is the "C" a cost-reduced design and they made an oversimplification when cost-reducing?

Yes I believe so, as my original issue was the 'B' revision forcing 16-bit transfers to the D segment of UMA and my EMS card was 8-bit only