Previous Thread
Next Thread
Print Thread
Page 7 of 11 1 2 5 6 7 8 9 10 11
Re: wd17xx.c: busy status bit [Re: Barry Nelson] #61287 04/24/10 07:57 PM
Joined: Oct 2004
Posts: 503
Barry Nelson Offline
Senior Member
Offline
Senior Member
Joined: Oct 2004
Posts: 503
By the way, I am fairly sure that this version of OS9 switch the speed to 1Mhz when running the floppy. In fact, the other disk roms you refer to that do not slow down in disk basic I think came on floppy controllers with non-Radioshack (not original) hardware, am I right? Did those controllers even use the WD chip? If they did, I bet they did not use the exact same circuitry as the Radioshack controller...

Re: wd17xx.c: busy status bit [Re: Barry Nelson] #61294 04/25/10 06:58 AM
Joined: Oct 2004
Posts: 503
Barry Nelson Offline
Senior Member
Offline
Senior Member
Joined: Oct 2004
Posts: 503
The relevant boot sequences for Coco3 OS9 Level II v 2.0.1:

1. DOS command loads in the kernel from track 34 (contains REL,BOOT,OS9P1), and executes it.
2. REL relocates (copies) kernel track code to $ED00, sets GIME etc.
REL then jumps to OS9P1.
3. OS9P1 inits vars, verifies kernel modules, tries F$Link to INIT.
Link fails, so does F$Boot which calls BOOT.
4. BOOT loads in os9boot file from floppy. OS9P1 can now find INIT.
5. OS9P1 tries link to OS9P2, jumps to it (else does F$Boot).
6. OS9P2 inits vars, checks INIT for default device, CHD/CHX to it
(else F$Boot)
7. OS9P2 checks INIT for default term, opens it.
8. OS9P2 starts up CC3GO.
9. CC3GO tries to CHD/CHX to /DD. Does startup shell, etc.

It is definitely stopping before step 8, give me time and I'll try running a debugger, etc... I think it is stopping when it tries to call F$Boot...

Re: wd17xx.c: busy status bit [Re: Barry Nelson] #61405 04/30/10 03:28 AM
Joined: Oct 2004
Posts: 503
Barry Nelson Offline
Senior Member
Offline
Senior Member
Joined: Oct 2004
Posts: 503
I've been running the MESS debugger...
I've traced it as far as calling OS9 F$Boot at address F1B8
That crashes and starts trying to execute memory containing invalid op codes...

I've also confirmed that a working version of MESS reaches the same OS9 F$Boot call at F1B8 but that this results in a successful boot of OS9.

Re: wd17xx.c: busy status bit [Re: Barry Nelson] #61406 04/30/10 08:19 AM
Joined: May 2007
Posts: 550
M
mizapf Offline
Senior Member
Offline
Senior Member
M
Joined: May 2007
Posts: 550
I also had to hunt down problems with a disk controller (smc92x4), and I would suggest the following:

Provided that you understand the machine language of the host system, have the emulator print the memory address and the contents together with the operation on the controller. This is easier than stepping throught the code with the debugger. Specifically, if the host system checks for a certain state of a line, you may figure out why it crashes at this point. Using a previous MESS version you can compare the outputs and see what is different.

Michael

Re: wd17xx.c: busy status bit [Re: mizapf] #61430 05/01/10 08:23 PM
Joined: Oct 2004
Posts: 503
Barry Nelson Offline
Senior Member
Offline
Senior Member
Joined: Oct 2004
Posts: 503
Something is hokey with the CPU! During the boot sequence, it tries to run these instructions...

Code:
EFD7 LBSR $EFDA        17 00 00
EFDA LBSR $EFDD        17 00 00
EFDD RTS               39

Instead BSRing to EFDA then BSRing to EFDD, then RTS, then BSRing to EFDD again, then RTS, the first LBSR jumps to FEFD??? What the?

On the older MESS it works properly and transfers control back to EE56, which the code there looks like
Code:
EE53 LBSR $EFD7        17 01 81
EE56 LDA ,X            A6 84

Alright, who broke the CPU?

Re: wd17xx.c: busy status bit [Re: Barry Nelson] #61434 05/01/10 10:47 PM
Joined: Dec 2007
Posts: 301
R
Robert Gault Offline
Senior Member
Offline
Senior Member
R
Joined: Dec 2007
Posts: 301
Barry,
Keep in mind that if you revert wd17xx.c to 7366, the boot process will work. That means the bug must reside in wd17xx.c. The CPU emulation should be located in coco.c.
The most likely cause for what we see is that the disk Read process has been changed in some subtle fashion so that either the OS-9 kernel or os9boot is not read correctly.

Whether this is an actual disk I/O problem or interference with MMU memory changes caused by the new wd17xx.c timing is a good question. As I understand the wd17xx.c changes (and I could be completely wrong) timing, interrupt handling, and disk size handling were the targets.
Why the changes have no impact on other programs using disk I/O but only the OS-9 boot process is bizarre.

Re: wd17xx.c: busy status bit [Re: Robert Gault] #61439 05/02/10 07:11 AM
Joined: Oct 2004
Posts: 503
Barry Nelson Offline
Senior Member
Offline
Senior Member
Joined: Oct 2004
Posts: 503
Look, I traced the above instructions and where they jump to by single stepping them, an LBSR is NOT a conditional branch, it is a long branch subroutine ALWAYS. The machine state is irrelevant to how this instruction should execute. An LBSR $EFDA should ALWAYS branch to EFDA, not FEFD! It shouldn't matter how the MMU is set, or what the register contents are. I could understand if it branched to the right address, and then started executing the wrong instructions, because the memory contents were wrong... That was what I expected to see, but that is not what I observed...

What I will try next when I have time is to poke the LBSR instruction into memory and run just those instructions.

Although... Maybe it could have to do with an interrupt not being masked and arriving it that moment, causing the CPU to branch off on an interrupt vector wild goose chase?

Re: wd17xx.c: busy status bit [Re: Barry Nelson] #61440 05/02/10 08:01 AM
Joined: Oct 2004
Posts: 503
Barry Nelson Offline
Senior Member
Offline
Senior Member
Joined: Oct 2004
Posts: 503
Good boot trace
Code:
EFD7: LBSR  $EFDA
EFDA: LBSR  $EFDD
EFDD: RTS   
EFDD: RTS   
EFDA: LBSR  $EFDD

   (loops for 2 instructions)

EE56: LDA   ,X
EE58: LDA   #$FF
EE5A: STA   $4,U
EE5C: LEAX  $00FA,PC
EE60: STX   $FC
EE62: LDA   #$09
EE64: STA   $FF40
EE67: LDD   #$C350


Failed boot trace
Code:
EFD7: LBSR  $EFDA
FEFD: LBRA  $FED2
FED2: LDB   #$FC
FED4: BRA   $FEB8
FEB8: LDA   #$00

Huh?

Re: wd17xx.c: busy status bit [Re: Barry Nelson] #61441 05/02/10 08:20 AM
Joined: Mar 2001
Posts: 16,575
R
R. Belmont Offline
Very Senior Member
Offline
Very Senior Member
R
Joined: Mar 2001
Posts: 16,575
Looks like it's getting an interrupt on the failed trace that isn't happening otherwise. When a known good CPU core jumps apparently randomly like that, that's usually what happened.

Re: wd17xx.c: busy status bit [Re: R. Belmont] #61444 05/02/10 12:57 PM
Joined: Dec 2007
Posts: 301
R
Robert Gault Offline
Senior Member
Offline
Senior Member
R
Joined: Dec 2007
Posts: 301
If a non-maskable NMI interrupt occurred just as the LBSR $EFDA was ready to process, there would be jump to $FEFD. In fact there is an NMI vector located at $FEFD, in the second IRQ table for a Coco3.

Two questions need to be answered, is this vector still active in this portion of the OS-9 boot process, and is this a false NMI caused by the new wd17xx.c code.

Page 7 of 11 1 2 5 6 7 8 9 10 11

Who's Online Now
1 registered members (1 invisible), 35 guests, and 1 spider.
Key: Admin, Global Mod, Mod
ShoutChat Box
Comment Guidelines: Do post respectful and insightful comments. Don't flame, hate, spam.
Forum Statistics
Forums9
Topics8,811
Posts115,965
Members4,914
Most Online890
Jan 17th, 2020
Powered by UBB.threads™ PHP Forum Software 7.7.3