Options for getting 3 1/2 inch drives, clock carts, other stuff.

[a8maestro]

Search here for "sdrive".

 

Rick D.

[atarian63]

That's the part I stink at. It tends to look like spagetti to me. Is he producing the board? From what I've seen of the board it doesn't seem to complicated but I've never done made a circuit on a perf board from a schematic. Maybe it's time to give it a shot.

 

Allan

IMHO there's only one SMD part on the part list - the SD slot. And it looks easy enough to solder it even for me... and that means something!

There actually is someone who had them produced but I don't want to make him angry by saying his name, hehe. All the PCBs are reserved, anyway. If there will be another batch I can let you know (but it may not be a good idea as I've previously sent some PCBs abroad only to learn that the buyers changed their minds and "archived" them. Not worth dealing with the evil post office, I'd say....

if they are available I would like one as well

[+Larry]

The XF551 isn't exactly ISO9001 material, either. Using 1050s is a way around the XF551. It doesn't have to use HD drives - any standard drive would work. But, even I don't have truckloads of new DD drives so HD needs to be an option.

 

My HD experience has been that if it formats OK, it will work OK, but I have seen a lot of disks that would not format clean.

 

Anyway, a 6507/65816 platform in a 1050 could be used for more than floppies, you know. There is space for a CF card, too. No HALTs, no NMIs. Easy to read IBM disks...

 

I can't believe that Bob Puff used an overclocked 1772. Were they actually factory certified to run at 16mhz?

 

 

Bob

 

This seems like a good juncture to ask about one of your projects I've been curious about for awhile. Does your internal compact flash project use ATR images or native Atari format? Of course, images have lots of advantages, but there are times when its more convenient to have native Atari format. Mr-Atari's MyIDE has a nice balance in that respect (IMO) and he keeps working on it to improve its speed and functionality.

 

For a 1050 project, how would you lay out the CF or SD "disk?"

 

My experience with HD is a little different -- good disks, good drives, good format -- a few months later, bad sector somewhere (usually where it hurts!).

 

-Larry

[+bob1200xl]

It's all Atari format. The CF card is just a bunch of sectors on the PBI. Would be the same on the SIO. There is a "partition table" in memory at $D7C0 that assigns blocks of sectors and density to drives. When you initiate SIO to a disk drive, the PBI code searches this table to see if the drive is enabled. If it is, then the PBI code executes the command using the table values for sector addresses. If not, then control is passed back to SIO. The code is the same as my IDE interface that is floating around somewhere.

 

So... you want to dump a bunch of ATRs onto the CF card on your PC and then plug the card into your CF1050 and read them as Atari formt? Is that where you're going with this?

 

Bob

 

 

 

The XF551 isn't exactly ISO9001 material, either. Using 1050s is a way around the XF551. It doesn't have to use HD drives - any standard drive would work. But, even I don't have truckloads of new DD drives so HD needs to be an option.

 

My HD experience has been that if it formats OK, it will work OK, but I have seen a lot of disks that would not format clean.

 

Anyway, a 6507/65816 platform in a 1050 could be used for more than floppies, you know. There is space for a CF card, too. No HALTs, no NMIs. Easy to read IBM disks...

 

I can't believe that Bob Puff used an overclocked 1772. Were they actually factory certified to run at 16mhz?

 

 

Bob

 

This seems like a good juncture to ask about one of your projects I've been curious about for awhile. Does your internal compact flash project use ATR images or native Atari format? Of course, images have lots of advantages, but there are times when its more convenient to have native Atari format. Mr-Atari's MyIDE has a nice balance in that respect (IMO) and he keeps working on it to improve its speed and functionality.

 

For a 1050 project, how would you lay out the CF or SD "disk?"

 

My experience with HD is a little different -- good disks, good drives, good format -- a few months later, bad sector somewhere (usually where it hurts!).

 

-Larry

[+CharlieChaplin]

The XF551 isn't exactly ISO9001 material, either. Using 1050s is a way around the XF551. It doesn't have to use HD drives - any standard drive would work. But, even I don't have truckloads of new DD drives so HD needs to be an option.

 

My HD experience has been that if it formats OK, it will work OK, but I have seen a lot of disks that would not format clean.

 

Well,

I used 3,5" Epson and Teac HD drives with my XF, but the drives could be jumpered to DD (and to drive zero, so they were bootable on the A8). I also used HD disks on these drives - and since the FDC of the XF does not allow HD disks, I used the write protection notches from the 5,25" disks on the HD hole of the 3,5" disks, so they were seen as DD disks.

 

There was no problem in formatting these HD disks in DD, because as said before there was a 3,5" HD drive in the XF. Think I had these drives for approx. 2-3 years without any problems. But since 3,5" never became a standard, and most of my disks (and especially the subscribed magazines) were 5,25", I sold these 3,5" XF drives. Would be interesting to know if any of these 3,5" HD disks (with A8 stuff) are still readable today or if they are as unreadable as most ST disks...

 

-Andreas Koch.

Edited December 10, 2008 by CharlieChaplin

[+Larry]

It's all Atari format. The CF card is just a bunch of sectors on the PBI. Would be the same on the SIO. There is a "partition table" in memory at $D7C0 that assigns blocks of sectors and density to drives. When you initiate SIO to a disk drive, the PBI code searches this table to see if the drive is enabled. If it is, then the PBI code executes the command using the table values for sector addresses. If not, then control is passed back to SIO. The code is the same as my IDE interface that is floating around somewhere.

 

So... you want to dump a bunch of ATRs onto the CF card on your PC and then plug the card into your CF1050 and read them as Atari formt? Is that where you're going with this?

 

Bob

 

Hi Bob-

 

No, just was curious as to how you did/would do it. Presume that the 1050 could be st up to do DD 3-1/2" disks (not just HD)? Being able to do CF or SD as well as disks would be very nice (since we are doing a "what-if." I would vote in favor of a native format device.

 

-Larry

[+bob1200xl]

The problem with a CF card or such is managing the files/disks on it. Even if you set all the partitions to 16mb, you could have 128 of them on a 2gb CF card. If the card is 'local' (on the PBI), you have enough bandwidth to reasonably search the 'drive'. You're not going to have that on the SIO. One thing you could do is to map whole disks to the CF card - all done inside the CF1050. It would read the floppy at high speed, set up a partition and sector copy the disk onto the card. Then, you could move the CF card to the PBI and access the data.

 

Anyway,,,

 

Sure, the 1050 would read SD, ED, DD, and HD. There seems to be some question as to whether that can be done with a single FDC chip - I think so.

 

Bob

 

 

 

It's all Atari format. The CF card is just a bunch of sectors on the PBI. Would be the same on the SIO. There is a "partition table" in memory at $D7C0 that assigns blocks of sectors and density to drives. When you initiate SIO to a disk drive, the PBI code searches this table to see if the drive is enabled. If it is, then the PBI code executes the command using the table values for sector addresses. If not, then control is passed back to SIO. The code is the same as my IDE interface that is floating around somewhere.

 

So... you want to dump a bunch of ATRs onto the CF card on your PC and then plug the card into your CF1050 and read them as Atari formt? Is that where you're going with this?

 

Bob

 

Hi Bob-

 

No, just was curious as to how you did/would do it. Presume that the 1050 could be st up to do DD 3-1/2" disks (not just HD)? Being able to do CF or SD as well as disks would be very nice (since we are doing a "what-if." I would vote in favor of a native format device.

 

-Larry

[Shawn Jefferson]

The problem with a CF card or such is managing the files/disks on it. Even if you set all the partitions to 16mb, you could have 128 of them on a 2gb CF card. If the card is 'local' (on the PBI), you have enough bandwidth to reasonably search the 'drive'. You're not going to have that on the SIO. One thing you could do is to map whole disks to the CF card - all done inside the CF1050. It would read the floppy at high speed, set up a partition and sector copy the disk onto the card. Then, you could move the CF card to the PBI and access the data.

 

Bob, descriptions/names of partitions and other metadata can be kept in a small table that would be easy to search. MyIDE does it this way for hundreds of disk images.

[+bob1200xl]

Not being familiar with MyIDE, myself, can you define small? Say 2000 files on 200 disk images? Searching may be easy but how about sorting and deleting and adding? Fixed block sizes? If you are doing all these non-drive related things over SIO, it would be a problem, wouldn't it?

 

Bob

 

 

 

The problem with a CF card or such is managing the files/disks on it. Even if you set all the partitions to 16mb, you could have 128 of them on a 2gb CF card. If the card is 'local' (on the PBI), you have enough bandwidth to reasonably search the 'drive'. You're not going to have that on the SIO. One thing you could do is to map whole disks to the CF card - all done inside the CF1050. It would read the floppy at high speed, set up a partition and sector copy the disk onto the card. Then, you could move the CF card to the PBI and access the data.

 

Bob, descriptions/names of partitions and other metadata can be kept in a small table that would be easy to search. MyIDE does it this way for hundreds of disk images.

[ijor]

Not being familiar with MyIDE, myself, can you define small? Say 2000 files on 200 disk images? Searching may be easy but how about sorting and deleting and adding? Fixed block sizes? If you are doing all these non-drive related things over SIO, it would be a problem, wouldn't it?

 

Why you would want to search the whole card device? The computer doesn't see all the images at the same time, it only see one image (per logical drive, or partition). It won't be able to manage the whole device, no matter how big or small is it.

 

I realize that in some cases you might be interested to search/sort the whole device. But you certainly wouldn't be able to do that with physical disks, would you? How do you search/sort (or whatever) across multiple physical disks? You can't.

 

With a CF (or SD), you still can manage the whole device if you want. Just connect it to your card reader on the PC.

 

Sure, the 1050 would read SD, ED, DD, and HD. There seems to be some question as to whether that can be done with a single FDC chip - I think so.

 

If this is in relation to my comments, I don't think I ever said you would need multiple FDC chips. What I said initially, and that was regarding the 1772 on the XF-551, is that you would need to double the clock, and either use a different FDC (replacing the 1772, not both), or either overclock it. Regarding the 2793, what I said is that you need to double the clock (not overclock), plus replace and readjust the external analog circuit.

 

Reading multiple densities is probably academic anyway. Because I think we agree it is much more convenient to use physically HD, disregarding the "logical" density.

[Shawn Jefferson]

Not being familiar with MyIDE, myself, can you define small? Say 2000 files on 200 disk images? Searching may be easy but how about sorting and deleting and adding? Fixed block sizes? If you are doing all these non-drive related things over SIO, it would be a problem, wouldn't it?

 

Well, I didn't mean searching inside disk images themselves (and since many disks, especially games, don't have a readable directory anyway it's value is somewhat limited...), but sorting and searching the names or descriptions of the disk images themselves.

 

So you could have a list like:

 

221 B Baker Street

Arkanoid

Lode Runner

Zork I

Zork II

 

etc... search and select the disk you want and then boot it. I think most of the high-capacity add-on products do this in some way or another. (SIO2USB, SIO2SD, MyIDE, etc...)

[+bob1200xl]

Evidently, MyIDE keeps a table somewhere that holds partition information. This would be the same thing but also include directory entries. I tend to use DOS2.0 disks on these cards so it would be pretty simple to search every logical disk. Something like MyDOS might make it a little more complicated. It may be more useful to just work with the disks directly and generate some simple database on the card.

 

The whole idea is to be able to find things. I have hundreds of 3.5s, dozens marked IDE Code. How do I find IDE35C.ASM without mounting every disk and reading the directory? I can't do that with physical disks but I can with a CF card.

 

No, you didn't say I would need multiple FDCs, I did. If I can't get one chip to read all densities, I would just use two FDCs. (and, two drives) (or four drives) You may have lots of legacy disks that you want to read...

 

Bob

 

 

 

 

Not being familiar with MyIDE, myself, can you define small? Say 2000 files on 200 disk images? Searching may be easy but how about sorting and deleting and adding? Fixed block sizes? If you are doing all these non-drive related things over SIO, it would be a problem, wouldn't it?

 

Why you would want to search the whole card device? The computer doesn't see all the images at the same time, it only see one image (per logical drive, or partition). It won't be able to manage the whole device, no matter how big or small is it.

 

I realize that in some cases you might be interested to search/sort the whole device. But you certainly wouldn't be able to do that with physical disks, would you? How do you search/sort (or whatever) across multiple physical disks? You can't.

 

With a CF (or SD), you still can manage the whole device if you want. Just connect it to your card reader on the PC.

 

Sure, the 1050 would read SD, ED, DD, and HD. There seems to be some question as to whether that can be done with a single FDC chip - I think so.

 

If this is in relation to my comments, I don't think I ever said you would need multiple FDC chips. What I said initially, and that was regarding the 1772 on the XF-551, is that you would need to double the clock, and either use a different FDC (replacing the 1772, not both), or either overclock it. Regarding the 2793, what I said is that you need to double the clock (not overclock), plus replace and readjust the external analog circuit.

 

Reading multiple densities is probably academic anyway. Because I think we agree it is much more convenient to use physically HD, disregarding the "logical" density.

[+bob1200xl]

I would think it would be reasonably clear that "Zork I" is a bootable game and "Basic Utilities" holds directory entries, yes. But, "Zork I" (a disk) is not such a problem - "SCH1020.BAS" (a file) is. That's where my problem lies. Not much value in having hundreds of disks on a CF card if you can't find anything. I just can't write small enough on the label... :>)

 

 

Bob

 

 

 

Not being familiar with MyIDE, myself, can you define small? Say 2000 files on 200 disk images? Searching may be easy but how about sorting and deleting and adding? Fixed block sizes? If you are doing all these non-drive related things over SIO, it would be a problem, wouldn't it?

 

Well, I didn't mean searching inside disk images themselves (and since many disks, especially games, don't have a readable directory anyway it's value is somewhat limited...), but sorting and searching the names or descriptions of the disk images themselves.

 

So you could have a list like:

 

221 B Baker Street

Arkanoid

Lode Runner

Zork I

Zork II

 

etc... search and select the disk you want and then boot it. I think most of the high-capacity add-on products do this in some way or another. (SIO2USB, SIO2SD, MyIDE, etc...)

[Shawn Jefferson]

Evidently, MyIDE keeps a table somewhere that holds partition information. This would be the same thing but also include directory entries. I tend to use DOS2.0 disks on these cards so it would be pretty simple to search every logical disk. Something like MyDOS might make it a little more complicated. It may be more useful to just work with the disks directly and generate some simple database on the card.

 

The whole idea is to be able to find things. I have hundreds of 3.5s, dozens marked IDE Code. How do I find IDE35C.ASM without mounting every disk and reading the directory? I can't do that with physical disks but I can with a CF card.

 

This is an interesting idea. It wouldn't be that difficult to create some software that builds a table, that at the very least would identify a filename and the corresponding disk image slot number (MyIDE has the concept of partitions AND a seperate area for disk images-I'm thinking of the disk image area at the moment.) The table would, at the least need 13 bytes, 11 for filename and 2 for the image slot number. That would be around 19 per sector, so about 19,000 or so given the typical disk image size on MyIDE (1008 sectors usually).

 

The problems would be:

 

1. It would take a long time to create the table.

 

2. Searching the table would take considerable time, but less than going through all your disks with some other tool.

 

3. How do you update the table easily? Rebuild it every time files are added to a disk image?

[+bob1200xl]

It would take a long time over SIO, not so long on PBI. If you have a device already full of images and files, I would scan it with DOS2.0, then MyDOS and then SpartaDOS. I'm not sure that I would trust the DOS to give me a 'good' directory, in particular for those whole disk images that actually have DOS sector maps and such even though they are just boot disks. (you only have to do it once...) If you create the table as you add images, it should be pretty easy/quick.

 

If the table is sorted, a binary search should be fast.

 

I think the best approach is to use keys rather than moving data all over the place in the table. Not being a database guy... Something like a bubble sort is not bad for sorting tables that are already almost in order, so adding 30 or 40 entries into a 2000 entry file isn't anywhere near as bad as sorting one with 2000 random entries. Even a brute force search of 2000 records wouldn't take THAT long.

 

Be nice to plug in a CF card and boot to "Mount (D)isk or (F)ile?"

 

Bob

 

 

Evidently, MyIDE keeps a table somewhere that holds partition information. This would be the same thing but also include directory entries. I tend to use DOS2.0 disks on these cards so it would be pretty simple to search every logical disk. Something like MyDOS might make it a little more complicated. It may be more useful to just work with the disks directly and generate some simple database on the card.

 

The whole idea is to be able to find things. I have hundreds of 3.5s, dozens marked IDE Code. How do I find IDE35C.ASM without mounting every disk and reading the directory? I can't do that with physical disks but I can with a CF card.

 

This is an interesting idea. It wouldn't be that difficult to create some software that builds a table, that at the very least would identify a filename and the corresponding disk image slot number (MyIDE has the concept of partitions AND a seperate area for disk images-I'm thinking of the disk image area at the moment.) The table would, at the least need 13 bytes, 11 for filename and 2 for the image slot number. That would be around 19 per sector, so about 19,000 or so given the typical disk image size on MyIDE (1008 sectors usually).

 

The problems would be:

 

1. It would take a long time to create the table.

 

2. Searching the table would take considerable time, but less than going through all your disks with some other tool.

 

3. How do you update the table easily? Rebuild it every time files are added to a disk image?

[ijor]

If the table is sorted, a binary search should be fast.

 

I think the best approach is to use keys rather than moving data all over the place in the table. Not being a database guy... Something like a bubble sort is not bad for sorting tables that are already almost in order, so adding 30 or 40 entries into a 2000 entry file isn't anywhere near as bad as sorting one with 2000 random entries. Even a brute force search of 2000 records wouldn't take THAT long.

 

Why not to do all that stuff at a PC? That's the good thing about using this type of media, you can plug it in on any PC.

 

You can do that also at the device if you want, by using a more powerful micro, and perhaps adding more RAM. But is it worth? Most of the time you would only want to mount and manage single images. Only occasionally you would want to manage all the files, on all the images on the media.

[+bob1200xl]

Well, the PC isn't going to recognize a MyDOS directory, for example. Plus, I'd have to write a whole bunch of PC code and learn a whole bunch of interface protocol just to talk to the card at a sector level.

 

I'll ask you again - how do you find any particular file? Do you have some sort of master directory that you look in? Are you so organized that you can tell what each drive image contains? I'm not...

 

So, we use 32 bytes for each file entry, giving us about 16,000 files in a 512K memory. That should be enough. We can have multiple masters, if we want.

 

Sure, it's worth it! After all, what does it cost? Some space in the card? You wouldn't have to use it if you didn't need it. Sure would be handy if you did need it, though.

 

Bob

 

 

 

If the table is sorted, a binary search should be fast.

 

I think the best approach is to use keys rather than moving data all over the place in the table. Not being a database guy... Something like a bubble sort is not bad for sorting tables that are already almost in order, so adding 30 or 40 entries into a 2000 entry file isn't anywhere near as bad as sorting one with 2000 random entries. Even a brute force search of 2000 records wouldn't take THAT long.

 

Why not to do all that stuff at a PC? That's the good thing about using this type of media, you can plug it in on any PC.

 

You can do that also at the device if you want, by using a more powerful micro, and perhaps adding more RAM. But is it worth? Most of the time you would only want to mount and manage single images. Only occasionally you would want to manage all the files, on all the images on the media.

[ijor]

Well, the PC isn't going to recognize a MyDOS directory, for example. Plus, I'd have to write a whole bunch of PC code and learn a whole bunch of interface protocol just to talk to the card at a sector level.

 

Accessing the card at the sector level is trivial both in Windows and Linux (except that you might have permission issues). But I wouldn't do that.

 

The way I would do this, is to use a FAT format on the card. Then you won't need to use any sector level access on the PC. You access plain ATR file images. I realize this might require a bit more processing power at the device. But IMHO, the benefit of being able to read/write/copy the ATR images just with Explorer (or your favorite file browser) is huge.

 

I'll ask you again - how do you find any particular file?

 

Personally, I rarely look for a particular file without having an idea on which disk (images) it is. Usually, I look more for disk images (or physical disks) than particular files. This should be even more on this case, because you can use bigger disk images. But again, that's my personal view.

 

Sure, it's worth it! After all, what does it cost? Some space in the card? You wouldn't have to use it if you didn't need it. Sure would be handy if you did need it, though.

 

It seems we were talking about different concepts. What I meant was the following: the same software that you would implement in the PC (for say, searching), you could implement on the device. This would require a microcontroller a bit more powerful, and for best performance you would need more RAM at the device (this, in turn, might mean a micro with an external bus interface).

[+bob1200xl]

You're talking about the controller in the 1050? Using that for searching/file maintenance? I can't see putting all that additional horsepower out in the drive when you already have it in your computer. And, as I said earlier, difficult and clumsy through SIO. The idea is to boot the system into the configurator, select or search for whichever drive(s) you want mounted and restart the computer in that mode.

 

If you use FAT, you will be in 512 byte sectors, won't you? That's a no-no. This is native mode Atari. (that's how this whole discussion started)

 

If you don't need to search files, you probably don't need a very capable design. For me, with things like 800 BellCom disks, I need to search for files. Even with things like Pooldisk CDs full of Atari files - I can at least do a "Tree" printout. (must be 10 pages or more...)

 

Bob

 

 

Well, the PC isn't going to recognize a MyDOS directory, for example. Plus, I'd have to write a whole bunch of PC code and learn a whole bunch of interface protocol just to talk to the card at a sector level.

 

Accessing the card at the sector level is trivial both in Windows and Linux (except that you might have permission issues). But I wouldn't do that.

 

The way I would do this, is to use a FAT format on the card. Then you won't need to use any sector level access on the PC. You access plain ATR file images. I realize this might require a bit more processing power at the device. But IMHO, the benefit of being able to read/write/copy the ATR images just with Explorer (or your favorite file browser) is huge.

 

I'll ask you again - how do you find any particular file?

 

Personally, I rarely look for a particular file without having an idea on which disk (images) it is. Usually, I look more for disk images (or physical disks) than particular files. This should be even more on this case, because you can use bigger disk images. But again, that's my personal view.

 

Sure, it's worth it! After all, what does it cost? Some space in the card? You wouldn't have to use it if you didn't need it. Sure would be handy if you did need it, though.

 

It seems we were talking about different concepts. What I meant was the following: the same software that you would implement in the PC (for say, searching), you could implement on the device. This would require a microcontroller a bit more powerful, and for best performance you would need more RAM at the device (this, in turn, might mean a micro with an external bus interface).

[ijor]

You're talking about the controller in the 1050? Using that for searching/file maintenance?

 

Yep, why not?

 

I can't see putting all that additional horsepower out in the drive when you already have it in your computer.

 

"All that horsepower" is almost nil for today tech. Weren't you planning to use a 65816?

Well, don't use a 65816, use a "modern" microcontroller. A modern MCU costs less (even half the price) than a 65816; it has a processing power several magnitudes beyond, and includes in the same chip flash, ram, and even a CF interface if you want (plus a lot more).

 

And, as I said earlier, difficult and clumsy through SIO.

 

You don't perform the whole processing through SIO. The computer just sends a high level command to the controller in your device .Say, "can you please tell me on which image is the file XXXX?". Then let the modern/fast/powerful micro to do the hard work without any need for long SIO transactions.

 

The idea is to boot the system into the configurator, select or search for whichever drive(s) you want mounted and restart the computer in that mode.

 

Right.

 

If you use FAT, you will be in 512 byte sectors, won't you? That's a no-no. This is native mode Atari. (that's how this whole discussion started)

 

No. The computer has no idea about the FAT format, the sector size, or if you are using a real Atari floppy, a 3.5 HD one, or a CF. All the "magic" is performed inside the device:

 

The computer asks for the third sector of the disk.

The MCU on the device finds the corresponding offset in the ATR file image, and returns 128 bytes (or 256 if the image is double density).

Edited December 16, 2008 by ijor