SuperCard Pro - Real disk images with WinUAE!

[JimDrew]

Hello Toni....

My name is Jim Drew, and I am a long time CBM developer - from PETs to Amigas.

Since I have released SuperCard Pro, I have had a few people start asking me about image files that will work with WinUAE. SuperCard Pro is a disk copier/imager device that generates flux level disk images. I have never looked at the PAULA emulation to see how complete it is (I know PAULA inside and out because I had to reverse engineer the data separator portion in order to create things like SYBIL, which was a disk copier/imager commonly used with EMPLANT, my Mac emulation). I think that flux level is a bit much for WinUAE though. I created a custom image format for SYBIL that was similar to a .dms image where the raw MFM data for each track was stored, along with the exact track length. Are there any formats that support this with WinUAE? If so, can you point me in the right direction and I will make a conversion routine for flux images. If not, can you recommend a direction to go? I can certainly help code this for the Amiga side if necessary - but I only code in assembly. I do have all of the original source code for everything I have done for the Amiga, so I could adapt something pretty quickly. I would like to be able to make image files of my entire Amiga collection (hundreds upon hundreds of original game disks) and have them work under WinUAE, and I guess I am not alone with that feeling.

So, if you are interested in this please let me know. I will do whatever is necessary to provide support for WinUAE.

Thanks!

Jim Drew - aka creator of SYBIL, EMPLANT, FUSION, and a bunch of other Amiga stuff.

[JimDrew]

Oh... and more info about SuperCard Pro can be found on my website: www.cbmstuff.com

[dlfrsilver]

Thanks Jim, that's pretty cool you came back aboard

[Galahad/FLT]

Your Sybil hardware was especially useful for copying and writing back down heavily protected Amiga disks as well

[JimDrew]

Believe it or not, I have about 50 brand new SYBIL units. I also have original ROM switch boards, boot drive selectors, SuperCard Ami II's, and around 400 EMPLANT boards! I am going to start putting these items on my www.cbmstuff.com website.

SYBIL was really popular with the BBS'ers. I remember seeing some of the BBS's back east with hundreds of SYBIL created disk images.

[Toni Wilen]

I don't want to do anything with flux transitions, it is too low level for emulation

If there is need for new format: technically emulation only needs byte-size data (DSKBYTR is byte based) and time until next byte is ready (if there is density changes) and position of index sync. The rest is automatic.

Raw MFM data is already supported with extended adf images. (track size is in bits, index is at bit offset = 0), simple format is described in disk.cpp. It does not support density changes or if protection reads track multiple time and checks for "random bits".

btw, UAE built-in FDI image support has MFM flux changes to binary data "converter" (and PLL simulation or something like that) but I still don't want to know how it works. (I didn't write it myself).

[JimDrew]

Thanks for the response, Toni. Unfortunately, there are a lot of programs that use the Rob Northern style of protections where the data on a track is written at various clocking times and then byte counted over a period of time. These protections would require some type of flux level support. Weakbits and strongbits can be easily implemented with WinUAE at the MFM level by using 0x00 as a weakbit (passing a random value to the data separator) and using 0xFF as a strongbit and passing a 0x00 to the data separator. These would work with extended .adf format, which I know nothing about - so, I will go track down the source code and woddle my way through the C to see how the structure is laid out.

Implementing weakbits and strongbits is as simple as I stated above, so please consider adding that support. If you have any questions pertaining to disk based stuff, PAULA, etc. please let me know. I would be happy to help out any way I can. Also, if you get bored and want to add support for the EMPLANT hardware, I happen to know a bit about that.

Thanks!

Jim

[Toni Wilen]

Emulation already supports weak bits and density changes (ipf and fdi). I only meant that I am not going to do any "flux changes to bits/density stream" converters, it is someone else's problem

EDIT: Normal method is for UAE to understand basics of the format (where track data starts and ends), when drive steps, track data is given to format specific "decoder" (this is the somebody else's problem) which returns two arrays, one that contains bitstream (size does not need to be byte divisible) and another that contains byte based density data and index sync offset relative from start of bit stream buffer. Data is re-requested after each emulated revolution (if it has weak bits).

[JimDrew]

I will look at the fdi format. How good is the GCR emulation in WinUAE? Several Amiga games were encoded with a mixture of MFM and GCR, mid track too.

With raw flux data there no "density" to contend with. For emulations that are using flux level, it greatly simplified things because the word of data that represents each flux transition is just a clocking duration and the MFM data is built from that, making it exactly like an original disk. SuperCard Pro can also be a floppy drive emulator and will use flux image files so no data has to be interpreted, it's just spooled like a real drive does.

Thanks again for your insight on this!

Jim

[Toni Wilen]

Originally Posted by JimDrew

I will look at the fdi format. I know the ipf format does not support many protection schemes. How good is the GCR emulation in WinUAE? Several Amiga games were encoded with a mixture of MFM and GCR, mid track too.

I have never seen any program ever using GCR bit = which means there is no GCR emulation. Give me Amiga executable that reads and writes GCR data and I'll think about it

With raw flux data there no "density" to contend with. For emulations that are using flux level, it greatly simplified things because the word of data that represents each flux transition is just a clocking duration and the MFM data is built from that, making it exactly like an original disk. SuperCard Pro can also be a floppy drive emulator and will use flux image files so no data has to be interpreted, it's just spooled like a real drive does.

I know but thats just the point, emulation does not need it = I don't need to care about it

I don't know (and probably don't want to know) how floppy controller PLL/data separator (and related circuitry) works. At least very good documentation is needed and required algorithms and more.

-> I prefer as high level data as possible that still looks like real data from real floppy drive to running software that directly accesses Paula registers.

[IFW]

Originally Posted by JimDrew

I know the ipf format does not support many protection schemes.

FUD master.

[mr.vince]

Jim, I bet Stingray or Galahad can explain to you how this works. It's no shame to ask.

Anyway, I am glad you are here and I bet others are, too. You can finally fulfill your promises after so many years: http://s11.postimg.org/yth6ksoz7/uu_sybil.jpg

[Galahad/FLT]

Originally Posted by JimDrew

I will look at the fdi format. I know the ipf format does not support many protection schemes. How good is the GCR emulation in WinUAE? Several Amiga games were encoded with a mixture of MFM and GCR, mid track too.

With raw flux data there no "density" to contend with. For emulations that are using flux level, it greatly simplified things because the word of data that represents each flux transition is just a clocking duration and the MFM data is built from that, making it exactly like an original disk. SuperCard Pro can also be a floppy drive emulator and will use flux image files so no data has to be interpreted, it's just spooled like a real drive does.

Thanks again for your insight on this!

Jim

Actually the IPF format is able to successfully duplicate most of the Copy protection systems that existed on Amiga, Copylock included.

Only a few one off protections and a few titles by Psygnosis are not included, but the majority of Amiga disk formats and protections are well known to the SPS team.

[JimDrew]

Toni, I wrote a LOT of Amiga programs that used GCR. Everything Mac emulation related, plus several disk copy programs, including SYBIL support code (which of course was finished and available - >Christian). A few other people have confirmed there were games that used both GCR and MFM formats. Most good Amiga copiers supported GCR mode too. So, programs that used GCR weren't exactly scarce. But, I did deal with GCR all of the time because of the Mac emulations and disk copiers I wrote.

I was looking for a method to supply 100% disk compatibility for the emulation, which ipf does not provide. People have contacted me asking if I can help provide this to WinUAE. I have all of the unpublished technical information about PAULA that I got from Commodore. I worked for Commodore in the early 80's and had a great relationship with them. I had a standing NDA, so If I needed undocumented information, licensing agreements for code, etc. I just had to call and arrange it. So, if perhaps you look at the disk emulation code again, I would be happy to help with PAULA related support. Thanks for your response!

[amilo3438]

Originally Posted by JimDrew

I worked for Commodore in the early 80's and had a great relationship with them. I had a standing NDA, so If I needed undocumented information, licensing agreements for code, etc. I just had to call and arrange it.

Just wondering if you could do something about (see below), that would be really great:

from topic -> "WANTED: hardware and documentation"
http://eab.abime.net/showpost.php?p=...&postcount=108

quote:
"Other chips, especially Agnus (blitter logic when programs write to registers while blitter is active is basically the last big unknown part)"

[Toni Wilen]

The point is still the same: I have never cared and still don't care about flux level support, I don't need it in emulation, I don't know or want to know how it works (It isn't really Amiga specific, every floppy controller has similar circuitry), I don't want to touch anything that is not fully digital.

Perhaps there is good enough reason but so far I can't see any that would make it worth the trouble.

Other developers are probably different but I require real world code (not some stupid simple examples, they are always totally useless) and specifications as priority.

Note that GCR support is totally different thing, it would be really easy to support it but no test programs = no support. I never do anything just by checking documentation, documentation is never good enough (only really great part in HRM for example is audio state diagram) and misses all important parts. (btw, mac emulation is not good enough reason, running emulation on emulation is really stupid reason)

EDIT: I mean that what would this enable that no other solution would not be able to do? (without requiring your floppy device!)

Also technically flux level support is interesting but at least fdi flux "decoder" looks horrible confusing and makes very little sense, it really needs documentation..

EDIT2: Supporting existing images (if there is enough and they are really confirmed working!) probably is good enough reason

And of course any kind of previously unpublished documentation is great

[mr.vince]

Originally Posted by JimDrew

including SYBIL support code (which of course was finished and available - >Christian)

If it was, let us have it. Since you are at it, you can as well deliver unfinished Emplant stuff. Thanks.

I repeat myself, if you don't understand IPF, ask someone that has the technical skills. There is no other format which is more versatile. Just add what you feel is missing.

Originally Posted by JimDrew

Most good Amiga copiers supported GCR mode too. So, programs that used GCR weren't exactly scarce.

Let me correct that for you:

Most good Amiga copiers did not support GCR mode. Programs that used GCR were scarce.

[JimDrew]

Christian, apparently you didn't bother to collect software updates. These were all readily available via the UUI BBS. Just because *you* didn't have the software doesn't mean it didn't exist. Perhaps you didn't want to call across the ocean to get it?

ipf is a file format, documented first by Jean, and then finally by you guys... not too much to understand really. WinUAE doesn't support flux level images, so no matter what is used (.ipf, .adf, .dms, .syb, etc.) it is never going to be 100% compatible. I am here in this forum because people have asked me to look into making an image file that would give WinUAE (or any other emulator for that matter), the ability to be 100% compatible with ALL protection schemes - not most, ALL. It's clear that Toni has no desire to do that, which is fine. I was just looking into as I was asked by my customers. That's it.

Like I said, most good copiers supported all modes used on disks - including GCR.

[JimDrew]

Originally Posted by amilo3438

Just wondering if you could do something about (see below), that would be really great:

from topic -> "WANTED: hardware and documentation"
http://eab.abime.net/showpost.php?p=...&postcount=108

quote:
"Other chips, especially Agnus (blitter logic when programs write to registers while blitter is active is basically the last big unknown part)"

I don't have any unpublished technical documentation about Agnus or FatAgnus. I can ask Dave Haynie if remembers anything specific. Bill Heard would likely know too. The only thing I remember is that writing to the blitter control registers during a bitblit was a no-no with "unpredictable" results. I didn't use the blitter much. I used it initially on the A500 for doing the MFM decoding, but ended up writing CPU based routines that were much faster when accelerators came out. I spent most of my time working with PAULA because of the disk copying and imaging software, and because of the Mac emulation - reading/writing variable speed disks.

[Toni Wilen]

About flux level support: as I said, it is technically interesting but I don't really see what it would enable that is not currently possible. (I only do "because I can" if it interests me )

FDI already has flux level support but I don't really understand how it actually works... It lives in too different (analog) world that does not really interest me too much, unless there is some good documentation that explains the operation.

Without extra help only thing that I can do is to (attempt to) modify FDI flux support to handle other types of images.

Perhaps you can easily convert between fdi and other types? FDI has really good documentation available from author's site. It may already support everything you need.

"Unfortunately" writing to blitter registers while it is active is not unpredictable at all (there are many demos that accidentally do it), it seems to always cause exact same (sometimes quite strange) side-effect, and it only depends on new and old BLTCON0 and BLTCON1 contents.