English Amiga Board Amiga Lore


Go Back   English Amiga Board > Support > support.WinUAE

 
 
Thread Tools
Old 18 December 2013, 21:55   #1
JimDrew
Registered User

 
Join Date: Dec 2013
Location: Lake Havasu City, AZ
Posts: 470
SuperCard Pro - Real disk images with WinUAE!

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.

Last edited by JimDrew; 22 March 2014 at 03:03. Reason: Typos!
JimDrew is offline  
AdSense AdSense  
Old 18 December 2013, 21:56   #2
JimDrew
Registered User

 
Join Date: Dec 2013
Location: Lake Havasu City, AZ
Posts: 470
Oh... and more info about SuperCard Pro can be found on my website: www.cbmstuff.com
JimDrew is offline  
Old 18 December 2013, 23:14   #3
dlfrsilver
CaptainM68K-SPS France
dlfrsilver's Avatar
 
Join Date: Dec 2004
Location: Melun nearby Paris/France
Age: 40
Posts: 7,063
Send a message via MSN to dlfrsilver
Thanks Jim, that's pretty cool you came back aboard
dlfrsilver is offline  
Old 18 December 2013, 23:35   #4
Galahad/FLT
Going nowhere

Galahad/FLT's Avatar
 
Join Date: Oct 2001
Location: United Kingdom
Age: 44
Posts: 6,504
Your Sybil hardware was especially useful for copying and writing back down heavily protected Amiga disks as well
Galahad/FLT is online now  
Old 19 December 2013, 04:53   #5
JimDrew
Registered User

 
Join Date: Dec 2013
Location: Lake Havasu City, AZ
Posts: 470
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.
JimDrew is offline  
Old 19 December 2013, 07:52   #6
Toni Wilen
WinUAE developer
 
Join Date: Aug 2001
Location: Hämeenlinna/Finland
Age: 42
Posts: 19,559
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).
Toni Wilen is online now  
Old 19 December 2013, 15:29   #7
JimDrew
Registered User

 
Join Date: Dec 2013
Location: Lake Havasu City, AZ
Posts: 470
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
JimDrew is offline  
Old 19 December 2013, 15:39   #8
Toni Wilen
WinUAE developer
 
Join Date: Aug 2001
Location: Hämeenlinna/Finland
Age: 42
Posts: 19,559
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).

Last edited by Toni Wilen; 19 December 2013 at 16:57.
Toni Wilen is online now  
Old 20 December 2013, 07:43   #9
JimDrew
Registered User

 
Join Date: Dec 2013
Location: Lake Havasu City, AZ
Posts: 470
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

Last edited by TCD; 22 March 2014 at 16:13.
JimDrew is offline  
Old 20 December 2013, 08:18   #10
Toni Wilen
WinUAE developer
 
Join Date: Aug 2001
Location: Hämeenlinna/Finland
Age: 42
Posts: 19,559
Quote:
Originally Posted by JimDrew View Post
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

Quote:
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.
Toni Wilen is online now  
Old 20 December 2013, 16:47   #11
IFW
Moderator
IFW's Avatar
 
Join Date: Jan 2003
Location: ...
Age: 45
Posts: 1,838
Quote:
Originally Posted by JimDrew View Post
I know the ipf format does not support many protection schemes.

FUD master.
IFW is offline  
Old 20 December 2013, 17:52   #12
mr.vince
Cheesy crust

mr.vince's Avatar
 
Join Date: Nov 2008
Location: Hawk's Creek
Age: 41
Posts: 1,374
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

mr.vince is offline  
Old 20 December 2013, 18:23   #13
Galahad/FLT
Going nowhere

Galahad/FLT's Avatar
 
Join Date: Oct 2001
Location: United Kingdom
Age: 44
Posts: 6,504
Quote:
Originally Posted by JimDrew View Post
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.
Galahad/FLT is online now  
Old 21 December 2013, 16:31   #14
JimDrew
Registered User

 
Join Date: Dec 2013
Location: Lake Havasu City, AZ
Posts: 470
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!
JimDrew is offline  
Old 21 December 2013, 16:57   #15
amilo3438
Amiga 500 User
 
Join Date: Jun 2013
Location: EU
Posts: 1,114
Quote:
Originally Posted by JimDrew View Post
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)"
amilo3438 is offline  
Old 21 December 2013, 17:29   #16
Toni Wilen
WinUAE developer
 
Join Date: Aug 2001
Location: Hämeenlinna/Finland
Age: 42
Posts: 19,559
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

Last edited by Toni Wilen; 21 December 2013 at 18:15.
Toni Wilen is online now  
Old 21 December 2013, 18:41   #17
mr.vince
Cheesy crust

mr.vince's Avatar
 
Join Date: Nov 2008
Location: Hawk's Creek
Age: 41
Posts: 1,374
Quote:
Originally Posted by JimDrew View Post
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.

Quote:
Originally Posted by JimDrew View Post
Most good Amiga copiers supported GCR mode too. So, programs that used GCR weren't exactly scarce.
Let me correct that for you:

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

Last edited by mr.vince; 21 December 2013 at 18:46.
mr.vince is offline  
Old 21 December 2013, 21:35   #18
JimDrew
Registered User

 
Join Date: Dec 2013
Location: Lake Havasu City, AZ
Posts: 470
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 is offline  
Old 21 December 2013, 21:44   #19
JimDrew
Registered User

 
Join Date: Dec 2013
Location: Lake Havasu City, AZ
Posts: 470
Quote:
Originally Posted by amilo3438 View Post
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.
JimDrew is offline  
Old 22 December 2013, 09:27   #20
Toni Wilen
WinUAE developer
 
Join Date: Aug 2001
Location: Hämeenlinna/Finland
Age: 42
Posts: 19,559
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.
Toni Wilen is online now  
AdSense AdSense  
 


Currently Active Users Viewing This Thread: 1 (0 members and 1 guests)
 
Thread Tools

Similar Threads
Thread Thread Starter Forum Replies Last Post
Supercard Pro Case kipper2k Hardware mods 4 25 March 2014 20:45
Powercopy Pro Original Disk images thread dlfrsilver request.Apps 7 03 June 2012 02:28
Winuae & real hard disk problem marcolau support.WinUAE 5 25 September 2009 17:44
Atari ST Disk Images in WinUAE 1.6.0 AmigaBoingBall request.UAE Wishlist 10 04 June 2009 21:14
Winuae problems with real HD and floppy images webmany support.WinUAE 3 25 April 2007 01:08

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off

Forum Jump


All times are GMT +2. The time now is 21:36.


Powered by vBulletin® Version 3.8.8 Beta 1
Copyright ©2000 - 2017, vBulletin Solutions, Inc.
Page generated in 0.26481 seconds with 11 queries