floppy in pmode

[distantvoices]

In my experience - it's simply that the FDC doesn't load what you want if you omit the seek_track thing.

I can ofcourse carry out an evaluation if you need a falsification of this. But that 'd have to wait til today evening.

[bubach]

It looks ok.
When you screw up in one way or another, failed to read or whatever, you should call "fdd_reset" and then "fdd_recalibrate".
The fdd_seek (or whatever you call it), should be called before issuing the read command.

[Dex4u]

Theres a bit you set, forgot which one off hand, for automatic seek or manual seek, from my test this (automatic seek) does not always work on all PC, so i did the manual seek on all PC (if needed)

[Pype.Clicker]

just to make sure, i've heard many ppl here giving out values of SRA and SRB when talking about buggy floppy drivers, but reading the specs seems to reveal they're just "spy pins" registers which do not play any role in the driver programming ... or do they ?

i mean are they useful for something else than debugging purpose ?

[Dex4u]

Are they not PS/2 specific registers.

[Pype.Clicker]

Are they not PS/2 specific registers.

they are, but afaik our modern PCs look more like PS/2 than like PC-AT or "model something", no ? so i assumed they were available. Question is, what are they good for ? ...

[Brendan]

Hi,

IMHO they are all just for diagnostics, except for the WP (Write Protect) bit in SRA. The only other way to find out if a disk is write protected is to issue a "sense drive status" command (0x04), or issue a write (without checking) and see if you get an error.

BTW, the "Model 30" was the first computer in IBM's "PS/2" range, sporting a lovely 10 MHz 80286 and an (optional) 20 MB hard drive . It was the only PS/2 with an ISA bus (later models used MCA). Starting price for a model 30 was $2965 USD (512 KB of RAM, standard VGA video, no hard drive). Probably could've bought a new car for the same price back then .


Cheers,

Brendan

[GLneo]

Code: Select all

void reset_floppy_controller()
{
    int temp;
    char temp2;
    motor_on = 1;
    outport(0x3F2, 0x08);                   // DOR <- DMAGATE,RESET, drive=0
    outport(0x3F7, 0x00);                   // CCR <-
    outport(0x3F2, 0x0C);                  // DOR <-
    wait_irq6();
    for(temp = 4; temp > 0; temp--)
    {
        send_byte(0x08);                     // CMD "Sense Interrupt"
        (void)get_byte();
        (void)get_byte();
    }
    send_byte(0x03);                         // CMD "Specify"
    send_byte(0xDF);       // SRT= 0xd; hut=0xf
    send_byte(0x02);        // hlt=1
    if(motor_on == 0)
    {
        start_motor();
        motor_on = 1;
    }    
    send_byte(0x07);                         // CMD "Recalibrate" (dsk=0)
    send_byte(0x00);
    wait_irq6();
    send_byte(0x08);
    (void)get_byte();
    (void)get_byte();
}

the controler never gives an irq, why ???

[Pype.Clicker]

What irq doesn't get out ? first one or the second one ?

I compared your code with Tim's code and it looks like he replaced the first wait-for-interrupt with the following loop:

Code: Select all

while ((in(fdc->base + REG_MSR) & MSR_MRQ) == 0);

   

Could you by any chance be running that code before IRQ6 has been properly enabled at the PIC or in a code section where interrupts are disabled (i suppose that's why Tim had to tweak his code like this) ?

[GLneo]

my entier code is:

Code: Select all

void wait_irq6()
{
    while(irq6_state == 0);
    irq6_state = 0;
}

void start_motor()
{
    outport(0x3F2, 0x1C);
    delay(1);
}    

void stop_motor()
{
    outport(0x3F2, 0x00);
}

void send_byte(unsigned char data)
{
    while((inport(0x3F4) & 0xC0) != 0x80);
    outport(0x3F5, data);
}

unsigned char get_byte()
{
    while((inport(0x3F4) & 0xC0) != 0xC0);
    return inport(0x3F5);
}

void fdc_reset()
{
    int temp;
    outport(0x3F2, 0x08);
    delay(1);
    outport(0x3F7, 0x00);
    outport(0x3F2, 0x0C);
    wait_irq6();
    for(temp = 4; temp > 0; temp--)
    {
        send_byte(0x08);
        (void)get_byte();
        (void)get_byte();
    }
    send_byte(0x03);
    send_byte(0xDF);
    send_byte(0x02);
}    

void fdc_recalibrate()
{
    char temp;
    if(motor_on == 0)
    {
        start_motor();
        motor_on = 1;
    }    
    send_byte(0x07);
    send_byte(0x00);
    wait_irq6();
    send_byte(0x08);
    (void)get_byte();
    (void)get_byte();
}

void set_floppy()
{
    get_floppy_type();
    irq_setter(6, irq6_handler);
    fdc_reset();
    fdc_recalibrate();
}

set_floppy(); is called after int are enabled

p.s. bubach, this is kinda like a c version of your fdc, it works on emulator but not on real computer, do you see a porblem ???

[Pype.Clicker]

just in case, make sure you have "irq_state" variable declared volatile ...

[Dex4u]

p.s. bubach, this is kinda like a c version of your fdc, it works on emulator but not on real computer, do you see a porblem ???

@GLneo, if your talking about the driver in BOS, that floppy driver is from "Dex4u" and writen by me, so if you are let me know and i will try and answer your ?.

[GLneo]

@Pype.Clicker, didn't fix it but most likely help, thx
@Dex4u, that's a good driver ;D, i think my problem is in get & send byte, am i searching for the right number ???

[Dex4u]

I not very good with C, but try putting big delays as this is important, you can speed it up later.

I will upload the fully commented original. in the mean time i will look over you code and get back to you.

http://falconrybells.co.uk/FddInfo.asm

http://falconrybells.co.uk/Fdd.asm

NOTE: The comments go with the pseudo code in the Intel controller manual.

[bubach]

As he said, that driver is from dex4u.
If it works in BOCHS the it's a almost always a timer issue. Can we have a look on you timer and IRQ (wasn't included) code?