Recent content by Krille

Yes, I had a brain fart. The Lite mode vs Full operating mode option is available on all the XT-builds of XUB, not just the Tiny build (XT-build meaning a binary built without the USE_AT define). ...or in a UMB, but that's probably not possible on an AT machine.

Rodney, did you configure XUB to use EMS? If so, that would probably be the reason.

Sounds like a hardware problem to me (faulty RAM would be my guess). Newer versions of XTIDECFG should work but you need to fix the hardware first. Try running Checkit or similar on the machine to identify the problem.

I could be wrong but I think the OS is supposed to handle any retry attempts. AFAIK, there is no* retry logic in any version of XUB for reads or writes, nor have I ever, in my adventures with IDA, seen any other hard disk BIOS with code implementing any kind of retry logic for reads or writes...

I don't think I have ever heard about this particular problem before. Tell us more about the "startup pain". The first thing to do is to re-check the soldering, the second thing is to check for marginal components. The third thing to do is to try the latest version of the BIOS. Even if it's...

I expect it to round to the closest tenth of a kilobyte since that's how it's presented. Let me show you an example from one of the text files I posted above; Cache size: 0 KB, 64 KB read in 9020 ms, 7.0 KB/sec Cache size: 1 KB, 96 KB read in 6930 ms, 13.0 KB/sec Cache size...

Since I mentioned rounding it should've been obvious that I was talking about the presentation of the results (in KB/sec), not the actual measurements. I'm sure it's a simple mistake so there's no need to get defensive about it.

The downside of the read-ahead cache, at least in its current form, is that it requires a lot of memory. Presumably very few people will connect to a server outside of their own home network so the performance is going to be acceptable as-is without read-ahead caching. For most people the speed...

OK, so I'm officially an idiot. The two versions I've released so far both have serious bugs in them. The first didn't support multiple drives due to the -D:xx parameter not being recognized because of a very simple last minute change that I didn't actually test (because it was, after all, a...

Are you sure RAM actually exists at the memory range given to USE!UMBS.SYS? A relatively simple way to test is to use DEBUG to try changing a value in RAM.

^This! Networking in general tends to require a lot of memory, even if it's not usually as bad as the above mentioned NFS driver. Keep in mind that XUB can be configured to use an UMB as its working space. Though, to be fair, I've not seen anyone actually use that feature yet. :)

You're using the original 2.0 version of USE!UMBS.SYS which doesn't support command line parameters. Use the latest version (2.2) instead.

ADP50(L) controllers? Absolutely not rubbish. Not at all. You can use them with XUB and they are the best performing IDE controllers you can have with an 8088 CPU.

Yeah, that would be my guess as well.

The simplest way is to start with zero and then, from that, subtract the value of every byte in the ROM except one (usually the last byte but it doesn't have to be). The value you now have is the checksum and that should be stored in the byte position you didn't subtract. Another, slightly more...