Image Map Image Map
Page 1 of 3 123 LastLast
Results 1 to 10 of 22

Thread: Turbo XT that suffers filesystem corruption when in 'turbo' mode (only)

  1. #1
    Join Date
    Sep 2020
    Location
    Wellington, New Zealand
    Posts
    31

    Default Turbo XT that suffers filesystem corruption when in 'turbo' mode (only)

    So this is a real head-scratcher...

    I recently acquired a Logicraft 88-XT machine, which is a generic Turbo XT system with 640K of RAM and an NEC V20 processor (in a socket labelled "8088-2") that runs at either 4.77Mhz or 8Mhz. I can't find schematics or a manual for this machine, but the turbo switch appears to select between a 14.318180Mhz crystal and a 24.0Mhz crystal. [Not an XCO.]

    I dropped in a known-good ST11R controller paired with a known-good ST-238R drive, did a brand new low-level format, installed MS-DOS 3.30, and everything was going fine until at some point I edited C:\CONFIG.SYS while in turbo mode. No errors or anything until after rebooting, when the system just failed to boot from the hard drive at all. CHKDSK from a MS-DOS 3.30 boot floppy spewed forth hundreds of errors, entire allocation chains were lost and IO.SYS / MSDOS.SYS were truncated, filenames were randomly corrupted, etc.

    Twice more I formatted and reinstalled DOS. Both times everything was working perfectly, with lots of disk reading and writing and copying of files, until I would absentmindedly reboot and forget to switch out of turbo mode (the default). At which point the root directory and the FAT would get corrupted again.

    Occasionally, even just reading from the disk in turbo mode would return incorrect data. Confirmed through the use of MD5SUM.EXE -- in normal mode the checksum was always correct, but in turbo mode the checksum was always wrong -- and each run through MD5SUM would return a different (but still incorrect) checksum. I created a RAM disk (RAMDRIVE.SYS) and confirmed that even in turbo mode, file checksums from the RAM disk were correct.

    Finally, and most perplexingly... Norton Disk Doctor 4.5 and SpeedStor 6.03 are both returning perfect results... even in turbo mode! I am about an hour into torturing the disk with Spinrite II's most aggressive pattern test, again in turbo mode, and again without observing even a single error yet.

    Any suggestions on what to try next?

    Is it possible there is some marginal RAM located exactly where DOS puts its disk buffers? [But if there is bad RAM, the RAM disk test ought to have failed as well, right?]

    Perhaps Disk Doctor and friends are bypassing the BIOS routines and submitting commands directly to the ST11R controller? And therefore could it be some mysterious timing-related bug in MS-DOS 3.30 or in the BIOS?

  2. #2
    Join Date
    Aug 2006
    Location
    Chicagoland, Illinois, USA
    Posts
    6,828
    Blog Entries
    1

    Default

    More testing is needed. For example, you're seeing this corruption when updating the hard drive; do you see it updating the floppy drive too? If so, I'd say you have RAM that isn't fast enough to work properly at the turbo speed. I'd also run a RAM test at both slow and fast speeds.
    Offering a bounty for:
    - A working Sanyo MBC-775 or Logabax 1600
    - Music Construction Set, IBM Music Feature edition (has red sticker on front stating IBM Music Feature)

  3. #3
    Join Date
    May 2011
    Location
    Outer Mongolia
    Posts
    2,966

    Default

    This simple disk performance test also has a "mediatest" function that I've found useful; it's a reliable tell for CF cards that have compatibility issues with my XTIDE/XT CF adapaters. It might be worth trying it, since it'll operate entirely through the DOS/BIOS interface. See if it reliably fouls the drive at turbo speeds but doesn't at standard?

    Turbo XTs are all over the map with regard to how cleanly they implement their higher clock speed, and XT hard disk controllers like the ST11R rely on DMA, which makes them pretty much the worst case scenario for causing problems if anything's at all sketchy.
    My Retro-computing YouTube Channel (updates... eventually?): Paleozoic PCs

  4. #4
    Join Date
    May 2018
    Location
    Lancashire
    Posts
    665
    Blog Entries
    18

    Default

    Controller cant take the higher bus speed, surely ?
    Current fleet
    TRS80 Model 4 - BBC B - Tatung Einstein - PCW9512 - PET 3032 - C64 - ZX81 - Spectrum 48K - Amiga A500 - VAX 3100,3300,4000VLC & 4000 Model 96 - Apple II europlus - Apple iMAC G3. Sharp MZ-80K. - DEC Micro PDP 11/73 - IBM 5160 XT - Multibus 286/10 - AlphaServer DS10 - AlphaStation 225 - MicroVax II.

  5. #5
    Join Date
    May 2011
    Location
    Outer Mongolia
    Posts
    2,966

    Default

    Quote Originally Posted by Gary C View Post
    Controller cant take the higher bus speed, surely ?
    There's a manual for the ST11R on Bitsavers that says what the minimal requirements are for bus pulse timings, you could probably do some math to try to work out if 8mhz is still within range. But there still might be devils in the details, like duty cycle, with regards to exactly how the particular clone implements the higher speed. There was a thread recently about how turbo XTs were sometimes "sloppy" about ensuring other peripherals were clocked correctly when turbo was engaged, it totally could be some kind of hardware or BIOS bug with DMA that only crops up in fast mode.

    Might be safer to just toss an XTIDE or XT-CF card into this one?
    My Retro-computing YouTube Channel (updates... eventually?): Paleozoic PCs

  6. #6
    Join Date
    Sep 2020
    Location
    Wellington, New Zealand
    Posts
    31

    Default

    Quote Originally Posted by Eudimorphodon View Post
    This simple disk performance test also has a "mediatest" function that I've found useful; it's a reliable tell for CF cards that have compatibility issues with my XTIDE/XT CF adapaters. It might be worth trying it, since it'll operate entirely through the DOS/BIOS interface. See if it reliably fouls the drive at turbo speeds but doesn't at standard?

    Turbo XTs are all over the map with regard to how cleanly they implement their higher clock speed, and XT hard disk controllers like the ST11R rely on DMA, which makes them pretty much the worst case scenario for causing problems if anything's at all sketchy.
    Excellent, that DISKTEST program you linked to looks like just the ticket.

    I think your suggestion that it's a DMA issue is a good hunch, and something I will investigate further. I get the feeling that advanced low-level tools like SpeedStor and SpinRite are bypassing much of the 'normal' DOS/BIOS interface.

    Also thanks to everyone else for the suggestions so far! What's a good RAM testing program for an XT class machine? It only has the standard 640KB (plus 32KB at B000 for the monochrome display adapter) and want something which is able to relocate itself so that it can test each and every address... especially critical to check the first ~16KB where DOS holds all of its buffers and pointers and other control information.

  7. #7
    Join Date
    May 2011
    Location
    Outer Mongolia
    Posts
    2,966

    Default

    Check-it 3.0 does a pretty comprehensive test (if you specifically select the extended test, the quick version probably isn't particularly definitive), and some of its other diagnostics might possibly come in handy.
    My Retro-computing YouTube Channel (updates... eventually?): Paleozoic PCs

  8. #8
    Join Date
    Sep 2020
    Location
    Wellington, New Zealand
    Posts
    31

    Default

    I've done further testing, and here's where I am at:

    (1) I ran CheckIt 2.1 (which fits on a 360K floppy) in turbo mode and all system tests (including RAM pattern tests) passed.
    (2) DISKTEST.EXE is able to trigger the data corruption issue in turbo mode, even when reading/writing to a floppy disk.
    (3) Pulled all cards from the system and ran with nothing except a known-good Hercules clone and a known-good floppy controller, and DISKTEST is still failing when in turbo mode.

    It's still very strange that Norton Disk Doctor, SpeedStor, and SpinRite all passed with flying colours even in turbo mode.

    So it must be something to do with the DMA controller or the ISA bus interface logic, yeah?

    I measured the CLK input to the NEC D8237AC-5 DMA controller chip on the motherboard using my el cheapo multimeter's frequency counter. In normal mode it measures a 4.771Mhz CLK input with a 54% duty cycle; in turbo mode it measures a 3.999Mhz CLK input with a 21% duty cycle. The datasheet specifies a minimum CLK period of 200ns (=5.00Mhz) with a minimum CLK high of 80ns and a minimum CLK low of 68ns. If the turbo mode clock input to the DMA controller really has a 21% duty cycle, the clock pulse might be as narrow as ~62.5ns... but do I trust my multimeter's measurement? [Alas I don't have access to any better test equipment and this is already way out of my depth!]

    I've been working from the assumption that this machine must have worked just fine in turbo mode at some point in the past. Is that a valid assumption to make here? I'm aware that some turbo XT systems would drop out of turbo mode during the BIOS disk access routines. Perhaps this machine used to do that, and something has changed to cause the BIOS to no longer switch out of turbo automatically?

    I guess my next step is to try and write a minimal test case that demonstrates the problem and go from there.... as always, thanks for the suggestions so far!

  9. #9
    Join Date
    Sep 2020
    Location
    Wellington, New Zealand
    Posts
    31

    Default

    Also, I haven't been able to find much at all about this machine online. Perhaps some photos will help someone to recognize it?

    IIMG_20200926_155316.jpg
    IIMG_20200926_155336_1.jpg
    IIMG_20200926_155353.jpg

    The motherboard says "LOGI PC88XT" (obscured by the ISA cards).

    Unfortunately the hard drive in the machine refuses to spin up when power is applied, i.e. totally dead, so no chance of finding useful drivers or information via that avenue...

  10. #10

    Default

    Thank you very much for the link to DISKTEST !
    My breadboard 8088 computer tends to corrupt its filesystem a lot, that program will definitely help me debug the issue.

Bookmarks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •