Image Map Image Map
Page 1 of 2 12 LastLast
Results 1 to 10 of 14

Thread: Osborne 1 with ROM v1.5/DD thrashing disk on boot

  1. #1

    Default Osborne 1 with ROM v1.5/DD thrashing disk on boot

    I've recently got Osborne One with Nuevo Electronics double density card installed. On power up when RETURN key is pressed the computer starts to repeatedly hit the disk drive head against track 0. No boot failure message (or any other message) is displayed while doing that. The process is the same whether there is a disk inside drive or the drive is empty. Booting from the second drive by pressing shift-quote key results in the second drive doing the same thing.

    Physically swapping drives and moving resistor assembly does not change the behaviour. I also tried removing one drive and booting with just one installed - same effect. Also tried powering on with built in monitor switched off (service manual suggests such test) - same result.

    I thought maybe track0 signal does not get to controller - no, testing it with oscilloscope showed that banging signal reaches the motherboard.

    At the moment I am out of ideas what else to check, so I would appreciate any suggestions.

    Oh, there is one - to remove the DD board and downgrade to single density. For that I would need the original ROM image, which I have not yet found anywhere available for download. If anyone has it, please share.

    I am going to dump my current ROM to study it a little bit, if anyone would be interested in studying it, I could share it as well.

    Last edited by vldmrrr; August 25th, 2018 at 07:51 PM.

  2. #2


    I'm not familiar with the Osborne, but a couple thoughts. There are two may reasons you might hear the drive do that. One is that the track-0 sensor is not working (could be sensor, cable, interface, ...) and the other is that the diskette has media errors which cause the software to keep retrying (or seeking track 0 to start over).

    If the computer is unable to ever see the track 0 signal, one recovery algorithm is to seek in a few steps then seek back out repeatedly.

    If the computer detects media errors - especially seek errors (unable to confirm track ID on media) - then it may step in (or out) and back, or even restore to track 0 and re-seek.

    Also, boot ROM code often would rety indefinitely, so even if it gives up trying to find track 0, it will only repeat the whole scenario and so you hear the continuous thrashing. I don't know whether the Osborne stubbornly tries to boot forever, or times-out and indicates an error. Knowing that might help determine what is going on (i.e. is the FDC controller chip stuck in some sort of infinite loop).

    It was my experience that these two scenarios had subtly different symptoms:

    A) If the hardware was unable to detect the track 0 signal, you would hear a significantly harsher thumping against the physical stops as the controller did not "softly" stop at the correct limit. Of course, if the track 0 signal were "stuck" ON, then you might get a different symptom.

    B) For media errors, the stepping rarely/never pounded against the physical stops, and so was less harsh sounding.

    Also, it is possible for the track 0 sensor to be mis-aligned, although it seems unlikely both drives would suffer the same problem.

    I guess one thing to try is to hook a scope or logic probe on the track 0 signal on the controller board, and confirm that the track 0 signal is reaching the board (although that is not the complete path required to reach the software - i.e. internal interface logic, including the FDC chip, may be broken.

    Have you tried multiple boot disks? Just to try and rule out media errors.

    Does the Osborne provide any sort of debug monitor code in ROM? If you could run some simple code to access the controller you might be able to get more information.

  3. #3


    @durgadas311: Thanks for suggestions. I did verify with oscilloscope that track 0 signal is reaching the pin 34 of controller chip. And since the head banging occurs regardless of disk being inserted or missing, the media error could be excluded. Osborne does not have any diagnostics or debug monitor in ROM.

    I was looking at ROM disassembly today trying to find out why the computer keep banging the head without showing "Boot error" message. One thing that occur to me while looking at it was that the ROM should be capable of handling unmodified single density setup. So I removed the Nuevo board, restored jumpers and tried booting that configuration - same result, head banging.

    From disassembly I found that cold boot routine (CBOOT) in Nuevo ROM starts somewhat different from OCC 1.4 ROM published in "Technical Manual". Here is relevant part of Nuevo code:
    CBOOT	call	RDRV ; restore drive
    	ld	a,B_0A
            ld	(SAVTRK),a
    	call	SEEK ; seek to track
    	call	 RDRV ; restore drive
    	call	SENDEN ; sense density
    	jr	z,LOADOS ; all good, load OS
            call	EBOOT ; print Boot error message
    	jr	 CBOOT
    This code sends restore drive command twice: at the beginning of the routine, then it seeks to track 10, then it does reset. The OCC code does just single restore and continues with density sense and boot. Neither version actually verifies if reset succeeded, and errors out only on error from density sensing routine.

    From watching the head movement it appears that first drive reset and seeking to track 10 works and the system gets stuck in the second reset banging drive head.

  4. #4


    That's good information. So it looks like the normal boot procedure is to step in to track 10, then go back out to track 0. This "banging the head", can you tell whether it is going back and forth between track 10 and track 0? or is it continuously stepping against the track-0-stop? I guess the question could be answered by watching the track-0 signal, too: if the signal has a square-wave appearance then it is likely looping on the boot routine, and if the signal is flat (on) then it must be trying to step out even though it has hit track 0.

    Also, what sort of floppy controller chip is being used? I'm familiar with the Western Digital line, especially the 179x series. I'm under the impression that the 179x series would actually refuse to step out once the track-0 signal is received. Also, if they are using the RESTORE command, that should stop stepping once track-0 is seen. Of course, seeing the signal at the pin of the chip does not prove that the signal is actually being seen by the chip (receiver could be toast, etc). If there was a way to actually run some code to read the chip status register and confirm that track-0 is being seen, that would be more conclusive.

    Might help to look at more of the RDRV and SEEK routines, to see what they do.

    Also, if you are trying to boot with no diskette in the drive, that also might appear to the software the same as media error - if it is not explicitly checking for the diskette spinning, somehow. A lot of software would watch for index pulses through the FDC chip, to determine if a diskette was actually inserted. Most did not have extra hardware to actually generate a READY signal, and drives of that era did not generate READY themselves.

    There's also the philosophy of the boot routine. I know the Heathkit H89 boot routines were oriented around failing gracefully and returning to the monitor ROM code, while Kaypro simply sat trying to boot continuously/forever after power on. This code snippet does show an apparent infinite loop trying to boot, but also hints that some sort of "error message" should be printed. If we know for certain that this error message is not occurring, we can probably conclude that it is not looping at this level. However, it could still be looping in RDRV or SEEK, or even in the FDC chip "firmware". Or else it is taking the "JR Z,LOADOS" branch but returning here after some other error. Sometimes, these "error messages" were nothing more than a clear-screen code, and possible bell. Those can be pretty subtle and easily overlooked.

    This might be where a logic analyzer would become indispensable... clipping something on the CPU and tracing what code is running would be invaluable.

  5. #5


    Here is the source of RDRV routine:

    ; Reset drive
    RDRV	ld	a,B_0A
    L_0C08	ld	(RTRY),a
    	call	SELDRV ; select drive
    	call	STEPIN ; step 1 track in 
    	call	L_0CDE ; do restore command
    	jr	nc,L_0C1F
    	ld	a,(RTRY)
    	dec	a
    	jr	nz,L_0C08
    	inc	a
    	stf	  ; set carry to indicate failure
    L_0C1F	xor	a ; clear carry to indicate success
    It seems that head banging happens inside the second call to RDRV (reset drive) routine. The seek to track 10 happens after the first call to RDRV. The head moves like this: on request to boot it retracts to track 0, then make long forward move (presumably track 10), then retracts to track 0 (presumably restore command in second call to RDRV), and then starts repeating short movement, that would fit single step in and retract to 0.

    The boot error message is actual print to screen, not just beep, I've seen it happen once (for some reason), and it is the same as can be seen on this youtube video (not mine) . The sound that is heard in this video is different from what mine makes - from mine it comes as a distinct tic-tok sound.

    What does not make sense to me is the fact that there is a retry count of 10 in reset routine, so after 10 hits it should return and print error message, but that does not happen. So I started to think this head banging is happening not under software control, but coming directly from controller chip. The chip is Fujitsu MB8877A, which should be upward compatible with Western Digital FD1793-02. The chip is actually on the socket, so I tried replacing it with a different clone of 1793 that I happened to have. With the different chip I've got the same behaviour, so I must exclude a controller fault as a reason of failure.

    Right now I am inclined to think that media failure is the reason. I presumed that disks that came with the system were good, so that at least with inserted disk the drive would show some differences. Being unable to confirm that in osborne itself, I tried reading the disk on my Commodore 128D, which shall be able to read osborne disks under CP/M. What happened after I inserted the disk in builtin 1571 drive, the system produced read error. What was worth, the drive stopped working all together (imagine my panic). I disassembled the drive, cleaned the head with alcohol, and although I did not notice any residue on cleaning q-tip, the drive returned to life.

    So now I am on the quest of creating bootable disks from downloaded IMD images using good blank disks. The only PC drive I have is 1.2MB so it might not produce a disk readable on original DD drive. The original osborne drive has pinout different from regular floppy connector (with power lines in place of some ground lines). It might be worth though assembling an adapter that would allow to connect osborne drive to PC to make sure that created disk would be readable on the target.

  6. #6


    I notice that RDRV sets the carry flag if it exhausts the retries, but that the calling sequence never checks carry - so it does not detect any failure from either call to RDRV (nor the call to SEEK, if it returns an error). It seems that RDRV should always return after 10 (?) failures, but it's not clear how to explain what you see. One thought, a stretch, is that something is corrupting RTRY, and so the retry loop never exits. That sort of bug might never be seen if the restore operation succeeds.

    Probably need to drill deeper and see what SELDRV, STEPIN, and L_0CDE routines do. Also, find out where RTRY is located in relation to the stack. If it only steps in to track 10 once, then it does seem that it must be in RDRV (or below). But, allowing for the possibility of software bugs, it could be something like the SEEK routine updates the FDC "track register", and that does not get cleared by the failed RESTORE operation, and so subsequent calls to SEEK to track 10 see the track register with 10 still in it, and so no stepping occurs.

    We're still looking at why the RESTORE operation is failing. But it might be good to attach the entire ROM code if you have it. We'll need the complete picture to understand what is happening.

  7. #7


    Here is link to binary ROM and my disassembly of boot code using the same labels as original osborne ROM.

    The listing of original ROM can be found here in ROM 1.4 section:

  8. #8


    I created fresh boot disk on a media as fresh as I could get. No change whatsoever. Of course, given that disk was created on 80 track 1.2MB PC drive does not add much confidence in this test. At least I have modded the PC drive for 250KB/s data rate. But hypothesis that problem is in media error still can not be dismissed. Well, another inconclusive effort.

  9. #9


    One classic problem with creating 40-track media on 80-track (or more) drives: the 80-track heads have a narrower write path, and so if you read that disk on a 40-track drive (with wider head) you get a much lower SNR (signal-to-noise ratio) and thus less reliability. Generally, back in the day, it was not recommended to write disks on 80-track drives and try to read on 40-track. Of course, none of that helps you get the machine running.

    I'll take a look at the ROM code later and see if I can guess where things have gone wrong. Since you are getting no error messages or indicators, that should narrow it down.

  10. #10


    I tried the reading the disk I created for Osborne using 80 track drive on a 40 track drive in my Commodore 128d. The system is capable of reading different formats, including Osborne.

    I was able to read the disk and to launch software from it. So, although still inconclusive, this does suggest that the problem with Osborne drive is prior to reading media.

Tags for this Thread


Posting Permissions

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