Comspec SA-1000 issues

[mark_k]

I've been looking at the Comspec SCSI driver code, since emulation seems to have some issues still. Hopefully I'll type up some more info shortly, but in the mean time...

Much of the time WinUAE says "WD33C93 WD_DATA READ without data request!?" on every (READ) command. The ComspecSCSI.device DMA (level 2) interrupt handler checks bit 7 at board+$8080. If set it clears bit 3 at board+$8080. Guess: WD33C93 /DRQ pin is connected to Zorro level 2 interrupt line? Could $8080 bit 3 connect to WD33C93 /DACK pin???


I tried setting up A-Max with a Comspec SA-1000 config. On starting Mac emulation with a bootable A-Max format floppy in DF0: (extended ADF) you just see a black screen. I think it gets stuck somewhere in the comspechd.amhd code, because if I change AX0: (a partition which A-Max detects since its name begins AX) to something that A-Max doesn't detect, Mac emulation starts and I can boot from floppy.

HDF and config:

http://www.media!fire.com/file/go2bptoq1e2byeg/Comspec_SCSI_A-Max_test.7z

To demonstrate: Load config, boot HDF to WB. Run A-Max, click Start A-Max II then OK. See black screen. There is no SCSI-related log output.

Now change AX0 DOS device name to something A-Max doesn't recognise:
- Reset, boot to WB, run SetUpHD.
- Click AX0 in UNIT INFO TABLE. Click in DOS NAME string gadget, change AX0 to AMX, press Return.
- Click DH0 in UNIT INFO TABLE. Select Install Drives -> Write Unit Info menu item, click Continue.
- Wait a couple of seconds then reboot. Run A-Max, click "Hard Disk / SCSI Preferences", notice no partitions are shown. Click OK then "Start A-Max II". See Welcome to Macintosh screen.

[Toni Wilen]

Originally Posted by mark_k

Much of the time WinUAE says "WD33C93 WD_DATA READ without data request!?"

This is normal. Driver does move.w (a1),d0 (a1 = $e98080, $8080.B = status, $8081.B = data port). Reads both status byte and data byte using single word read, then it checks if status = no data available, it ignores invalid data byte.

[Toni Wilen]

Level 2 interrupt = WD chip DRQ and level 6 = WD chip INT. This was already implemented.

AMax hang is now fixed (WD reset command didn't clear busy in all situations) and boot screen appears but then nothing. I guess this is normal?

[mark_k]

Yes, there's no Mac OS on the HDF. You should be able to boot from an A-Max format Disk Tools floppy when emulation starts. I included a set in this archive:

https://www.4!shared.com/file/IOaVwrmeba/A-Max_AdIDE_GVP_HDFstar.html

I'll try installing the Mac OS and upload an HDF with that.

Something else I noticed... boot the HDF to WB, open Shell and do Format DRIVE AX0: NAME dummy NOICONS

With 68000 cycle-exact emulation that seems very slow. There's a significant delay after you press return before the first SCSI I/O. Each (fake) cylinder is written/read with one command, giving log output like this:
WD33C93 WD_DATA READ without data request!?
SCSIEMU HD 0: 2A.00.00.00.92.0A.00.00.BA.00.00.00 CMDLEN=10 DATA=0000000007FF05C0
-> DATAOUT=95232 ST=0 SENSELEN=0 REPLYLEN=0
SCSIEMU HD 0: 28.00.00.00.92.0A.00.00.BA.00.00.00 CMDLEN=10 DATA=0000000007FF05C0
-> DATAOUT=95232 ST=0 SENSELEN=0 REPLYLEN=0

ComspecSCSI.device has a watchdog timer. It installs a vblank interrupt server. If "something" doesn't happen within 10 (default, can be changed) vblanks it signals the unit task. Could the slowness be due to something not happening, so the watchdog timeout occurs which "wakes up" the unit task???

(I'll upload my current disassemblies later.)

[mark_k]

http://www.media!fire.com/file/ybp83end3zbzul1/Comspec_disasms_20171230.tar.gz

That archive contains disassemblies of the ROM and disk-loadable ComspecSCSI.device & ComspecHD.device.

Since the ROM contains the Kickstart loader as well as ComspecSCSI.device and ComspecHD.device, in that disassembly I just concentrated on the Kickstart loader. The individual .device disassemblies are much more detailed for those parts.

[mark_k]

I just tried booting the Mac Disk Tools (Disk9.extadf) in A-Max. It boots, then when the Mac desktop appears you're prompted to eject or intialize the RAM disk and HD partition. You can enter a name for the HD partition and click Initialize, but no icon for it appears on the desktop. There's no SCSI-related log output either. That's with winuae.exe dated 2017-12-30 12:04.

[mark_k]

Aha, think I found a possible cause of the slow-Format issue!

I ran Show after booting the HDF. Do Show DE to list devices:


Notice that ComspecSCSI.device appears twice. Maybe the "wrong" one receives/handles certain interrupts, causing the "right" one to time out???

So for the SA-1000, you probably need to have AutoConfig diag valid bit always 0.

[Toni Wilen]

But without autoconfig, there is no ComspecHD.device and installer complains.

So it sounds more like $f0 ROM should go away after it has done its KS install task.

[mark_k]

Exec scans the region $F00000-$F7FFFF for residents though, wouldn't that pick up ComspecHD.device? (The installer disk does have ComspecHD.device and ComspecSCSI.device files in its devs directory.)

I'm pretty sure the ROM stays at $F00000 after passing control to Kickstart. The code which passes control to Kickstart doesn't do anything special (like copy instructions to RAM and call them, which the A1000 boot ROM has to do since it does go away on writing to $F80000), so it needs to remain present. See offset $3992 in the ROM disassembly.

[Toni Wilen]

Not if resident structure does not use absolute $f0 address which would make it incompatible in autoconfig region, proper autoconfig resident always needs "manual" relocation via diaginit.

Isn't this the test expects autoconfig mode:

; If on Kickstart 1.3+ *AND* running from $F0xxxx ROM, just return 0.

[mark_k]

The diag area in the ROM is a little odd; it causes both .device drivers to be copied to RAM (and relocates them). Whereas it would have saved memory and been faster on chip-RAM-only machines to just copy the resident tags, leaving the actual code to run from ROM.

That's why there are two ComspecSCSI.device entries in the device list. But the ComspecHD init routine does nothing if on Kickstart 1.3 and running from $F0xxxx, which is why there's only one ComspecHD in the device list in the pic above. I wonder if the later-version ROM (see SA-2000 thread) fixes that?

[mark_k]

Currently if you install Kickstart 1.2 on the HDF, on booting it gets stuck in a loop: load Kickstart from HD (grey screen), orange, green, reboot, ...

Would the result be the same if ROM still at $F00000, but AutoConfig diag valid bit 0?

[Toni Wilen]

Changed but not tested.

[mark_k]

This is strange... Now with SA-1000 autoboot disabled checked, it loads Kickstart (1.2) from HD then shows insert Workbench disk screen. So far so good: it's not auto-booting but still loads Kickstart from HD.

Then if I insert any bootable floppy disk, the system actually boots from HD! There is SCSI activity indicated in the log. See a requester saying
Please insert volume
df0:
in any drive
On clicking cancel there is this text in the CLI window:
Drive df0: not found
Addbuffers failed returncode 20

There's something wrong with the keyboard at that point though, because trying to type assign in the CLI actually shows assCgi ???

It seems ComspecHD.device "hijacks" DF0: in order to boot. I commented out Addbuffers from the HD startup-sequence and can now fully boot to WB from HD (on KS 1.2) after inserting any bootable floppy disk (and keyboard works OK). There's no icon for DF0: on WB, DF0: isn't shown on typing Info in CLI.

Maybe Comspec tried to get the HD to be fully bootable under KS 1.2 but couldn't manage it without removing access to DF0:???

Try this HDF in latest winuae.exe with autoboot disabled box checked:

http://www.media!fire.com/file/t15txxu7ltwblew/Quantum_ProDrive_40S_Comspec_KS1.2.7z

[Toni Wilen]

Originally Posted by mark_k

There's something wrong with the keyboard at that point though, because trying to type assign in the CLI actually shows assCgi ???

FastFonts (which modifies blitter register after starting it) without immediate blitter? (or without cycle-exact)

EDIT: DF0: boot: I guess Comspec didn't know how (or it didn't exist yet?) Multi Evolution/Combitec KS 1.2 booting worked without disk in DF0:. (DF0: needs bootblock injection because KS 1.2 always wants to only boot from DF0:, only if it has valid bootblock, it checks for other devices, I guess this only due to tripos always having bootable HD support)

[mark_k]

Nope. FF was in startup-sequence, but config is cycle-exact. And keyboard issue happens even if I Ctrl-D to interrupt startup-sequence before FF runs. Weirdly though, at some point the keyboard "fixes" itself since by the end of startup-sequence it's back to normal.

If you boot the HDF and tap i repeatedly after [CLI 2] appears, notice the characters you type change from C to i at some point. Maybe after the Setmap command runs? I wonder if when Kickstart 1.2 was written to the HD, there was random corruption affecting the ROM keymap??? Edit to add: Or maybe the Kickstart ADF I used was corrupted?

[mark_k]

AMHD disassembly, not very commented but maybe could be of some use?

http://www.media!fire.com/file/8977o99133w45ji/ComspecAMHDdisasm20171230.tar.gz

By the way, are there any unknown-purpose bits in the status register (board+$8080)?

[Toni Wilen]

Originally Posted by mark_k

By the way, are there any unknown-purpose bits in the status register (board+$8080)?

Here are bits currently used in emulation:

bit 0: RTC IO mapped (?)
bit 3: level 2 irq request
bit 4: level 2 irq enable
bit 6: reset WD chip (and perhaps other chips too?). Active low. Also disables interrupts when enabled.
bit 7: WD DRQ active

[mark_k]

Status register bit 5 may be the level 6 interrupt enable???

In the ComspecSCSI disassembly, look at Command10_main. It maintains an "open count", IO_LENGTH=0 decrements the count, if count reaches 0 then it clears status register bit 5. IO_LENGTH <> 0 increments count and sets status register bit 5. Device commands which transfer data seem to use command 10 to set status reg bit 5 before the transfer and clear it after. (Well, clear if the "open count" is zero, since there can be multiple tasks using it I guess?)

Also, the driver code is careful to maintain a shadow copy of the value last written to the status register, suggesting some bits are write-only.

Edit to add: Look at DoDataTransfer. After data transfer is complete it sets bit 3 of the status register. (To cause a level 2 interrupt, so the unit task is signalled?)

"ResetBoardThenResetSCSI" intially writes status reg with bit 6 0, bits 3 & 4 both 1. Then after a short delay it writes it with bit 6 1 (bits 3 & 4 still 1). It expects to see an interrupt (level 2 or 6?) with 1/6 second.

[Toni Wilen]

Originally Posted by mark_k

Status register bit 5 may be the level 6 interrupt enable???

Possibly, perhaps I used wrong bit previously (bit 6 as master interrupt disable and reset but when correct bit was 5)

Edit to add: Look at DoDataTransfer. After data transfer is complete it sets bit 3 of the status register. (To cause a level 2 interrupt, so the unit task is signalled?)

I don't think so because interrupt code (DMAInt_Code) checks first if bit 7 is set (DRQ), more like it re-enables interrupts after transfer loop is done because during transfer loop those interrupts would be useless and only cause huge slowdown.

"ResetBoardThenResetSCSI" intially writes status reg with bit 6 0, bits 3 & 4 both 1. Then after a short delay it writes it with bit 6 1 (bits 3 & 4 still 1). It expects to see an interrupt (level 2 or 6?) with 1/6 second.

Reseting WD chip causes it to activate its IRQ line after reset sequence is complete. This is already emulated (or nothing would have worked).