HD controller ROM images for Toni

[idrougge]

…and possibly Mark K.

In the Zone are ROM dumps for the Vortex 2000, Spirit InMate and an ultra-rare networking card from Nine Tiles.

[Toni Wilen]

Thanks!

Vortex System 2000 seems to work with existing emulation, it does two scsi reads and then opens alert, probably because test drive had normal RDB but it required something custom and I didn't bother to install one just yet. (Emulation was originally implemented using boot disk driver, rom was MIA until now).

InMate needs driver disassembly (Hi Mark!), it looks like board+0x84 contains jumper settings (Documentation seems to be MIA?). 0x80 and 0x82 probably are Adaptec chip IO.

Another NIC ROM seems to be only for autoconfig, other seems to contain non-68000 code. Available information seems to be practically non-existing.

[idrougge]

I could possibly dig up documentation for the InMate, our user group has two.

[Toni Wilen]

Jumper documentation would be very useful.

[mark_k]

The manual would be helpful.

There's a board pic on the BBoAH page.

Takes ZIP RAM, the ROM supports 0, 1, 2, 4, 8MB. Memory is non-AutoConfig. The ROM adds it according to the jumper settings. Might not be DMA-capable either, maybe the manual says?

It's probably possible to have memory in a setup which the ROM doesn't support. In that case you could set the jumper for 0MB and manually add mem in the startup-sequence. Probably not much use for non-supported settings though (e.g. 2MB at $200000 + 2MB at $600000).

68881 (if installed) appears at Board+$100.

Jumper settings as readable at board offset $84 seem to be:
bits 0 and 1: determine memory size, 00 = 1MB, 01 = 2MB, 10 = 4MB, 11 = 8MB
bit 2: If zero, don't add any memory.
bit 3: Controls how long the SCSI driver initial delay is (subq.l #1,D0 / tst.l D0 / bne.w loop). Bit=1: short delay (1000000 counter), bit=0: long delay (7500000 counter).
bit 4: If zero, don't load inmate.device (the SCSI driver).
bit 5: If 1, don't add MathIEEE.resource. You'd set the jumper such that this bit is 1, if no 68881 is fitted. If a 68881 is present, it probably physically appears at Board+$100, the jumper just controls whether it's made available to the OS.
bit 6: Base address of memory.


The SCSI driver is embedded as an Amiga load file in the ROM complete with reloc32 hunk, easy to extract, maybe ending up with the same disk-loadable driver as would be on the install disk?

Uses DBF loops for delays. Not too bad though, since it's pretty much guaranteed to be running on a 68000.


Memory details... the ROM checks for ZKick RomTag, doesn't add the 512KB at $200000 if present.
If memsize is 8MB, always add 8MB at $200000.
If bit 6 is 1:
memsize 4MB: add it at $400000
memsize 2MB or 1MB: add it at $600000
if bit 6 is 0:
memsize 4MB: 2MB at $200000, 2MB at $800000
memsize 2MB or 1MB: add it at $200000

[mark_k]

Would it be possible to get a re-dump of the Inmate ROM? I'm wondering whether there's some corruption. For example this code, where A0 points to the board base address:

move.b  #0,($82,A0)     ; 117C 0000 0082
move.b  #1,($82,A0)     ; 117C 0001 0082
move.b  ($5D9182).L,D0  ; 1039 005D 9182 <--- ???
move.b  #0,($82,A0)     ; 117C 0000 0082

[Toni Wilen]

0x84
- bit 7: SCSI chip DMA request line is active
0x88.W
- Fake DMA data port

Next step is to implement SCSI chip PIO mode emulation. Same chip was also used in HardFrame but it used true DMA.

I'll emulate this as it would be normal SCSI autoconfig board (not accelerator board), the rest is not that useful and don't really need emulation. Emulating 6888x in IO mode would be extremely painful..

EDIT:

It has bad code that detects memory region type by checking the name and causes address error if KS 3.1..

00203404 2268 000a MOVEA.L (A0, $000a),A1 ;memory node name
00203408 2011 MOVE.L (A1),D0 ;FAIL! memory name string can be in odd address. (and it is at least in KS 3.1)
0020340A 0080 2020 2020 OR.L #$20202020,D0 ;to lower case
00203410 b0bc 6368 6970 CMP.L #$63686970,D0 ; "chip"

[mark_k]

My current disassemblies:

https://www.media!fire.com/?8683rvwkc5ckvzd

The SCSI driver is quite simple: no interrupts, busy-wait loops. Has some interesting non-standard device commands:
22 - issue TEST UNIT READY
23 and 31 - issue REQUEST SENSE (routine for both commands is identical/duplicated)
24 - issue FORMAT UNIT
25 - issue MODE SENSE (6)
26 - issue MODE SELECT (6)
27 - IOERR_NOCMD. Maybe some other Spirit product used command #27 for something?
28 - HD_SCSICMD (I think)
29 - issue REZERO UNIT
30 - issue SCSI command $02. What is that???
32 - issue READ (6)
33 - issue WRITE (6)
34 - issue SCSI command $10. What is that??? (Xebec S1410A manual says that's READ SECTOR BUFFER, but this command doesn't transfer any data.)
35 - issue SCSI command $11. What is that???

[idrougge]

Originally Posted by mark_k

Would it be possible to get a re-dump of the Inmate ROM? I'm wondering whether there's some corruption.

Should be possible. I'll look into it the next time I'm back in Stockholm.

[alexh]

0x02 - ???
0x10 - Write Filemarks (6) / Synchronise Buffer
0x11 - Space (6)

[mark_k]

You should be able to software-dump (most of) the ROM if that's easier than removing the chip. (Dump the 32KB at board_address+32KB using your favourite monitor program.)

[mark_k]

Originally Posted by alexh

0x02 - ???
0x10 - Write Filemarks (6) / Synchronise Buffer
0x11 - Space (6)

Thanks, the intended commands $10 and $11 aren't tape-related. All three are probably vendor-specific to some type of SCSI-ST-506 controller, but I'm not sure which. $02 could be "READ SYNDROME", but like the others, the device command doesn't actually transfer any data after issuing the command.

Edit: Actually I think you're right about commands $10 and $11! The inmate.device code puts IO_LENGTH in CDB bytes 2-4 which corresponds with those SCSI command definitions. And the SCSI-bus-scan routine which checks for (hard) drives, doesn't issue TEST UNIT READY or READ CAPACITY for SCSI ID 6. Did Spirit Technology market a tape drive too???

[Toni Wilen]

Inmate emulation is now done but it crashes after reading some RDB blocks. Possible due to ROM being corrupted? (It suddenly jumps to data area, it seems to happen dos tries to do something indirectly)

[mark_k]

Could that happen if the filesystem-loading code doesn't handle reloc32 hunks? Which filesystems are in your test HDF RDB? Does the same happen if you have either no filesystem, or the FFS from WB 1.3?

There's an extra e in your git commit:
{ _T("Spirite Technology InMate")

Edit to add: Check this:

MOVEA.L	(_LSEGBuf).L,A1
MOVE.L	(A1),D0
CMP.L	#'LSEG',D0
BNE.W	lbC0005A0

BSR.W	CalcRDBSectorChecksum
TST.L	D0
BNE.W	lbC0005A0

MOVE.L	(lsb_LoadData,A1),D6
DIVU.W	#492,D6	;492 = 123*4
ANDI.L	#$FFFF,D6
ADDI.L	#1,D6
MOVE.L	D6,D0
MULU.W	#492,D0
MOVE.L	D0,(lbL0005EA).L
MOVE.L	#(MEMF_PUBLIC|MEMF_CLEAR),D1
MOVE.L	(lbL0005EA).L,D0
MOVEA.L	(_SysBase).L,A6
JSR	(_LVOAllocMem,A6)
MOVE.L	D0,(lbL0005E6).L
BEQ.W	lbC0005A0

It looks like the driver expects the first longword of lsb_LoadData to contain the number of sectors the filesystem occupies???

[Toni Wilen]

I noticed the same. It can't work with any normal filesystem (It gets 000003f3 as size so it loads only first 3 filesystem blocks...)

This is the worst filesystem loader ever:
- loads the filesystem like it is plain single binary file (must be single hunk)
- assumes no relocations
- Something (installer?) patches the filesystem so that this crappy loader knows how to load it (and only if it has single hunk and no relocs)

This is not RDB compatible loader.

(But at least RDB without FFS installed and OFS partitions only do work!)

[mark_k]

Originally Posted by idrougge

I could possibly dig up documentation for the InMate, our user group has two.

Could you check/dump the ROM of the other InMate? BBoAH board pic seems to show an EPROM with V1.2 on its label. inmate.device version in the dumped ROM is 1.0.

[Toni Wilen]

And is there install disk? There is no way hdtoolbox can be used to configure any FFS partitions due to weird filesystem loader. (At least with 1.0 ROM)

[idrougge]

It seems not, but I'll ask around.

[mark_k]

Was the InMate ROM dumped using software on the Amiga, or by removing the EPROM and reading it with a chip programmer?

The reason I ask is, there are some "holes" in the ROM image which may or may not be due to software-dumping. Two bytes at offset $20 are 0. Those correspond to board offsets $40 and $42. Bytes $40-$4F are also 0, corresponding to board offsets $80, $82, ..., $9E. The SCSI chip appears at those addresses.


Regarding filesystems, the first longword needs to be the byte length (not HUNK_HEADER). Assuming you have a single-hunk, no-relocs filesystem, patching it for the InMate could be quite simple. Does HDToolBox require that a selected filesystem be an Amiga load file, or does it just write the file data straight to the LSEG blocks?

The Spirit developer used the same "technique" when embedding the inmate.device load file in the ROM image; if you check using a hex editor, the longword at offset $4C00 is $00002674. Replace that with $000003F3, extract $2674 bytes from there and you have the inmate.device load file. [Can that be used with BindDrivers?]
The ROM code which copies it to RAM does seem to handle its reloc32 hunk...

[Toni Wilen]

Any possibility to get at least sharp photo of the board? (existing photos are too blurry)