Previous Thread
Next Thread
Print Thread
Page 10 of 11 1 2 8 9 10 11
Re: wd17xx.c: busy status bit [Re: Robert Gault] #61484 05/04/10 01:45 PM
Joined: Oct 2004
Posts: 503
Barry Nelson Offline
Senior Member
Offline
Senior Member
Joined: Oct 2004
Posts: 503
Originally Posted By Robert Gault
Barry,

I tried the same test and got slightly different results.

No NMI was generated with $D1 or $D2. This may not be an adequate test as the bits select "not ready to ready" and "ready to not ready" and those conditions probably were not met.
Both $D4 and $D8 generated an NMI but of different nature. $D4 changed the screen to orange and left it that way until the next keypress. $D8 caused a brief flash of orange that was not always seen.
Both $D4 and $D8 behave as expected. $D4 generates an NMI at each index pulse, so there should be a stream of NMI. $D8 generates one immediate NMI. The ROM switches the screen back to normal (green) as part of the Coco3 main loop when it is not tied up with NMI processing.

Then I tried the same thing with MESS; patched wd17xx.c. I did not get the orange screen changes. Well hard to say whether an NMI was generated so I changed the routine to
Code:
  org $2600
a1  lda #8
    sta $ff22
    bra a1


Now both $D4 and $D8 changed the MESS screen orange but $D1 and $D2 did not. The behavior of a real Coco3 was exactly emulated.

I don't think the patch I submitted gives 100% correct behavior of the forced interrupt command yet, but I guess it is an improvement.

When you do the pokes listed, don't forget the poke 359,57, otherwise the screen will only flash, if you see anything at all...

How can I test the ready to not ready and not ready to ready interrupt behavior?

Re: wd17xx.c: busy status bit [Re: Barry Nelson] #61485 05/04/10 02:24 PM
Joined: Oct 2004
Posts: 503
Barry Nelson Offline
Senior Member
Offline
Senior Member
Joined: Oct 2004
Posts: 503
Also, when an interrupt is generated, is this code (and the original code) causing two interrupts? One immediately, and one 12us later when the timer calls the callback function?

Re: wd17xx.c: busy status bit [Re: Barry Nelson] #61488 05/04/10 07:40 PM
Joined: May 2007
Posts: 549
M
mizapf Offline
Senior Member
Offline
Senior Member
M
Joined: May 2007
Posts: 549
OK, seems as if the TI can work with your patch - read/write sector and formatting was OK. FORCE_INT seems to only occur on system reset.

I read the TYPE IV description in the spec, but, honestly ... I don't get it frown . What is this command supposed to do precisely?

- Terminate the currently running command (this must be respected in the callbacks).
- Now when does the conditional interrupt occur? If the condition is valid during the FORCE_INT execution? Later? How long?

The spec is contradictory wrt. to the interrupt: "When a command is completed, an interrupt is generated..." (in "COMMAND DESCRIPTION"), but with I3-I0=0 "Terminate with no interrupt". So that is the reason why the implementation always raised the interrupt.

Michael

Re: wd17xx.c: busy status bit [Re: mizapf] #61489 05/04/10 08:18 PM
Joined: Oct 2004
Posts: 503
Barry Nelson Offline
Senior Member
Offline
Senior Member
Joined: Oct 2004
Posts: 503
My question was more about how the C code is functioning, not the original device, but with respect to the original device there seems to be some confusion as well... Although I can always do more testing with the real disk controller. smile

I can probably test the code some more using the debugger and a test 6809 code program. If no none else steps up, expect another patch from me once I get a better handle on this issue. This patch was really only a crude hack just to get it to work, I never really intended to have it applied to the main code base... crazy

Re: wd17xx.c: busy status bit [Re: Barry Nelson] #61507 05/05/10 06:52 AM
Joined: Oct 2004
Posts: 503
Barry Nelson Offline
Senior Member
Offline
Senior Member
Joined: Oct 2004
Posts: 503
Don't make any more changes to the svn code base yet! But I think I have found that this if statement seems to yield more accurate results...
Code:
/* set intrq after delay */
static TIMER_CALLBACK( wd17xx_command_callback )
{
        running_device *device = (running_device *)ptr;
        wd1770_state *w = get_safe_token(device);

        if ((w->last_command_data & ~FDC_MASK_TYPE_IV) != FDC_FORCE_INT)
        {
                wd17xx_set_intrq(device);
        }
}

This appears to be because the interrupt is being generated properly in WRITE8_DEVICE_HANDLER( wd17xx_command_w ) before it reaches the callback. Of course that means no 12us delay... Should there be a 12us delay on a FDC_FORCE_INT? If so, some code needs to move from WRITE8_DEVICE_HANDLER( wd17xx_command_w ) to static TIMER_CALLBACK( wd17xx_command_callback )...

I wrote this program for a coco3 (might work with modifications on a coco1 or 2) to help test when an NMI is generated... Entering a blank value resets the nmi vector and exits the program. Entering a hex number pokes that value into FF48. If an interrupt is generated by this poke the screen changes to orange. If the value causes an interrupt when the controllers ready state transitions, the screen flashes...
TESTNMI.DSK

If anyone knows, please let me know if there should or should not be a 12us delay on this NMI for a FDC_FORCE_INT... If no one knows, I may try to write something to time the delay...

Re: wd17xx.c: busy status bit [Re: Barry Nelson] #61517 05/05/10 06:11 PM
Joined: Dec 2007
Posts: 301
R
Robert Gault Offline
Senior Member
Offline
Senior Member
R
Joined: Dec 2007
Posts: 301
There is no information in the WD specs of the 1773 or 1793 of a delay before execution of a forced interrupt. The implication is no delay as the term 'immediate' is used describing the results.
The only mention of a delay is after the command is issued. If you don't wait, you nullify the forced interrupt command. The post command delay is 1773 16usec double density 32usec single density, 1793 8usec double density 16 usec single density.

Re: wd17xx.c: busy status bit [Re: Robert Gault] #61520 05/06/10 02:13 AM
Joined: Oct 2004
Posts: 503
Barry Nelson Offline
Senior Member
Offline
Senior Member
Joined: Oct 2004
Posts: 503
Originally Posted By Robert Gault
There is no information in the WD specs of the 1773 or 1793 of a delay before execution of a forced interrupt. The implication is no delay as the term 'immediate' is used describing the results.
The only mention of a delay is after the command is issued. If you don't wait, you nullify the forced interrupt command. The post command delay is 1773 16usec double density 32usec single density, 1793 8usec double density 16 usec single density.


Hmmm, interesting text, if the results are immediate, how does doing something in the next 16us or so (depending) undo the immediate result and interrupt that already occurred in the past? crazy

According to the spec sheet I dug up WD1773 spec PDF
On page 5 it says...

Code:
Type IV command (the only type IV command is the forced interrupt)
I3-I0 Interrupt condition bits (Bits 3-0)

I0 = Not used (WD1770-00, WD1772-00)
     Not Ready to Ready Transition (WD1773-00)
I1 = Not used (WD1770-00, WD1772-00)
     Ready to Not Ready Transition (WD1773-00)
I2 = Interrupt on Index Pulse
I3 = Immediate Interrupt

So from that it appears that the only condition that causes an immediate interrupt is I3 set. The other bits cause an interrupt next time the given condition occurs. That could be immediate, or could be a certain time later...
According what I have observed on the hardware, and what the spec sheet says, the only way to stop/reset these interrupts is to issue another command within ~16us or issue a "D0" command...
I will test further and confirm...



Re: wd17xx.c: busy status bit [Re: Barry Nelson] #61527 05/06/10 05:03 PM
Joined: Oct 2004
Posts: 503
Barry Nelson Offline
Senior Member
Offline
Senior Member
Joined: Oct 2004
Posts: 503
Testing on the real machine shows that the index pulse interrupt requested by command D4 occurs on the next index pulse only (1 time). If you toggle the bit value 32 off and then on again on ff40, you get another interrupt on the next index pulse. D1 and D2 cause an interrupt on the next ready state transition. D8 seems to occur right away, but I have not timed it at the micro second level yet. I plan to do that next.
Based on what I have seen so far, although the current if statement is not entirely accurate, it is a reasonable approximation that should allow most software using a FDC_FORCE_INT command to function.

If I endeavor to rewrite some code to make it more accurate, is there any emulation of the floppy index pulse as a timed event?


Re: wd17xx.c: busy status bit [Re: Barry Nelson] #61529 05/06/10 05:22 PM
Joined: May 2004
Posts: 891
D
Duke Offline
Senior Member
Offline
Senior Member
D
Joined: May 2004
Posts: 891
There is a callback that gets called for every index pulse. See http://git.redump.net/cgit.cgi/mess/tree/src/mess/machine/wd17xx.c#n816

Note that interrupts on index pulse are already supported (but might be implemented wrong - I haven't looked into it).

Re: wd17xx.c: busy status bit [Re: Duke] #61536 05/07/10 02:19 AM
Joined: Oct 2004
Posts: 503
Barry Nelson Offline
Senior Member
Offline
Senior Member
Joined: Oct 2004
Posts: 503
Thanks! Right now, I think a D4 is generating an interrupt here:
static TIMER_CALLBACK( wd17xx_command_callback )
if I comment that out, I don't see an interrupt from here:
wd17xx_index_pulse_callback

When is this callback active? It should generate an index pulse as long as there is media in the drive, the drive is spinning, and the disk select line is active...
Maybe it's active and just not generating an interrupt.

Page 10 of 11 1 2 8 9 10 11

Who's Online Now
2 registered members (AJR, Luengo), 359 guests, and 3 spiders.
Key: Admin, Global Mod, Mod
ShoutChat Box
Comment Guidelines: Do post respectful and insightful comments. Don't flame, hate, spam.
Forum Statistics
Forums9
Topics8,734
Posts114,832
Members4,879
Most Online890
Jan 17th, 2020
Powered by UBB.threads™ PHP Forum Software 7.7.3