Gigatron Arriba HD

[mark_k]

I noticed the Gigatron Arriba HD on amiga.resource.cx. Internal IDE controller for A500, plugs into 68000 socket. AutoConfig mfr/product 2109/1.

Here's some info if you feel like knocking another one off the "WinUAE doesn't emulate this yet" list...

There are two 32KB PLCC EPROMs on the board. Maybe a jumper selects which half is active for disabling autoboot??? Probably no actual ROM dumps online, but there's a loadable driver on the software disk. It could be fairly easy to extract/construct a working ROM image from that.

ROM at board address, IDE registers start at board+$8000:
$8000.L data: Driver reads/writes longwords
$8200.B error/features
$8400.B sector count
$8600.B sector number
$8800.B cylinder low
$8A00.B cylinder high
$8C00.B device/head
$8E00.B command/status

Driver doesn't support HD_SCSICMD. Has "special" commands at 22, 23, 24, probably used by PrepArriba. Command 24 issues ATA FORMAT TRACK command.

Incomplete disassembly:

https://www.media!fire.com/file/aawd2azboj6v7g3/arriba_disasm_20171201.tar.gz

[Toni Wilen]

Done, at least booting install disk mounts existing HDF. Which is good enough for me when there is no ROM dump

[mark_k]

One hour from feature request to implemented. Is that a record?

Command 22 seems to read RDB and mount partitions. Another one to add to the don't-try-TD_GETGEOMETRY blacklist for filesystems?
Command 23 does something with sprites???
Command 24 issues FORMAT TRACK for the track specified by IO_OFFSET. (Also changes mouse pointer before & after?)

I set up a config with 20MB HDF and booted from the Arriba install disk:

https://www.media!fire.com/file/cowo39ycn2ddmiv/A500_Arriba.7z

This log output:
IDE4 identify drive
IDE4 initialize drive parameters, CYL=615,SPT=17,HEAD=4
IDE4 read off=0, sec=1 (0) lba48=0

On running PrepArriba I clicked O.K. to "LowLevel format the drive". Mouse pointer turned to BUSY for a *long* time with no log output. But it did continue eventually (maybe some driver timeout?). On asking to DOS format and clicking O.K., get "ERROR: Mount failed!" requester.

PrepArriba issues arriba.device command 24, which issues FORMAT TRACK ($50) command to the drive. That's probably the reason for the hang. If you look at Command24_routine, after writing $50 to the command register it writes 512 bytes to the data register. I guess whichever drive actually supports that command fills all sectors of the track with that data???

Also check the routine lbC00033A. It sets the mouse(?) sprite to one which says "ANARCHY IN GERMANY" !!!???

[Toni Wilen]

Implementation actually took less than 30minutes. Add a device descriptor entry, some copy&paste and renaming and finally write address to IO register mapping. Done.

This seems to be first driver that uses FORMAT TRACK. FORMAT TRACK emulation only returned "all ok" but it should first take block size worth of data. Driver probably timed out when it waited for DRQ.

Apparently FORMAT TRACK can only work in CHS mode ("Track" does not exists in LBA addressing) and ATA-2 spec says "The implementation of the FORMAT TRACK command is vendor specific. It is recommended that system implementations not utilize this command"

EDIT: and ATA-1 says "The implementation of the Format Track command is vendor specific. The actions may be a physical reformatting of a track, initializing the data field contents to some value, or doing nothing". So why did they use it?

[mark_k]

Fake/home-made boot ROM image, untested but will hopefully work:

https://www.media!fire.com/file/mp8zznbs6bhdugw/Arriba_fake_ROM.bin.gz

I just took the code hunk from arriba.device, filled in the first few bytes of ExpansionRom data and padded it to 8KB.

[Toni Wilen]

FORMAT TRACK fixed. Installer seems to work now.

[mark_k]

The IBM PC/AT Technical Reference (26MB PDF) has a description of the FORMAT TRACK command on page 609. I'll type that up here:

"Format Track: The track specified by the task file is formatted with ID and data fields according to the interleave table transferred to the buffer. The interleave table is composed of two bytes per sector as follows: 00, Physical Sector 1, 00, Physical Sector 2, ... 00,Physical Sector 17. The table for 2-to-1 interleave is: 00, 01, 00, 0A, 00, 02, 00, 0B, 00, 03, 00, 0C, 00, 04, 00, 0D, 00, 05, 00, 0E, 00, 06, 00, 0F, 00, 07, 00, 10, 00, 08, 00, 11, 00, 09. The data transfer must be 512 bytes even though the table may be only 34 bytes. The sector count register must be loaded with the number of sectors per track before each Format Track command. An interrupt is generated at the completion of the command; the Format Track command supports no error reporting. A bad block may be specified by replacing a 00 table entry with an 80. When switching between drives, a restore command must be executed prior to attempting a format."

(I think the A2090 and other ST-506 controllers support similar functionality.)


There's some info on FORMAT TRACK in the ATA-1 specification; see pages 42-43 of the PDF here.


Note: arriba.device seems to always write 0 to the sector count register, which differs from the text above.


Edit to say: So you could have FORMAT TRACK be a no-op, or maybe have it zero-fill the sectors of the specified track.

[Toni Wilen]

All FORMAT-type commands (both IDE and SCSI) write nothing in emulation. They are obsolete and mainly meant for low level formatting and testing for bad blocks. So far no utility checks data that format writes, they only check that format and/or reading succeeds. (no bad blocks).

They are also track based which can cause problems if geometry is not exactly right (Out of bounds access, writing too much or less). All other sector based commands may still (accidentally or not) work just fine.

Note: arriba.device seems to always write 0 to the sector count register, which differs from the text above.

I noticed and this probably makes it incompatible with some IDE drives that validates it.

[mark_k]

Did you hook up boot ROM support yet?

Originally Posted by Toni Wilen

EDIT: and ATA-1 says "The implementation of the Format Track command is vendor specific. The actions may be a physical reformatting of a track, initializing the data field contents to some value, or doing nothing". So why did they use it?

To set the interleave. PrepArriba asks you to enter the interleave before it starts the low-level format.

Getting interleave right could significantly improve performance. For a drive with no read-ahead cache, reading each successive sector could require an additional disk revolution (1/60 sec at 3600rpm) if the host isn't fast enough for 1:1 interleave. And OFS reads one sector at a time...

Can you dump the 512 bytes data sent after FORMAT TRACK to the log? Would be interesting to see what PrepArriba sends.

ATA-1 has a more extensive description of FORMAT UNIT and actually recommends zero-filling.

9.8 Format track

The implementation of the Format Track command is vendor specific. The
actions may be a physical reformatting of a track, initializing the data field
contents to some value, or doing nothing.

The Sector Count Register contains the number of sectors per track.

The track address is specified in the Cylinder High and Cylinder Low
Registers, and the number of sectors is specified in the Sector Count
Register. When the command is accepted, the drive sets the DRQ bit and waits
for the host to fill the sector buffer. When the sector buffer is full, the
drive clears DRQ, sets BSY and begins command execution.

The contents of the sector buffer shall not be written to the media, and may
be either ignored or interpreted as follows:
+=============-=============-=============-==========================+
|DD15 ---- DD0|             |DD15 ---- DD0|                          |
|-------------|             |-------------+--------------------------|
| First sector|             | Last sector | Remainder of buffer      |
| descriptor  | : : : : : : | descriptor  | filled with zeros        |
+====================================================================+

One 16-bit word represents each sector, the words being contiguous from the
start of a sector. Any words remaining in the buffer after the representation
of the last sector are filled with zeros. DD15-8 contain the sector number.
If an interleave is specified, the words appear in the same sequence as they
appear on the track. DD7-0 contain a descriptor value defined as follows:
    00h - Format sector as good;
    20h - Unassign the alternate location for this sector;
    40h - Assign this sector to an alternate location;
    80h - Format sector as bad.

    NOTES
    9 - Some users of the ATA drive expect the operating system partition table to
    be erased on a Format command. It is recommended that a drive which does not
    perform a physical format of the track, write a data pattern of all zeros to the
    sectors which have been specified by the Format Track command.
    10 - It is recommended that implementors resassign data blocks which show
    repeated errors.

[Toni Wilen]

Yeah, but did 1990+ IDE drives really use interleave? It sounds like the driver was originally designed for something more ancient.

FORMAT gets this data: (the rest was zeros)

00019434 0001 000A 0002 000B 0003 000C 0004 000D  ................
00019444 0005 000E 0006 000F 0007 0010 0008 0011  ................
00019454 0009 0000 0000 0000 0000 0000 0000 0000  ................¨

Did you hook up boot ROM support yet?

No. Problem is: where it is supposed to be located? I am not just going to select some random offset between 0 to 0x8000.

[mark_k]

That data corresponds to 2:1 interleave which is the PrepArriba default. From looking at the adverts, the board was always bundled with a drive so I guess whichever drives they used (initially 20MB, later also 40MB and 60MB) did support changing it. And the developer didn't have to worry about supporting a large variety of different manufacturers' drives. [BTW, text in driver mentions Oliver Kastl who later wrote IDEfix97.]

The latest ad pic indicates they sold an A2000 Zorro II board version. Perhaps that had similar or identical hardware???

It's extremely likely that ROM appears in the first 32KB of board space, apart from the first 256 bytes. While I put ExpansionRom data in the first bytes of the edited "fake" attempt I uploaded, after thinking about it I reckon it's more likely that ExpansionRom data and AutoConfig registers were implemented in the two GAL chips.

Why? Look at the arriba.device code hunk. Apart from MOVEQ #-1,D0 / RTS so as not to crash if run from CLI, the first 256 bytes of data are all $FF so as not to interfere with that. So here's another attempt at a boot ROM (same as first except all $FFs at the start):

https://www.media!fire.com/file/f8tzxndjutz9h4i/Arriba_boot_ROM_try2.bin.gz

Looking at the board pic there are two 256kbit EPROMs, so 64KB total. Given the size of the driver, maybe 256kbit chips were used simply because they were the smallest capacity available?

There's a jumper near the top right. Could select which halves of the EPROMs are active, or perhaps more likely, simply control the diag valid bit in ExpansionRom data. It's next to one of the GAL chips.


Also, I wonder if the alternate status register is implemented, just not used by the driver?

[Toni Wilen]

ROM can't work. da_Size is only 0x88 and there is no code that copies the rest of the driver.
(EDIT: rom loading supported)

[mark_k]

It runs the driver code directly from ROM. Check the DiagPoint routine. It puts board address in D0, then adds that to the NAME, IDSTRING and INIT fields of the (RAM copy of) resident tag.

[Toni Wilen]

Right, I did wrong length calculation

Now it works, IDE had only a special case for single board (golem fast scsi) to support code execution in ROM. Other boards returned more or less random data..

[mark_k]

If you run LedArriba ON, that tells arriba.device to create a sprite showing drive activity near the top left of the screen.

I think the "ANARCHY IN GERMANY" sprite should appear for 10 seconds when CMD_STOP is issued to arriba.device then.

[mark_k]

By the way, the ICD AdIDE icddiskide.amhd (for use with A-Max) can issue IDE FORMAT TRACK when the Mac tries to issue SCSI FORMAT UNIT. I didn't bother checking whether that works, need to find some old Mac SCSI formatting program first.