MAME: Emulating FDC Boards

want to talk about MESS/model b/beebem/b-em/electrem/elkulator? do it here!
Coeus
Posts: 407
Joined: Mon Jul 25, 2016 11:05 am

Re: MAME: Emulating FDC Boards

Postby Coeus » Thu Mar 09, 2017 11:42 pm

Ok, so after I wrote the last post I suddenly had a thought. If that busy wait loop is waiting for bit 0 of the RAM copy of the status register to become clear, and the code in the NMI routine before the D0 command is issued sets that RAM copy to zero, why is that loop looping?

The answer is that an NMI is arriving during that delay loop. from the debugger:

Code: Select all

0D45: 88       DEY           >s
0D46: D0 FD    BNE 0D45      >s
0D45: 88       DEY           >s
0D46: D0 FD    BNE 0D45      >s
0D45: 88       DEY           >s
0D46: D0 FD    BNE 0D45      >s
0D00: 85 CC    STA CC        >s
0D02: 84 CD    STY CD        >s
0D04: AD 84 FE LDA FE84      >s
0D07: 8D 36 10 STA 1036      >r
    6502 registers :
    A=83 X=FF Y=3C S=01D9 PC=0D07
    Status : N  I C
0D07: 8D 36 10 STA 1036      >s
0D0A: 29 5C    AND #5C       >s
0D0C: D0 07    BNE 0D15      >s
0D0E: AD 87 FE LDA FE87      >s
0D11: A4 A2    LDY A2        >s
0D13: 91 A0    STA (A0),Y    >s
0D15: E6 A2    INC A2        >s
0D17: F0 05    BEQ 0D1E      >s
0D19: A5 CC    LDA CC        >s
0D1B: A4 CD    LDY CD        >s
0D1D: 40       RTI           >s
0D45: 88       DEY           >s
0D46: D0 FD    BNE 0D45      >s
0D45: 88       DEY           >s
0D46: D0 FD    BNE 0D45      >s


Clearly this NMI routine is not meant to be re-entrant because it stores the registers at fixed locations, not on a stack, so this is not what is expected to happen. So maybe the issue is that the 1770 emulation doesn't allow extra delay for the inter-sector gap, i.e. longer than the delay between any two bytes of the same sector.

evert67
Posts: 47
Joined: Mon Jul 14, 2003 8:45 pm

Re: MAME: Emulating FDC Boards

Postby evert67 » Fri Mar 10, 2017 12:14 am

I hope I'm not posting twice, since I thought I had already posted this. And sorry if this is slightly off-topic.

I didn't know Mame supported the BBC B. Is there anyone who can how good it is? For example, how does it compare to Beebem?

Thanx!

tom_seddon
Posts: 78
Joined: Mon Aug 29, 2005 11:42 pm
Contact:

Re: MAME: Emulating FDC Boards

Postby tom_seddon » Fri Mar 10, 2017 1:14 am

Coeus wrote:Clearly this NMI routine is not meant to be re-entrant because it stores the registers at fixed locations, not on a stack, so this is not what is expected to happen. So maybe the issue is that the 1770 emulation doesn't allow extra delay for the inter-sector gap, i.e. longer than the delay between any two bytes of the same sector.


Yes, I think that was what I was seeing before I introduced the sector-to-sector delay.

I've been using DDFS 1.54T, but I tried DDFS 1.53 on my emulator after adding support for the Watford DDB2 interface, and that seems to work too. I had a quick look through an instruction log of it doing *CAT and it looks like it's doing exactly the same stuff.

--Tom

Coeus
Posts: 407
Joined: Mon Jul 25, 2016 11:05 am

Re: MAME: Emulating FDC Boards

Postby Coeus » Mon Apr 17, 2017 12:06 am

tom_seddon wrote:Yes, I think that was what I was seeing before I introduced the sector-to-sector delay.


Thanks, Tom. I have added the inter-sector delay to B-Em. The branch at
https://github.com/stardot/b-em/tree/sf/wd1770 should now emulate Opus, Solidisk and Watford 1770 boards - I have just got the multiple write sector support working.

What I need now is a good way to test that file I/O is error free. Does anyone know of a good test suite for this?

Coeus
Posts: 407
Joined: Mon Jul 25, 2016 11:05 am

Re: MAME: Emulating FDC Boards

Postby Coeus » Mon Apr 17, 2017 3:48 pm

Further to my last message does anyone know exactly what the 1770 does when you try to read a disk recorded with the opposite density from the one you have selected? I am trying to debug why density switching isn't working on the Watford and Opus DFSes. It works fine on Solidisk.

What I am currently doing is returning with status "record not found" (1770 status byte 0x90) but that does't seem to do the trick. Neither does returning header CRC error (0x98) or data CRC error (0x88).

Coeus
Posts: 407
Joined: Mon Jul 25, 2016 11:05 am

Re: MAME: Emulating FDC Boards

Postby Coeus » Mon Apr 17, 2017 10:09 pm

And to answer my own question it seems Watford enables the verify option on the WD1770 restore command and expects that to report the sector not found error. If it doesn't it then assumes it has the density correct and any further sector not found errors are just reported to the user. Implementing the verify option fixes that one. The Opus DDOS instead issues a read address command.

tom_seddon
Posts: 78
Joined: Mon Aug 29, 2005 11:42 pm
Contact:

Re: MAME: Emulating FDC Boards

Postby tom_seddon » Wed Apr 19, 2017 12:01 pm

My code issues a Record Not Found when doing a Read Sector, Write Sector or Read Address when the density is wrong, and that seemed to sort out the Challenger/DDOS density detection at least. Good point about the verify flag though... looks like I have a bit more code to add...

On another (slightly random) note: something I originally just copied unthinkingly from BeebEm was the "TR00 active high" flag: https://github.com/stardot/beebem-windo ... rd.cpp#L61, https://github.com/stardot/beebem-windo ... 0.cpp#L372, etc. - but at some point I switched it off, and haven't had any problems.

I guess this might just have been canceling out some other problem in BeebEm? BeebEm's track 0 bit looks like it's the wrong way round, so that's one option - but I found the code a bit difficult to follow, so I didn't go much further than that. There could also be multiple things wrong with mine too of course ;)

Doesn't look like B-em does this, though, so I'm feeling confident!

--Tom


Return to “emulators”

Who is online

Users browsing this forum: No registered users and 3 guests