5 ms·

About the disk format: the Amiga native disk format was just one huge sector per track. That is how the Amiga fitted 880K on the same disk MS-DOS filled with 72

About the disk format: the Amiga native disk format was just one huge sector per track. That is how the Amiga fitted 880K on the same disk MS-DOS filled with 720K and MacOS 800K. One of the custom chip on the Amiga had hardware for teh track decoding. So the Amiga could read the disk while performing other operations, the data would come in via DMA (direct memopry access) of the co-processor. (MacOS used variable-speed, that is how it fitted more sectors on outer tracks and achieved 800K.)

zepearl 8y ago
I owned an Amiga 500 and at a certain point I bought for it a HDD (20 MBs, if I remember correctly) => then later I switched to an IBM-compatible (386sx with a HDD) and, subjectively, I thought that the HDD of the IBM-compatible was slower than the one I previously used on the Amiga => any HW reason why the Amiga-HDD might be faster than the IBM-HDD, or did I just imagine it?
- bluedino 8y ago
  Amiga was very likely a SCSI drive vs IDE
- puzzle 8y ago
  It might have been a SCSI drive/controller, but it might have also been that you used FastFileSystem, which was pretty efficient. One of the HD manufacturers of the time, either Conner or Maxtor, was known to use Amiga 3000 machines to test their SCSI disks, because of the CPU/chipset/OS/FS combination. Not many systems were able to extract 90%+ of theoretical throughput like the A3000 could.
  - zepearl 8y ago
    Thx - it was just some sort of standard HDD for Amiga 500 - cannot remember anything specific about it... . Can it be that the Amiga 500 had in its case a place for a HDD? (I don't remember using external cases, but maybe I have forgotten...)
    - puzzle 8y ago
      The A590 was a drive that plugged on the left side of the A500. It usually came with a 20MB SCSI disk inside... There was no room in the A500 for a 3.5" drive. Later, the A1200 and A600 had a built-in IDE controller and an internal bay, but for a 2.5" disk.
      - jacobush 8y ago
        The 590 had a SCSI controller with DMA, but only for the external SCSI connector. The internal drive was 8-but IDE and dog slow. So if it was faster, it must be chalked up to better OS, better filesystem and I would assume a 68000 at 7Mhz was faster than a 4.77Mhz 8088 at shuffling data around. Especially since the memory data bus was 16 bit wide for the Amiga but only 8 bit wide for the PC. (Right?!)
        puzzle 8y ago
        The A590 had both a SCSI and an XT header for internal drives (on the right side): http://amiga.resource.cx/photos/photos/a590-5.jpg http://amiga.resource.cx/photos/photos/a590-5.jpg I only ever saw them with SCSI drives in person, but they also sold XT units. Maybe you saw the latter?
        jacobush 8y ago
        If they sold'em with XT-IDE inside, I was probably unfortunate to have on of those. Still beat swapping floppies. Thanks to the HDD I could compile C programs without switching floppies all the time. IIRC I had the compiler and the headers on one floppy and the linker etc on another. Eventually I made DICE (Matt Dillon yo!) fit on one floppy. Or was it an early Lattice C?? Can't remember.:-P By that time I had bought a 486SX for uni, so I reluctantly used Turbo C instead. Turbo C was just too good to pass up...
      - zepearl 8y ago
        Yes, you're right - it was the A590, thx!
  - vidarh 8y ago
    Part of it may also have been that even expansions that used non-SCSI drives tended to offload most of the processing from the CPU. My A2000 SCSI card had a Z80 on it, for example.
hermanhermitage 8y ago
The native disk format was actually broken into sectors, see: http://amigadev.elowar.com/read/ADCD_2.1/Devices_Manual_guide/node015B.html http://amigadev.elowar.com/read/ADCD_2.1/Devices_Manual_guid... It read full tracks at a time, but you can see from the doc there were 11/22 sectors with no inter sector gaps, but there are separate sectors of 512 bytes which are addressed in the file system structures.
- pierrebai 8y ago
  That's just a clash of nomenclature between the logical and physical layout. It had logical sectors, but on disk, it was written as one contiguous sector.
  - puzzle 8y ago
    Yes, it read the whole track, starting from wherever the head was, then the floppy device handler figured where each logical block was, based on the magic sync word $4489 (which is not supposed to be output by the default MFM encoding) and track/sector IDs embedded in the track's bitstream.
    - philpem 8y ago
      Not even "Not supposed to be" -- it can't be. $4489 decoded is a valid byte, but with one of the clock transitions 'blanked'. If you decode $4489 via MFM then re-encode that byte, you'll get a 1-bit difference. This is why it works as a sync marker: even if you wrote that byte in the data area of the sector, it wouldn't encode the same way because of the missing clock :) It's a common trick on radio systems too -- a short burst of data which can't be obtained through normal encoding processes (invalid FEC bits, flipped parity, etc).
richrichardsson 8y ago
> One of the custom chip on the Amiga had hardware for teh track decoding If memory serves correct, the raw data was pulled in from disk to memory DMA-style, but the actual decoding could be done either using the blitter or 68k. True about performing operations whilst loading from disk though; I coded a trackloader demo that was loading the next part of the demo whilst the current part was ongoing, using the 68k to decode so that the blitter could be hammered for graphic effects!
- puzzle 8y ago
  The MFM encoding used 2 raw bits for each bit of data to be stored. As such, people figured how to use the Blitter to do just that. I'm not sure if the OS did it; it was probably not the case in the 1.x days.
  - jacobush 8y ago
    I don't know either when it did what, but when Amigas got faster CPUs IIRC there were patches (or newer Kickstarts?) to move the decoding to the CPU because the blitter was slower than the CPU then.
rasz 8y ago
>One of the custom chip on the Amiga had hardware for teh track decoding. sadly no, it was just deserializing head magnetic flux data (encoded as pulses) to raw bytestream, you still had to compute actual data out of it. Whats worse Commodore shipped same, outdated even in 1987, Double Density chip for the whole life of Amiga.
philpem 8y ago
Yeah, constant angular velocity (hub motor RPM is fixed) vs. constant linear velocity (linear speed over the disk is fixed). If memory serves, the 800K Mac and Commodore 1541 disks were actually Z-CLV or Zoned-CLV -- where the drive speed changes every "n" tracks. The reason you do ZCLV is that it reduces the complexity of the controller hardware (fewer taps on the clock divider). The fun trick is, with a drive controller which works based on "time between pulses" (DiscFerret, Catweasel, etc) you can do all of the above with a CAV disk drive just by tweaking the read/write clock. Same trick probably works for discrete drive controllers like the 765 and 1771 (I say probably because I haven't checked the datasheet!).

zepearl 8y ago

I owned an Amiga 500 and at a certain point I bought for it a HDD (20 MBs, if I remember correctly) => then later I switched to an IBM-compatible (386sx with a HDD) and, subjectively, I thought that the HDD of the IBM-compatible was slower than the one I previously used on the Amiga => any HW reason why the Amiga-HDD might be faster than the IBM-HDD, or did I just imagine it?

bluedino 8y ago
Amiga was very likely a SCSI drive vs IDE
puzzle 8y ago
It might have been a SCSI drive/controller, but it might have also been that you used FastFileSystem, which was pretty efficient. One of the HD manufacturers of the time, either Conner or Maxtor, was known to use Amiga 3000 machines to test their SCSI disks, because of the CPU/chipset/OS/FS combination. Not many systems were able to extract 90%+ of theoretical throughput like the A3000 could.
- zepearl 8y ago
  Thx - it was just some sort of standard HDD for Amiga 500 - cannot remember anything specific about it... . Can it be that the Amiga 500 had in its case a place for a HDD? (I don't remember using external cases, but maybe I have forgotten...)
  - puzzle 8y ago
    The A590 was a drive that plugged on the left side of the A500. It usually came with a 20MB SCSI disk inside... There was no room in the A500 for a 3.5" drive. Later, the A1200 and A600 had a built-in IDE controller and an internal bay, but for a 2.5" disk.
    - jacobush 8y ago
      The 590 had a SCSI controller with DMA, but only for the external SCSI connector. The internal drive was 8-but IDE and dog slow. So if it was faster, it must be chalked up to better OS, better filesystem and I would assume a 68000 at 7Mhz was faster than a 4.77Mhz 8088 at shuffling data around. Especially since the memory data bus was 16 bit wide for the Amiga but only 8 bit wide for the PC. (Right?!)
      - puzzle 8y ago
        The A590 had both a SCSI and an XT header for internal drives (on the right side): http://amiga.resource.cx/photos/photos/a590-5.jpg http://amiga.resource.cx/photos/photos/a590-5.jpg I only ever saw them with SCSI drives in person, but they also sold XT units. Maybe you saw the latter?
        jacobush 8y ago
        If they sold'em with XT-IDE inside, I was probably unfortunate to have on of those. Still beat swapping floppies. Thanks to the HDD I could compile C programs without switching floppies all the time. IIRC I had the compiler and the headers on one floppy and the linker etc on another. Eventually I made DICE (Matt Dillon yo!) fit on one floppy. Or was it an early Lattice C?? Can't remember.:-P By that time I had bought a 486SX for uni, so I reluctantly used Turbo C instead. Turbo C was just too good to pass up...
    - zepearl 8y ago
      Yes, you're right - it was the A590, thx!
- vidarh 8y ago
  Part of it may also have been that even expansions that used non-SCSI drives tended to offload most of the processing from the CPU. My A2000 SCSI card had a Z80 on it, for example.

hermanhermitage 8y ago

The native disk format was actually broken into sectors, see: http://amigadev.elowar.com/read/ADCD_2.1/Devices_Manual_guide/node015B.html http://amigadev.elowar.com/read/ADCD_2.1/Devices_Manual_guid... It read full tracks at a time, but you can see from the doc there were 11/22 sectors with no inter sector gaps, but there are separate sectors of 512 bytes which are addressed in the file system structures.

pierrebai 8y ago
That's just a clash of nomenclature between the logical and physical layout. It had logical sectors, but on disk, it was written as one contiguous sector.
- puzzle 8y ago
  Yes, it read the whole track, starting from wherever the head was, then the floppy device handler figured where each logical block was, based on the magic sync word $4489 (which is not supposed to be output by the default MFM encoding) and track/sector IDs embedded in the track's bitstream.
  - philpem 8y ago
    Not even "Not supposed to be" -- it can't be. $4489 decoded is a valid byte, but with one of the clock transitions 'blanked'. If you decode $4489 via MFM then re-encode that byte, you'll get a 1-bit difference. This is why it works as a sync marker: even if you wrote that byte in the data area of the sector, it wouldn't encode the same way because of the missing clock :) It's a common trick on radio systems too -- a short burst of data which can't be obtained through normal encoding processes (invalid FEC bits, flipped parity, etc).

richrichardsson 8y ago

> One of the custom chip on the Amiga had hardware for teh track decoding If memory serves correct, the raw data was pulled in from disk to memory DMA-style, but the actual decoding could be done either using the blitter or 68k. True about performing operations whilst loading from disk though; I coded a trackloader demo that was loading the next part of the demo whilst the current part was ongoing, using the 68k to decode so that the blitter could be hammered for graphic effects!

puzzle 8y ago
The MFM encoding used 2 raw bits for each bit of data to be stored. As such, people figured how to use the Blitter to do just that. I'm not sure if the OS did it; it was probably not the case in the 1.x days.
- jacobush 8y ago
  I don't know either when it did what, but when Amigas got faster CPUs IIRC there were patches (or newer Kickstarts?) to move the decoding to the CPU because the blitter was slower than the CPU then.

rasz 8y ago

>One of the custom chip on the Amiga had hardware for teh track decoding. sadly no, it was just deserializing head magnetic flux data (encoded as pulses) to raw bytestream, you still had to compute actual data out of it. Whats worse Commodore shipped same, outdated even in 1987, Double Density chip for the whole life of Amiga.

philpem 8y ago

Yeah, constant angular velocity (hub motor RPM is fixed) vs. constant linear velocity (linear speed over the disk is fixed). If memory serves, the 800K Mac and Commodore 1541 disks were actually Z-CLV or Zoned-CLV -- where the drive speed changes every "n" tracks. The reason you do ZCLV is that it reduces the complexity of the controller hardware (fewer taps on the clock divider). The fun trick is, with a drive controller which works based on "time between pulses" (DiscFerret, Catweasel, etc) you can do all of the above with a CAV disk drive just by tweaking the read/write clock. Same trick probably works for discrete drive controllers like the 765 and 1771 (I say probably because I haven't checked the datasheet!).