Jump to content
IGNORED

First 3 disk sectors always 128 bytes?


E474

Recommended Posts

Hi,

 

   I know that for a double density 180K disk (typically "true" double density disks as made by Happy, US-doubler, etc.) the first 3 sectors are actually 128 byte sectors, and the rest of the disk uses 256 byte sectors.

 

   Is this also true for larger capacity disks, e.g. 360K, 720K, upwards? Are the first 3 sectors on any density/type of disk always 128 byte sectors? 

 

    Also, can you have the first 3 sectors at 128 bytes, then larger sectors like 512 byte or 1K sectors on some disks/devices? I know sector size is provided as part of the Percom Block, but is there always the (implicit) assumption that the first 3 sectors are a special case?

 

    I thought this was due to the OS only booting single density sectors, and 3 sectors was enough to boot an initial boot loader, though I guess you could have as many single density sectors as you like, though I am not sure how this could be achieved.

 

    Note this is about SIO attachable drives, I have no idea how PBI, etc., hard disks are organised.

 

    Does anyone have any more information on this?

 

    Thanks!

Link to comment
Share on other sites

41 minutes ago, E474 said:

I know that for a double density 180K disk (typically "true" double density disks as made by Happy, US-doubler, etc.) the first 3 sectors are actually 128 byte sectors, and the rest of the disk uses 256 byte sectors.

Most drives for the Atari that do double density physically format all sectors as 256 byte MFM, and the drive only returns the first 128 bytes of the first three sectors. One upgrade, the Duplicator 1050, physically formats those first 3 sectors as 128 byte MFM, different from all other drives. This causes problems with density detection in the US Doubler 1050, and maybe some other upgrades (happy?) as it determines the density of the disk by the size of the first sector it happens to read on the track, If it happens to be 1, 2, or 3, it will incorrectly detect single density, and be unable to read the rest of the sectors on the disk. The solution to this bug is to just always format disks in another drive.

 

41 minutes ago, E474 said:

Is this also true for larger capacity disks, e.g. 360K, 720K, upwards? Are the first 3 sectors on any density/type of disk always 128 byte sectors?

 

Yes, all double density (256 byte sector) disks of any size up to 65535 sectors always start 3 with 128 byte sectors. I believe this is also true for MIO & Black Box PBI hard disks, but if it isn't, the 2nd 128 bytes would be unused. I'll have to verify with DiskRX with the MIO. The SIDE2 SpartaDOS X with 512 Byte sector support allows all 512 bytes to be used for data. But this is a special case which had spartados specific enhancements developed after the original ICD releases.

 

360K, 720K etc SIO drives will also always present 128 bytes to the computer for first three sectors. Those drives "should" also physically format those as 256 byte, but again the 2nd 128 bytes will be inaccessible because the firmware of the drive will never transmit them, and SIO handler will not accept more than 128 bytes I think. Maybe possible if bypassing the ROM CIO... But the drive firmware would also need to be modified to somehow allow transmitting more than 128 bytes for those sectors, maybe with a non-standard request like was developed for the ATR8000 disks to write 256 bytes of data to those sectors using CP/M mode...

  • Like 2
Link to comment
Share on other sites

System boot sectors are often 3 sectors but do not need to be that magic number at all. One, 2 or twenty are legal and doable, but they must be 128 byte sectors as the OS Boot routine can not read 256 byte sectors. This value of boot sectors to load is the 2nd byte of the 1st sector, game disks offered in SD or ED will often have a nonstandard, not 3 value here. DOS and other utilities tend to religiously stick to 3 value here.

 

Most drives do have firmware that read the possibly 256 byte 'boot' sectors 1, 2 and 3 as if they were 128 byte sectors and send only that amount of data in order to comply with the ROM OS requirement of 128 byte boot up transfers.

 

The 3rd and 4th bytes of sector 1 are the load address the boot code is to be transferred into RAM by the ROM based OS boot code that is limited to 128 byte transfers. 5th and 6th bytes are the INIT address which will be run as a subroutine jump as soon as the count of sectors moved equals the value of the 2nd byte of the 1st sector. These all important first 6 bytes are preserved in page zero that is used by the OS ROM boot code. And after that INIT run that ends with a RTS op code has completed, then actual code is run at the 7th byte of sector one at it's new address in ram which has to exist AND match of course. And that ends the boot process.

 

The first sector is loaded to 0x0400 from where the OS boot code moves it to it's specified location and the 0x0400 region is then treated as the transfer buffer from then on being overwritten with each new sector coming in. IIRC that is.

 

This isn't in a book that I know of, it's leaned by reading enough OS disassembly and looking at enough disks with a disk editor to figure it out and verify the assumptions made. At least that's how I had to do it.

  • Like 1
Link to comment
Share on other sites

Hi,

 

   Thanks very much that's just the info I was after.

 

   I can understand why getting the firmware to fake the sizes of the first 3 sectors would be simpler than writing 3 sectors of 128 bytes, then the rest of the sectors at a larger size. Also, it would mean that the first 3 sectors couldn't be read on a standard 1050, as they are not genuinely 128 byte sectors.

 

   IIRC, the disk boot header (6 bytes) is the same as the cassette boot header, there's a bit of documentation in Mapping the Atari at $700, I'm sure there must be other sources too though.

 

   Thanks again!

  • Like 1
Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...