Click Here
home features news forums classifieds faqs links search
6071 members 
Amiga Q&A /  Free for All /  Emulation /  Gaming / (Latest Posts)
Login

Nickname

Password

Lost Password?

Don't have an account yet?
Register now!

Support Amigaworld.net
Your support is needed and is appreciated as Amigaworld.net is primarily dependent upon the support of its users.
Donate

Menu
Main sections
» Home
» Features
» News
» Forums
» Classifieds
» Links
» Downloads
Extras
» OS4 Zone
» IRC Network
» AmigaWorld Radio
» Newsfeed
» Top Members
» Amiga Dealers
Information
» About Us
» FAQs
» Advertise
» Polls
» Terms of Service
» Search

IRC Channel
Server: irc.amigaworld.net
Ports: 1024,5555, 6665-6669
SSL port: 6697
Channel: #Amigaworld
Channel Policy and Guidelines

Who's Online
10 crawler(s) on-line.
 130 guest(s) on-line.
 0 member(s) on-line.



You are an anonymous user.
Register Now!
 saimo:  8 mins ago
 DiscreetFX:  9 mins ago
 sibbi:  10 mins ago
 vox:  20 mins ago
 kolla:  31 mins ago
 Mr_DBUG:  32 mins ago
 Gunnar:  1 hr 11 mins ago
 retrofaza:  1 hr 23 mins ago
 A1200:  1 hr 35 mins ago
 MEGA_RJ_MICAL:  1 hr 40 mins ago

/  Forum Index
   /  Classic Amiga Hardware
      /  Anyone still using A2090/A2091/A590 "XT" hard disks?
Register To Post

Goto page ( Previous Page 1 | 2 )
PosterThread
klx300r 
Re: Anyone still using A2090/A2091/A590 "XT" hard disks?
Posted on 25-Nov-2016 22:22:21
#21 ]
Elite Member
Joined: 4-Mar-2008
Posts: 3833
From: Toronto, Canada

Quote:

Beans wrote:
@klx300r

Quote:
of course that will take 30+ years to prove & by then we'll all have robots keeping all the information for us anyhow


At 55, I doubt I will live to be able to contest your contention.
I guess I'll have to mull it over on the way to work in my flying car.

BUT, if the last 30 years are any indication, what the world will be like in thirty years is going to be hard to predict.


hehe I'm not too far behind ya and I intend to still be around in 30 years messing on my miggies when I'm 80, God willing of course!

_________________
____________________________
c64-2sids, A1000, A1200T-060@50(finally working!),A4000-CSMKIII
! My Master Miggies- Amiga 1000 & AmigaOne X1000 !
mancave-ramblings
X1000 I BELIEVE

 Status: Offline
Profile     Report this post  
Hypex 
Re: Anyone still using A2090/A2091/A590 "XT" hard disks?
Posted on 26-Nov-2016 15:39:46
#22 ]
Elite Member
Joined: 6-May-2007
Posts: 11180
From: Greensborough, Australia

@olsen

Quote:
The last thing to do would be to break something that should not be broken because there is no replacement for it.


On that note where would the new HDToolbox/ProdPrep go? I suspect if someone is still running an XT drive, possibly on 1.3, they still likely would have Workbench disks or an Installer disk. And if they haven't needed to touch the software for the past 20 years they would be doing well!

In any case would also supplying an old "classic" version be feasible?

I used to have an A590. Somehow I convinced my dad I needed one, because I was an Advanced User * like it said in the commercial, and he forked out $750 to get me one. Infact, even my A500 would have cost my dad around $1,000 of our money, and I honestly don't know how he spent that much on me one Christman, let laone afforded it. Big difference between a $100 C16 and $1,000 Amiga.

* In fact, Advanced User would have been true. I was getting into music, graphics and especially programming. And my collection of floppy files was bursting at the seams. I was ready to move on from the single disk I managed to compact the three disk KindWords onto. And I had no external floppy!

Quote:
You could not fix the limitations of the A2090 and its DMA controller, but you could work around them.


I could see it as an advanced setting but to me the driver should have known the values internally or known the limits. Since the relation between the driver and hardware was usually close.

Quote:
The same later happened again on the Amiga 4000 and Amiga 1200 when the IDE and notebook drives available at the time did not work as well as the standard would have required them to.


Yes we had to max them to 0x1FE00 IIRC. And this reveals another problem. Blurring of device drivers. Where the SCSI driver also handles IDE.

I also ran into trouble myself when I aquired an A4000. I had come from my A1200 Ferret SCSI setup which used the max 0x7FFFFFF. And so, since the A4000 was considered to be superior I thought it would easily match that. Nope. I had a WarpEngine, don't recall reading much about MaxTransfer, so set it to max. I of course got errors. Didn't know what it was. IIRC I asked on forums and then got some clue about MaxTransfer but it isn't always the first advice you get. Now it's usually the first thing I mention.

Now that is a specific example. Really the driver should have had limits internally. Since it was mated to specific hardware, especially for a ROM driver, on card. . So I really think MaxTransfer and Mask should have been an inside job for third party cards and drivers. And even for OS drivers like scsi.device, if it knew what hardware it was talking too and it really should have known, including what Amiga model, it should have known the limits.

Quote:
I used to believe that the "Rigid disk block" (RDB for short) partitioning scheme used by the Amiga allowed for disks to be read by all Amiga SCSI (or IDE) controllers.


In what sense? I mean in what way is it not compatible? So taking a HD formatted on one controller may not work if used with another?

I know of examples like GVP hardware refusing to boot on anything but FFS. Which looks like they are trying hard to limit it. Even though that's another matter.

Quote:
Let's say that the disk tells "HDToolbox" that there are 4096 bytes to a sector. Then "HDToolbox" will lay out the RDB with 4096 bytes per sector. Few hard disk controllers will even recognize this layout.


I was reading into this sort of thing recently. Infact, I was recently learning how to scan an RDB for a boot block and also scan partitions. While writing my first Linux program that scanned the RDB for a bootable volume.

Quote:
You need this with SCSI storage devices, which when probed by the SCSI host controller may take a while to respond.


Okay for SCSI I can understand. It never gave me too much trouble on my A1200 when I used SCSI or IDE. But on an A1 it can be a hassle. It's confusing, since Kickstart is loaded from disk. Now if the Kickstart loads and the last drive marked doesn't contain Workbench then the system will ask for Workbench. Wait it just loaded Kickstart off the disk! How can it lose the disk?! That's a real example and it can baffle people as you can imagine. It's also annoying to fix. Booting an OS4 CD is way slower than booting a classic OS3 Install floppy.

Last edited by Hypex on 26-Nov-2016 at 03:55 PM.

 Status: Offline
Profile     Report this post  
olsen 
Re: Anyone still using A2090/A2091/A590 "XT" hard disks?
Posted on 27-Nov-2016 8:56:39
#23 ]
Cult Member
Joined: 15-Aug-2004
Posts: 774
From: Germany

@Hypex

Quote:

Hypex wrote:
@olsen

Quote:
The last thing to do would be to break something that should not be broken because there is no replacement for it.


On that note where would the new HDToolbox/ProdPrep go?


It would keep sitting on the "Install" disk of the Workbench disk set.

Quote:
I suspect if someone is still running an XT drive, possibly on 1.3, they still likely would have Workbench disks or an Installer disk. And if they haven't needed to touch the software for the past 20 years they would be doing well!

In any case would also supplying an old "classic" version be feasible?


What I am currently working on concerns the "classic" version only. The problem I need to get a handle on is in how far the old hardware can be supported while at the same time not making it too hard to maintain/update old code which never was particularly geared towards maintainability.

Quote:
I used to have an A590. Somehow I convinced my dad I needed one, because I was an Advanced User * like it said in the commercial, and he forked out $750 to get me one. Infact, even my A500 would have cost my dad around $1,000 of our money, and I honestly don't know how he spent that much on me one Christman, let laone afforded it. Big difference between a $100 C16 and $1,000 Amiga.

* In fact, Advanced User would have been true. I was getting into music, graphics and especially programming. And my collection of floppy files was bursting at the seams. I was ready to move on from the single disk I managed to compact the three disk KindWords onto. And I had no external floppy!


I know the situation When work on "Legend of Faerghail" as a commercial product commenced, I requested a hard disk drive for the duration of the development work. The scope of the game with all its assets and of course the program itself was already too unwieldy to be wrangled with two floppy disk drives.

Quote:

Quote:
You could not fix the limitations of the A2090 and its DMA controller, but you could work around them.


I could see it as an advanced setting but to me the driver should have known the values internally or known the limits. Since the relation between the driver and hardware was usually close.
I looked at the driver code, and one thing stuck out: this was possibly the simplest solution which worked (although it may not have appeared so to the authors at the time).

Because the Amiga platform was just beginning to take off, it was hard to future-proof the hardware and driver designs. In retrospect it seems odd that trackdisk.device/hddisk.device/scsi.device were very thin layers on top of hardware whose properties you had to know before you could use them correctly.

For example, none of these drivers can read data in chunks smaller than the sector size which so it happens used to be 512 bytes. But in the respective API nothing prevents you from asking for 7 bytes to be read, beginning at the 115th byte of the disk. Both read/write offset and read length are expressed in bytes, not in sectors. There is an odd lack of hardware abstraction in the drivers, while the I/O request API design already is abstract to begin with.

These disk drivers were supposed to go into ROM, and this eventually happened. Fixing a "broken" driver became so much harder: Commodore didn't just have to build and test it, the driver had to be cast into ROMs or EPROMs, the Amiga dealers had to replace the ROMs, etc.

So the limitations stayed in and it became easier to work around them rather than to solve them.

Quote:


Quote:
The same later happened again on the Amiga 4000 and Amiga 1200 when the IDE and notebook drives available at the time did not work as well as the standard would have required them to.


Yes we had to max them to 0x1FE00 IIRC. And this reveals another problem. Blurring of device drivers. Where the SCSI driver also handles IDE.


If I remember correctly, this was a customer support issue. Much of the existing software was written to use "scsi.device" by default, and short of modifying the software which interacted directly with it (e.g. "HDToolbox" and "ProdPrep") to figure out what other driver to use, it was easier to stick with "scsi.device".

This is where the limitations of the Amiga device driver API really hurt. You couldn't query which device drivers were likely candidates for managing mass storage hardware. You had to go by device name and hope for the best.

Quote:

I also ran into trouble myself when I aquired an A4000. I had come from my A1200 Ferret SCSI setup which used the max 0x7FFFFFF. And so, since the A4000 was considered to be superior I thought it would easily match that. Nope. I had a WarpEngine, don't recall reading much about MaxTransfer, so set it to max. I of course got errors. Didn't know what it was. IIRC I asked on forums and then got some clue about MaxTransfer but it isn't always the first advice you get. Now it's usually the first thing I mention.

Now that is a specific example. Really the driver should have had limits internally. Since it was mated to specific hardware, especially for a ROM driver, on card. . So I really think MaxTransfer and Mask should have been an inside job for third party cards and drivers. And even for OS drivers like scsi.device, if it knew what hardware it was talking too and it really should have known, including what Amiga model, it should have known the limits.


It should, but there was no precedent for that, with device drivers being very thin layers on top of the hardware rather than more general abstractions.

Some of this may be owed to ROM space considerations. A trackdisk.device or maybe scsi.device which would permit access to data at arbitrary offsets, with arbitrary amounts of data being accessed had to be more complex than what we got.

Also, because of alignment requirements and DMA controller restrictions, the respective driver would have to manage intermediate buffers ("bounce buffers"). What we got was the original trackdisk.device which only allowed data to be read and written to/from buffers stored in chip memory.

With this complexity absent from the drivers it nevertheless had to go somewhere: into the file system layer. Amiga file system design was already very challenging due to lack of documentation and the responsibilities which the dos.library layer offloads to the file systems.

Because the drivers did not bother, the file system had to make sure that it only transferred perfectly aligned sector data to/from the disk ("Mask" setting), allocated from a specific kind of memory ("BufMemType" setting), breaking transfers down into manageable portions ("MaxTransfer" setting), in chunks which were a multiple of the hardware sector size ("SizeBlock" setting).

Each single file system had to reimplement this functionality. Had it been available in the trackdisk/scsi.device, etc. layer there would have been no need for it.

Quote:

Quote:
I used to believe that the "Rigid disk block" (RDB for short) partitioning scheme used by the Amiga allowed for disks to be read by all Amiga SCSI (or IDE) controllers.


In what sense? I mean in what way is it not compatible? So taking a HD formatted on one controller may not work if used with another?

Yes. It just didn't happen because hard disk drives had been using 512 byte sectors for a very long time. Had the manufacturers switched to 2048 or 4096 byte sectors in the early 1990'ies it would have broken a lot of hard disk drivers.

Quote:

I know of examples like GVP hardware refusing to boot on anything but FFS. Which looks like they are trying hard to limit it. Even though that's another matter.

Quote:
Let's say that the disk tells "HDToolbox" that there are 4096 bytes to a sector. Then "HDToolbox" will lay out the RDB with 4096 bytes per sector. Few hard disk controllers will even recognize this layout.


I was reading into this sort of thing recently. Infact, I was recently learning how to scan an RDB for a boot block and also scan partitions. While writing my first Linux program that scanned the RDB for a bootable volume.


So, is the scanning process restricted to 512 bytes per sector or does it permit larger sector sizes, too?

Quote:

Quote:
You need this with SCSI storage devices, which when probed by the SCSI host controller may take a while to respond.


Okay for SCSI I can understand. It never gave me too much trouble on my A1200 when I used SCSI or IDE. But on an A1 it can be a hassle. It's confusing, since Kickstart is loaded from disk. Now if the Kickstart loads and the last drive marked doesn't contain Workbench then the system will ask for Workbench. Wait it just loaded Kickstart off the disk! How can it lose the disk?! That's a real example and it can baffle people as you can imagine. It's also annoying to fix. Booting an OS4 CD is way slower than booting a classic OS3 Install floppy.


Yes, but then CDs are still much slower when it comes to random access, and they store much more data.

 Status: Offline
Profile     Report this post  
Anonymous 
Re: Anyone still using A2090/A2091/A590 "XT" hard disks?
Posted on 27-Nov-2016 12:39:50
# ]

0
0

@olsen

As you don't seem to get anything from me, i gotta hijack this thread

You got PM

...and sorry for ijacking, please, go on

 
     Report this post  
Hypex 
Re: Anyone still using A2090/A2091/A590 "XT" hard disks?
Posted on 2-Dec-2016 16:42:50
#25 ]
Elite Member
Joined: 6-May-2007
Posts: 11180
From: Greensborough, Australia

@olsen

Quote:
It would keep sitting on the "Install" disk of the Workbench disk set.


New 3.1 set?

Quote:
What I am currently working on concerns the "classic" version only.


I mean a 1.3 version. You're not updating this again?

I find it funny how 1.3 was popular, then the tides turned and 3.1 became popular.

Quote:
When work on "Legend of Faerghail" as a commercial product commenced, I requested a hard disk drive for the duration of the development work.


That must be going back. I take it that wasn't a German version of a game based on Fergal Sharkey?

Quote:
In retrospect it seems odd that trackdisk.device/hddisk.device/scsi.device were very thin layers on top of hardware whose properties you had to know before you could use them correctly.


Taking scsi.device as an example, what did it use for it's data transfer? Did it bang hardware from some task or use an another API for the actual grit?

Quote:
Both read/write offset and read length are expressed in bytes, not in sectors.


I noticed that. I saw this as a problem years ago when going past the 4GB barrier. To me I always thought it shouldn't be an offset but a sector index.

Quote:
Much of the existing software was written to use "scsi.device" by default, and short of modifying the software which interacted directly with it (e.g. "HDToolbox" and "ProdPrep") to figure out what other driver to use, it was easier to stick with "scsi.device".


I wonder what the software did that the included HD tools didn't? I had a Ferret and did fine with all the tools included.

There was work in getting those device details off the system drive if you could figure where out it was.

I suppose a virtual scsi.device could have added but that would be a bit of a hack. But, "scsi.device" does imply a SCSI device. And not always suitable for IDE drives.

Quote:
You couldn't query which device drivers were likely candidates for managing mass storage hardware.


Even with OS3.5 NSD patch it wasn't much easier. In fact, AFAIK, that requires going through the entire device list and sending in an IO command to see what's a disk, which isn't that efficient either. Has this been improved for OS4+?

Quote:
What we got was the original trackdisk.device which only allowed data to be read and written to/from buffers stored in chip memory.


What about a standard DMA transfer from a SCSI card on a Zorro bus, does that have to go into chip RAM?

Quote:
With this complexity absent from the drivers it nevertheless had to go somewhere: into the file system layer.


Yes and it had to be done for all partitions to my knowledge making it more annoying. But if you used the card software it didn't matter a smuch.

Quote:
Had it been available in the trackdisk/scsi.device, etc. layer there would have been no need for it.


Yes it becomes apparent it should have been upstream in the device layer. Now if there was a SCSI/IDE commmand to find this info it could have been transparent.

Quote:
Had the manufacturers switched to 2048 or 4096 byte sectors in the early 1990'ies it would have broken a lot of hard disk drivers.


That's interesting. It would have had to be managed in software. I mean the device driver would need toknow about it. A kind of MinTransfer. And Offset alignment.

Quote:
So, is the scanning process restricted to 512 bytes per sector or does it permit larger sector sizes, too?


Actually I think it would be 512 now that you ask. I allocate space for a struct RigidDiskBlock and BootstrapCodeBlock. Which would default to 512 AFAIK. But then use the blocks SummedLongs to checksum it. Which would break on greater than 512. So good point there.

Quote:
Yes, but then CDs are still much slower when it comes to random access, and they store much more data


They do but all we need is Kickstart possibly and OS4 version of Install disk.

 Status: Offline
Profile     Report this post  
olsen 
Re: Anyone still using A2090/A2091/A590 "XT" hard disks?
Posted on 5-Dec-2016 13:25:49
#26 ]
Cult Member
Joined: 15-Aug-2004
Posts: 774
From: Germany

@Hypex

Quote:

Hypex wrote:
@olsen

Quote:
It would keep sitting on the "Install" disk of the Workbench disk set.


New 3.1 set?


Yes. The partitioning tools needed a brush-up, but there wasn't enough time to get this done properly. This update will follow.

Quote:

Quote:
What I am currently working on concerns the "classic" version only.


I mean a 1.3 version. You're not updating this again?


Not enough of the Kickstart/Workbench 1.x source code survives to be able to reconstruct or rework everything that might benefit from it. The 1.x hard disk partitioning software is one such thing that (as far as I can tell) was lost and stayed lost.

Quote:

Quote:
When work on "Legend of Faerghail" as a commercial product commenced, I requested a hard disk drive for the duration of the development work.


That must be going back. I take it that wasn't a German version of a game based on Fergal Sharkey?


Similar time frame (late 1980'ies), different act, I'm afraid "Legend of Faerghail" was a computer role playing game for the Amiga (the Atari ST and the IBM-PC compatible machines available at the time). I worked on it through 1988-1990, which was just the time when an Amiga hard disk was a very peculiar piece of hardware.

Quote:

Quote:
In retrospect it seems odd that trackdisk.device/hddisk.device/scsi.device were very thin layers on top of hardware whose properties you had to know before you could use them correctly.


Taking scsi.device as an example, what did it use for it's data transfer? Did it bang hardware from some task or use an another API for the actual grit?


The SCSI version of scsi.device (as opposed to the IDE version) directly talked to a particular Western Digital chip and a DMA controller, both of which were part of the A2090 card. That's about the same low-level hardware access deal as trackdisk.device had with the custom chipset and the I/O hardware.

Quote:

Quote:
Both read/write offset and read length are expressed in bytes, not in sectors.


I noticed that. I saw this as a problem years ago when going past the 4GB barrier. To me I always thought it shouldn't be an offset but a sector index.


I disagree, and so did the authors of the various fixed disk hardware drivers The exec I/O API is supposed to be an abstraction for the underlying hardware. It doesn't get any more abstract than using byte offsets and byte lengths. There used to be one problem, though: you could only access the storage medium in chunks the size of a sector, yet the API didn't tell you what sector size had to be used.

Quote:

Quote:
Much of the existing software was written to use "scsi.device" by default, and short of modifying the software which interacted directly with it (e.g. "HDToolbox" and "ProdPrep") to figure out what other driver to use, it was easier to stick with "scsi.device".


I wonder what the software did that the included HD tools didn't? I had a Ferret and did fine with all the tools included.


You can change the name of the device driver to use through icon tool types. That's the easiest way to do it.

Quote:

Quote:
You couldn't query which device drivers were likely candidates for managing mass storage hardware.


Even with OS3.5 NSD patch it wasn't much easier. In fact, AFAIK, that requires going through the entire device list and sending in an IO command to see what's a disk, which isn't that efficient either.


There's not just the efficiency issue, it's also hard to predict what will happen when you open a device driver in the first place.

Some may require a very specific unit number to be used so that they may be safely queried (get that wrong and the driver does what it's hardwired to do, which may not be what you want). Some may not permit the same unit number to be used for opening it if there's already a program using it. Some may suffer from implementation bugs which lead to undefined behaviour when the device is opened and the NSD query command is issued.

These problems can be worked around with a blacklist/whitelist and runtime patches which hook into OpenDevice() and BeginIO(), but the complexity of the effort to keep the NSD query operations robust is very high. These are the challenges of adding something to an API which is needed but poorly supported as an extension to the existing codebase.

By codebase I mean device drivers developed both by Commodore and 3rd party developers. Bugs that could break NSD were likely to be present in either. The difference was in how many customers were actively using them. This would give you the means to prioritize NSD patches for those customers who were most likely to run into problems, but if left those behind who would use "more exotic" drivers.

Quote:

Has this been improved for OS4+?


I believe so: at the very least there are no legacy device drivers around any more which suffer from various implementation bugs that preclude the query commands from working in the first place.

Quote:

Quote:
What we got was the original trackdisk.device which only allowed data to be read and written to/from buffers stored in chip memory.


What about a standard DMA transfer from a SCSI card on a Zorro bus, does that have to go into chip RAM?


Yes, for some configurations of the Amiga 2000. The Amiga 3000 and all models which followed it had no such limitations.

If you had an Amiga 2000 with an A2090 installed and a memory expansion which showed up in the address space beyond what the A2090 DMA controller could cover, then you might have been in trouble.

I take it that these were rare cases, as this kind of memory expansion would typically be part of an expansion board which also contained a CPU and its own SCSI hardware. You'd use the dedicated SCSI driver for that card (most likely "gvpscsi.device") and it would get the job done.

However, if you needed to use that A2090 card alongside the CPU/RAM/SCSI expansion, then you had to make sure that all I/O operations would use memory from the address space which the DMA controller was restricted to, such as chip memory.

The funny thing is that "HDToolbox" is unaware of whether or not the driver needs chip memory for read/write operations to work. It cannot know the driver's requirements, because there is no API for obtaining such information. The next best thing it does is to reject old scsi.device versions which are known not to be compatible with how "HDToolbox" works.

Quote:

Quote:
Had the manufacturers switched to 2048 or 4096 byte sectors in the early 1990'ies it would have broken a lot of hard disk drivers.


That's interesting. It would have had to be managed in software. I mean the device driver would need toknow about it. A kind of MinTransfer. And Offset alignment.


Exactly: the driver would have had to know what the constraints are and provide the means for I/O operations to succeed even if the client did not provide properly aligned buffers, or buffers located outside the safe DMA range.

 Status: Offline
Profile     Report this post  
duga 
Re: Anyone still using A2090/A2091/A590 "XT" hard disks?
Posted on 5-Dec-2016 18:21:29
#27 ]
Regular Member
Joined: 1-May-2012
Posts: 227
From: Unknown

@olsen

Well, I have a vanilla A2000 with a A2090 board + HDD in the cellar. But no driver for using it, therefore I haven't tested if it's working or not. The HDD LED at least is blinking which I suppose is a good sign.

Do I see any use for it? Not really.

 Status: Offline
Profile     Report this post  
Hypex 
Re: Anyone still using A2090/A2091/A590 "XT" hard disks?
Posted on 8-Dec-2016 13:49:21
#28 ]
Elite Member
Joined: 6-May-2007
Posts: 11180
From: Greensborough, Australia

@olsen

Quote:
This update will follow


Okay.

Quote:
The 1.x hard disk partitioning software is one such thing that (as far as I can tell) was lost and stayed lost.


Like the Enhancer packages?

Quote:
"Legend of Faerghail" was a computer role playing game for the Amiga


I wonder if Amiga Future reviewed it?

Yes only in Amigaland would a harddisk be peculiar.

Quote:
That's about the same low-level hardware access deal as trackdisk.device had with the custom chipset and the I/O hardware.


Yes that would tie it somewhat to one chipset.

Quote:
The exec I/O API is supposed to be an abstraction for the underlying hardware. It doesn't get any more abstract than using byte offsets and byte lengths.


The problem is the 4GB limitations which would quickly be reached. And even now cause trouble for 68K setups. There needed to be some way to specify 64-bit offset or as I suggest to have a multipler for sector index.

Then we have TD64/NSD hacks/patches. And those who claim one is superior over the other. When the difference is one bit in a command word.

Quote:
You can change the name of the device driver to use through icon tool types. That's the easiest way to do it.


Well that's nice but for myself being able to change dkbscsi.device to scsi.device would have been rather pointless.

Quote:
By codebase I mean device drivers developed both by Commodore and 3rd party developers. Bugs that could break NSD were likely to be present in either.


Yes you do bring a host of problems surrounding NSD patches of existing devices.

Quote:
I believe so: at the very least there are no legacy device drivers around any more which suffer from various implementation bugs that preclude the query commands from working in the first place.


Well that's a good start.

Quote:
You'd use the dedicated SCSI driver for that card (most likely "gvpscsi.device") and it would get the job done.


Using only DOSx I read for that driver.

Quote:
The next best thing it does is to reject old scsi.device versions which are known not to be compatible with how "HDToolbox" works.


Well that's one way around it. I recall some version of RAD or ramdrive.device were very annoying. So I have this virtual floppy disk in memory and the driver still insists on stealing my chip ram! Illogical! At this point I give up and discover StatDisk.

Quote:
Exactly: the driver would have had to know what the constraints are and provide the means for I/O operations to succeed even if the client did not provide properly aligned buffers, or buffers located outside the safe DMA range.


Sounds good to me. Even if there might have been a hardware buffer to device buffer to internal program buffer doing the rounds.

Last edited by Hypex on 08-Dec-2016 at 01:50 PM.

 Status: Offline
Profile     Report this post  
scuzz 
Re: Anyone still using A2090/A2091/A590 "XT" hard disks?
Posted on 18-Jan-2017 0:22:26
#29 ]
Regular Member
Joined: 30-May-2004
Posts: 365
From: New Forest United Kingdom

@olsen

Hi

Finally dug out my A590 with the 20MB XT drive and connected the sidecar to my A500 with the 3.1ROM. Obviously the Workbench 34.28 1.3.2 is on the drive itself. Fired up first time and loaded the Workbench screen in seconds. Confirmed Kickstart 40.63 and Workbench 34.28 and 20MB drive. 457688 graphics and 367056 other. The drive powers from its own brick with circular connector though no activity until you power up the 500 from its own brick with square connector. My GVP powers up from its own switch which threw me a bit as I thought the thing was dead to start with. Makes quite a racket firing up but calms down once into the Workbench screen. Autoboots every time and given it hasn't probably been used since 2005 that is not bad going.

There is a piece of software on the machine called Prep Hard Disk.

Not sure if that helps.

I also found my brand new A590 in its original box never been used. My other 590 is packed away with my Checkmate. Not sure where at this time. I kinda think I have another somewhere. I prefer the GVP to be honest.

I've had the 500 with the 3.1 rom running generally during the day over the last week and works without fault.

scuzz

 Status: Offline
Profile     Report this post  
olsen 
Re: Anyone still using A2090/A2091/A590 "XT" hard disks?
Posted on 18-Jan-2017 9:07:11
#30 ]
Cult Member
Joined: 15-Aug-2004
Posts: 774
From: Germany

@scuzz

Quote:

scuzz wrote:
@olsen

Hi

Finally dug out my A590 with the 20MB XT drive and connected the sidecar to my A500 with the 3.1ROM. Obviously the Workbench 34.28 1.3.2 is on the drive itself. Fired up first time and loaded the Workbench screen in seconds. Confirmed Kickstart 40.63 and Workbench 34.28 and 20MB drive. 457688 graphics and 367056 other. The drive powers from its own brick with circular connector though no activity until you power up the 500 from its own brick with square connector. My GVP powers up from its own switch which threw me a bit as I thought the thing was dead to start with. Makes quite a racket firing up but calms down once into the Workbench screen. Autoboots every time and given it hasn't probably been used since 2005 that is not bad going.

There is a piece of software on the machine called Prep Hard Disk.

Not sure if that helps.

I also found my brand new A590 in its original box never been used. My other 590 is packed away with my Checkmate. Not sure where at this time. I kinda think I have another somewhere. I prefer the GVP to be honest.

I've had the 500 with the 3.1 rom running generally during the day over the last week and works without fault.

scuzz


Thank you very much! This confirms that the A590 is supposed to work with Kickstart 3.1, in XT drive mode.

Since I asked the question I found that the documentation for the "Prep Hard Disk" software, called "HDToolBox" today, specifically covers the A590. That documentation came from the large ring binder which contained the Amiga 3000 manual. It states that the XT drive settings are used solely with the A590 and are not relevant for the Amiga 3000.

Both the A590 and the Amiga 3000 appear to use the same Western Digital SCSI chip. Some documentation which I found suggests that this chip both supports SCSI and XT drive operations.

One question remains: did the A2090/A2091 support XT drives, using "xt.device", too?

 Status: Offline
Profile     Report this post  
HammerD 
Re: Anyone still using A2090/A2091/A590 "XT" hard disks?
Posted on 18-Jan-2017 14:16:26
#31 ]
Cult Member
Joined: 31-Oct-2003
Posts: 934
From: Ontario, Canada

@olsen

If it's working OK in 3.1 I would hate to see support for it removed. Especially for people who may have the old hardware and want to use it one day. If there is basically no work for you to leave it in, perhaps you should not mess with it

_________________
AmigaOS 4.x Beta Tester - Classic Amiga enthusiast - http://www.hd-zone.com is my Amiga Blog, check it out!

 Status: Offline
Profile     Report this post  
olsen 
Re: Anyone still using A2090/A2091/A590 "XT" hard disks?
Posted on 19-Jan-2017 14:52:06
#32 ]
Cult Member
Joined: 15-Aug-2004
Posts: 774
From: Germany

@HammerD

Quote:

HammerD wrote:
@olsen

If it's working OK in 3.1 I would hate to see support for it removed. Especially for people who may have the old hardware and want to use it one day. If there is basically no work for you to leave it in, perhaps you should not mess with it

This XT drive support issue does not concern the operating system itself. The A590, A2090, A2091, etc. are "self-contained" devices which play by the operating system's rules. They initialize the hardware, add the necessary device drivers, spin up the drives and support booting from disk partitions. Nothing to be changed here, there isn't anything broken which would need fixing.

The "don't fix it if it ain't broke" rule does not apply to the "HDToolBox" disk setup and management program, though. A significant portion of the "HDToolBox" code is concerned with the peculiarities of XT drives. This is extra functionality which was needed because at the time both the drives and the controller hardware were more "primitive" than the SCSI hardware. "HDToolBox" needed to compensate for these deficiencies, which would result in a more complex program.

This extra complexity comes to bear on how the user interface looks like, and how it works. For example, you may recall that you need to "Define a drive type" when you set up a new disk. This is needed because the XT drives did not report as much information as the SCSI drives about themselves, and Commodore had to ship a drive database file with the relevant information with "HDToolBox", just so you could set up and use XT drives. This database is where the layout information for the XT drives came from. The "Define drive type" step is not really needed for IDE/SCSI drives, because they provide all the relevant layout information (sure enough, that information is stored in the database file, but "HDToolBox" can perfectly regenerate it by asking the drive about itself and does not need to look it up in a database file). Yet it's in "HDToolBox".

I view such "anachronistic" features as problematic because they needlessly make it harder to use the program, which was hard even when you had to deal with those XT drives (in 1987/1988). If software is easy to use, it's almost a given that the software itself is complex to allow for that ease, with the inverse being true, too (hard to use = software is implemented in the simplest possible way which gets the job done). With "HDToolBox" it's the odd case of being both hard to use and a very complex implementation: worst of both worlds.

My conclusion as to whether XT support in "HDToolBox" should stick around or not is to keep it for now. Further development work might take a different tack, because any changes made need to be tested, but there is preciously little hardware around to test it with. Rather than wishing and hoping that the changes will work with XT hardware, it would be more honest/straightforward not to pretend to support it in the first place.

Last edited by olsen on 19-Jan-2017 at 02:58 PM.

 Status: Offline
Profile     Report this post  
HammerD 
Re: Anyone still using A2090/A2091/A590 "XT" hard disks?
Posted on 20-Jan-2017 4:15:53
#33 ]
Cult Member
Joined: 31-Oct-2003
Posts: 934
From: Ontario, Canada

@olsen

Quote:

olsen wrote:
@HammerD

Quote:

HammerD wrote:
@olsen

If it's working OK in 3.1 I would hate to see support for it removed. Especially for people who may have the old hardware and want to use it one day. If there is basically no work for you to leave it in, perhaps you should not mess with it

This XT drive support issue does not concern the operating system itself. The A590, A2090, A2091, etc. are "self-contained" devices which play by the operating system's rules. They initialize the hardware, add the necessary device drivers, spin up the drives and support booting from disk partitions. Nothing to be changed here, there isn't anything broken which would need fixing.

The "don't fix it if it ain't broke" rule does not apply to the "HDToolBox" disk setup and management program, though. A significant portion of the "HDToolBox" code is concerned with the peculiarities of XT drives. This is extra functionality which was needed because at the time both the drives and the controller hardware were more "primitive" than the SCSI hardware. "HDToolBox" needed to compensate for these deficiencies, which would result in a more complex program.

This extra complexity comes to bear on how the user interface looks like, and how it works. For example, you may recall that you need to "Define a drive type" when you set up a new disk. This is needed because the XT drives did not report as much information as the SCSI drives about themselves, and Commodore had to ship a drive database file with the relevant information with "HDToolBox", just so you could set up and use XT drives. This database is where the layout information for the XT drives came from. The "Define drive type" step is not really needed for IDE/SCSI drives, because they provide all the relevant layout information (sure enough, that information is stored in the database file, but "HDToolBox" can perfectly regenerate it by asking the drive about itself and does not need to look it up in a database file). Yet it's in "HDToolBox".

I view such "anachronistic" features as problematic because they needlessly make it harder to use the program, which was hard even when you had to deal with those XT drives (in 1987/1988). If software is easy to use, it's almost a given that the software itself is complex to allow for that ease, with the inverse being true, too (hard to use = software is implemented in the simplest possible way which gets the job done). With "HDToolBox" it's the odd case of being both hard to use and a very complex implementation: worst of both worlds.

My conclusion as to whether XT support in "HDToolBox" should stick around or not is to keep it for now. Further development work might take a different tack, because any changes made need to be tested, but there is preciously little hardware around to test it with. Rather than wishing and hoping that the changes will work with XT hardware, it would be more honest/straightforward not to pretend to support it in the first place.


Hi Olaf, thanks for the clarification. I gather the code is so messy that it would no be easy to untangle the "XT" stuff and put it behind a single button. I do appreciate the work you are doing with OS 3.1. I primarily use OS 3.9 now (as I have A4000 class systems) but I do think it is important work you are doing. Thanks!

_________________
AmigaOS 4.x Beta Tester - Classic Amiga enthusiast - http://www.hd-zone.com is my Amiga Blog, check it out!

 Status: Offline
Profile     Report this post  
olsen 
Re: Anyone still using A2090/A2091/A590 "XT" hard disks?
Posted on 20-Jan-2017 10:08:54
#34 ]
Cult Member
Joined: 15-Aug-2004
Posts: 774
From: Germany

@HammerD

Quote:

HammerD wrote:

Hi Olaf, thanks for the clarification. I gather the code is so messy that it would no be easy to untangle the "XT" stuff and put it behind a single button. I do appreciate the work you are doing with OS 3.1.

No, this is not messy code, it is "just" complex code which solves a number of problems which no longer deserve this degree of attention than used to be the case in 1987-1989.

The original hard disk preparation and management software was written specifically for the consumer hard disks available at the time. These were the XT drives, intended for use in IBM-compatible PCs.

The controller hardware for these drives was less powerful and simpler than the hardware which served the same purpose in SCSI drives. Consequently, the software we now know as "HDToolBox" (and the "xt.device" of the A590) had to do the odd jobs which the hardware was not capable of.

For example, there are the odd jobs of detecting media defects, keeping track of where these are located and replacing the affected blocks with spares. An XT drive would not do this, so all these tasks fell to "HDToolBox" and "xt.device".

A sizable portion of "HDToolBox" is concerned with "bad block" detection, tracking the defects and remapping the affected blocks, which extends to the user interface, too.

This detection/tracking/remapping may sound like an elaborate bookkeeping exercise, and it is, but there's a twist to it: the controller hardware of the XT drives of the time was sometimes so "slow" that it could not completely transfer the contents of a block just read from the disc to the host computer before the same transmit buffer was needed for next block to be read from the disc.

One way to work around this limitation would be for the controller to wait for a full revolution of the disc before reading the next block, but that would result in even lower I/O performance.

One solution to the problem is to use a technique known as "interleaving" the blocks. Instead of storing the blocks consecutively on a track (sector numbers 0,1,2,3,4,5,6,7 etc.), the blocks would be reordered (sector numbers 0,4,1,5,2,6,3,7, etc). The controller could then read one block, transfer it to the host computer, skip one block, then read the next one and transfer it, etc. until the entire track was read.

Sounds complicated, but, well it is, and this affects how the defect detection, tracking and remapping works out within "HDToolBox": it becomes much more complex.

All of this was needed to support XT drives properly. But drives of this type were displaced by SCSI and IDE/ATA drives within 2-3 years, which perform all these odd jobs entirely by themselves. They neither demand nor support the highly complex defect detection/tracking/remapping to be performed by the host computer. Yet, there's a big lump of code in "HDToolBox" dedicated to these tasks.

This is just one big example of old obligations weighing down "HDToolBox". Some of this could be switched off/excised easily, but it is the exception. "HDToolBox" treats the SCSI/IDE/ATA drives as a "special" case of hard disk drive, of which the XT drives are the "typical" kind. You cannot easily untangle this relationship unless you plan to perform a lot of compatibility testing. This ship (XT drives vs. SCSI/IDE/ATA) sailed long ago.

Quote:
I primarily use OS 3.9 now (as I have A4000 class systems) but I do think it is important work you are doing. Thanks!

I believe it is important, too, I just wish it wasn't me having to rewrite and update the old code

 Status: Offline
Profile     Report this post  
Dandy 
Re: Anyone still using A2090/A2091/A590 "XT" hard disks?
Posted on 6-Feb-2017 12:47:07
#35 ]
Elite Member
Joined: 24-Mar-2003
Posts: 3049
From: Cologne * Germany

@olsen

Quote:

olsen wrote:
@Hypex

...

Quote:


I suspect if someone is still running an XT drive, possibly on 1.3, they still likely would have Workbench disks or an Installer disk. And if they haven't needed to touch the software for the past 20 years they would be doing well!

In any case would also supplying an old "classic" version be feasible?



What I am currently working on concerns the "classic" version only. The problem I need to get a handle on is in how far the old hardware can be supported while at the same time not making it too hard to maintain/update old code which never was particularly geared towards maintainability.



Being a 'proud' owner of 2 working MFM/RLL harddrives and one working A590 XT drive myself, I can only say that both solutions work flawlessly with OS/KS 3.1 and I would think they would also work with OS 3.5/3.9 and KS 3.1.

"Next Gen" AmigaOS (4.0 and above) won't work on 1987 A500s, anyhow. Unless you find a working PPC card for A500s, that is...

So my suggestion here is to throw out support for these old drives in all new AmigaOS versions that will materialise in future. Already published versions can't be changed in the aftermath, anyway.

Everyone who wants to use such old drives with old, classic hardware most likely already has the necessary stuff to operate them.

It might be a good idea to archive all the required software ("HDToolbox", old "scsi.device"s, Boil3, disk tools like B.A.D. and the like), e.g. on Aminet, if not already there. This way everybody who actually needs it could get it there...

Quote:

olsen wrote:

Because the Amiga platform was just beginning to take off, it was hard to future-proof the hardware and driver designs. In retrospect it seems odd that trackdisk.device/hddisk.device/scsi.device were very thin layers on top of hardware whose properties you had to know before you could use them correctly.



You should also not forget that RAM was very expensive back in those days.
Therefore the coders had to write their code as efficient as possible and optimise it wherever possible.
Aside from that, back then nobody could foresee the future and what kind of development it would bring with regard to data storage devices, the coders could not cover all and every possible future evolution in their drivers.

Quote:

olsen wrote:

For example, none of these drivers can read data in chunks smaller than the sector size which so it happens used to be 512 bytes. But in the respective API nothing prevents you from asking for 7 bytes to be read, beginning at the 115th byte of the disk. Both read/write offset and read length are expressed in bytes, not in sectors. There is an odd lack of hardware abstraction in the drivers, while the I/O request API design already is abstract to begin with.

These disk drivers were supposed to go into ROM, and this eventually happened. Fixing a "broken" driver became so much harder: Commodore didn't just have to build and test it, the driver had to be cast into ROMs or EPROMs, the Amiga dealers had to replace the ROMs, etc.

So the limitations stayed in and it became easier to work around them rather than to solve them.



I would rather attribute that to the limited resources on the most systems out there at that time.

My own A500 back then had 512 kB of RAM onboard, which I expanded with an internal 1.8 mB RAM expansion board later on (the A1000 even came with just 256 kB).

Hard disk drivers must not assume a size of 256 kB if 256 kB RAM is all you have on your system - you also need some RAM to run your OS and at least one program...

Quote:

olsen wrote:

...
It should, but there was no precedent for that, with device drivers being very thin layers on top of the hardware rather than more general abstractions.



"Intelligent" drivers can't be done in files with just a few bytes in size...

Quote:

olsen wrote:

Some of this may be owed to ROM space considerations. A trackdisk.device or maybe scsi.device which would permit access to data at arbitrary offsets, with arbitrary amounts of data being accessed had to be more complex than what we got.
...



Exactly.

_________________
Ciao

Dandy
__________________________________________
If someone enjoys marching to military music, then I already despise him.
He got his brain accidently - the bone marrow in his back would have been sufficient for him!
(Albert Einstein)

 Status: Offline
Profile     Report this post  
Amigo1 
Re: Anyone still using A2090/A2091/A590 "XT" hard disks?
Posted on 6-Feb-2017 14:54:42
#36 ]
Super Member
Joined: 24-Jun-2004
Posts: 1582
From: the Clouds

@Dandy

Quote:

Dandy wrote:
@olsen


"Next Gen" AmigaOS (4.0 and above) won't work on 1987 A500s, anyhow. Unless you find a working PPC card for A500s, that is...

So my suggestion here is to throw out support for these old drives in all new AmigaOS versions that will materialise in future. Already published versions can't be changed in the aftermath, anyway.


Oh yes, please! pretty pleaaaase!! Let's start to move on!!

Let's start to ditch old dead weight from the system. From my experience with every update of the OS more and more old Software does not work on X1000 and X5000 anyway.. A clean cut really seems the more sensible thing to do.

So why not just ditch all the old stuff and API compatibility and invest it in a proper e-uae for the compatibility (which ATM works times better on almost every other OS and computers out there than it does on AmigaOnes making other computers are more compatible to Amiga68k than Amigas ) and spend the hobby developing time of the developers to the path of renewing AmigaOS, and I repeat myself, without having to drag all the deadweight behind.

No sarcasm here. It's kind of sad seeing guestOSes working better on AmigaOnes than the Operating system they where apparently meant and build for does.

Quote:

Everyone who wants to use such old drives with old, classic hardware most likely already has the necessary stuff to operate them.

It might be a good idea to archive all the required software ("HDToolbox", old "scsi.device"s, Boil3, disk tools like B.A.D. and the like), e.g. on Aminet, if not already there. This way everybody who actually needs it could get it there...



Yes, I totally agree, good idea.

edit: layout

Last edited by Amigo1 on 06-Feb-2017 at 02:55 PM.

 Status: Offline
Profile     Report this post  
scuzz 
Re: Anyone still using A2090/A2091/A590 "XT" hard disks?
Posted on 19-Feb-2017 21:28:46
#37 ]
Regular Member
Joined: 30-May-2004
Posts: 365
From: New Forest United Kingdom

@klx300r

I have now uncovered a few more of the A590 units. I have had more success with these drives than the with the GVP. Only three of my GVPs worked one of which was the Turbo. A590s are pretty reliable albeit a bit short of hard drive space. The Checkmate listed below has another external SCSI drive daisy chained to the A590. It also has daisy chain external 5.25" and 3.5" drives. The KCS board is a emulator which requires its own dedicated PC partition. Hence the second drive.

Details of two A590s running on 2.0 and 3.1 ROM.

FIRST: Checkmate: A500 machine fitted in customised case A1500

The base 1500 Checkmate with Commodore 1084S monitor. The main power is a 200W switched power supply unit the type you find in old PCs. There is separate power brick for SCSI hard drive and A590 external sidecar drive. The computer has 5.25” external drive and Amiga 3.5” external drive. When you fire the computer up its a joy to behold as lights start flashing all over the place. Lights on the drives, keyboard and red lights even on the floppy drives with illuminated numbers.

The OS Kickstart 37.175 and Workbench 37.67 1985-1991. The memory is 1.5 and 2.0 24Bit DMA. SysInfo gives the machine as a 68000 CPU/MHz though it is faster than an A600 by some distance. Boards are 2 x ZorroII A590 SCSI/XT 64K and Fast Memory 2048K. Drives are DF0 DF1 5.25 and DF2 3.5. Hard is DH0 xt.device A590 20MB and DH1 scsi. device 50MB. There is also a KCS disk which is not a DOS disk and not recognised. The computer has a PC emulator so some work needed here. The computer is fitted with a Megachip 2000/500 and Multistart II giving Workbench 2.0 with the compatibility of Workbench 1.3.

SECOND: I found the A590 that was originally fitted to the 3.1 machine but was running on a 2.0 ROM Amiga 500. The stats reflect the machine running a 3.1 Workbench on a 2.0 ROM.

Kickstart Version 37.175 Workbench Version 40.42 XT - 20MB Fast File System Bootable 68000 2.0MB FastRAM Public 24BitDMA and 1.0MB Chip RAM Local Public 64K Zorro II A590 SCSI/XT

What I then did was swap out the A590 and fitted to the 3.1 ROM machine... much better appearance.

Kickstart 40.63 Workbench 40.42 and SetPatch 40.16 1985-93 CPU 68000 Memory used 15% 31446784 AmigaOS 3.1 OCS 432656 Chip 2265464 Fast

I love the sound of the A590. It really does sound like one of those old SciFi movies where the computer is trying to make contact with aliens from outer space. The drive sings to you.

http://www.scuzzscink.com/amiga/amiga_scuzz86.htm

http://www.scuzzscink.com/amiga/amiga_scuzz48.htm

Onwards to my HamLab now and also HamE. Never a dull moment.

scuzz

 Status: Offline
Profile     Report this post  
Goto page ( Previous Page 1 | 2 )

[ home ][ about us ][ privacy ] [ forums ][ classifieds ] [ links ][ news archive ] [ link to us ][ user account ]
Copyright (C) 2000 - 2019 Amigaworld.net.
Amigaworld.net was originally founded by David Doyle