• Please review our updated Terms and Rules here

PCjr and disk errors?

erikarn

Experienced Member
Joined
Dec 14, 2020
Messages
65
Location
Oakland, California
hi! I'm trying out some turbo C 2.0 programs I've written on my PCjr (running them there, not compiling them there.) However, under MS-DOS and PC-DOS 3.3, i hit a disk read failure w/ ABF, but any key I press just gives the "i'm doing disk IO, no keyboard input here!" beep. not even a ctrl-alt-delete works.

has anyone seen this before? should I just stick with pc-dos 2.x? or is this something that can happen when it runs out of RAM or runs on a PCjr?

Thanks!


-a
 
i should follow up by saying the drives are fine, the drive can read the same disk with a full dos 3.3 or 2.1 image on it, and the disk works in other drives / computers fine.
 
If you're writing a 360K disk in a high density 1.2MB drive, that usually doesn't work because the track widths are different. If that's what you're doing, you may have to find a different way to write your disks (use a real 360K drive, transfer files via a serial cable or Xircom PE3 parallel-port ethernet adapter, etc.)
 
I promise I'm using the right disks and the right drives. :) I remember that from ye olde 90s!

(My 5170 actually has both the 1.2MB drive and the 360k drive, so I can flip between things :)
 
Could you post the disk access code for one of those programs? It is possible that the program is tripped up by one of the differences in the hardware.
 
I'll go take a closer look, thanks krebizfan. It's just whatever turbo c 2.0 is spitting out.

It's just a bit interesting that i'm seeing the ABF error from DOS, but I can't type further. I would've thought that PC-DOS would've gotten the BIOS keyboard access stuff right, but I also don't know what code paths on the PCjr lead to the keyboard NMI handler being "disabled" (ie, beep) during keypresses..
 
I admit my first thought was that the increase in memory usage between DOS 2 and DOS 3 cause the program to access memory that was being allocated for video but that is a guess not backed by information. If memory is available on the Jr, maybe try loading the program above 128K which would verify that the preceding was not the cause.
 
Back
Top