DOS not booting

[MK14HAK]

Can some one with a working drive please verify:
If you change DOS (Im using Tut Disk2) just to go to A* after loading track 1 and change the step rate to something that is obviously wrong - does DOS still boot completely?

My 5" drive is not booting. INITs fine no errors. R/W any track -no errors.
Seeks to TK0 and loads it ok but wont load TK1 on boot.
Will read TK1 though with CA no problem
Have I got a stepper problem of TKO adjust issue or ...??

[bxdanny]

Huh? You obviously have a working drive you can boot from if you are able to test the one in question with CAll commands, etc. Can you be a little more specific about the setup, and what you can and can't do?

Too bad you gave up on the 8" drives. What software did you have for them?

[MK14HAK]

Danny, the DOS (Tutorial Disk2 v3.1 I think) has been serialed from PC, not booted.
Further investigation reveals its hanging before it does the read track 1 call. Some adaptive step rate juggling going on @ $13BC call. (Messy stuff here)
My DOS code boots fine in winOSI though.
I lost all my 8" media (still hurts) and re constructed my own images.(osiweb.org - includes bug fixes) So hoping John (or Dave) can dump his C3 original disks ...
Do you have any 8" software?

Mike

[bxdanny]

The standard OSI 5.25" versions of 65D for the C2/C4 look for a signal from the 540 board for timing information - specifically, to bit 7 of $DE00, which I think reflects the horizontal sync of the 540 video signal. But the code that looks at that is loaded from track one, it loads into the directory buffer at $2E79 during boot. So if the drive is really not stepping to track one, that wouldn't be it. If it is not stepping from track one to track two, I figured it could be. But no, a closer look reminds me that most disks actually step all the way to track SIX at that point, to load the patched keyboard driver at $3180, before checking the signal from the 540, so I guess that really isn't about the stepping rate, at least stepping in during read. It is about setting a timing delay value at $267B, normally $31 for 1 MHz and $62 for 2 MHz. (BTW, the disk image I posted as my "Enhanced Basic", the one with the 5.25" version of DQ Secretary, doesn't use that technique, it uses the ACIA of the disk interface for timing information, so a disk made from that (specifically, one using track one of that) it will not hang if that signal isn't there.)

Are you sure the diskette you are using to boot is good? Are it's contents the same as your serialized image? If the drive works when running your serialized image but not when booting from the real diskette, and the problem really is some adaptive code on track zero, it should be possible to use the "load track zero and return to monitor" entry point ($FFF3 in the standard ROM), patch out what is causing the trouble, and then go to $2200 to continue the boot.

I've gone on long enough, it's between 3 and 4 AM and I can't sleep, I apologize if I'm barking up the wrong tree.

[dave]

Danny,

I believe the "NMHZ" versions of OS65D store the timing constant at $267B (inside the 1ms delay routine at $267A). The values are $31 for 1 MHz and $62 for 2 MHz, as you describe.

At the moment, I can't remember exactly where this is set, and can't find it in the disassembly file, but I seem to recall that this is set from the ACIA, as you describe. If you know where this happens on your Enhanced BASIC disk, I'd be grateful for a pointer.

I am not aware that any bits at DE00 can change with the video output signals, although that would be very cool if it did (or if an interrupt were triggered on vsync). Could you double check that? Again, if you can provide a pointer to the code, I'd like to review it as well.

It's after 4am here as well so I'd better quit typing, and also apologize for any errors.

Thanks as usual for your informative and detailed comments!

Dave

[MK14HAK]

Thanks for your ideas Danny.
I compared both tks of the serial code and the media code and apart from self modified code areas they are the same.
I have created another DOS 3.2 vesion that has the same problem as the 3.1
Tk1 header ($28C4 routine)is not recognized before it hits the index and DOS jumps to $2A4B the Err9 routine that it hasn't loaded !! See code at $28B0 if header not found/index hit.
Put a JMP $FE00 where the Err9 code should be and sure enuf it hits the index.
My boot code runs in winOSI when serialed but again if I create an image with it it fails to boot in the emulator also -not loading a single byte from tk1 again hitting the index.
Ive created bootable 8" media from images before but must be doing something wrong with the way I am constructing tk1 this time. (or tk0 code is incorrect)
I dont think its step rate related now and wont bother with the 3.1 NMHZ adaptive step rate (Tut2) disk any more.
I want to get v3.2 on 5" media again for starters and it shouldn't be this difficult...

[bxdanny]

MK (or is it HAK?), it sounds like you know what you are doing, so I will let you be. Good luck.

Dave, the code I was talking about is on track 1 and loads to $2E79 (the track loads starting at $2A00). Look at the standard version, it has LDA $DE00 instructions, followed by BMI or BPL, it is looking at something on the 540 board and I believe it is a retrace signal that is gated onto the bus when that location is read. I can't see that it is of much use other than as a way of figuring out the CPU clock speed, which is its purpose here. This is not the Commodore 64 where you can change the border color at a given scan line, especially since you don't know what line is what, since I don't think the vertical retrace is readable (though perhaps a jumper on the 540 could make it so). Now look at my modified version, I instead look at $C010 after writing to $C011 (but not actually to the disk) as a way of gauging CPU speed, because I wanted it to work with either 600 or 540 video. Remarkably, the code I used usually comes up with the same values of either $31 or $62, while allowing for the possibility of other values for non-standard clock speeds.

[bxdanny]

MK/HAK:

I reread your message and it sounds like you might not have the proper track start or sector start codes on your disk or image.

From the OS-65D 3.0 manual:

TRACK FORMATTING
--------------------------------
THE REMAINING TRACKS ARE FORMATTED AS FOLLOWS :
- 1 MILLISECOND DELAY AFTER THE INDEX HOLE.
- A 2 BYTE TRACK START CODE, $43 $57.
- BCD TRACK NUMBER.
- A TRACK TYPE CODE, ALWAYS A $58.
THERE CAN BE ANY MIXTURE OF VARIOUS LENGTH SECTORS HEREAFTER.
THE TOTAL PAGE COUNT CAN NOT EXCEED 12 PAGES IF MORE THAN ONE SECTOR
IS ON ANY GIVEN TRACK. 13 PAGES CAN BE PLACED ON A TRACK IF ONLY ONE
SECTOR RESIDES ON A TRACK. EACH SECTOR IS WRITTEN IN THE FOLLOWING
FORMAT:
- PREVIOUS SECTOR LENGTH (4 IF NONE BEFORE) TIMES
800 MICROSECONDS OF DELAY.
- SECTOR START CODE, $76.
- SECTOR NUMBER IN BINARY.
- SECTOR LENGTH IN BINARY.
- SECTOR DATA.

While this was written for 8" disks, it should also apply to 5.25" disks, except for the references to 12 or 13 pages per track.

So track one needs to start with $43, $57, $01, $58, then $76, $01, $08 and the 2048 bytes of data. Since the problem occurs even on the emulator, it would not be due to insufficient delay between the index hole and track header, or between the track header and sector header. In an image file, the raw data for track one starts at offset $900 into the file.

[MK14HAK]

In an image file, the raw data for track one starts at offset $900 into the file.

Magic , thanks a bunch Danny. I hadnt looked closely enuf at the start address. My TK0 ended one byte short. I must have edited it and deleted a byte in error that has pushed tk1 up one byte early. So thats sorts my emulator image.
It must be a timing thing with the real media boot I guess. Ill take another look now that I know the code boots fine in the emulator.

[dave]

MK (or is it HAK?), it sounds like you know what you are doing, so I will let you be. Good luck.

Dave, the code I was talking about is on track 1 and loads to $2E79 (the track loads starting at $2A00). Look at the standard version, it has LDA $DE00 instructions, followed by BMI or BPL, it is looking at something on the 540 board and I believe it is a retrace signal that is gated onto the bus when that location is read. I can't see that it is of much use other than as a way of figuring out the CPU clock speed, which is its purpose here. This is not the Commodore 64 where you can change the border color at a given scan line, especially since you don't know what line is what, since I don't think the vertical retrace is readable (though perhaps a jumper on the 540 could make it so). Now look at my modified version, I instead look at $C010 after writing to $C011 (but not actually to the disk) as a way of gauging CPU speed, because I wanted it to work with either 600 or 540 video. Remarkably, the code I used usually comes up with the same values of either $31 or $62, while allowing for the possibility of other values for non-standard clock speeds.

Danny, I think $DE00 is the 32/64 column latch on the 540A, along with some other control bits on the 540B. I am not aware that the 540 board provides any meaningful value on read to DE00. I am not seeing it, but something could be hidden in the tangle of address decode circuitry there. I've never heard of this, though.

$2E79 is the start of the scratch area, which is why there's nothing there on the various disassembly listings. I checked a couple of disk images indeed, there is code there! I don't see the LDA $DE00. I do see the OS65D command strings from $2E30 to 2E78, then the following:

Code: Select all

2E79   EE 5E 26   INC $265E (sector number)
2E7C   A9 00      LDA #$00
2E7E   85 FE      STA $FE (memlo)
2E80   85 FF      STA $FF (memhi)
2E82   20 67 29   JSR $2967 (read track to memory)
2E85   A9 01      LDA #$01
2E87   8D 5E 26   STA $265E (sector number)
2E8A   A9 13      LDA #$13 
2E8C   20 BC 26   JSR $26BC (move to track 19)
2E8F   A9 32      LDA #$32
2E91   85 FF      STA $FF
2E93   A9 74      LDA #$74
2E95   85 FE      STA $FE (set memptr to $3274)
2E97   4C 1A 2B   JMP $2B1A (jump into the call command with track, sector, memory preloaded: load sector to memory)

So it looks like it's loading something else from disk, then returning to wherever it was called from. I am seeing this on two different disk images, but not sure what's going on without looking back at the calling routine, and also at the loaded code.

Any thoughts?