A2630 & Golem HD3000 "not a dos disk" & Golem roms

[system11]

So my A2630 arrived, fallback doesn't seem quite as good as on the A2620 but I've found another interesting problem.

In 68030 mode the Golem HD3000 hard disk tries to boot and then reports "not a dos disk in unit 0"

In 68000 mode it boots just fine.

2630 card has roms labelled as version 7 on it already, Amiga is 1.3 kickstart, Golem has "1.4" low/high pair and I'm led to believe 3.9 exist but can't find them anywhere.

I'd better dump the Golem chips, it seems very likely copies don't exist. Does anyone know where I can find the new ones to test with? Might not even be for this card but I'm happy to try.

[Toni Wilen]

There are at least 3 different Golem SCSI hardware variants, one of them does have v3.9 ROM available (http://amiga.resource.cx/exp/golemscsi500) "Fast SCSI" variant has v4.x. (http://amiga.resource.cx/exp/golemfastscsi). It looks like major version was bumped when new incompatible hardware was released.

HD3000 ROM dump would be very nice, thanks in advance (If you don't have hardware to read it, I can give relatively easy software dump instructions)

My guess is some bad timing routine (CPU delay loop? Should be easy to see by checking ROM dump disassembly). It can't be DMA related, controller is PIO only.

[system11]

I don't think that will be a problem, I'm a member of TDU (arcade dumping group)

Done.

http://www.system11.org/temp/ROMs/Amiga

[system11]

As an aside before I store/sell my A2620, are the rev 4 chips dumped?

[Toni Wilen]

Thanks and yes, only rev 2 is missing. (but there are 2 different rev3's..)

[mark_k]

... so dump the rev 4 ROMs anyway just to be sure.

I've had a quick look at the Golem ROM code. For a couple of loops with timeouts, it does TST.B ($BFD201).L
That isn't a canonical CIA address. Could that cause issues with the A2630?

Also (not relevant here) device command 22 is not TD_GETGEOMETRY but instead basically calls the routine pointed to by IO_DATA...

[Toni Wilen]

Do you get same error if you disable boot rom (there should be jumper, at least ROM is in two parts, first 8k block is mapped when autoboot is enabled, second 8k when autoboot is disabled) and try to mount it using install disk?

Assuming install disk exists that has newer or same driver version. (on-disk version may work differently even if has same version numbers)

[system11]

The install disk image is broken unfortunately, the image online is apparently garbage, it crashes when you try to load the disk definition on 1.3 or 2.0, accel or without. I'll see if sysinfo can spot the disk without the boot rom this weekend. There's a switch on the back which disables booting (or perhaps the whole card, I'll check that too)

[Toni Wilen]

Originally Posted by system11

The install disk image is broken unfortunately, the image online is apparently garbage, it crashes when you try to load the disk definition on 1.3 or 2.0, accel or without. I'll see if sysinfo can spot the disk without the boot rom this weekend. There's a switch on the back which disables booting (or perhaps the whole card, I'll check that too)

Driver is completely gone in non-autoboot mode.

Not a dos disk means driver detected (or got really confused) a drive and found a partition and added it to expansion.library mountlist. I'd have expected drive detection to fail but this seems to be something more complex than just a basic timing problem.

Does floppy booting still work? (with HD autoboot enabled). Does sysinfo or c:info list any HD partitions? (with a not a dos disk state)

[mark_k]

Yes the install disk on amiga.resource.cx is bad. In particular the file GOLEM.HDisk.device is 0 bytes long. Also note that the ROM driver name is golem.device. So the disk may well be for a different driver version.

My current ROM disassembly (remove ! after pasting into your browser's URL bar):

https://www.media!fire.com/file/0fkucebhz1acgwh/HD3000_1.4_disasm_20171026.tar.gz

[system11]

Test results:

sysinfo can see the card with boot enabled or not. With boot enabled it can also see the disk - both tests in 68030 mode.

However if I turn on the boot and check sysinfo under 68030 it shows only partial disk information compared to 68000 mode - see attached images.

I can boot Workbench from a floppy in 68030 mode and I just see a "DH0:NDOS" icon, with boot rom turned off it doesn't know it's there.

[system11]

By the way - let me know if you want me to do any other tests / gather info on this hardware. I'll probably be selling the card/drive soon as it turns out the drive itself is worth quite a bit now but if you're planning to add support to UAE I can hold it for a while.

[Toni Wilen]

Strange. Geometry and device name is correct which means partition table was read and parsed correctly.

Does WB disk C:Info also show same disk state? (No disk in drive or not a dos disk)

<snipped from CMD_READ_routine>

	MOVEQ	#$1D,D0
	BTST	#1,(lbB005037-Unit,A3)
	BEQ.W	.Set_IO_ERROR_and_return

So any read command returns $1D (TDERR_DiskChanged) if lbB005037 bit 1 is not set. Bit is only set in HackToHandleRDSKSectorWrite which makes no sense, why would normal boot (68000 mode) ever write to RDB blocks.. Unless there is some uninitialized variable..

Write routine has similar check.

Emulation is already done (It uses OMTI controller that was already emulated, only needed to hook up ROM, autoconfig and IO space) but it won't help much without install disk and hdtoolbox just seems to hang doing nothing.

[system11]

Info says "unreadable disk" in 68030 mode. Is there a driver somewhere on the disk or in the code for it to work in 68k? If so could it be extracted somehow? I checked the disk itself - same 0 byte file in DEVS.

[mark_k]

Latest disassembly:

https://www.media!fire.com/file/j85ddxl7b1cpgse/HD3000_1.4_disasm_20171029.tar.gz

The label HackToHandleRDSKSectorWrite is a slight misnomer since it's not only called by the CMD_WRITE routine. HandleRDB calls it too.

Anyway, HackToHandleRDSKSectorWrite examines RDSK sector data. If rdb_Flags bit 31 is 1 it treats drive as write-protected. If drive parameters/geometry have not already been set (which is what lbB005037 bit 1 indicates), or the geometry in RDSK data differs from the current one, it issues command $0C (INITIALIZE DRIVE PARAMETERS?) to the OMTI controller. It also (re-)allocates the track buffer if necessary.

[mark_k]

Originally Posted by system11

Info says "unreadable disk" in 68030 mode. Is there a driver somewhere on the disk or in the code for it to work in 68k? If so could it be extracted somehow? I checked the disk itself - same 0 byte file in DEVS.

Best to ignore that broken install disk.

Try using Degrader. Using that turn off CPU caches and disable fast RAM. Then have it reset, remove the floppy disk and see whether the system boots from the Golem HD. ADF in this post.

[mark_k]

Originally Posted by system11

By the way - let me know if you want me to do any other tests / gather info on this hardware. I'll probably be selling the card/drive soon as it turns out the drive itself is worth quite a bit now but if you're planning to add support to UAE I can hold it for a while.

How much do you think the old MFM drive is worth?

Could you try dumping the entire drive to an image file? You'd need to boot from a floppy disk in 68000 mode. Then mount your CF card (you mentioned Tandem IDE controller in another thread) and use a package like Dev-Handler to read golem.device unit 0 to a file on the CF.

Having that image file would allow testing of the HD3000 emulation in WinUAE.

However, testing in WinUAE may be possible without it. You'd need to manually specify a valid drive geometry, use HDToolBox etc. to partition drive connected to a different (emulated) controller then transfer it to the (emulated) HD3000.

[emufan]

Originally Posted by system11

Info says "unreadable disk" in 68030 mode. Is there a driver somewhere on the disk or in the code for it to work in 68k? If so could it be extracted somehow? I checked the disk itself - same 0 byte file in DEVS.

DiskSalv can rescue Goiem.HDisk.device on the resource.cx disk from the expansion folder.
trouble is, it seems short. but at least some 4kb of the file can be investigated.

[mark_k]

Archive (~1MB) with config and HDF for testing Golem HD3000 emulation:

https://www.media!fire.com/file/hi3a3q4qp3h8ry9/Golem_HD3000_test.7z

HDF has two ~20MB OFS partitions, the first is bootable. Though you'll need Kickstart 3.1 to boot this HDF as-is, you should be able to reformat and install an earlier OS.

Edit2: WinUAE prints some log output which may indicate a problem:
SCSIEMU HD 0: 0C.00.00.00.00.00.00.00.00.00.00.00 CMDLEN=6 DATA=10F0D080
INITIALIZE DRIVE CHARACTERISTICS: Heads: 8 Cyls: 520 Secs: 2
02 82 08 02 82 02 82 00
-> DATAOUT=8 ST=0 SENSELEN=0 REPLYLEN=0

The actual drive parameters are (C/H/S) 642/8/17. If WinUAE is interpreting fields in the initialize drive characteristics data wrongly (it's using C/H/S 520/8/2) does that have any adverse effect? Or is that just a problem with the log output text?

[system11]

Is there any danger using dev-handler to read the device (assuming I don't specify a bad write destination)? I'm not sure I could repartition this disk since the tools on the disk immediately crash so I don't want to risk the existing data. Happy to dump the whole thing if it's safe. My working IDE setup is already a floppy wb2.0.