wd33c93 emulation debugging

[Toni Wilen]

[Moved from MMU thread]

Originally Posted by mark_k

Could the files /usr/sys/amiga/alien/a2091.c and /usr/sys/amiga/alien/a3091.c in the AMIX kernel configuration package (conf.cpio) be of any help there?

Interesting source stuff..

Anyway, problem is SCSI phase numbers. I haven't found documentation that describes exactly how scsi phases work, most of the stuff in emulation is guesses only.

This driver apparently checks SCSI phase value returned by SCSI chip and simply hangs if value is not any of expected values. (I guess this also explains guru rom problem, some phase value is wrong)

I'll try testing the MMULib tools when booting from a clean floppy disk and report back.

Hopefully it is a real emulation bug and not some buggy software

[alexh]

The only SCSI book I have has a very small section which you've probably already seen :

SCSI COMMAND PHASES
Individual commands execute in subsequent parts called phases. Some phases are set by the Initiator, some by the Target. Following is a list of all 8 SCSI command phases:

1. arbitration
2. selection
3. message
4. reselection
5. command
6. data
7. status
8. bus free

The SCSI specification allows execution of command phases in any order, with the exception that each command must start with arbitration and selection. In practice however, we will see SCSI commands executing in phases as though in a certain predefined sequence. Some phases are missing in some commands, but the general sequence is always the same; it is usually:

1. arbitration
2. selection (with Attention)
3. message out
4. command data in/out
5. status
6. message in

This is a link to the SCSI Phase section of the SCSI-II specification with diagrams

http://www.staff.uni-mainz.de/tacke/scsi/SCSI2-06.html

I appreciate that this information is widely available and what you're probably after is how the WD chip actually works.

[Toni Wilen]

Originally Posted by alexh

The only SCSI book I have has a very small section which you've probably already seen :

I have seen similar documents but they never show any real world examples.

[Toni Wilen]

WD SCSI chip documentation seems to miss some information..

It says about "Select and Transfer" command that command phase 0x60 = Command completed but other SCSI phase document says (for example http://challenge.nvg.ntnu.no/sgistuf...csi-errors.txt)

ST_SATOK 0x16 Select-And-Transfer completed successfully
that is, all phases have completed in a
normal manner

but it also says

PH_COMPLETE 0x60 Command complete message received;
SCSI command is finished, and SCSI bus
is free.

Amix driver expects 0x16, not 0x60. Could someone explain the difference? WD documentation does not even mention phase code 0x16..

[mark_k]

I assume you have the 66-page WD33C93 datasheet (PDF available from http://www.datasheetcatalog.org/data.../501413_DS.pdf)?

From that, the PH_xxx values are what appear in the command phase register (address 10 hex). The ST_xxx values are put in the SCSI status register (address 17 hex). That's from pages 17-18 of the PDF.

There's also a WD33C93B data sheet (better quality than the other one) at http://bitsavers.informatik.uni-stut...3_WD33C93B.pdf
And WD33C93A: http://bitsavers.informatik.uni-stut...oller_1991.pdf

[Toni Wilen]

From that, the PH_xxx values are what appear in the command phase register (address 10 hex). The ST_xxx values are put in the SCSI status register (address 17 hex).

That explains the problem perfectly

After some tweaks (+implemented SCSI statefile support) I got slightly farther..

[Toni Wilen]

Documentation says: "After the Command phase, the 33C93B anticipates a Data phase if the TRANSFER COUNT register contains a non-zero value, a Status phase if this register contains zero,"

This actually means Select-and-Transfer command jumps directly to Status phase if TRANSFER COUNT = 0, skipping whole Command phase!

This is what A590 driver assumes. Funnily enough it seems A590 driver developer did it wrong but got lucky, code sets phase to $46 (which does nothing because Select-and-Transfer only writes to phase register, it does not care what it contains at the start of command) and code also does not clear transfer count (It was cleared by previous transfer).

This A590 (now weird looking) driver behavior really confused me because I of course assumed setting phase to $46 must mean something. It does absolutely nothing with Select-and-Transfer... TC == 0 was the important information.

Amix now detects partitions but partitioning fails with bus errors (and unfortunately they are real bus errors, some pointer has become null)

Whats the original A3000UX HD size? Perhaps it hates too small or too big drives?

[alexh]

Originally Posted by Toni Wilen

Whats the original A3000UX HD size? Perhaps it hates too small or too big drives?

200MBytes

[dlfrsilver]

the w33c93 is used on the capcom CPS-3 system. maybe there is info in the mame driver about this device ?

[Toni Wilen]

It seems only A590/A2091 and Guru ROM drivers do something weird with WD33C93.

All other drivers seem to use standard Select-and-Transfer command that does everything (select the drive, send command, send/receive data, disconnect) automatically.

Weird drivers seem to do part of the SCSI protocol using lower level SCSI commands and then some other part(s) with high level commands (like Select-and-Transfer with zero transfer count).

btw, I was wrong, Select-and-Transfer ignores scsi phase only if it started with non-zero transfer count. If transfer count = 0, it will check scsi phase number and jump to specific processing phase depending on scsi phase number. This is not fully documented in WD33C93 documentation.

EDIT: I was even more wrong, scsi phase number is only ignored (starts from beginning) if unit is not currently selected. If already selected = continue from current scsi phase.

[mark_k]

What with the new MMU support and improved A2091 emulation, I thought I'd try installing NetBSD 6.0.1 (using the 2013-01-02 winuae.exe).

I partitioned a hardfile and copied the miniroot.fs to it. On booting from that NetBSD repeatedly reports:
sbicwait TIMEO @1570 with asr=x0 csr=x1f

See attached pic. WinUAE config and hardfile attached too.

[Toni Wilen]

Originally Posted by mark_k

What with the new MMU support and improved A2091 emulation, I thought I'd try installing NetBSD 6.0.1 (using the 2013-01-02 winuae.exe).

Timeout fixed but now it does something really weird.

Does it really work with real hardware? It tries to send SCSI command to the drive with WD DMA mode but without programming DMAC for DMA operation. Normally commands are always send in PIO because DMA only makes sense with larger transfers.

EDIT: Wait a moment, perhaps it enables DMA after starting the command..

EDIT2: No, it does not still make any sense. It still uses CPU writes while WD is in DMA mode.. This can't be right.

[mark_k]

I haven't tested it on real hardware, but would assume it does work.

You can browse the source at http://cvsweb.netbsd.org/bsdweb.cgi/..._with_tag=MAIN. Scroll down and click wd33c93.c then click Download. Maybe that could help figure what the NetBSD devs are trying to do?

Edit: A better browse interface (e.g. with links to function definitions) would be here: http://fxr.watson.org/fxr/source/dev...v=NETBSD;im=10.

[Toni Wilen]

Yes but as usual it isn't that simple and assumptions are bad idea. There is also similar looking driver under amiga (arch/amiga/dev/sbic.c)...

[mark_k]

Yes on second thoughts (bearing in mind the "atzsc0" text in the screenshot), probably these files are relevant:
arch/amiga/dev/atzsc.c
arch/amiga/dev/atzscreg.h
arch/amiga/dev/sbic.c
arch/amiga/dev/sbicreg.h
arch/amiga/dev/sbicvar.h

[Toni Wilen]

All your links point to same file

I don't see anything obvious but perhaps it gets confused because not all scsi messages are generated during processing (like save pointers). I am still not familiar enough with SCSI stuff. It is soooo complex. (Guru ROM also seems to require this stuff)

[jbenam]

Strim (member here on EAB) is the one who handles the NetBSD Amiga port, so if you've got any questions, Toni, he should be your man

[strim]

Hi guys.

I can't really comment on the problem you are seeing here. I don't know if A2091 driver still works, however I'm sure that A3000 driver does - I've tested it few months ago and I know of many users that installed 6.x on their A3000s. Both A2091 (atzsc) and A3000 (ahsc) use Amiga-specific 33C93 driver (sbic - SCSI phases are handled there). Differences between atzsc and ahsc are small, so I would expect that atzsc still works on a real hardware.

I have to admit, that I don't really understand how this driver works . It doesn't use any modern kernel abstraction layers. It was written almost 20 years ago and didn't change much in last 10 years. Perhaps, there are old time developers still lurking on port-amiga .at. netbsd.org list. Asking there might be useful.

I can prepare NetBSD kernel with DEBUG enabled for sbic driver if that helps.

Btw. I also remember that Michael van Elst (of bustest fame) has his own UAE version for NetBSD testing (source). AFAIR it doesn't support SCSI, but might be interesting because of MMU and VNC code.

[mark_k]

Testing with the 2013-01-04 18:50 winuae.exe, output for A2091 and A3000 emulation is similar. The output with emulated A2091 has an additional "sbic_save_ptrs: asr 21 canceled!" line. WinUAE A3000 config file attached.

[Toni Wilen]

Originally Posted by strim

I can prepare NetBSD kernel with DEBUG enabled for sbic driver if that helps.

That would be great.

ADDED: Log from working A3000 boot phase would be nice too for comparison purposes. (I'll try to do one, different drives may use different scsi features)

Btw. I also remember that Michael van Elst (of bustest fame) has his own UAE version for NetBSD testing (source). AFAIR it doesn't support SCSI, but might be interesting because of MMU and VNC code.

AFAIK that wasn't using real MMU emulation. NetBSD most likely works fine when using IDE emulation but we are trying to improve SCSI emulation