01-09-2014, 08:43 AM
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.
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.