MAME: Emulating FDC Boards

want to talk about MESS/model b/beebem/b-em/electrem/elkulator? do it here!
User avatar
Pernod
Posts: 938
Joined: Fri Jun 08, 2012 10:01 pm
Location: Croydon, UK

MAME: Emulating FDC Boards

Postby Pernod » Mon Aug 15, 2016 11:24 am

So for the Model B, MAME and other emulators typically emulate the standard Acorn 8271 and 1770 FDC's. There are many other DFS/DDFS/DDOS/etc. ROMs out there that cannot currently be used in any emulator due to their required FDC's not being emulated, fortunately MAME already has devices of all relevant FDC's. I'm aiming to emulate all known FDC boards!

Current findings and status:
Acorn 8271: Working
This works well and provides the following DFS to choose from:
Acorn DFS 0.90
Acorn DFS 0.98
Acorn DNFS 1.20
Acorn DNFS 1.21

Amcom DFS 0000
Amcom DFS A7259
Amcom DFS B4084
Amcom DFS B4218
All Amcom DFS will catalogue a standard DFS disc but also report Disc Fault 18, and fail to load anything. Anyone with any experience of this DFS know why? Also suspect more versions are out there, anyone have any not listed here?

Watford 1.10
Watford 1.30
Watford 1.41
Watford 1.42
Watford 1.43
Watford 1.44

Are there any other DFS compatible with 8271?

Acorn 1770: Working
This works well and provides the following DFS to choose from:
Acorn DFS 2.10
Acorn DFS 2.20
Acorn DFS 2.23
Acorn DFS 2.25
Acorn DFS 2.26

Are there any other DFS compatible the the Acorn 1770 board?

Cumana QFS: Working
This used the MB8877A FDC and I believe the following DFS should work with this.
QFS 2.00
QFS 1.02

Computer Village 1797:
This is unusual and uses the FD1797 with following ROM.
LVL Dos 0.91

Very little known about this, *HELP just gives Double Density 0.91f and no further details. Fails to catalogue standard Acorn disc, is it expected to?

Microware:
This used the WD1793 FDC and I believe the following DFS should work with this.
Microware DDFS 0.90
UDM DDFS 2.00

Both return Disc Fault 18 probably due to not being mapped correctly, further investigation required.

MRM E00:
Standard 8271 with 4K RAM, used for workspace to keep page at &E00.
MRM DFS 1.20

Not yet implemented RAM so DFS disables itself. Shouldn't take too much effort to fix.

Opus 8272:
Video on YouTube shows this with Opus DDOS 3.00. The machine is now at Computing History in Cambridge.

Opus 2791: Working
This used the WD2791 FDC and I believe the following DFS should work with this.
Opus DDOS 3.15
Opus EDOS 0.4

The DDOS works well. Anyone have other DDOS 3.1x versions? There's definitely 3.16 and 3.12 out there somewhere.

Opus 2793: Working
This used the WD2793 FDC and I believe the following DFS should work with this.
Opus DDOS 3.35

The DDOS works well. Anyone have other DDOS 3.3x versions? There's definitely 3.36 out there somewhere.

Opus 1770: Working
This used the WD1770 FDC and I believe the following DFS should work with this.
Opus DDOS 3.45
Opus DDOS 3.46

The DDOS works well. Anyone have other DDOS 3.4x versions?

Watford Electronics 1770: Working
This works well and provides the following DFS to choose from:
Watford DDFS 1.54T

Any other versions of DDFS for the 1770?

Watford Electronics 1772: Working
Watford DDFS 1.40
Watford DDFS 1.50
Watford DDFS 1.53

Seems a little odd that Watford went from the 1772 to the 1770, any technical details about this board anywhere?

Others:
Solidisk: STL DDFS 1.9 with 1770, not yet tested.
Kenda Professional: Anyone have any details/ROM for this?
Viglen: Viglen DSDFS 1.00, anyone have details/ROM for this?
BS-DOS-2.22: No details for this, don't even know which FDC it's for.
LDos0.90: No details for this, don't even know which FDC it's for.

Anyone know of any other FDC boards/DFS ROMs that I haven't mentioned above?
Last edited by Pernod on Wed Sep 14, 2016 3:06 pm, edited 1 time in total.
- Nigel

BBC Model B, ATPL Sidewise, Acorn Speech, 2xWatford Floppy Drives, AMX Mouse, Viglen case, etc.

User avatar
tricky
Posts: 1823
Joined: Tue Jun 21, 2011 8:25 am
Contact:

Re: MAME: Emulating FDC Boards

Postby tricky » Mon Aug 15, 2016 12:15 pm

I seem to remember upgrading my Solidisk: STL DDFS 1.9 to 2.00 at some point, but it was only a ROM change.
PS Does MAME have a help section for setting up tape/disc images yet?

User avatar
Pernod
Posts: 938
Joined: Fri Jun 08, 2012 10:01 pm
Location: Croydon, UK

Re: MAME: Emulating FDC Boards

Postby Pernod » Mon Aug 15, 2016 2:27 pm

tricky wrote:I seem to remember upgrading my Solidisk: STL DDFS 1.9 to 2.00 at some point, but it was only a ROM change.

Yeah, have the ROMs but haven't looked at STL yet. They also did the DFDC board with switchable 8271/1770 but not sure how to implement this yet in MAME framework.
PS Does MAME have a help section for setting up tape/disc images yet?

Not sure what you mean.
Run MAME:
- select BBC Model B
- press TAB and select File Manager
- select cass or flop interface
- select appropriate image or select something from the Software Lists (if you have them installed)
- Nigel

BBC Model B, ATPL Sidewise, Acorn Speech, 2xWatford Floppy Drives, AMX Mouse, Viglen case, etc.

User avatar
sweh
Posts: 1833
Joined: Sat Mar 10, 2012 12:05 pm
Location: New York, New York
Contact:

Re: MAME: Emulating FDC Boards

Postby sweh » Mon Aug 15, 2016 5:42 pm

Pernod wrote:
tricky wrote:They also did the DFDC board with switchable 8271/1770 but not sure how to implement this yet in MAME framework.

It was a physical switch and you had to reset the machine (recommended to switch it while off; control-BREAK at the very least) so I'm not sure you need to emulate the switching mode; just build two "FDC emulators", one in 1770 mode and one in 8271 mode. I don't know if the 8271 mode was 100% compatible with Acorn; I never had one but a friend did. If the STL ROM -www.nvg.ntnu.no/bbc/rom/SoliDisk/fs/DFS-8271-1770-2.2M2.zip - works with the native Acorn 8271 board then that bit is easy :-)
Rgds
Stephen

User avatar
tricky
Posts: 1823
Joined: Tue Jun 21, 2011 8:25 am
Contact:

Re: MAME: Emulating FDC Boards

Postby tricky » Tue Aug 16, 2016 5:41 pm

Spoiler alert: I still can't get mame to load any .ssd files.

I did a bit of debugging in MAME and it seems the search path when using bbcb (B with 8271) for floppy based games is based on the data in "hash\\bbcb_flop.xml"

Code: Select all

<?xml version="1.0" encoding="UTF-8"?>
. . .
<software name="3dbombal">
  <description>3D Bomb Alley</description>
  <year>1983</year>
  <publisher>Software Invasion</publisher>
  <info name="notes" value="Original"/>
  <part name="flop1" interface="floppy_5_25">
    <dataarea name="flop" size="102400">
      <rom name="3dbomballey.ssd" size="102400" offset="0" sha1="d0f4716a376e4407492b4db7f87597bc07d7651f" crc="5a8deaff"/>
    </dataarea>
  </part>
</software>
. . .

    "roms\\3dbombal\\3dbomballey.ssd"
    "roms\\3dbombal.zip"
    "roms.zip"
    "roms\\3dbombal.7z"
    "roms.7z"
    "roms\\bbcb_flop\\3dbombal\\3dbomballey.ssd"
    "roms\\bbcb_flop\\3dbombal.zip"
    "roms\\bbcb_flop.zip"
    "roms.zip"
    "roms\\bbcb_flop\\3dbombal.7z"
    "roms\\bbcb_flop.7z"
    "roms.7z"
I haven't done much more exploring, but it would have been nice to have been able to put the .ssd images in the sth hierarchy in a bbc_flop folder, so they were separate from my other ROMs, still together, accessibly by all beeb variants and avoid the few images with the same name.
This feature is probably already available, but I didn't find it.

After trying all sorts of copying and zipping, I still couldn't get mame to load 3D bomb alley, even after manually creating the 3dbombal directory/zip (I can't think of a way to automate this without parsing the hash xml. DOH it's just the first 8 characters isn't it!)
Attachments
3dbombal.zip
zip attached incase I have done something stupid
(5.66 KiB) Downloaded 20 times

User avatar
Pernod
Posts: 938
Joined: Fri Jun 08, 2012 10:01 pm
Location: Croydon, UK

Re: MAME: Emulating FDC Boards

Postby Pernod » Tue Aug 16, 2016 6:16 pm

If you don't have the Software List items installed then simply navigate to your own sth collection in File Manager, or from command line:

Code: Select all

mame64 bbcb -flop1 "c:\sth\Aardvark\Zalaga.ssd"
- Nigel

BBC Model B, ATPL Sidewise, Acorn Speech, 2xWatford Floppy Drives, AMX Mouse, Viglen case, etc.

User avatar
tricky
Posts: 1823
Joined: Tue Jun 21, 2011 8:25 am
Contact:

Re: MAME: Emulating FDC Boards

Postby tricky » Tue Aug 16, 2016 10:28 pm

I do have there lists installed, or at least I think I do - I get a big list of games that then say they are missing.
I'll try the command line.

User avatar
tricky
Posts: 1823
Joined: Tue Jun 21, 2011 8:25 am
Contact:

Re: MAME: Emulating FDC Boards

Postby tricky » Thu Aug 18, 2016 6:39 pm

Thanks,
the command line works.

SteveF
Posts: 429
Joined: Fri Aug 28, 2015 8:34 pm

Re: MAME: Emulating FDC Boards

Postby SteveF » Sun Aug 21, 2016 2:51 pm

Pernod wrote:Anyone know of any other FDC boards/DFS ROMs that I haven't mentioned above?

There's very little information on it, but I don't think the one mentioned in the thread here viewtopic.php?f=3&t=10690&p=130618#p130395 is on your list...

User avatar
Pernod
Posts: 938
Joined: Fri Jun 08, 2012 10:01 pm
Location: Croydon, UK

Re: MAME: Emulating FDC Boards

Postby Pernod » Sun Aug 21, 2016 3:38 pm

Nice find, but without any technical details and a ROM I can't do anything with it.

Anyone here an expert on Watford boards? I've seen photos of the DDB3 board (Acorn 1770 compatible) in 1770 and 1772 variants. Similarly, I've seen photos of the DDB2 board (DDFS 1.53 and below) also with either 1770 or 1772. There was also a DDB board but the FDC had no markings and have no idea which DDFS it expected.
- Nigel

BBC Model B, ATPL Sidewise, Acorn Speech, 2xWatford Floppy Drives, AMX Mouse, Viglen case, etc.

User avatar
Pernod
Posts: 938
Joined: Fri Jun 08, 2012 10:01 pm
Location: Croydon, UK

Re: MAME: Emulating FDC Boards

Postby Pernod » Sun Aug 21, 2016 7:45 pm

Were the Acorn DNFS 1.21 and 1.22 official releases or user patched? The downloads for these at http://mdfs.net/System/ROMs/Filing/Disk/Acorn/ are broken.

Edit: Versions 1.21 and 1.22 were unofficially patched.
- Nigel

BBC Model B, ATPL Sidewise, Acorn Speech, 2xWatford Floppy Drives, AMX Mouse, Viglen case, etc.

User avatar
Pernod
Posts: 938
Joined: Fri Jun 08, 2012 10:01 pm
Location: Croydon, UK

Re: MAME: Emulating FDC Boards

Postby Pernod » Wed Sep 14, 2016 3:16 pm

I'm now wading through the various Solidisk DFS/DDFS/ADFS, what a mess! I've 22 variants of this buggy DFS, many of which are not obvious which issue of their board they are intended for. I have both Issue 1 and 2 boards emulated so am having to test each ROM in each configuration.
Anyone know if the letters in the version had any significance of were just part of the version number?
There seems to be 3 versions of DFS 2.1J, the first doesn't identify which issue it's intended for and the others specifically say Issue 1 or Issue 2, all very confusing!
- Nigel

BBC Model B, ATPL Sidewise, Acorn Speech, 2xWatford Floppy Drives, AMX Mouse, Viglen case, etc.

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

Re: MAME: Emulating FDC Boards

Postby Coeus » Wed Sep 14, 2016 5:19 pm

Do you know where to find the board issue number? Or can you work it out from the date? I have one of their 1770-based boards as shown:

20160914_170749_9748.jpg


Here is the start of the DFS ROM I have with it:

Code: Select all

00000000 - 00 00 00 4C FF A9 82 1A 01 44 46 53 20 32 2E 31 ...L.....DFS 2.1
00000010 - 20 28 31 37 37 30 29 20 00 41 00 28 43 29 20 53  (1770) .A.(C) S
00000020 - 4F 4C 49 44 49 53 4B 2C 20 62 79 20 4B 2E 54 2E OLIDISK, by K.T.
00000030 - 41 43 52 45 53 00 45 2E 21 42 4F 4F 54 0D 4C 2E ACRES.E.!BOOT.L.
00000040 - 21 42 4F 4F 54 0D A0 17 B9 5F 80 99 40 0D 88 10 !BOOT...._..@...
00000050 - F7 AD 74 10 8D 41 0D A5 F4 8D 4E 0D 4C 40 0D A9 ..t..A....N.L@..
00000060 - 00 85 F4 8D 30 FE AD 80 FE 4A B0 FA A9 00 85 F4 ....0....J......
00000070 - 8D 30 FE 4C 81 87 C0 17 B0 02 A0 17 60 48 98 18 .0.L........`H..
00000080 - 85 B1 9D F0 0D 69 01 48 A9 00 85 B0 A0 D4 91 B0 .....i.H........
00000090 - C8 91 B0 68 A8 68 60 C9 01 F0 DB C9 02 F0 DE C9 ...h.h`.........
000000A0 - 08 D0 03 4C 5F 82 20 28 83 C9 04 D0 06 20 8A 8B ...L_. (..... ..
000000B0 - 4C 96 89 C9 0A F0 17 C9 03 F0 35 C9 09 D0 D7 B1 L.........5.....
000000C0 - F2 20 82 8B C9 0D D0 E8 98 A0 02 4C E8 88 20 1A . .........L.. .
000000D0 - 83 A0 D5 B1 B0 10 BF A9 00 91 B0 A8 C0 C0 90 05 ................
000000E0 - B9 00 10 B0 03 B9 00 11 91 B0 88 D0 EF 4C 22 9E .............L".
000000F0 - 84 B3 A9 7A 20 F4 FF 8A 10 07 AD 9E 0D C9 41 D0 ...z .........A.
00000100 - 04 C9 32 D0 91 A5 B3 48 20 8A 83 44 46 53 20 32 ..2....H ..DFS 2
00000110 - 2E 31 20 28 31 37 37 30 29 20 0D 8D 90 17 A9 FF .1 (1770) ......
00000120 - 48 20 8A 83 44 6F 75 62 6C 65 A0 20 0D 8C A9 10 H ..Double. ....


and here is the start of the ADFS ROM:

Code: Select all

00000000 - 00 00 00 4C 41 80 82 15 00 53 54 4C 20 41 44 46 ...LA....STL ADF
00000010 - 53 00 32 2E 31 00 28 43 29 53 4F 4C 49 44 49 53 S.2.1.(C)SOLIDIS
00000020 - 4B 31 31 2F 31 30 2F 38 35 77 72 69 74 74 65 6E K11/10/85written
00000030 - 20 62 79 20 4B 2E 54 2E 41 43 52 45 53 00 6C 1E  by K.T.ACRES.l.
00000040 - 02 C9 01 D0 2A 48 84 AE 20 44 B0 A6 F4 C9 0A 90 ....*H.. D......
00000050 - 12 A9 00 9D A2 02 9D A1 02 A9 E9 C0 17 D0 04 A0 ................
00000060 - 0E D0 0A 18 69 17 C5 AE B0 02 A5 AE A8 68 60 C9 ....i........h`.
00000070 - 02 F0 1B C9 08 D0 03 4C 81 B0 20 7C 94 C9 04 F0 .......L.. |....
00000080 - 3F C9 09 F0 2A C9 03 F0 53 C9 12 F0 46 60 98 9D ?...*...S...F`..
00000090 - F0 0D 48 20 7D 83 B1 B4 C5 F4 D0 0B 20 79 82 CD ..H }....... y..
000000A0 - 99 10 D0 03 20 48 82 A6 F4 68 A8 C8 A9 02 60 B1 .... H...h....`.
000000B0 - F2 C9 0D F0 06 A2 3C A9 BF D0 09 A0 00 4C E7 94 ......<......L..
000000C0 - A2 2C A9 BF 86 AE 85 AF 4C 70 95 A9 43 D0 02 A9 .,......Lp..C...
000000D0 - FF D0 05 C0 08 D0 D7 98 48 48 D0 5C 98 48 20 71 ........HH.\.H q
000000E0 - B0 E8 D0 0E AD 9E 0D C9 44 F0 1D AD 8D 02 F0 1D ........D.......
000000F0 - A2 44 CA 8A E0 79 F0 15 E0 27 F0 11 E0 19 F0 0D .D...y...'......
00000100 - E0 41 F0 09 E0 43 F0 02 68 60 68 8A 48 58 8A 48 .A...C..h`h.HX.H
00000110 - AD 8D 02 F0 03 20 20 83 A9 41 8D 9E 0D 20 BA 94 .....  ..A... ..
00000120 - 53 54 4C 20 41 44 46 53 20 A8 AC 98 0D C8 98 20 STL ADFS ......


and here is what they look like with *HELP:

20160821_174237_9586.jpg


So hopefully that is one working combination.

As far as the large number of version goes you've reminded me that on at least one occasion I called their technical support because of a bug in one or the other of the ROMs and as a result received a replacement EPROM in the post a few days later. From a customer experience point of view that is good, second only to not having had to report the bug in the first place, but it may mean that a new version of the ROM was released "into the wild" with each bug fix made in response to each customer report whereas the visible version numbers may be driven instead by planned change, i.e. extra features or revisions to the FDC board.

You've also got me wondering - just how different are the various 1770-based boards? Aren't most going to end up very similar?

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

Re: MAME: Emulating FDC Boards

Postby Coeus » Thu Sep 15, 2016 3:52 am

So what have you discovered so far?

Reading the two ROMS I have to go with my board, the one I posted a photo of, and running them under b-em I can see they expect the WD1770 to be mapped at FE80-FE83 and the latch in the FE84-FE87 space. By comparison the DFS 2.2 J and M versions and ADFS 2.1 D and M versions expect these the other way round with the latch at FE80 and the 1770 at FE84-FE87 which appears to match the way the way Acorn configured the 1770 in the non-master machines. Certainly these versions work with B-EM's 1770 emulation as supplied, intended for the Acorn DFS/ADFS.

User avatar
Pernod
Posts: 938
Joined: Fri Jun 08, 2012 10:01 pm
Location: Croydon, UK

Re: MAME: Emulating FDC Boards

Postby Pernod » Thu Sep 15, 2016 11:01 am

Your board is an issue 1, simply by the date being 1984 which precedes Acorn defining their 1770 implementation in '85.

The issue 1 control register/latch is at &FE86 and is as follows:
bit 0: drive select 0 = drive 0, 1 = drive 1
bit 1: side select
bit 2: density
Acorn also had a bit for master reset but haven't been able to determine whether Solidisk implemented this yet, your photo seems to show it's not connected.

Since you have an issue 1 board could you let me know if INTRQ on pin 28 of the 1770 is connected to anything? Your photo suggests not but also looks like DRQ is not connected either, can you confirm? The INTRQ is connected to NMI on issue 2 boards, but causes data corruption under my issue 1 emulation.

I also don't seem to have some of the ADFS versions you refer to so could you upload them, thanks.
- Nigel

BBC Model B, ATPL Sidewise, Acorn Speech, 2xWatford Floppy Drives, AMX Mouse, Viglen case, etc.

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

Re: MAME: Emulating FDC Boards

Postby Coeus » Thu Sep 15, 2016 5:08 pm

From checking with a multimeter INTRQ is not connected and DRQ is connected to pin 11 of the 8271 socket which the 8271 has as INT - I assume this maps to the 6502 NMI line.

The master reset line of the 1770 is also not connected. I think this explains some odd behaviour I have seen where if I issue a command that attempts to access a floppy and starts the motor but there is none in the drive and the door is open, even pressing break or ctrl-break does not turn the motor off. The only thing that will turn the motor off is to turn off the power for a few seconds.

I also found this website, http://www.adsb.co.uk/bbc/disk_controllers/, which has circuit diagrams and some other details. I was looking at the diagram for the issue 1 board and wondered what the "aux" port was but then I noticed a set of five holes at the north west of the board next to the word DDFS which enables other equipment to be connected to the outputs of the five unused latch outputs.

I attach the two ROMs I have with my issue 1 board in case these are yet another variation. The roms I referred to that work with the issue 2, Acorn compatible, board are from http://mdfs.net/System/ROMs/Filing/Disk/Solidisk/. In particular:


I was also interested to note that the issue 1 board does not have any chip on it that looks like it would be doing address decoding. From the circuit diagram it looks like there is some decoding using the line NOT(FDC & A2) which determines if the 8x register/latch is written to but it seems like this is not fed to the 1770. I think that means the 1770 also responds in parallel to the latch for the addresses FE84-FE87. For reads this means this address range will read the 1770 registers and write will set both the 1770 register and the latch. This explains the choice of &FE86 as the address the software uses to write to the latch as that way it would only be overwriting the 1770's sector register which is probably about to get changed anyway. &FE84 is not used to write to the latch as this would issue a command to the 1770. I am not sure how much practical value this level of detail is but it certainly means, from a software perspective, one should always set drive/side/density first and then set track/sector and finally issue the command.

HTH,
Steve.
Attachments
stl.zip
(24.4 KiB) Downloaded 21 times

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

Re: MAME: Emulating FDC Boards

Postby Coeus » Fri Sep 16, 2016 12:26 pm

Well done, BTW in picking up the interrupt line as something critical. Prior to that I had a brief go at modifying the wd1770 module in B-Em to emulate the STL board by updating the addresses but it didn't work properly. Removing the NMI on command completion makes all the difference and now it seems to work fine.

User avatar
Pernod
Posts: 938
Joined: Fri Jun 08, 2012 10:01 pm
Location: Croydon, UK

Re: MAME: Emulating FDC Boards

Postby Pernod » Fri Sep 16, 2016 2:36 pm

The Opus DDOS boards also don't have INTRQ connected, though DDOS doesn't mind but EDOS does. With what I've learnt from this it should be fairly trivial to add any board to B-em.

I'm still at a loss with BS-DOS 2.22 http://mdfs.net/System/ROMs/Filing/Disk/Others/BS-DOS222, also have 2.19. It's clearly intended for the 8271 but am now suspecting it's not intended to read any Acorn format. There's zero information on this, though maybe produced by Business Systems, anyone have any clues?

Also still looking out for Kenda Professional http://acorn.huininga.nl/pub/magazines/Beebug/BeebUG%20Volume%2002%20Number%2008%20Jan-Feb%201984.pdf, see page 10. No sign of ROM or technical info.
- Nigel

BBC Model B, ATPL Sidewise, Acorn Speech, 2xWatford Floppy Drives, AMX Mouse, Viglen case, etc.

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

Re: MAME: Emulating FDC Boards

Postby Coeus » Fri Sep 16, 2016 4:33 pm

Pernod wrote:...I'm still at a loss with BS-DOS 2.22 http://mdfs.net/System/ROMs/Filing/Disk/Others/BS-DOS222, also have 2.19...


Does that mean you have all the info you need on the STL boards?

Pernod wrote:..It's clearly intended for the 8271 but am now suspecting it's not intended to read any Acorn format. There's zero information on this, though maybe produced by Business Systems, anyone have any clues?


CP/M format, perhaps, so as to compatible with CP/M on a Z80 co-processor? On the 8271 data sheet there is also mention of an IBM format I had never heard of but may have been a defacto standard of the day.

If it uses the 8271 presumably it would have used the hardware as designed by Acorn. Does the ROM have a formatter in? Could you run it in an emulator, tell it to format a disk and then inspect the disc to see if you recognise the format?

User avatar
sweh
Posts: 1833
Joined: Sat Mar 10, 2012 12:05 pm
Location: New York, New York
Contact:

Re: MAME: Emulating FDC Boards

Postby sweh » Fri Sep 16, 2016 8:03 pm

Pernod wrote:The Opus DDOS boards also don't have INTRQ connected, though DDOS doesn't mind but EDOS does. With what I've learnt from this it should be fairly trivial to add any board to B-em.

IIRC, the main difference between the Opus DDOS board and the STL DDFS board was the density select bit (I think it was that one) at &FE86 was different. I was able to hack the DDOS ROM to work on my STL board with a JSR and a small routine that fitted at the end of the ROM.

Code: Select all

B625 A5 CF    ..    LDA &CF
B627 29 03    ).    AND #&03
B629 20 80 BF  ..   JSR &BF80
B62C 29 7F    ).    AND #&7F
B62E 8D 86 FE ...   STA &FE86
B631 60       `     RTS



BF80 AD E3 10 ...   LDA &10E3
BF83 29 7F    ).    AND #&7F
BF85 D0 04    ..    BNE &BF8B
BF87 A9 04    ..    LDA #&04
BF89 D0 02    ..    BNE &BF8D
BF8B A9 00    ..    LDA #&00
BF8D 05 CF    ..    ORA &CF
BF8F 60       `     RTS
Rgds
Stephen

User avatar
Pernod
Posts: 938
Joined: Fri Jun 08, 2012 10:01 pm
Location: Croydon, UK

Re: MAME: Emulating FDC Boards

Postby Pernod » Fri Sep 16, 2016 8:10 pm

sweh wrote:IIRC, the main difference between the Opus DDOS board and the STL DDFS board was the density select bit (I think it was that one) at &FE86 was different. I was able to hack the DDOS ROM to work on my STL board with a JSR and a small routine that fitted at the end of the ROM.

Correct, Opus writes to &FE84 whereas STL is &FE86, and the density is selected with bit 6 for Opus and bit 2 for STL. Bits 0 and 1 for drive and side select are the same on both boards.
- Nigel

BBC Model B, ATPL Sidewise, Acorn Speech, 2xWatford Floppy Drives, AMX Mouse, Viglen case, etc.

User avatar
sweh
Posts: 1833
Joined: Sat Mar 10, 2012 12:05 pm
Location: New York, New York
Contact:

Re: MAME: Emulating FDC Boards

Postby sweh » Fri Sep 16, 2016 8:17 pm

Coeus wrote:If it uses the 8271 presumably it would have used the hardware as designed by Acorn. Does the ROM have a formatter in? Could you run it in an emulator, tell it to format a disk and then inspect the disc to see if you recognise the format?

I just tried to use it format an SSD in BeebEm using a model B with 8271; it gave errors and didn't write anything. So it doesn't seem to be totally Acorn compatible.
Rgds
Stephen

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

Re: MAME: Emulating FDC Boards

Postby Coeus » Fri Sep 16, 2016 9:01 pm

Pernod wrote:
sweh wrote:IIRC, the main difference between the Opus DDOS board and the STL DDFS board was the density select bit (I think it was that one) at &FE86 was different. I was able to hack the DDOS ROM to work on my STL board with a JSR and a small routine that fitted at the end of the ROM.

Correct, Opus writes to &FE84 whereas STL is &FE86, and the density is selected with bit 6 for Opus and bit 2 for STL. Bits 0 and 1 for drive and side select are the same on both boards.


But bear in mind what I said earlier. On the STL board the CLK input of the latch takes a signal which includes A2 whereas it appears the 1770 does not. if I am right that means whereas the latch will only appear at FE84-FE87 the 1170 will also be mapped in that region as well as it's proper place of FE80-FE83. I think that's why the STL ROMs write to that latch at FE86 rather than the more obvious FE84 - to avoid sending a command to the 1770 at the same time!

If the Opus ROM is writing to FE84 that suggests more thorough address decoding on the Opus board so probably at least one more chip on the board?

Do I take it the benefit of hacking the DDOS ROM to work with the STL board is a more reliable DFS than the STL version or are there interesting features?

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

Re: MAME: Emulating FDC Boards

Postby Coeus » Tue Oct 04, 2016 7:47 am

So as I have the Solidisk 1770 FDC board I thought I'd add support for it to B-Em. This turned out to be reasonably straightforward given the previous discussion.

As the Opus board is similar I thought I add support for that too. This turned out to be a little more complicated because the Opus DDOS uses the multi-sector commands which weren not implemented. Adding those and it worked so then I thought "I may as well do the Watford too" but this turned out to be a bit of a headache.

I think I have cracked it in the end, though. The Watford board relies on the NMI on command completion and also uses the mult-sector commands expecting to be able to issue a force interrupt command when it has read enough data. The snag was that it issues this from the data-reading NMI routine but then expects to have time to swap to a status-reading NMI routine before the completion NMI happens. Failure to delay the interrupt for long enough results in the Watford DFS corrupting the sector it has just read and some bizarre output.

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

Re: MAME: Emulating FDC Boards

Postby tom_seddon » Wed Mar 08, 2017 3:22 am

I happened to find this thread while looking for something else, and thought I'd add to it, since I've been working on my emulator again recently and have been looking at 1770 stuff lately.

After receiving the last byte of interest, DDFS waits for ~240usec before cancelling the command. So it'll get more data than it bargained for if you emulate a multi-sector read by sending all the bytes in a stream, one after the other, going straight from one sector to the next. (Looks like b-em does this when reading from SSD files? - and it's what my emulator did originally too, as it's the obvious thing when supporting sector dump-type disc images.)

What I did to fix this was add a pre-sector delay to the 1770 code: when doing a sector read, including when reading a sector as part of a multi-sector read, wait 300+ microseconds before delivering the first byte. I don't have a good feel for how the FDC might operate internally, so I've no idea how realistic this delay might be, but 300 microseconds corresponds to something like 2-3 bytes... and presumably the controller will have to read at least that many just to check the sector IDs... right???

This still doesn't really explain the delay before issuing the Force Interrupt command, though, so I'm suspicious that there's something I'm missing, and/or there's something else I'm still not doing properly.

Maybe I need to spend some quality time with the MAME source...

--Tom

P.S. regarding Opus and INTRQ: based on watching the code at work, the Challenger 1770 also looks to have INTRQ disconnected.

P.P.S. my notes about the Watford NMI code that does the delay:

Code: Select all

// Watford DDFS reads by initiating a multi-sector read,
// counting sectors read, then doing this when it's got
// the data it wants:
//
// <pre>
// 0D43: ldy #$60                A=00 X=FF Y=60 S=DC P=nvdIzC (D=60)
// 0D45: dey                     A=00 X=FF Y=5F S=DC P=nvdIzC (D=D0)
// 0D46: bne $0D45               A=00 X=FF Y=5F S=DC P=nvdIzC (D=01)
// 0D48: lda #$D0                A=D0 X=FF Y=00 S=DC P=NvdIzC (D=D0)
// 0D4A: sta $FE84               A=D0 X=FF Y=00 S=DC P=NvdIzC (D=D0)
// </pre>
//
// The loop at D43 is $5f*(2+3)+(2+2)=$1df=479 cycles, or
// 240 usec.
//
// So delay a bit more than that between sectors.

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

Re: MAME: Emulating FDC Boards

Postby Coeus » Wed Mar 08, 2017 9:20 pm

Interesting as I had not looked into that delay loop. I did get the Watford DDFS to work:

Screenshot from 2017-03-08 21-03-32.png


As I said above, the critical thing I found was that the NMI that confirms completion of the Force Interrupt (0xd) command must not be delivered too early because the DDFS still has its data-receiving NMI routine in place at that point so an NMI causes it to read the data register which the emulator will respond to by fetching the first byte of the next sector and returning it. So in the new B-em code this works by waiting a number of ticks before issuing the NMI.

I found a suitable timing by experimentation which 1000 * 2Mhz/16.

What I hope will be the new B-em 1770 code is here: https://github.com/SteveFosdick/b-em/bl ... c/wd1770.c

This isn't mainstream yet but hopefully will be soon.

SarahWalker
Posts: 1038
Joined: Fri Jan 14, 2005 3:56 pm
Contact:

Re: MAME: Emulating FDC Boards

Postby SarahWalker » Wed Mar 08, 2017 9:25 pm

tom_seddon wrote:This still doesn't really explain the delay before issuing the Force Interrupt command, though, so I'm suspicious that there's something I'm missing, and/or there's something else I'm still not doing properly.

I would guess it's giving time for the FDC to read and check the CRC before cancelling the command.

The inter-sector gap should be on the order of 60 bytes I think, btw.

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

Re: MAME: Emulating FDC Boards

Postby tom_seddon » Thu Mar 09, 2017 1:21 am

SarahWalker wrote:I would guess it's giving time for the FDC to read and check the CRC before cancelling the command.

The inter-sector gap should be on the order of 60 bytes I think, btw.

Right, yes, good point about the CRC - that makes sense. And a sector gap of 60 bytes certainly sounds a lot more plausible than just 2 ;)

Though interestingly, if this delay is there to give the FDC time to do something, DDFS doesn't actually do anything with the result, whatever it might be, since it sets its copy of the status register to 0 before doing the delay and then never checks again. I did wonder whether maybe it's waiting for the sector register to update, but it's doesn't appear to read that either...

While waiting for the command to complete, the DDFS runs a loop in the ROM, checking a copy of the FDC's status register at $1036:

Code: Select all

83E7: lda $1036 ; get RAM copy of FDC status
83EA: lsr A ; put FDC busy bit in carry
83EB: bcs $83E7 ; taken if FDC busy

The NMI routine for reading data starts like this:

Code: Select all

0D00: sta $CC           
0D02: sty $CD           
0D04: lda $FE84 ; FDC status register
0D07: sta $1036 ; save RAM copy
0D0A: and #$5C ; %01011100 - WP, RNF, CRC, LOST
0D0C: bne $0D12 ; taken if there was a problem
0D0E: lda $FE87 ; FDC data register
<save byte in memory, inc dest address, check byte count, etc.>

Then once it's read the last byte, just before the delay loop, it does this, setting $1036 to 0:

Code: Select all

0D3E: lda #$00
0D40: sta $1036

So the loop in the ROM breaks out and it carries on. But the code then never checks the FDC again. So the status is always 0, as far as it's concerned.

--Tom
Last edited by tom_seddon on Thu Mar 09, 2017 1:30 am, edited 1 time in total.

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

Re: MAME: Emulating FDC Boards

Postby tom_seddon » Thu Mar 09, 2017 1:27 am

Coeus wrote:As I said above, the critical thing I found was that the NMI that confirms completion of the Force Interrupt (0xd) command must not be delivered too early...

What I hope will be the new B-em 1770 code is here: https://github.com/SteveFosdick/b-em/bl ... c/wd1770.c



DDFS cancels using a $d0 command, which issues no interrupt (http://www.zimmers.net/anonftp/pub/cbm/ ... 177x16.gif) - there should be no NMI in that case.

I've got a note from my old emulator that says the Superior Collection uses command $d4 (INTRQ on next index hole - so up to 0.5sec if the motor is on, I suppose), but I don't recall to what end. Doesn't look like I ever found a need for $d8.

--Tom

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

Re: MAME: Emulating FDC Boards

Postby Coeus » Thu Mar 09, 2017 10:32 pm

tom_seddon wrote:DDFS cancels using a $d0 command, which issues no interrupt (http://www.zimmers.net/anonftp/pub/cbm/ ... 177x16.gif) - there should be no NMI in that case.


But if I don't generate an NMI after the Force Interrupt completes DDFS doesn't seem to see the operation as complete. My test was simply to issue a *. command. With the NMI enabled I get the catalogue. Without it, it hangs. The last few lines in the log are:

Code: Select all

wd1770: continue multiple read sector drive=0 side=0 track=0 sector=4 dens=0
sdf: seeking to 1024 bytes
wd1770: write to watford WD1770 board: fe84=d0, pc=0d4d
wd1770: force interrupt
wd1770: FDC callback D0


so according to that DDFS is making no further access to the FDC after issuing the D0 command. Doing an intruction trace sees it sitting a status loop similar to the one you had already spotted, though at a different ROM address*:

Code: Select all

83D9: AD 36 10 LDA 1036     41 FF 11 DF      C
83DC: 4A       LSR A        83 FF 11 DF N    C
83DD: B0 FA    BCS 83D9     41 FF 11 DF      C
83D9: AD 36 10 LDA 1036     41 FF 11 DF      C
83DC: 4A       LSR A        83 FF 11 DF N    C
83DD: B0 FA    BCS 83D9     41 FF 11 DF      C
83D9: AD 36 10 LDA 1036     41 FF 11 DF      C
83DC: 4A       LSR A        83 FF 11 DF N    C


So it seems DFS is waiting for a NMI at this point because the NMI routine is the one that reads the status register and updates the RAM copy. Here's running through the D0 command onwards in the debugger:

Code: Select all

D9CD: A9 40    LDA #40       >break 0d48
    Breakpoint 0 set to 0D48
D9CD: A9 40    LDA #40       >c
    Break at 0D48
0D48: A9 D0    LDA #D0       >s
0D4A: 8D 84 FE STA FE84      >s
0D4D: D0 EA    BNE 0D39      >s
0D39: A5 CC    LDA CC        >s
0D3B: A4 CD    LDY CD        >s
0D3D: 40       RTI           >s
83DD: B0 FA    BCS 83D9      >s
83D9: AD 36 10 LDA 1036      >s
83DC: 4A       LSR A         >s
83DD: B0 FA    BCS 83D9      >s
83D9: AD 36 10 LDA 1036      >s
83DC: 4A       LSR A         >s
83DD: B0 FA    BCS 83D9      >s


This shows the NMI routine issuing the D0 command and then RTI is returning to the busy wait loop in the ROM that is waiting for RAM copy of the status register to indicate the FDC is no longer busy. The only way that can happen is if another NMI occurs.

Reading the datasheet suggests that DRQ may be asserted to indicate the status register is ready for reading in the same way as when a data byte is ready and presumably at hardware level this shares the name NMI as the INTRQ line.

* this maybe another copy of the loop or maybe it is different version of DDFS? I have version 1.53


Return to “emulators”

Who is online

Users browsing this forum: Bing [Bot] and 4 guests