Jim Drew opens website + info on SuperCard Pro

[+Ksarul]

TI-99/4As used FM (40 tracks, 9 sectors/track, 256 bytes each, single or double sided), or MFM (40 or 80 tracks, 16 or 18 sectors/track, 256 bytes each, single or double sided) using WD1771, 1772, or 1773 controller chips.

 

The Cortex used MFM (40 or 80 tracks, 18 sectors/track, 256 bytes each, single or double sided) using TMS9909 controller chips.

[JimDrew]

Ok, so standard stuff. Not a problem for SuperCard Pro. You would just use the 360K/720K "PC" format. Thanks for this info!

 

The WD177x controller chips are the same as standard PC format, being it is normal MFM. Nothing fancy, much like the Atari ST.

[+Ksarul]

Do note that the FM formats are 90K/180K (SSSD and DSSD), so there are some differences from PC formats--and the 16-sector DD format only gives you 160K/320K (SSDD and DSDD). Many thanks for the response.

[JimDrew]

Fortunately, for copying there is no such thing as sectors when using flux data. Sectors only apply to decoded disk images. Are there disk mages for the TI-99/4A emulators? If so, where can I find some info on those? Thanks!

[JimDrew]

Well, I finally got the last piece of my Atari puzzle - a 1040ST with monochrome monitor (I already had the color monitor, just no computer). I also have standard 800, the 800XL w/1050, TRS-80, Amigas and C64's galore. So, I am looking for the TI-99/4A w/disk drive and I think I will have just about every major system that had floppies to make sure their disks can be duplicated and imaged. I did get detailed info on the disk structure and it is basically PC format, with programs like TI99-PC able to read/write to real TI disks. So, this will be easy enough to implement, just need a system to test. I also have the .TIDisk and .v9t9 disk image structure information for creating disk images.

Edited November 26, 2013 by JimDrew

[carlsson]

Err.. didn't you forget Apple ][ in your lineup?

 

Also, there are quite a number of other, mostly MFM based formats, e.g. BBC Micro using both 40 and 80 tracks, but as I've successfully written at least 40 track floppy disks on a regular PC with Linux, I doubt such formats will present any challenges to your device.

 

If you want a decent list of MFM type of formats, the OmniFlop homepage lists a lot of these.

 

Another, less common GCR format is the Victor 9000/Sirius-1. I suppose in case you don't already have a full list of possible formats, you could look into what existing competitors have documented, unless that is considered cheating and the wheel must be invented every time a new product is designed.

Edited November 26, 2013 by carlsson

[JimDrew]

I have a Laser 128, which I use for Apple ][ testing.

 

Yes, I have looked at what the competition has, and I have all of those formats covered (and then some), but I wanted to really support every emulator's disk image formats - besides being able to make disk backups.

 

Thanks for the link. I am learning more every day!

[carlsson]

Do you have a solution for reading/writing floppy disks for 100 tpi drives? I suppose one needs a 100 tpi drive to do that, no matter what kind of nifty electronics one puts inbetween. Or maybe a 96 tpi drive that can sample multiple half tracks and combine those could be made to work?

[ianoid]

So as far as disk 'recovery', you are able to read disks that may not be readable in native drives?

 

And, forgive my lack of technical savvy, this would be useful for making disk images of copy protected original disks that could be used with this device to make copies of a disk with copy protection intact? And could the disk images be used with hardware emulation, like for my Apple II, the CFFA300 disk emulator?

 

If so, put me on your mailing list. I'm interested.

[JimDrew]

The sole reason for SuperCard Pro is to archive your disks at a flux level. This means that 100% of everything is intact. I am not aware of what a CFFA300 disk emulator is, but if it can accept a GCR or flux level image, then yes, it could work. I can make sure that this is supported if you can give me some info on it!

[JimDrew]

OK, I located the CFFA 3000 website. I registered and I will be asking the creator of this device how the image file format works. If it's sector based, then that would not support copy protected disks. But, if it is GCR level, then it is certainly possible to support the vast majority of Apple copy protected disks. There will be some odd ball programs that used 1/4 track (spiral track) protection. But, for the most part it would allow you to run the game just like it was an original disk. I already have a publish flux image specification. Perhaps I can work this guy and help implement something. Flux files for CBM disks are about 2.5MB each, but CBM disks store way more data than Apple's do. Apple used a different GCR encoding scheme and a fixed density, offering less data in the same physical space. This is why a 35 track CBM disk stored more data than an Apple 40 track disk did.

Edited November 28, 2013 by JimDrew

[RobertB]

So, I am looking for the TI-99/4A w/disk drive and I think I will have just about every major system that had floppies to make sure their disks can be duplicated and imaged. I did get detailed info on the disk structure and it is basically PC format, with programs like TI99-PC able to read/write to real TI disks. So, this will be easy enough to implement, just need a system to test. I also have the .TIDisk and .v9t9 disk image structure information for creating disk images.

I have a TI-99/4A plus Peripheral Expansion Box (with disk drive) that I am not using right now.

 

Truly,

Robert Bernardo

Fresno Commodore User Group

http://videocam.net.au/fcug

[JimDrew]

If all else fails, I would borrow your setup Robert, thanks!

 

I missed the question about the 100TPI drives. Yeah.. you are stuck finding a 100TPI mechanism. I have a couple of SFD-1001 drives (Commodore's 100 TPI drive) and I can tell you there is no way to use a 96TPI drive to fully read disks created on a 100TPI drive.

 

Got the info on the CFFA 3000 image file formats that are supported. It supports .dsk, .po, and .nib formats. I went looking around and found that I already had the source code for the .dsk and .nib formats for my Apple II emulator for the Amiga. We didn't call them .dsk and .nib though, so it didn't dawn on me until I saw the physical format layout that I already had this info. The .po is just a different sector interleave from the .dsk format.

Edited November 29, 2013 by JimDrew

[JimDrew]

SuperCard Pro has been released. I am working on the various conversion routines for converting disks to all of the different formats needed by emulators.

[+Ksarul]

Well, I just bought one--now to see how the transaction goes, and just as importantly, how everything works once I get it. . .the link to the manual on the site is broken, but the link to the installer software works.

 

I'd been looking at this, Cryoflux, and Disc Ferret as possible disk preservation systems. I liked the direction this one seems to be going, so I decided to try it out.

Edited December 14, 2013 by Ksarul

[JimDrew]

As stated in our forum, I have not yet put the manual online. That will happen this weekend. If you have not already joined our forum, please do so and feel free to ask any questions! Thanks!

Edited December 14, 2013 by JimDrew

[+Ksarul]

I got my SuperCard Pro this weekend, so I'll be doing some experimentation with it once I get one of my systems set up properly for it. Definitely quick service on the purchase!

[telengard]

I've been on the fence about the Kryoflux and it hasn't been available for a while and this seems like a (possibly even better) alternative. My main use case would be for imaging rare games I come across that aren't dumped for a multitude of platforms (most of the ones mentioned are supported, although Coco support would be great). What I'm wondering is, are there currently means to convert the flux level images to the more ubiquitous ones used by emulators etc until those emulators support the flux level images, assuming unprotected (i.e. A8 flux disk to .atr), or to a format can handle the protection (st flux disk to .stx)?

Edited March 9, 2014 by telengard

[+Ksarul]

Actually, I just looked on their site and the Cryoflux is in stock. I did get one of these though--and I was also waffling between it, the Cryoflux, and the DiscFerret.

[JimDrew]

I've been on the fence about the Kryoflux and it hasn't been available for a while and this seems like a (possibly even better) alternative. My main use case would be for imaging rare games I come across that aren't dumped for a multitude of platforms (most of the ones mentioned are supported, although Coco support would be great). What I'm wondering is, are there currently means to convert the flux level images to the more ubiquitous ones used by emulators etc until those emulators support the flux level images, assuming unprotected (i.e. A8 flux disk to .atr), or to a format can handle the protection (st flux disk to .stx)?

 

There is a program called "Aufit" that will convert .scp image files made from Atari ST disks into .stx files.

 

You can also use the HxC's "floppy drive emulator" software to convert to/from .scp images to/from a large number of different disk image formats.

 

WinUAE, FS-UAE, and E-UAE all support .scp image files directly. If you have info on the .atr format, I can look at making a converter for .scp to .atr. Currently I am adding .adf support (Amiga), and I already have .g64 support (C64). I am working on the generic MFM (PC, Atari ST, TRS-80+, etc.) to normal sector routine. I would guess that most images needed for emulations are just raw sectors in a sequential order.

Edited April 3, 2014 by JimDrew

[telengard]

 

There is a program called "Aufit" that will convert .scp image files made from Atari ST disks into .stx files.

 

You can also use the HxC's "floppy drive emulator" software to convert to/from .scp images to/from a large number of different disk image formats.

 

WinUAE, FS-UAE, and E-UAE all support .scp image files directly. If you have info on the .atr format, I can look at making a converter for .scp to .atr. Currently I am adding .adf support (Amiga), and I already have .g64 support (C64). I am working on the generic MFM (PC, Atari ST, TRS-80+, etc.) to normal sector routine. I would guess that most images needed for emulations are just raw sectors in a sequential order.

 

Sounds good. I own a HxC so that would work well, as for the .atr format. Here is the info I provided a while ago to the catweasel folks:

 

The 'standard' ATR file format is: (first byte listed as 1, not 0)

* 01: NICKATARI Signature

* 02: "

* 03: Paragraphs, low

* 04: Paragraphs, high

* 05: Sector Size, low

* 06: Sector Size, high

* 07: Extended paragraphs

* 08..16: Unused

* Remainder of image contains Atari data.

If you need more detailed info, or if this isn't what you need I can dig it up.

[JimDrew]

I went to Nick Kennedy's website and got the info on the .atr disk format, along with a sample disk image. Now I need to write a routine to convert FM data to raw sector data. I should then be able to easily convert disks to .atr images.

Edited April 4, 2014 by JimDrew

[Great Hierophant]

I am interested in a device like this for potentially rescuing data off dodgy floppies. Suppose I have a standard IBM PC-DOS formatted disk that I am trying to make an image of, but gives read errors despite retries, cleaning drive heads, no obvious signs of damage to the media, etc. I would assume this is because the sector's CRC is not matching up with the data being read from the sector. In other words, some of the data being read is turning out to be a "1" instead of a "0", but a simple CRC check cannot tell you which bits are dodgy. I understand the principle of using a device to record flux transitions is to capture the data at the lowest level from the disk. I also believe these devices can sample floppy data at a much higher resolution than a PC disk controller. Would that help to determine the true identity of the bit and help save data? Or would a disk written from the flux transitions just transfer the error to a new disk or drive?

 

Continuing with this line, what if the disk has a "weak bit" protection scheme and also dodgy data sectors? Wouldn't I get false positive or negatives unless I knew how the protection scheme functioned (i.e. where the weak bits were supposed to be?) In many cases, I think the scheme would be obvious, just look for a cylinder with odd sector sizes and such.

[JimDrew]

Flux is flux. As long as the flux falls within a normal window (4us/6us/8us) it can be way off "center" and the data be recovered. Most of the WD177x and compatible controllers can handle a 10% variance in flux duration and still decode the data correctly. I have Amiga disks that are off by 30%, will not read on an Amiga at all and still decode correctly with SCP's .adf image/recovery option. If the flux is truly bad, it is really bad and there no way to "guess" the correct values because bad flux is never just a single transition, but rather groups of bad transitions. But, any good data between these bad ones can be recovered.

[papa_november]

So what can the SCP write right now or in the near future? I've always wanted something that can write floppies for all the systems I have. I've been burned before on the promises made by the Catweasel (Remember that thing?), and the Kryoflux is taking too long to get to where I need it to be to justify a purchase for me.

 

While I absolutely agree with the importance of being to read and hopefully duplicate original copy-protected disks, for my purposes all I really want is something that I can plug into a modern PC and write out non-protected plain disk image files straight to real floppies that I can run on the machines I have. Having to set up a serial link or keep an OmniFlop-capable Windows XP machine around just to do this is a big hassle and can be a huge time suck.

 

My basic wish list is for write support for the following formats:

 

C64

Amiga

(If I understand both are already working)

 

Apple II 5.25'

Apple II/Mac 800K

Atari Single Density

(If I remember right all of these are in the works)

 

720K 3.5 and variants (Atari ST, MSX, Commodore 1581 and friends)

(will be covered by the planned generic WD177X support)

 

X68000 5.25

(almost the same as PC 5.25 high density but with slightly different geometry)

 

3-Mode

(3.5 floppy format with the exact same disk geometry as a high-density 5.25 disk. Used on the PC-98X1, X68000 Compact, and other Japanese systems. Uses special 3.5 drives that can spin at 360 RPM)

 

 

Will all of these be working eventually? Support for the Apple formats in particular would be amazing, as the only way to do those as of now is to write out the disk images on the target machine itself. I'd love to not have to lug around a dedicated floppy-writing PC anymore as well.

 

3-Mode is a pain too because while every USB floppy drive is 3-mode compatible, modern Windows makes it pretty difficult (if not impossible after XP) to write 3-mode disks.

Edited May 8, 2014 by papa_november