SuperCard Pro Flux Image format (.scp)
#41
No, v0.96 does not handle strongbits. There is NO change required to the file format to support strong bits. A firmware upgrade to the SuperCard Pro board itself which will be required to support strongbits, and that will be released next week.

I corrected the only location in the file that had 164 as the max number of tracks - thanks! I also made a note about how 0x0000 bit cell times are interpreted.

The file spec was changed to use the number of revolutions as the number of entries. ie:

; TRACK DATA HEADER:
;
; 0000 'TRK' (ASCII CHARS) - 3 chars
; 0003 TRACK NUMBER - 1 byte
; .... START OF TABLE OF ENTRIES FOR EACH REVOLUTION
; 0004 INDEX TIME (1st REVOLUTION) - 4 bytes
; 0008 TRACK LENGTH (1st REVOLUTION) - 4 bytes
; 000C DATA OFFSET (1st REVOLUTION) - 4 bytes (offset is from start of Track Data Header)
; .... ADDITIONAL ENTRIES FOR EACH REVOLUTION (IF AVAILABLE, OTHERWISE THIS WILL BE FLUX DATA)...
; 0010 INDEX TIME (2nd REVOLUTION) - 4 bytes
; 0014 TRACK LENGTH (2nd REVOLUTION) - 4 bytes
; 0018 DATA OFFSET (2nd REVOLUTION) - 4 bytes
; 001C INDEX TIME (3rd REVOLUTION) - 4 bytes
; 0020 TRACK LENGTH (3rd REVOLUTION) - 4 bytes
; 0024 DATA OFFSET (3rd REVOLUTION) - 4 bytes
; 0028 INDEX TIME (4th REVOLUTION) - 4 bytes
; 002C TRACK LENGTH (4th REVOLUTION) - 4 bytes
; 0030 DATA OFFSET (4th REVOLUTION) - 4 bytes
; 0034 INDEX TIME (5th REVOLUTION) - 4 bytes
; 0038 TRACK LENGTH (5th REVOLUTION) - 4 bytes
; 003C DATA OFFSET (5th REVOLUTION) - 4 bytes
; .... etc. etc.

So, there is no longer a blank entry for the 'next' entry because there won't be one. This didn't work when you had 5 revolutions anyways, as the 'next' entry would be flux data. So, as long as you are using the offsets and the number of revolutions as the number of entries (which technically should have been done from the beginning), then the file is fully compatible. All images generated by every version of the SCP copier is still compatible. The previous files were generated with extra wasted space in the TDH.

There are no 'holes' in the data. The flux data is still stored sequentially. The only thing that changed is that there are no longer 5 hard coded sets of 3 longwords. Instead, there is one set for each revolution. So, you can't check for a null (0x00000000) entry as a termination for the last entry in the TDH, you use the value in IFF_NUMREVS instead to determine the number of revolutions. My code does this:

... set rawbuffer pointer to 0
For X = 1 to ImageFileBuffer(IFF_NUMREVS)
... get duration, get length, get offset
... move file data to rawbuffer, rawbuffer pointer = rawbuffer pointer + length *2
Next X

This moves the data from the file buffer to the raw buffer. Technically, this is the correct way to do it. However, you could add up all of the bit cell lengths and use the offset for the first entry and move all of the data at once, instead of each revolution individually. The imager always creates the file with sequentially stored flux data. But, since the file spec allows data to be placed anywhere, the correct method is revolution by revolution.
Reply
#42
Thanks for the info
I have been spending the last hour trying to figure out why my program was crashing on a file generated with V0.96
I have finally found that the null entries in the revolution table are gone Smile
and now i know how to fix the problem (for now I have hard coded the rev value Smile ...
All this was not obvious because I have modified many things in this version ...

I have also modified the code so it should be ready when the new scp format will be released for strong bits. As it is upward compatible my modification should handle correctly the current and future scp format.
Reply
#43
I updated my post while you were posting. Take a look at the file spec again - I fixed the last track reference issue and made a note about how the strongbits are stored.
Reply
#44
When the SCP firmware is released, v0.96 and later will automatically work. The long sections of no flux data will appear just as we discussed, as 0x0000 for an overflow. You add 65536 for each consecutive 0x0000 entry and add that sub-total to the first non-0x0000 entry as the total time. I plan on using the logic analyzer this weekend with the Amiga to determine what it does exactly to generate the proper data to create these no flux areas.
Reply
#45
I am stuck.
I thought I have found the problem but I still cant read 0.96 files Sad correctly ...
I have an image with 4 revolutions and I cant read the file correctly I must be doing something stupid. Works great with 0.94 !!!
I have tested your analyzer and it reads the file correctly?
Reply
#46
Ok I beleive the problem is in your file!
I will send you test cases
Reply
#47
(01-06-2014, 08:50 AM)admin Wrote: ALL of the 3.5" drives I have here are hitting the metal bracket on track 82, with no possibility to go to track 83. The Chinon drives used in the Amiga could not make it to 82 most of the time.

Hello Jim, all my amiga can read up to 83 tracks. As written on the atari forum, there are a number of games which use up to 83 tracks.

The Hitec games on amiga for instance (Scooby-doo, and many others of the same editor).

I use a PC drive name Sony MFP-920 (able to read up to 83 tracks, which i use also to dump with kryoflux btw).

i hope it can help Smile
Reply
#48
Are you saying that your drive can read 84 tracks? Most drives can't read 83 tracks. 83 tracks is 0-82 (inclusive), so 83 tracks are supported.
Reply
#49
(01-09-2014, 09:40 AM)DrCoolZic Wrote: I am stuck.
I thought I have found the problem but I still cant read 0.96 files Sad correctly ...
I have an image with 4 revolutions and I cant read the file correctly I must be doing something stupid. Works great with 0.94 !!!
I have tested your analyzer and it reads the file correctly?

Well, maybe I broke something! Smile

Got your email - I will look into what you found. LordCrass reported a problem that might be linked to the same issue.
Reply
#50
(01-09-2014, 11:58 AM)admin Wrote: Are you saying that your drive can read 84 tracks? Most drives can't read 83 tracks. 83 tracks is 0-82 (inclusive), so 83 tracks are supported.

83 tracks. Not 84 Smile I don't know any drive that can do that.

You use a different track numbering.

Oh, i forgot. Some Kingsoft games also use up to 83 tracks, for protection too.
Reply




Users browsing this thread: 2 Guest(s)