Getting a DTK Peer-2030 computer running

[modem7]

Here are CONFIG.SYS and AUTOEXEC.BAT.

To rule these out, simply rename them, then reboot. If the problem disappears, then you start investigating the contents.

I'm using DOS 6.22 and it was working fine until 3 or 4 days ago, whichever day that was.

And that was the day that you added the extra RAM sticks ?

You are back down to two sticks. Are those sticks the original ones? I assume so based on an earlier post, but just making sure.

I expect that Checkit's memory tester is basic. But in the CheckIt log file is '(QUICK TEST ONLY)'. You really need to be doing a thorough test. And a dedicated tool is expected to be better. Perhaps an early version of MemTest86. See 'Older Versions' at [here].

You wrote, "It did report parity error in memory .." but when I look in the CheckIt log file, I see nothing reported there.

This is the question. Is this a RAM subsystem problem, or is this something else making it look like a RAM subsystem problem? A thorough test of the RAM subsystem will give you confidence as to which.

I ran the virus checker in CheckIt 3.0 and it found nothing. If there are other virus checkers to recommend, please do.

Maybe F-PROT. See [here].

If we investigate the line that this is floppy related, then simple random read testing (you skipped random write testing) is not enough. Yes, the controller chip on the controller card may be reading a sector, and successfully comparing the CRC of the sector contents to the stored CRC, but that is only part of the story. The problem could be after that.

Perhaps the use of CRC.EXE from [here].
Example:
1. On your C: drive, create a directory named 360K
2. Into that directory, copy in say 320K worth of files (and have many files rather than one large file).
3. Change to that directory, then execute the command CRC *.* F (that will create a file named CRCKLIST.CRC, containing the CRC of the files in the directory)
4. Execute the command CRC
5. Verify that CRC.EXE finds that for every file, the calculated CRC matches what is recorded for the file in CRCKLIST.CRC

Now the floppy test.

6. Copy all of the files (including CRCKLIST.CRC) in the 360K directory to a blank 360K floppy.
7. Change to the floppy.
8. Execute the command CRC
9. Verify that CRC.EXE finds that for every file, the calculated CRC matches what is recorded for the file in CRCKLIST.CRC

 

[Bill-kun]

To rule these out, simply rename them, then reboot. If the problem disappears, then you start investigating the contents.

Renaming them to dummy names made the difference of SETUP.EXE hanging up a couple steps earlier than without renaming them.

And that was the day that you added the extra RAM sticks ?

No, it was 4 days after I got the 2 additional RAM sticks working, and was trying to get the CD-ROM drive working. I may have slightly bumped the RAM stick in the rightmost slot with my fingers, since it is within about 5 millimeters of the SB16 card, but that's all I can think of that would have contributed.

You are back down to two sticks. Are those sticks the original ones? I assume so based on an earlier post, but just making sure.

Yes, they are the original ones.

I expect that Checkit's memory tester is basic. But in the CheckIt log file is '(QUICK TEST ONLY)'. You really need to be doing a thorough test. And a dedicated tool is expected to be better. Perhaps an early version of MemTest86. See 'Older Versions' at [here].

You wrote, "It did report parity error in memory .." but when I look in the CheckIt log file, I see nothing reported there.

I thought it did. Maybe I'm thinking of when I tried to run it from floppy; I know it did then, before the program even got started: "Parity error but segment not found, Press any key to continue !". The log file came from me running it from the D-drive CF card.

Running the read and write tests in CheckIt on both floppy drives results in the A-drive working fine and the B-drive working fine.

For MemTest86, I don't see anything that will run on a DOS 386. The closest thing I see is "V4 Windows Downloads: Image for creating bootable Floppy Drive." I opened the image file and it looks like the filenames inside are indicating Linux. If you have an exact link in mind, please specify.

This is the question. Is this a RAM subsystem problem, or is this something else making it look like a RAM subsystem problem? A thorough test of the RAM subsystem will give you confidence as to which.


Maybe F-PROT. See [here].

The forums posts in that thread seem to have now-dead links for F-PROT. Please check, since I'm not 100% sure I was clicking on what you intended me to click on.

If we investigate the line that this is floppy related, then simple random read testing (you skipped random write testing) is not enough. Yes, the controller chip on the controller card may be reading a sector, and successfully comparing the CRC of the sector contents to the stored CRC, but that is only part of the story. The problem could be after that.

Perhaps the use of CRC.EXE from [here].
Example:
1. On your C: drive, create a directory named 360K
2. Into that directory, copy in say 320K worth of files (and have many files rather than one large file).
3. Change to that directory, then execute the command CRC *.* F (that will create a file named CRCKLIST.CRC, containing the CRC of the files in the directory)
4. Execute the command CRC
5. Verify that CRC.EXE finds that for every file, the calculated CRC matches what is recorded for the file in CRCKLIST.CRC

I tested 43 files. All 43 matched.

Now the floppy test.

6. Copy all of the files (including CRCKLIST.CRC) in the 360K directory to a blank 360K floppy.
7. Change to the floppy.
8. Execute the command CRC
9. Verify that CRC.EXE finds that for every file, the calculated CRC matches what is recorded for the file in CRCKLIST.CRC

While using XCOPY to copy the files to the floppy, the screen momentarily went blank, then came back. The A-drive head kept moving back and forth on the disk, stuck on that one file (MT32.DRV, for future reference). Eventually, the screen text went from white-gray to yellow with a brown border, and the floppy drive head stopped moving, and the text went no further.

(While I was doing an unrelated copy of some files (DISK2IMG program) to the B-drive a half hour earlier, a similar phenomenon happened, except that the video signal never came back. I checked the monitor connection on both ends. The floppy head continued as if it was writing the files as normal. After it stopped, I chose to reboot.)

After Ctrl-Alt-Del, DIR A: showed all the files listed with the correct number of bytes. Running CRC.EXE resulted in a few files matching, then it gave "Parity error but segment not found, Press any key to continue !". I pressed keys, and got the attached screens.

 

[modem7]

For MemTest86, I don't see anything that will run on a DOS 386. The closest thing I see is "V4 Windows Downloads: Image for creating bootable Floppy Drive." I opened the image file and it looks like the filenames inside are indicating Linux. If you have an exact link in mind, please specify.

Yes, the "Older Versions" section that I referred to are the old V4 versions, primarily because your computer won't have UEFI support.

The Linux is a red herring. They are bootable images. You write the image to the applicable media, then boot from that media. (The concept is that the diagnostic code doesn't have DOS, etc. sitting in the background, causing potential interference.)

The forums posts in that thread seem to have now-dead links for F-PROT. Please check, since I'm not 100% sure I was clicking on what you intended me to click on.

Try [here] instead.

"free to use for non-commercial purposes."

While using XCOPY to copy ........................................

It really does suggest a problem in the floppy subsystem.
Would a virus target all floppy drive operations, but not hard drive operations? I don't know.

Re the CRC.EXE experiment. Does that work if you take the hardware back to basics: video card, floppy controller. And boot from the 360K floppy.

 

[Bill-kun]

The exact model of the SB16 that I have in this unit is CT2230.

No, it was 4 days after I got the 2 additional RAM sticks working, and was trying to get the CD-ROM drive working.

I apologize to the community. I should have known better by now.

Reflecting on the above, plus the effect on something as unrelated to ordinary RAM as the video signal, I realized the addition of the CD-ROM drive is when the problem started. When I said in post 47 that the SB16 is set to base I/O 220h, MPU at 300h, and IRQ 5, DMA 1,5, I was referring to AUTOEXEC.BAT. I neglected to check the jumpers on the SB16 card and make sure the jumpers matched the command line. I neglected to check all the SB16 jumpers for things that affected the CD-ROM.

Here is a link to the jumper configuration guide for the CT2230 at stason.org.

Here are what my CT2230 jumpers have been set for:

• MPUEN closed (MPU-401 enabled)
• MSEL closed (sets MPU-401 at DMA 300 if open, 330 if closed)
• IOS0 closed, IOS1 closed (sets base I/O to DMA 220)
• CD-ROM brand: Mitsumi
• Mitsumi CD IRQ: open open open (meaning no defined IRQ?)

Problems identified:

1. The CD-ROM has never been assigned an IRQ by the SB16 jumper.
2. There has been a conflict for the SB16 base I/O between the jumpers setting it at 320, and AUTOEXEC.BAT setting at 220.
3. There has been a conflict for the CD-ROM DMA between the SB16 line in CONFIG.SYS setting it to 330, and the Mitsumi DEVICE line in CONFIG.SYS setting it to 320.
4. There has been a conflict at DMA 320 between the SB16 base I/O jumper setting, and the Mitsumi DEVICE line setting in CONFIG.SYS.

That was quite the knot that I tied my computer into.

Solutions I am going to execute:

1. Set CD-ROM IRQ to 11 on jumpers. Take a photograph of the SB16 clearly showing all jumpers. Reinsert the SB16, connect the CD-ROM drive, and boot up.
2. Delete the relevant lines in CONFIG.SYS and AUTOEXEC.BAT entirely. Reboot.
3. Rerun the SB16 installation and match the jumpers for whatever it asks about.
4. Rerun the Mitsumi SETUP.EXE and match the jumpers for whatever it asks about.

 

[Bill-kun]

Okay, I found out that it also was not nearly entirely my fault.

Further major things that caused my problems:

1. I can find no setting by jumper or by software to set the CD-ROM DMA on a Sound Blaster 16.
2. Thanks only to this thread at vogons.org, I learned that the SB16 automatically sets the CD-ROM DMA equal to the base I/O address+10. For example, if I set my SB16 base I/O to 220h, the CD-ROM will automatically be at 230h. I looked through three SB16 manuals (1994, 1995, 1997) and did not find that stated anywhere in them.
3. The only 4 base I/O addresses the SB16 can be set to by jumpers are 220, 240, 260, and 280. The only addresses the Mitsumi SETUP.EXE allows you to choose from are 300, 310, 340, 360, and 390. Therefore, even if you do know that (CD-ROM DMA)=(base DMA)+10, you can't even properly set the CD-ROM DMA address at all if you only go by the settings the hardware and software allow!

However, simply editing CONFIG.SYS, I was able to move the CD-ROM to 220+10=230. I rebooted, and the CD-ROM drive is finally recognized!



Boy, this is one for the books!

The IDE 40-pin extension cables also arrived today. So after I add one so I can mount the CF card bracket on an expansion card window, and put the 2 new memory sticks back in, the only thing left on my list is for me to put in an internal modem card. More later.

 

[modem7]

I apologize to the community. I should have known better by now.

I'm sorry; it's not enough. VCFed policy is quite clear on the matter. You must now perform hara-kiri (seppuku).

 

[Bill-kun]

Ah, a word I was first introduced to in 1996 by Ranma 1/2.


Docking the CD-ROM drive was one of those "Oh no, I don't have any drive rails that will work for this case" aggravations, despite my inventory of over 50 drive rails. Seriously, drive rails should have been way more standardized. Well, I docked in it the bottom of the 3 bays, had to support it from the bottom with a stack of cardboard box slices, went to the hardware store to get screws of the same thread but longer length, added small washers, and finagled the case back on, and off, and on, and off, and on, and off, and on, until everything fit together.

I was so overjoyed to finally put the cover on this computer case for the first time in over 2 years, that I almost forgot about the Mitsubishi CD audio cord. I ordered 4 on eBay, since like the IDE extension cables for the CF adaptor, I will be using them on other computers I will work on in the coming weeks. Then I will have to rewire one of them to fit the Mitsubishi CD-ROM drive and tape a paper tag to the wire explaining that it is re-mapped, and why. (You should always leave notes to your future self.)

 

[Bill-kun]

Somehow the memory just started working properly. I love it and hate it when that happens.

I added the internal modem card.

According to this article for the LU005S from July 24, 2021, it looks like I need the driver file MTMCDE.SYS which it links to.

Also according to that article, the Mitsumi CD audio cords were standard shape, but non-standard pin order (even among their own models), and using a cord with pins not ordered properly for it can destroy the CD-ROM drive. Well, that means I'll have to get a CD audio cord, check continuity to verify pin position, and probably rewire it.

The last thing I then had to do was add a wire set to properly remap the CD audio from the SB16 to the Mitsumi LU005S CD-ROM drive. Thanks to a particular wire with the right connector that I found in my inventory, I was able to sit down and draw a schematic to remap the wires using only loose bare-ended wires from a Radio Shack project kit (blue, green, and yellow to avoid confusion with any of the already existing colors). Here is the diagram I made. Once I made that schematic, it was easy to put the right bare ends into the pin receptacles. I verified continuity of each of the 4 "lanes" so that they were remapped exactly as I expected. I plugged it in, booted up and tested it with an audio CD, and it works!

The rectangular "Remapping" box is just an imaginary box; it is not a wire that connects to any of the colored wires at the nodes. It should be a dotted line defining a boundary, not a solid line. Sorry for the confusion on that; it made total sense to me, though, when I drew it.


I put a lot of labels made with painter's tape on the wires to keep it clear to my future self and anyone else. Sorry the photographs of it didn't turn out too well. I'm also going to put the schematic and a miniature printout of that webpage in the computer case, and maybe one or more pages of this thread.

 

[thecheese2022]

Could you dump the bios?