MAME: Emulating FDC Boards

[Coeus]

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]

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]

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]

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]

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]

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]

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

[vanekp]

MAME .SSD disc's don't work properly, below is the same file saved on a BeeBEm (Below) and on Mame (Above)

in the hex dump you can see MAME offsets the data at &100 by 1 and if you write to a existing disc image you end up destroying it.

Hope this problem will be addressed and fixed soon.
Peter.

[Pernod]

Hope this problem will be addressed and fixed soon.
Peter.

Before I take a look, can you confirm you're using latest 0.193?

[vanekp]

Yes I am using 0.193 of mame.

[Pernod]

I'm not seeing any problem here, so will need more info on exactly what you did (machine/dfs).

I ran MAME with: mame64 bbcb -fdc acorn1770
- created an empty ssd image from internal ui
- formatted image with *FORM 80 0
- saved a BASIC program to disc
- checked resulting ssd image and looks good

[Coeus]

in the hex dump you can see MAME offsets the data at &100 by 1 and if you write to a existing disc image you end up destroying it.

I am not sure that is what I see in that hexdump. The set of four &20 values, i.e. four space characters at &0100-&0103 are the end of the disc title which has been set on one version and not on the other. Have you checked http://mdfs.net/Docs/Comp/Disk/Format/DFS so see if the other values in sector 1 make sense?

[vanekp]

I am using the BBC Model B in mame, with the standard Acorn DFS 1.20, I created a blank SSD in BeebEm opened the image in Mame and wrote a file to it.
If I then try to open the image in BeebEm I cant and when comparing it with a image created in BeebEm (see hex dumps) block 2 of the disk bytes are offset, same if I load a working disk in mame afterwards if I write to it the image is no longer usable in any other emulator.

[Pernod]

I'm able to duplicate the issue, but can't see how it's specifically BBC related. I need to do some more testing with both FM and MFM formats, and also try saving from other machines (Atom and Dragon should be good test cases).

[vanekp]

You mean its an issue with mame itself and not with the BBC model B emulation under mame ?
In any event it is creating non standard format .SSD's
addition:-
Did some more testing..... the BBC Master 128 works fine does not screw up the disk image and the BBC Micro Model B+ 64k also work fine so it seems its something within the BBC Model B that is messing up disc images.
Peter.