Masoboshi Mastercard reverse-engineering (was: crashes WinUAE)
 

Choose any quickstart config, add Masoboshi MasterCard IDE controller, click on Start -> WinUAE is gone.

Happens in 3.4.0, 3.3.0 is ok.

Fixed. (Broke when hw info panel was added)

Note that Masoboshi emulation is not complete. It has weird custom DMA chip and driver also does weird things and at least 2.201 boot ROM does red flashes because it apparently misdetects some IDE transfers as failing (was reported happening with real hardware too).

Really need very rare 2.204 which supposedly fixes all bugs.

Do you get the red flashes with the 2.202 ROM too (in the SetPatchMC702 1.2 archive on Aminet)?

I don't remember and I don't want to waste more time with this weird thing without having the board or at least someone confirming its behavior with exact same rom version.

I'm trying to test a Masoboshi config to see what the problem might be, but (with winuae.exe 2017-06-05 20:21) there are no SCSI accesses in the log.

Config:Example log output:

It was even more broken.. Now autoconfig works again.

SCSI does not seem to work (or I did something else wrong), IDE at least still works and causes red flashes.

(btw, check old emails, we really tried to get this working but the SCSI part of driver, at least write code path made no sense)

Thanks. Looking at the 2.201 driver code, it does some bogus/broken things. For example see the code below from the scan-for-SCSI-drives routine and wince...

It issues MODE SENSE (6) for page 3 (format device page). The CDB has DBD bit 0, but the driver seems to assume the drive doesn't send any block descriptors. And the code checks for some things at the wrong offset...

Nice. Now we have at least one driver that wants at least empty block descriptor (or it blows up, I don't remember which one but I remember adding it because some driver required it) and here is one that don't expect it (or it blows up).

Looking at the code again I was wrong. The driver assumes the drive does return a block descriptor. It's still broken in various ways though, not only if the drive doesn't return a block descriptor.

The memory it allocates isn't cleared so could contain garbage values.

Assuming the drive returns a block descriptor, then you have:
- four-byte mode parameter header
- 8-byte block descriptor
- mode page 3 data

If MODE SENSE executes OK, driver checks longword at offset 4. That's the first four bytes of the block descriptor, which are: density code (1 byte), number of blocks (3 bytes).

Then it checks the word at offset 10. That's the (low 16 bits of) the block length in the block descriptor.

If both those values are non-zero, it uses them as the number of blocks and block size.

The driver assumes the density code will be zero, i.e. that the 1st 4 bytes are effectively the number of blocks (8GB limit for 512-byte sectors...). But note the SCSI standard says "A value of zero indicates that all of the remaining logical blocks of the logical unit shall have the medium characteristics specified"
(So if a drive returns 0 for the number of blocks field in the block descriptor, providing the density code byte is also 0, the driver will issue READ CAPACITY instead.)

If the driver does issue READ CAPACITY, there's an off-by-one bug; the maximum LBA returned by READ CAPACITY is (number of sectors)-1


Googling for masoboshi 2.204 leads to a page which lists changes between 2.202 and 2.204 firmware:

I think I saw that change log. No red flashes and enforcer hit fixes would be nice to have.

SCSI now works, it was later NCR update that broke it. (in pio mode fifo always contains max 1 byte but there is a special case, it will contain status + message byte(s) after command $11 ICCS. With only status byte in fifo, masoboshi driver still sent $12 accept message but then decided that there is nothing else to do anymore)

Thanks. Testing with 3.5.0b12 now. SCSI reading seems to work OK. I could boot an OS 3.1-installed HDF which I had previously prepared when IDE-connected. [Not sure if relevant, but I had previously used MasterInstall to disable DMA, so the driver probably wouldn't have tried to use DMA when SCSI-connected.]

But on attempting the first write to it when SCSI-connected, got an error requester:
Part0
has a write error
on disk block 20224

Log output prior to that:
There are both A-Max and Chamäleon II drivers for the MasterCard, so next step could be to try those over IDE. I can test the A-Max one myself, but if someone else could try the Chamäleon II (Atari ST emulator) driver that would be great, since I have almost no ST knowledge.

Yes, SCSI writing is not working, this is the part where driver code makes no sense..

EDIT: Does it have SCSI A-Max driver? It probably is much much much simpler than ROM driver.

Yes the AMHD handles both IDE and SCSI. Disassembly at

This is the mysterious part from rom driver (from your 2 year old disassembly with extra comments)

This looks normal (and probably already works just fine). 256 unrolled copy loops only. No weird extra 16 bytes anywhere.

Perhaps this change makes the difference? Pre-2.203 defaults to some weird mode that can't work if "alien RDB" (as in normal, I guess..) ? :)

Time to test official installer..

EDIT: 2.1 installer uses same code path. Same 16+512 byte writes (that are impossible because scsi commands are based on blocks, not bytes)

Masoboshi IDE and SCSI configs, 20MB HDF:To change MasterCard-specific options... Since SCSI writing doesn't work yet, boot with the HDF connected to IDE and make changes. Then try booting with it connected to SCSI. [I'm assuming MasterInstall does actually set the relevant bits in the RDB even if they don't apply to IDE drives.]

Run MasterInstall. Click Spezial. You can select Asynchron, Disconnect/Relselect.
Click MasterCard. There you can select MasterCard-specific options:
- DMA
- "Schnelle ubertragung" (fast transfers?)
- Parity Bit
- Schreibschutz (write-protection)
- RDB-Schutz (write-protection of the RDB area)
- Write Cache

Note: you have to re-set the manual geometry every time you change HDF, since WinUAE helpfully "forgets" it every time... C/H/S 320/4/32.

I already tested those and I can't get DMA mode active (even if I make CPU very slow or DMA instant). It always does the DMA speed test but then it always uses PIO, ignoring special options, even if only DMA is checked.

SCSI writing "works" as long as caller does not check IO_ACTUAL (Which will be +$10 compared to IO_LENGTH) or IO_ERROR.. ("HFERR_DMA" = $29)

My crystal ball says pre-2.203 DMA mode was always the default which worked as long as speed test selected DMA. (Probably practically always except with some later accelerators).

They also probably didn't want to mention in changelog that the driver was practically broken ("some harmless red flashes fixed"..) :)

This probably won't help, but here's info on how the MasterCard-specific options are stored in the RDSK sector.

Starting at rdb_ControllerVendor (byte offset $BC) there are 24 bytes:
- 4 ASCII bytes "MaCa"
- checksum byte
- options byte (see below)
- 00 00
- 16 ASCII bytes "MasterCard "
- 00 00 00 00

The checksum byte is chosen so that (the low byte of) the sum of all 28 bytes is 0.

Also, the RDBFB_CTRLRID bit is set in rdb_Flags (not sure whether or not the ROM checks that).

Options byte:
bit 0: DMA
bit 1: Fast transfer
bit 2: Parity bit
bit 3: Write-protection
bit 4: Write cache
bit 5: RDB write-protection

My current ROM 2.201 disassembly:About the IO_ACTUAL problem... could that be related to there being a FIFO (in the Masoboshi ASIC)? Look at this code:
Could the longword at Board+$F10C be a DMA pointer??? And look at the code at lbC003A76. Related to synchronous transfers?
The FAS216 datasheets mentions "Programmable Synchronous Transfer Offsets up to 15 Bytes". Maybe that's why the driver writes 16 "extra" bytes?