A500 supra scsi interface

[Toni Wilen]

Originally Posted by mark_k

Thanks for doing that. Unfortunately I screwed up for a second time in telling you what address range to dump!

Could you try again, but this time with start address $E90000 and end $E98000?

SBT3V2.dmp is fine. Works in emulation after removing odd bytes (does Test Unit Ready + Reads blocks 0 and 1, I guess it does not support RDB?)

EDIT: SupraChkRom confirmed. "ROM checksum = 204529664. ROM is good: Series II Autoboot ROM -- AMAB3"

[mark_k]

That's good news, but strange; looking at the ROM dump in a hex editor there's very little data there (the ROM data is duplicated, so there's less than 2KB of code). Perhaps it contains just enough code to load the actual driver from the first sectors of the hard disk? Anyone have the Supra Series II software disks?

[Toni Wilen]

Yes, it is tiny, only AMAB5 and 6 are bigger. (boot rom collection in the zone updated)

[clh333]

Originally Posted by Toni Wilen

SBT3V2.dmp is fine. Works in emulation after removing odd bytes (does Test Unit Ready + Reads blocks 0 and 1, I guess it does not support RDB?)

EDIT: SupraChkRom confirmed. "ROM checksum = 204529664. ROM is good: Series II Autoboot ROM -- AMAB3"

I have three Series II (1.09f) disks: Boot, Tools and RAM.

When I run the SupraChkRom utility that is on the Version 3.8 Supra Boot disk, having booted from that disk, I get the following:

SupraChkRom - V.1.2 - May 7 1992
Found Supra Hard disk controller.
Board type: A500 ByteSync/XP
ROM checksum = 204529664
ROM is good: Series II AutoBoot RROM - AMAB3

If I do not boot from v.3.8 none of these utilities will execute. I gather from that, and my experiences of today (described elsewhere), that very little of what occurs during the Supra boot is executed from the ROM itself. Enough perhaps to pre-empt the Kickstart ROM, receive a signal from the drive and check for the presence of a DOS floppy in df0:, then point to routines on the hard disk.

Shall I upload the new range or not? Or anything else?

-CH-

[Arnie]

I would upload what you have. someone may find them useful.

[clh333]

Originally Posted by Toni Wilen

EDIT: SupraChkRom confirmed. "ROM checksum = 204529664. ROM is good: Series II Autoboot ROM -- AMAB3"

This is a little off the thread but pertinent to the Supra 500 interface.

The pre-XP board used 16 1x1Mb RAM ICs to attain 2 Mb. expansion RAM. The XP board used 16 1x4Mb. ICs to attain 8 Mb expansion RAM. Mine has 16 1x1s.

Given that the ROM check utility identifies the board as "A500 ByteSync/XP" would it be possible to populate with the higher density chips?

-CH-

[mark_k]

Yes the AMAB3 ROM is tiny. It contains just enough code to read the RDB and load code pointed to by rdb_DriveInit.

The later Series III Supra ROM doesn't use that method. Instead the later ROMs contain the complete device driver. In fact the 3.8b tools disk contains a RemoveDriveInit program to remove DriveInit code from the RDB. Don't run that yourself though, since removing it will prevent your system with AMAB3 ROM from booting!

No need to try dumping memory again since we already got the AMAB3 code successfully.

But it would be useful if you could create disk images (DMS files) for your three floppy disks. Make sure the disks are write-protected. Then use commands like
DMS READ ram:Supra_Boot.DMS FROM DF0: NOZERO
to create a DMS file from each disk.

[clh333]

As a final note: I reached my objective today, by recognizing, formatting, mounting and addressing an Iomega Zip 100 drive attached to the Amiga 500 through its Supra 500 SCSI interface.

To do so it was necessary to update the software used by the Supra; what was alluded to in version 1 was realized in version 3...

The new version of the Supra tools recognized the ZIP device as ID5, but only after removing termination resistor packs at the HD, which was intermediate in the chain. The Supra HD utility offered defaults for the unformatted ZIP disk which I modified to change the volume name, device ID and partitions.

I then commenced a low-level format of the disk, which hung the machine during the mapping of the disk - one of many hangs during the day. After reboot and some head-scratching I wrote the RDB with new parameters and then with no better plan I opened a DOS cli and invoked a format of my new volume.

To my surprise, DOS complied, and after 6000+ cylinders I had a usable ZIP disk with an icon on the workbench. I dragged several folders from the HD to the ZIP and then invoked the Park utility, which parked the HD and ejected the ZIP.

Q.E.D.

(I will be upgrading the boot ROM soon - doing this from a floppy drive is like having open-heart surgery and going in through the foot.)

Thanks to all for your help.
Charles Hudson
clh333

[thomas]

Whenever you see "low-level format" in any program, keep your hands away from it by all means. Stick a piece duct tape on the monitor where the button would appear so that you never see it nor click it.

Whenever you see "quick" next to "format" in a program, choose "quick". There is no need at all to do a full format of a harddrive of any kind. All harddrives available today come already low-level formatted by the manufacturer and there is no software which can change this. For harddrives the "format" button does nothing useful, it only wastes time and energy.

Only for floppy disks you might need to use "format" rather than "quick".

[mark_k]

Originally Posted by clh333

The pre-XP board used 16 1x1Mb RAM ICs to attain 2 Mb. expansion RAM. The XP board used 16 1x4Mb. ICs to attain 8 Mb expansion RAM. Mine has 16 1x1s.

Given that the ROM check utility identifies the board as "A500 ByteSync/XP" would it be possible to populate with the higher density chips?

Possibly, definitely if the manual says you can.

You can confirm for sure which board type you have by comparing it with the pics on amiga.resource.cx: SupraDrive 500, SupraDrive 500/XP.

Some easily noticeable differences are: 500/XP has 16 sockets for RAM chips, and text "AMIGA 500 HARD DISK w/ RAM" near the Amiga connector.
The original model has no RAM sockets and its ROM is next to the 5380 SCSI chip. There is a daughterboard which holds RAM chips.

Looking at the 500/XP board pic, there is 512K, 1MB and 2MB text below each row of RAM sockets. That shows the order in which you'd fill the sockets with 1Mbit RAM chips. But the picture shows four 4MBit chips in the "1MB" row. Presumably that configuration does work. Or maybe whoever owns that specific board was trying to use 4Mbit chips and thought that would work?

[clh333]

Originally Posted by mark_k

Possibly, definitely if the manual says you can.

I have a socketed daughterboard. I just don't know if the controller has the ability to read the higher density memory, or again perhaps the limitation is in ROM; i.e. never looks above 2 Mb.

I'd be willing to try it if I could locate the ICs. But that's another thread: What can I do to improve / expand the A500 without losing backward compatibility? Virtually everything I have for the Amiga is pre-1990; WShell 1.2, DPaint3, games, etc.

BTW: Uploaded 3 disk images 10:20 AM EDT.

-CH(eers!)-

[TjLaZer]

Is the AMAB6 natively a 8k or 16k file?

[mark_k]

Originally Posted by clh333

But that's another thread: What can I do to improve / expand the A500 without losing backward compatibility? Virtually everything I have for the Amiga is pre-1990; WShell 1.2, DPaint3, games, etc.

BTW: Uploaded 3 disk images 10:20 AM EDT.

-CH(eers!)-

Thanks very much for uploading the disks! I don't think a Series II SupraTools disk was available online before now.

I think the best upgrade would be to install a Kickstart 3.1 ROM. Then you can use Workbench 3.1 and most more recent software which often requires at least Kickstart 2.04. Backward-compatibility is surprisingly good for OS-legal software. For things like games and demos there is WHDLoad which allows many to be installed to hard disk. You could also buy a Kickstart ROM switcher to allow both 1.3 and 3.1 ROMs to be fitted.

[mark_k]

I noticed that your SupraBoot disk (version 1.09f) is slightly earlier than supraboot.dms available from www.l8r.net (version 1.10c).

The version of supradirect.device on your disk has the same bug as I mentioned in this posting. I've attached a fixed version of supradirect.device from your SupraBoot disk here. You should make a copy of your SupraBoot disk then replace devs/supradirect.device with this fixed version.

The problems you were having earlier may be due, in part at least, to that bug. I don't know how Supra never noticed such a serious bug. Maybe they only used auto-booting setups in-house? (The SupraAuto.DevInit file used for auto-booting doesn't have the bug.)

[TjLaZer]

The supra word sync controller works great with workbench 3.1 along with the AMAB6 ROM

[TjLaZer]

Thanks for the update. Will have to update my Supra 4x4. Was the AMAB5, 6 been fixed?

[clh333]

Originally Posted by mark_k

I noticed that your SupraBoot disk (version 1.09f) is slightly earlier than supraboot.dms available from www.l8r.net (version 1.10c).

The version of supradirect.device on your disk has the same bug as I mentioned in this posting. I've attached a fixed version of supradirect.device from your SupraBoot disk here. You should make a copy of your SupraBoot disk then replace devs/supradirect.device with this fixed version.

I am now booting from a floppy: v.3.8 of SupraBoot. Part of the boot sequence offers to run SupraHDTools, which I accept, and with that I confirm that the HD and ZIP disk are mounted. If I skip this step the ZIP disk goes unrecognized. I think HDTools chains two other utilities to inventory the SCSI bus; I may try invoking them directly to see if that is the case.

I hope to replace the boot ROM with v6, at which point the bug in version 1.09 should be moot. They DID find the bug eventually, didn't they?

Thanks again to those who suggested the DSM disk compression and LHA file unpacking utilities. I have now "mashed" some 55 commercial titles to the ZIP disk. These are variety of applications not including games, which I have yet to process. There are another 50 of those, plus perhaps 25 or more Fred Fish disks and whatever else was downloaded from various BBS.

All in all more than 200 disks; more than the poor ST125 could hold. Hence my urgency to find a solution for the ZIP device. I will publish an inventory when done. There may well be some rarities among the lot.

(Word Perfect comes to mind: I recall that when WP announced they were dropping support for the Amiga version I wrote to them and implored them to reconsider. Their answer was that 90% of their sales came from the IBM / PC version, 9% from Apple and the remaining 1% was divided among all other brands. I had to agree they had a point. But now I am well into the 99th percentile with one of the few surviving copies.)

-CH-

[mark_k]

Originally Posted by clh333

I hope to replace the boot ROM with v6, at which point the bug in version 1.09 should be moot. They DID find the bug eventually, didn't they?

I assume so. But I may have been a bit pessimistic about the bug's effects. It may be that, purely by luck/chance and depending on your Kickstart version, it doesn't severely affect some Supra controllers.

Originally Posted by clh333

All in all more than 200 disks; more than the poor ST125 could hold. Hence my urgency to find a solution for the ZIP device. I will publish an inventory when done. There may well be some rarities among the lot.

It's definitely a good idea to save/archive disks before they get so old that the data becomes unreadable. I'd recommend you always use the NOZERO option to DMS when archiving disks by the way.

[Jope]

Originally Posted by mark_k

I'd recommend you always use the NOZERO option to DMS when archiving disks by the way.

This can't be stressed enough.. DMS is a bit buggy and you might end up with incorrect data if you don't use NOZERO.

[clh333]

Originally Posted by Jope

This can't be stressed enough.. DMS is a bit buggy and you might end up with incorrect data if you don't use NOZERO.

Thank you for the suggestion. Reading the DMS documentation it states that in EXTREME circumstances this option may be needed: "Generally you will rarely if ever need to use this option." So I omitted it. Guess I have to start over.

Two questions:

Does the NOZERO option still apply the default "BEST" compression, or will the resulting archive be 880k+ in length? In other words: Is there another flag I should also set as a "best practice"?

The archive activity, processing 80+ disks recently, appears to have created a mis-alignment in my external floppy drive. I have been booting from df0: in order to recognize my ZIP drive (archive) and reading from df1:. Drive df1: has started reporting read and checksum errors on disks inserted into it.

I have two of these 1010 devices; I had cleaned the heads in both before commencing this project. Now the one that has not seen heavy use reads a disk that the other cannot. I conclude this is an alignment problem. My question is: Is there a way to align it or a substitute 3.5 that I can use? I have spares from PC usage...

Once again, your suggestions are greatly appreciated.

Charles Hudson
clh333