512 byte sector ATR info?

[tschak909]

I'm currently adding support for 512 byte/sector images to #FujiNet, and almost have it, but there seem to be some subtle things I am missing.

 

Namely, Somehow with 512 byte/sector, I am getting C8 FF for bytes 3 and 4, instead of E0 FF for bytes 3 and 4 from the disk generated by Altirra. I am calculating the sector offsets like this:

 

// Returns byte offset of given sector number (1-based)
uint32_t DiskTypeATR::_sector_to_offset(uint16_t sectorNum)
{
    uint32_t offset = 0;

    switch (sectorNum)
    {
        case 1:
            offset=16;
            break;
        case 2:
            offset=144;
            break;
        case 3:
            offset=272;
            break;
        default:
            if (_disk_sector_size == 256)
                offset=((sectorNum-3)*256)+16+128;
            else if (_disk_sector_size == 512)
                offset=((sectorNum-3)*512)+16+128;
            else
                offset=((sectorNum-1)*128)+16;
            
            break;
    }

    return offset;
}

and when creating:

 

// Returns FALSE on error
bool DiskTypeATR::create(FILE *f, uint16_t sectorSize, uint16_t numSectors)
{
    Debug_print("ATR CREATE\n");

    struct
    {
        uint8_t magicL;
        uint8_t magicH;
        uint8_t filesizeL;
        uint8_t filesizeH;
        uint8_t secsizeL;
        uint8_t secsizeH;
        uint8_t filesizeHH;
        uint8_t res0;
        uint8_t res1;
        uint8_t res2;
        uint8_t res3;
        uint8_t res4;
        uint8_t res5;
        uint8_t res6;
        uint8_t res7;
        uint8_t flags;
    } atrHeader;

    memset(&atrHeader, 0, sizeof(atrHeader));

    uint32_t total_size = numSectors * sectorSize;
    // Adjust for first 3 sectors always being single-density (we lose 384 bytes)
    if (sectorSize > 128)
        total_size -= 384; // 3 * 128

    uint32_t num_paragraphs = total_size / 16;

    // Write header
    atrHeader.magicL = LOBYTE_FROM_UINT16(ATR_MAGIC_HEADER);
    atrHeader.magicH = HIBYTE_FROM_UINT16(ATR_MAGIC_HEADER);

    atrHeader.filesizeL = LOBYTE_FROM_UINT16(num_paragraphs);
    atrHeader.filesizeH = HIBYTE_FROM_UINT16(num_paragraphs);
    atrHeader.filesizeHH = (num_paragraphs & 0xFF0000) >> 16;

    atrHeader.secsizeL = LOBYTE_FROM_UINT16(sectorSize);
    atrHeader.secsizeH = HIBYTE_FROM_UINT16(sectorSize);

    Debug_printf("Write header to ATR: sec_size=%d, sectors=%d, paragraphs=%d, bytes=%d\n",
        sectorSize, numSectors, num_paragraphs, total_size);

    uint32_t offset = fwrite(&atrHeader, 1, sizeof(atrHeader), f);

    // Write first three 128 uint8_t sectors
    uint8_t blank[256] = {0};

    for (int i = 0; i < 3; i++)
    {
        size_t out = fwrite(blank, 1, 128, f);
        if (out != 128)
        {
            Debug_printf("Error writing sector %hhu\n", i);
            return false;
        }
        offset += 128;
        numSectors--;
    }

    // Write the rest of the sectors via sparse seek to the last sector
    offset += (numSectors * sectorSize) - sectorSize;
    fseek(f, offset, SEEK_SET);
    size_t out = fwrite(blank, 1, sectorSize, f);

    if (out != sectorSize)
    {
        Debug_println("Error writing last sector");
        return false;
    }

    return true;
}

Is there also a status bit that I need to set for 512 byte sector operation?

 

-Thom

 

[flashjazzcat]

512bps disk images don't have short 128 byte boot sectors.

[E474]

Isn't the OS going to try and read 128 byte sectors on boot?

[tschak909]

4 minutes ago, E474 said:

Isn't the OS going to try and read 128 byte sectors on boot?

It's this reason why you can't boot from 512 byte/sector ATR images.

 

This is not as big of an issue as might seem, because the only thing that actively supports disks with sectors this large is SpartaDOS X. (OS/A+ 4 could, but nobody will ever attempt this.)

 

-Thom

 

[_The Doctor__]

My hard drive is an embedded scsi drive only capable of 512 byte sectors. The Black Box boots from it without issue. I am not sure if it concatenates sectors to save them and splits them up on reading however... just don't remember.

as for other flavors of fun... well that's floppy hell... remember inDUS and atr8000 boot floppies for CPM etc... There were multiple images with the first few sectors modified so it would boot from the attached parallel drives or the sio drives etc...

Edited April 25, 2021 by _The Doctor__

[+Nezgar]

45 minutes ago, _The Doctor__ said:

My hard drive is an embedded scsi drive only capable of 512 byte sectors. The Black Box boots from it without issue. I am not sure if it concatenates sectors to save them and splits them up on reading however... just don't remember.

Don't have a black box, but I recall reading the Black box can split each physical 512 byte sector to 2 256 byte sectors. And the first three sectors of each partition are presented as 128 bytes to the computer. The black box has a 2nd mode for "MIO" compatibility that just uses the 1st half of each 512 byte sector, so you can only use half the capacity - as that is what an MIO would do...

 

[E474]

It's kind of a strange design decision not to let 512 byte sector ATR files be bootable, as you could tell if the first 3 sectors should be 128 bytes by looking at the total size (in paragraphs, IIRC) in the ATR header. 

[_The Doctor__]

MIO mode was stupid. I know cause that's how I murdered my BBS drive

[drac030]

7 minutes ago, E474 said:

It's kind of a strange design decision not to let 512 byte sector ATR files be bootable, as you could tell if the first 3 sectors should be 128 bytes by looking at the total size (in paragraphs, IIRC) in the ATR header.

512-bps ATRs are intended as SDX 32 MB HDD partition images, therefore they do not have to be bootable. A custom OS, which cares to read PERCOM block before booting, will be able to boot them, though.

 

Also, the disk emulator can of course recognize if the boot sectors are short or not. But Atari cannot, there is no way to recognize if the boot sectors are of full size or not from the Atari system level. So, there is only one bootsector, of full size, for consitency and to avoid mess we already experience in 256-bps ATRs.

[E474]

Hi,

 

   I guess I should be careful commenting on things I haven't used or had a hand in developing, so am not saying anything further on not faking first 3 sectors at 128 bytes/sector in 512 byte ATRs.

 

   I think I had a similar problem with generating ATR headers in ATRMaker Deluxe (still not quite finished, but not abandoned either), it's possibly because you (@tschak909) are writing the header before trying to read the first 3 sectors, which, with 512 byte ATRs, should apparently throw up an SIO error when you try to read 128 byte sectors for the first 3 sectors of the disk. However, I'm guessing you don't get to this until after you have built the header. 

 

   I guess this is also a change to ATRMaker Deluxe's code, as this is the first bit of info I have seen about the first three sectors of ATR 512 byte sectors being 512 bytes, and not the 128 byte spec given for ATR files by  https://www.atarimax.com/jindroush.atari.org/afmtatr.html , although now that I've dug a little bit further, there is a thread on ATR headers here: 

  Among others. 

 

  Hope this helps!

[_The Doctor__]

15 hours ago, _The Doctor__ said:

MIO mode was stupid. I know cause that's how I murdered my BBS drive

just kidding though, it was very useful in moving data from on system to another.

[Mathy]

Hello guys

 

I do own a BlackBox and can confirm that the BB does read 512 byte sectors and somehow splits them into two 256 byte sectors.  IIRC it reads each sector twice.

 

Sincerely

 

Mathy

 

[drac030]

This is what most IDE hard disk handlers do. It is not that splitting a 512-byte sector into 128-byte records would not be possible. It is perfectly possible, it is just much ado about nothing really useful, and on a HDD it may impair performance (as the sector 1 under SpartaDOS is accessed quite often). Also, 3x128=384, whereas 1x512=512 One bootsector holds everything.