Some SCSI card EPROM images

[mark_k]

Reading about the GVP SCSI controller emulation in WinUAE 3.1 encouraged me to look for some old EPROM images. I have attached an archive with:

• gvpscsi 4.13 EPROM image. I bought this chip from a US eBay seller.
• GVP "BETA2" EPROMs. Also bought on eBay. I think these are for the old GVP 68030 cards which had an on-board IDE controller, so not usable with WinUAE currently. Odd/even chips, but I created a combined image and included that too.
• Z3SCSI versions 5.777 and 5.820. Presumably these are for the Fastlane Z3?
• My GVP 68030 Combo A2000 accelerator came with gvpscsi.device 3.14. I think that's what is in the "OMNI 3.5" EPROM image. Archive also contains images of the disk which came with the card.
• ICD AdSCSI 2000 ROM 1.6 and disk image.

The file is an XZ-compressed tar archive. Remove .zip from the name before unpacking it.

Edit: Added Masoboshi Mastercard MC-702 EPROM image. I don't remember what version it is.
And added AT-Bus 2008 EPROM image.

[Toni Wilen]

I usually only add latest available version to ROM scanner unless there are big enough differences in other versions. But better keep them in safe place

I am not sure what to do with GVP accelerators with built-in SCSI. Nearly every one uses same driver. There is hardware ID which driver checks so technically each model should be listed, main difference seem to be DMAC addressing width. (24bits or more)

IDE emulation is hardwired to A600/A1200/A4000 emulation only. Needs big rewrite. Much later.

SCSI updates: "Software" SCSI boards like Apollo also need lower level SCSI implementation. (Code directly pokes SCSI signal and data lines, there is no SCSI controller chip. It can't get any cheaper!). Remaining "real" controller based boards use non-emulated controller chips.

[mark_k]

Originally Posted by Toni Wilen

I usually only add latest available version to ROM scanner unless there are big enough differences in other versions. But better keep them in safe place

I am not sure what to do with GVP accelerators with built-in SCSI. Nearly every one uses same driver. There is hardware ID which driver checks so technically each model should be listed, main difference seem to be DMAC addressing width. (24bits or more)

I seem to remember reading somewhere that 4.13 was the last version actually shipped by GVP.

The SCSI controller on GVP accelerators can DMA to all RAM, there's no 24-bit restriction. I assume the current GVP hardware emulation can only do 24-bit DMA? It's possible there could be Mask issues if using an image from a real Amiga with GVP accelerator SCSI. Or maybe the GVP ROM checks the product ID and knows to only DMA to 24-bit addresses even if Mask=0xFFFFFFFE for example.

[Toni Wilen]

Originally Posted by mark_k

I seem to remember reading somewhere that 4.13 was the last version actually shipped by GVP.

The SCSI controller on GVP accelerators can DMA to all RAM, there's no 24-bit restriction. I assume the current GVP hardware emulation can only do 24-bit DMA? It's possible there could be Mask issues if using an image from a real Amiga with GVP accelerator SCSI. Or maybe the GVP ROM checks the product ID and knows to only DMA to 24-bit addresses even if Mask=0xFFFFFFFE for example.

Current emulation emulates Z2 board version of GVP which can only do 24-bit.

According to NetBSD gvp drivers some accelerators with built-in SCSI have only 24bit or 25bit DMA support. (sys/arch/amiga/dev/gvpbus.c and gtsc.c)

I am quite sure driver will detect hardware model, for example Z2 GVP with RAM outside of 24-bit space: DMA is always done to buffer in 24-bit fast or chip ram.

[mark_k]

That's what should happen, but the need for Mask in mount files/RDB suggests some drivers don't do that properly...

25-bit DMA support makes sense (though 24-bit doesn't). The GVP accelerator card can have up to 16MB fast RAM starting at $01000000 (automatically added to the memory list by the boot ROM), so 25 bits is enough to cover that.

[Toni Wilen]

IDE stuff will be implemented soon (AlfaPower/AT-BUS already done), it is usually very easy.

I also implemented low level scsi emulation, Apollo SCSI now works. But Apollo IDE (and IDE+SCSI combo) boot ROM is still missing (Apollo AT500/AT2000 IDE and 500/2000 IDE+SCSI combo cards), all available ROMs appear to be dumped from Apollo accelerator boards and they don't have full IDE driver. (It has some parts remaining, like drive detection for some reason but main part is not included)

GVP "BETA2" EPROMs. Also bought on eBay. I think these are for the old GVP 68030 cards which had an on-board IDE controller, so not usable with WinUAE currently. Odd/even chips, but I created a combined image and included that too.

At least this can't be for GVP A3001, it has IDE but device name is gvpat.device and ROM contents are very different. This rom's device name is scsidev.device. (Some very old GVP SCSI controller?)

[mark_k]

Yes, it looks like those EPROMs were for the GVP Series I SCSI controllers. E.g. Impact A2000-1/X, Impact A2000-HC, Impact A2000-HC+2. (User manual available from archive.org btw.)

I haven't tried using the EPROM images with WinUAE's current GVP controller emulation. My guess is they won't work if you only emulate Series II hardware.

[Toni Wilen]

Originally Posted by mark_k

Yes, it looks like those EPROMs were for the GVP Series I SCSI controllers. E.g. Impact A2000-1/X, Impact A2000-HC, Impact A2000-HC+2. (User manual available from archive.org btw.)

I haven't tried using the EPROM images with WinUAE's current GVP controller emulation. My guess is they won't work if you only emulate Series II hardware.

It shouldn't work. Series I is not (at least by looking at PCB images) DMA controller (no custom chip with enough pins) but has 2*8k SRAM buffer RAM. Probably more complex to emulate than normal PIO or DMA controller.

[mark_k]

Apparently the SCSI device can DMA into the on-board SRAM, but transfers from that to Amiga memory are done manually (PIO or maybe just copying memory if it's mapped into Amiga address space).

[Toni Wilen]

Originally Posted by mark_k

Apparently the SCSI device can DMA into the on-board SRAM, but transfers from that to Amiga memory are done manually (PIO or maybe just copying memory if it's mapped into Amiga address space).

Got it working, mostly. RAM is at board + 0x4xxx. Each read always gets next byte or word, there seems to be internal hardware address counter. I think this was done because WD SCSI chip is not designed for PIO data read/write (it would be really slow, would need multiple IO access to read or write single byte).

Driver also refused to boot PFS3 partition (all partitions appeared in early startup) and for some reason it executes WD reset command all the time when idle. Probably best to get non-beta ROM first.

Masoboshi: difficult to guess IO mappings because it has both IDE and SCSI parts. IDE only rom would help.

ICD AdSCSI 2000: Unemulated 5380 chip. (should not be that difficult to emulate now that low level scsi emulator exists, it is quite low level chip). Other older SCSI controllers also use 5380 (or 53c80)

[mark_k]

Originally Posted by Toni Wilen

Driver also refused to boot PFS3 partition (all partitions appeared in early startup) and for some reason it executes WD reset command all the time when idle. Probably best to get non-beta ROM first.

You could try running without the boot ROM and load the driver from SYS:Expansion with BindDrivers. But maybe the old ROMs only supported OFS & FFS booting, nothing else.

DMS file is linked from the amiga.resource.cx page. Luckily/interestingly, the Expansion/scsidev driver on that disk has symbol hunks making disassembly a lot easier...

Edit: this code extract checks specifically for the DOS\1 DosType. Should be easy to patch out.

_add_filsys	LINK.W	A5,#-8
	PEA	(addfilsys.MSG,PC)
	JSR	(_KPrintF,PC)
	ADDQ.W	#4,SP
	MOVE.L	(12,A5),-(SP)
	JSR	(_getenvec,PC)
	ADDQ.W	#4,SP
	MOVE.L	D0,(-8,A5)
	MOVEA.L	(-8,A5),A0
	CMPI.L	#11,(A0)
	BLS.W	.Return

	MOVEA.L	(-8,A5),A0
	CMPI.L	#$444F5301,($40,A0)	;DOS\1
	BNE.W	.Return
	...

[Toni Wilen]

Originally Posted by mark_k

You could try running without the boot ROM and load the driver from SYS:Expansion with BindDrivers. But maybe the old ROMs only supported OFS & FFS booting, nothing else.

Possibly but I am not going to bother with binddrivers. Boot roms only.

Edit: this code extract checks specifically for the DOS\1 DosType. Should be easy to patch out.[code]_add_filsys LINK.W A5,#-8

No patches. ROMs must be non-modified! (IMHO if you are going to emulate (very) old hardware, you must accept all limitations and bugs too)

[mark_k]

Loaded-from-floppy drivers could allow testing with more driver versions. The BETA2 EPROMs contain scsidev 2.02c(15 Jan 1989). The v1.3 install disk driver is scsidev 1.1.6(16 July 1988). Are any other series-I-only drivers available online?

Obviously whether the user uses a patched ROM is irrelevant for hardware emulation. It might allow easier testing of non-FFS filesystems without needing mount files. But on the other hand, there's probably some problem/bug other than the explicit DosType check that would cause other filesystems to not work from RDB.

Other than curiosity, historical interest or wanting an emulated setup to match a real Amiga there probably isn't much point in the end user using these old GVP driver versions; v3.15 will work and presumably be less buggy. Although... filesystem developers might want to check the device name and not try to use HD_SCSICMD if on scsidev.device. Here are some findings about the 1.1.6 driver.

Hard-coded for 512-byte sectors.
Can only autoboot(/automount?) DOS\0 and DOS\1 partitions.

TD_FORMAT: If IO_OFFSET = 0 issue FORMAT UNIT command, else set IO_COMMAND to CMD_WRITE and proceed accordingly.

Command 27: Does something, not sure what.
Command 28: Might allow sending an arbitrary 6-byte SCSI command. This is probably not compatible with HD_SCSICMD.
Command 29: Issue START STOP UNIT with LoEj = 0, Start = 1
Command 30: Causes _reset_scsi() to be called. Resets SCSI bus or just single device?
Command 31: Issues REQUEST SENSE

[Toni Wilen]

I got BETA2 driver working without strange reset loop (winuae.zip). It has interrupt request byte at board + 0x3e and because I normally handle addresses < 0x40 as autoconfig, I didn't notice driver 0x3e access.

Whole interrupt stuff is strange, byte is read from level 2 interrupt but it does not add any level 2 interrupt handlers like normal device drivers do. Not sure where it hooks it but it is called from KS ROM. (Not really important because it works but seems strange)

Documenting driver bugs/features is always good thing, not sure about others

EDIT: Easy test to see if HD_SCSICMD works: try hdtoolbox.

[thebajaguy]

FWIW - the Beta2 ROMS are the early scsidev.device v2.0 driver, an update on the original v1.0 ROMs, which was soon bumped to v2.2 and v2.3 and called 'Advanced AutoBoot ROM' kit back in the Impact SCSI (Series I) controller days. Yes, they were created, and existed as RDB-loading drivers, before C= made the RDB standard (established with the A2091/A590). C= basically improved greatly on the concept that GVP first used.

For the v3.x and v4.x gvpscsi.device drivers, Ralph Babel wrote them to the C= spec. Ralph basically solved all the glitches in the WD33C93/WD33C93A series, including those caused by the 7.xx MHz clocking (vs the 8/16MHz standard that the chip expects). He later made Sync SCSI work on the GVP Series II and C= DMAC boards which supported 14MHz clocking setting with the v6 GuruROM.

The v1.x/v2.x scsidev.device never supported HD_SCSI_CMD, and the driver should be skipped, deferring to the v3.15 ROM in all cases. It's faster, too. There is a 2-ROM version link on Ralph's page for the HC2 which otherwise needs a PAL changed to support the single chip ROM v3.x