Masoboshi Mastercard reverse-engineering (was: crashes WinUAE)

[Toni Wilen]

Thanks, I missed that part where IO_ACTUAL is "adjusted".

It has nothing to do with sync mode but 16-byte FIFO. (Sync mode register is write only, read returns number of bytes in FIFO)

Weird driver, it writes 16 bytes too much, then after the transfer ends, it checks if FIFO still has data (16 bytes), it empties it with dummy reads. This only works if status register contents are exactly right.

NCR5394 (and clones) emulation is getting more complex and complex..

[Toni Wilen]

Should finally work now..

[mark_k]

Not quite (yet).

Booting my 20MB HDF (which boots fine connected to IDE), it gets to Workbench then when something attempts a write (I assume) I get error requesters:
Part0
has a checksum, error
on disk block 25140
and
MASOBOSHI.device
Program failed (error #80000003).
Wait for disk activity to finish.

Last few lines of log output:
-> DATAOUT=4608 ST=0 SENSELEN=0 REPLYLEN=0
SCSIEMU HD 0: 0A.00.51.00.01.00.00.00.00.00.00.00 CMDLEN=6 DATA=0FBD9728
-> DATAOUT=512 ST=0 SENSELEN=0 REPLYLEN=0
SCSIEMU HD 0: 08.00.64.34.09.00.00.00.00.00.00.00 CMDLEN=6 DATA=0FBD9728
-> DATAOUT=4608 ST=0 SENSELEN=0 REPLYLEN=0
Exception 3 (2011 20579a) at 20579a -> f80ad0!

(I think the HDF must have had the write cache enabled, hence all reads seem to be for 9 sectors.)

[Toni Wilen]

Finally working part 2. (extra write bytes caused next read to think read buffer was valid too early)

EDIT:

Step 2: How to force DMA mode?

Not guaranteed this change will be included with final 3.5. Masoboshi fix needed non-trivial 5394 changes..

[mark_k]

Originally Posted by Toni Wilen

Step 2: How to force DMA mode?

See my post above? But if that doesn't seem to work I could perhaps provide a patched ROM with always forces DMA.

But if there's something wrong with the current DMA emulation, could it be that the driver detects an error condition and falls back to non-DMA?

[Toni Wilen]

I used installer to set only DMA checkbox. It still wants to use "fake" DMA after speed test.

Confusing driver code is so annoying to follow.. Perhaps it has some extra test or something else weird somewhere.

[mark_k]

A couple of code chunks:

lbC0005B6	TST.B	(UseSCSIDMAFlag?-DataArea,A5)
	BNE.W	lbC000856

	TST.B	(ScsiDrivePresentBits-DataArea,A5)
	BNE.B	.AtLeastOneScsiDrivePresent

	TST.B	(IDEDriveDMAEnabledBits?-DataArea,A5)
	BNE.W	lbC000856

.AtLeastOneScsiDrivePresent
	MOVEA.L	(_SysBase-DataArea,A5),A6
	MOVE.W	#INTF_INTEN,(_custom+intena).L
	ADDQ.B	#1,(IDNestCnt,A6)

	LEA	(_ciab+ciatodlow).L,A1	;$BFD800
	MOVEQ	#0,D6
	MOVEQ	#0,D7
	MOVE.B	($200,A1),D6	;Read ciabtodhi ($BFDA00)
	SWAP	D6
	MOVE.B	($100,A1),D6	;Read ciabtodmid ($BFD900)
	ASL.W	#8,D6

This chunk checks the "use DMA" bit in RDSK "MaCa" flags byte:

.Continue4	BTST	#0,D3	;DMA
	BEQ.B	.NoDMA

	CMPI.W	#7,D0	;Unit 8 or 9 = IDE
	BGT.B	.EnableIDEDMA

	CLR.L	(LowSpeedMemoryRegionFlags-DataArea,A6)
	ST	(UseSCSIDMAFlag?-DataArea,A6)
	BRA.B	.Return

.EnableIDEDMA	MOVE.W	(IDEDriveDMAEnabledBits?-DataArea,A6),D1
	BSET	D0,D1
	BRA.B	lbC001234

.NoDMA	CMPI.W	#7,D0	;Unit 0 to 7 = SCSI
	BLE.B	.Return

	MOVE.W	(IDEDriveDMAEnabledBits?-DataArea,A6),D1
	BCLR	D0,D1
lbC001234	MOVE.W	D1,(IDEDriveDMAEnabledBits?-DataArea,A6)
.Return	MOVEM.L	(SP)+,D1-D4/A1
	MOVEQ	#0,D0
	RTS

So the RDSK DMA-enable bit seems to apply to both IDE and SCSI. But for SCSI drives (unit 0 to 7) the second code chunk just sets "UseSCSIDMAFlag?" to $FF and clears "LowSpeedMemoryRegionFlags". So the DMA setting can be changed per-IDE drive, but applies to all SCSI drives.

Maybe I've got the sense of the flags the wrong way though? That is, could what I call "UseSCSIDMAFlag?" really be "DisableSCSIDMAFlag"??? And similarly for the IDE DMA flags.

[Toni Wilen]

Only DMA and Schnelle ubertragung ticked: "Maca" value in RDB is 0x10.

German manual lists these:

#define MCB_DMAOFF 0
#define MCB_TRANSFERSLOW l
#define MCB_PARITYON 2
#define MCB_WRITEPROTECT 3
#define MCB_CACHEOFF 4

So DMA should be on.

If DMA test runs at least 4 times, it will automatically enable DMA. (This happens in emulation)

LowSpeedMemoryRegionFlags remains at zero (DMA enabled?)

Then comes confusing IO_FLAGS mangling. ($44? $C0? $80? $40? Other bits?)

Could someone who knows german (without using any online translators ) check the manual and install disk readme. It mentions something about DMA.

There is also "masterdma" program that apparently only sets filesystem mask. It also made no difference.

EDIT: IDE does the same, never uses real DMA.

EDIT2: using masterdma to set the mask and then attempting to read from HD seems to make a difference. Reads hang.. (and no DMA hardware accesses either)

It can't be that difficult to enable DMA..

EDIT3: SCSI has different DMA register space than IDE. Weird.. Looks promising now..

[mark_k]

Ah thanks. So I did get the sense of the flags wrong, I'll change labels in the disassembly which will hopefully make things clearer.

Edit: It seems that for IDE, DMA is only used for CMD_READ to chip RAM (both read and write to fast RAM).

[Toni Wilen]

IDE DMA is now working (both reads and writes). SCSI read DMA is also working. SCSI DMA writes don't work. (Writes goes to hdf but driver detects error)

[idrougge]

I didn't know there was a Zorro II IDE controller with DMA. Is the performance any good?

[Toni Wilen]

SCSI write DMA is also working now. It does same FIFO thing that PIO did, at the end of transfer it uses current DMA pointer and bytes in FIFO to calculate IO_ACTUAL.

Other 5394 based controllers set chip's DMA transfer counter to length of SCSI transfer but Masoboshi sets it to max (0 = 65536) and assumes "overflow" data goes to chip's FIFO before transfer stops. Masoboshi's custom DMA controller counter is also set to max.

IDE DMA uses DMA transfer counter. (transfers data block by block)

btw, it is possible DMA controller is dual channel, SCSI and IDE uses different addresses (base+F000 to F00F = SCSI and F040 to F04F = IDE) so in theory driver may use both simultaneously. This is not (yet) supported in emulation.

EDIT: code clean up, now IDE and SCSI DMA emulation are separated.

Originally Posted by idrougge

I didn't know there was a Zorro II IDE controller with DMA. Is the performance any good?

AFAIK Masoboshi Mastercard is the only DMA capable Amiga IDE controller.

I have no idea how it performs.

[mark_k]

I have one, though I never measured its performance. Maybe some old German Amiga magazines have reviews? Some ads mention 3.5MB/sec possible without an accelerator card.

The driver certainly is well-optimised (a nightmare to figure out what it's doing). But there are quite a few bugs, at least in v2.201 which I disassembled. There's an 8GB limit with some SCSI drives, IDE is CHS only and HD_SCSICMD SCSI emulation for IDE drives only supports very few commands (enough for HDToolBox I guess). And the probable "over-reading" bug (the driver reads beyond the end of the source buffer when writing to disk; in very rare cases where the buffer is right at the end of valid memory, could the over-read cause a bus error on some machines?)

The DMA controller is very likely to be dual-channel since that would improve performance when accessing both IDE and SCSI drives. A good way to test would be to have two HDFs, one SCSI the other IDE. Two partitions on each, then copy a load of files in both directions at the same time and see if there's any data corruption.

For example if SCSI1: & SCSI2: are partitions on the SCSI-connected HDF, IDE1: & IDE2: partitions on the IDE-connected HDF, open a Shell and do
Run Copy SCSI1: IDE1: ALL
Copy IDE2: SCSI2: ALL


Edit: Actually the 8GB limit might not apply, you'd have to use HD_SCSICMD to access past 4GB anyway of course.

[mark_k]

Another wtf? thing about the Masoboshi driver (this isn't relevant for emulation)...

After scanning for drives, the driver creates a task at priority -16 which busy-waits until DOS appears in the Exec library list (and has been opened). Then that task creates the main process (I think that's used for disk change detection) and returns (exits). OK so far, but then the driver frees part of the memory it occupies. Mismatched FreeMem() (address and length not matching the original allocation) is illegal, right? Could cause corrupted memory list?

	MOVE.L	#5000,D0
	MOVE.L	#(MEMF_PUBLIC|MEMF_CLEAR),D1
	MOVEA.L	(_SysBase-DataArea,A5),A6
	JSR	(_LVOAllocMem,A6)
	MOVEA.L	D0,A2

	LEA	($18,A2),A1	;Our task structure goes at offset $18 in just-allocated 5000 bytes
	MOVE.W	#$1F0,(LN_TYPE,A1)	;Node type 1 = NT_TASK, Pri = -16

	LEA	(MASOBOSHIMC70.MSG,PC),A0
	MOVE.L	A0,(LN_NAME,A1)

	LEA	(TC_MEMENTRY,A1),A0
	MOVE.L	A0,(4,A2)
	MOVE.L	A2,(A0)+
	MOVE.L	A2,(4,A0)
	MOVE.L	A0,(A2)
	MOVE.W	#1,(ML_NUMENTRIES,A2)
	MOVE.L	A1,($10,A2)
	MOVE.L	#4976,(20,A2)	;5000 - $18 bytes in ME_LENGTH
	LEA	(TC_SIZE,A1),A3
	MOVE.L	A3,(TC_SPLOWER,A1)
	LEA	($1314,A1),A3
	MOVE.L	A3,(TC_SPUPPER,A1)
	MOVE.L	A3,(TC_SPREG,A1)
	LEA	(ProcessStarterTaskCode,PC),A2
	LEA	(0).W,A3
	MOVEA.L	(_SysBase-DataArea,A5),A6
	JSR	(_LVOAddTask,A6)

	MOVEA.L	(A5),A0
	MOVE.L	(4,A5),(4,A0)
	MOVEA.L	(4,A5),A0
	MOVE.L	(A5),(A0)

	LEA	(lbW000218,PC),A1	;???
	MOVE.L	#lbC0008EE-lbW000218,D0	;???
	MOVEA.L	(_SysBase-DataArea,A5),A6	;???
lbC0008EE	JSR	(_LVOFreeMem,A6)	;???

	MOVE.L	A5,D0
	MOVEM.L	(SP)+,D1-D7/A0-A6
	RTS



ProcessStarterTaskCode
	LEA	(DosName,PC),A1
	MOVEA.L	(4).W,A6
	LEA	(LibList,A6),A0
	JSR	(_LVOFindName,A6)
	TST.L	D0
	BEQ.B	ProcessStarterTaskCode

	MOVEA.L	D0,A0
	TST.W	(dl_lib+LIB_OPENCNT,A0)
	BLE.B	ProcessStarterTaskCode

	MOVEQ	#0,D0
	LEA	(DosName,PC),A1
	MOVEA.L	(4).W,A6
	JSR	(_LVOOpenLibrary,A6)
	TST.L	D0
	BEQ.B	ProcessStarterTaskCode

	MOVEA.L	D0,A4
	LEA	(MASOBOSH.MSG,PC),A0
	MOVE.L	A0,D1
	MOVEQ	#1,D2
	LEA	(ProcessFakeSegList,PC),A0
	MOVE.L	A0,D3
	ASR.L	#2,D3
	MOVE.L	#$800,D4
	MOVEA.L	A4,A6
	JSR	(_LVOCreateProc,A6)
	MOVEA.L	(4).W,A6
	MOVEA.L	A4,A1
	JSR	(_LVOCloseLibrary,A6)
	MOVEA.L	(4).W,A6
	RTS

[mark_k]

Originally Posted by Toni Wilen

Not guaranteed this change will be included with final 3.5. Masoboshi fix needed non-trivial 5394 changes..

One more beta? Maybe you could specifically ask people to test other 5394/FAS216/etc.-based SCSI controllers.

[Toni Wilen]

Originally Posted by mark_k

One more beta? Maybe you could specifically ask people to test other 5394/FAS216/etc.-based SCSI controllers.

I have config file for every emulated SCSI and IDE controller. Booting and writing still seems to work so masoboshi related changes should be safe.

[Toni Wilen]

Originally Posted by mark_k

Mismatched FreeMem() (address and length not matching the original allocation) is illegal, right? Could cause corrupted memory list?

Code looks quite ugly..

Standard exec memory allocation routines don't cause corruption if freed memory is completely inside already allocated region, even if start address or length don't match original allocation. (Of course this is bad idea and unsupported)

[mark_k]

I installed A-Max and Mac System 6.0.8 and 7.1 to HDFs. Connected via Masoboshi IDE the Mac boots OK. However via SCSI it doesn't, just showing a disk with question mark icon.

Configs and HDFs:

https://www.media!fire.com/?degy53g3574mzz1

Boot to Workbench. Run A-Max Startup. Click Start A-Max II. Click OK.

My guess: The Amiga driver uses DMA and the FIFO still contains the last "extra" data from the last READ command, which confuses the AMHD code which uses PIO?

[Toni Wilen]

Fixed.

This was caused by old bad code.. MOVEP emulation did something like (get_byte(x) << 8) + get_byte(x+2) which compiler is allowed to reorder. (Other similar cases were fixed ages ago, for some reason this was missed)

x = scsi chip status register
x + 2 = scsi chip interrupt status. Reading this clears status register..

[mark_k]

Cool, so it's not just SCSI emulation that A-Max drivers are good for finding bugs in.