Need feedback from experts on JagCD session/track format

[belboz]

This is a rather long message so I apologize up front.

 

I received a couple disks from Curt with some of the development tools I have gotten from him. I've had trouble booting two of the Jaguar format CD's he sent me (unsigned CD's so you need a bypass mechanism).

 

One disk is the CES demo disk with the various Jaguar commercials and some movie clips. The second is labeled as a "CD to Alpine Loader". I believe this is something Atari did with some demos or full versions (not sure) of Jaguar games that can be loaded to the Alpine and run. This doesn't look like the fancy Jukebox loader of Matthias.

 

Originally I was using the CD bypass image loaded onto my Alpine as I didn't have a bypass cart, or a mod'ed JagCD. Because of my frustration with these two disks I went ahead and popped open my JagCD and was happy to see it was socketed. So I put in the hacked bios that Glenn did that allows you to boot signed or unsigned stuff on stub Jags, or normal Jags. That didn't help with booting these two disks though.

 

I've tried booting them on my stub/94 Jag with the alpine loaded bypass, and also with Glenn's bios hack on the stub jag. I also tried the hacked CD with an unmodified Jag. No go. Curt said he tested the disks and they worked fine with his bypass cart. He suggested I ask here for some help.

 

I will add that I can boot unsigned CD's I made. I use R. Demming's program to take the gorf demo and burn it to a CDR. It works fine for me using all the various boot methods above.

 

In both cases with the two problem CD's, the system starts booting (i.e. you get the little jag animations as the CD loads) then the screen goes black and sits there. The CD still spins though, but I don't hear any head seeking or anything.

 

I did a little looking around on the actual data on the CD's with the pc program isobuster. With it I extracted each track in raw format and I noticed a few wierd things when looking at them with a hex editor.

 

First I wrote a little program that would search for the ATRI 64 byte header and the "ATARI APPROVED DATA HEADER ATRIx" header and then pull the code length and code starting address from the raw file. It would write out the raw binary code to another file (and byte swap it) and display the start address.

 

I ran my little program on the boot code track of the CES demo disk I extracted earlier with isobuster and took the resulting binary and loaded it into memory at $4000 (where it was suppose to go according to the header info) with my Alpine/stub system. I also ran the cdbios31.db script to load the cdbios into dram. I popped the original CD in the drive and executed the code at $4000 that I previously had loaded into memory.

 

I got the little "Licensed to Atari" logo on the screen. It then started playing the Cinepak files on the CD. There were some glitches hear and there in a couple of the movies, but they mostly played. It was cinepak clips of Jaguar commercials (Doom, Kasumi Ninja, Video Games 101, Iron Solider 2, A vs P). It had lo and hi res versions of most of these. It also contained high res movie clips from Star Wars, Jaws, some cowboy movie, and Back to the Future 3.

 

Anyway one of the things I noticed that is different about these two disks then all my other Jaguar disks (all commercial though) is that only the boot track had any of the ATRI and "Atari approved" header stuff. All the Cinepak movie tracks did not have this. (header or footer)

 

On all my commercial CD's the header/footer information is on every track. And in the case of Vidgrid which has Cinepak files on it, they also include the headers and footers.

 

I don't know enough about the headers and footers to know if they somehow are getting stripped during the copy process when Curt made copies for me, or if you just don't need them.

 

I don't understand why his disks won't boot. I am betting if I took the bin file I ripped from the boot track and remade a disk with it, it would probably boot. Something seems to be messed up to kill the boot process.

 

I ran my little ripper on the CD to Alpine disk also and ran that program on my dev system as above. It would pop up a green screen that said in small white text at the top "CD To Alpine Loader". The CD would spin, but nothing would pop up. I suspect it might have multiple code tracks, but I only ripped the one initially.

 

So it would seem in both cases I was able to extract working boot code from the raw boot code tracks saved to disk with isobuster. But in both cases these disks would not even boot on my Jags.

 

I'm hoping to find someone who has the CES disk who can possibly use ISObuster to read the boot code track and one of the movie tracks out as a raw file, and examine it and or send them to me. This would let me know if their disk contains the ATRI and other headers for the non boot code track, and also possibly see any differences in the boot code track which might give me an idea why mine is booting.

 

So if somebody has the CES demo disk I would love to get a raw extraction of the boot code track and the next track (its the low rez doom commercial, so its a small one).

 

Any help or advice with this would be greatly appreciated. Its driving me crazy!

[Stone]

Sounds like the CDs got minced in the copy process. Neat trick to get around that btw :-)

 

The CD-to-Alpine loader is the program that came out of Atari - Matthias's program is based on its source, making it look prettier and adding some new stuff. The reason the CD keeps spinning is because (as you suspected) it's looking for data tracks, which are cart binaries to put onto the Alpine. Ask Glenn, Robert Demming or Matthias about this since they all know lots :-)

 

Stone

[+rdemming]

If you view the boot track with ISO buster (sector view), at what offset does the ATRI header start. If it starts to early in the sector or maybe in the previous sector the CD-Bios won't find the boottrack. This happens when I copy a Jaguar CD with CloneCD 4.2.x and my Plextor writer. It writes the track earlier to the cd than then original. A normally written track with CD-record starts at offset $112 on my system.

 

Try to create a copy of the CD by extracting all tracks with ISO buster, byte swap them and removing the zero bytes before the ATRI header and writing the tracks back to CD with CD-Record. Does this work?

 

Robert

[atarifan49]

This is a rather long message so I apologize up front.

 

I received a couple disks from Curt with some of the development tools I have gotten from him.  I've had trouble booting two of the Jaguar format CD's he sent me (unsigned CD's so you need a bypass mechanism).

 

One disk is the CES demo disk with the various Jaguar commercials and some movie clips.  The second is labeled as a "CD to Alpine Loader".  I believe this is something Atari did with some demos or full versions (not sure) of Jaguar games that can be loaded to the Alpine and run.  This doesn't look like the fancy Jukebox loader of Matthias.

 

 

The CES Demo was a disk done by Atari to demonstrated the movie playing ability of the Jaguar (compared to other CD systems of the time, i.e. Sega CD, TG, 3DO). Atari spent a good chunk of money (around $80k for first payment) to Supermac to license the Radius Cinepak technology of video compression. Jaguar's movie format is a spinoff of Apple's Quicktime (which was one the best movie play formats at that time). CES Demo disk comprised of 160 x 120 and 288 x 216 screen size versions of their TV commercials (i.e. Doom, AVP, Tempest 2000, Iron Soldier (not 2), VGM 101, Kasumi Ninja) plus full size video bites of Star Wars, Jaws, Maverick (movie trailer), and Back to the Future III. The 160 x 120 size clips can be rotated and all movies can be scaled in real time to demonstrate the Jaguar's power.

 

 

 

Originally I was using the CD bypass image loaded onto my Alpine as I didn't have a bypass cart, or a mod'ed JagCD.  Because of my frustration with these two disks I went ahead and popped open my JagCD and was happy to see it was socketed.  So I put in the hacked bios that Glenn did that allows you to boot signed or unsigned stuff on stub Jags, or normal Jags.  That didn't help with booting these two disks though.

 

I've tried booting them on my stub/94 Jag with the alpine loaded bypass, and also with Glenn's bios hack on the stub jag.  I also tried the hacked CD with an unmodified Jag.  No go.  Curt said he tested the disks and they worked fine with his bypass cart.  He suggested I ask here for some help.

 

 

What I picture is happening is that the Stub/94 ROM is allowing you to paritally boot, but the CD's boot code is trying to authenticate the CD. So you need the developer CD boot code in the ROM. Even though that hacked version of the CD boot ROM does an alright job, it doesn't quite work on everything. At the time I made it, I had tested it on about 20 different disks and one would not boot with it.

 

If you modify your Jaguar system for development, I suggest the following:

 

Install a 27C020 EPROM in the Jaguar (in addition to the regular boot ROM) that contains both the Stub/94 and latest BJL ROM. Have two switches that allows you to switch between the original ROM and developer ROMS. The second switch can then be used to switch between the Stub/94 and BJL ROM's. You would need to have some 1k ohm resistors that will apply either a ground or +5V signal to the upper address line of the EPROM. This will allow the switching between the two halves of the 27C020. This will be like having three 27C010's in your Jaguar.

 

Install a 27C040 EPROM in the CD and have a EPROM that contains both the normal CD boot code and the developer CD boot code. The developer CD boot code works quite well for booting unsigned CD's and works well with the Stub/94 ROM. On this you will need a switch and some resistors to apply either a ground or +5V signal to the upper address pin.

 

 

 

I will add that I can boot unsigned CD's I made.  I use R. Demming's program to take the gorf demo and burn it to a CDR.  It works fine for me using all the various boot methods above.

 

In both cases with the two problem CD's, the system starts booting (i.e. you get the little jag animations as the CD loads) then the screen goes black and sits there.  The CD still spins though, but I don't hear any head seeking or anything.

 

 

It sounds like the movie player code is crashing or it's not finding the sync information for it to properly start playing the movie files.

 

 

 

I did a little looking around on the actual data on the CD's with the pc program isobuster.  With it I extracted each track in raw format and I noticed a few weird things when looking at them with a hex editor.  

 

First I wrote a little program that would search for the ATRI 64 byte header and the "ATARI APPROVED DATA HEADER ATRIx" header and then pull the code length and code starting address from the raw file.  It would write out the raw binary code to another file (and byte swap it) and display the start address.  

 

I ran my little program on the boot code track of the CES demo disk I extracted earlier with isobuster and took the resulting binary and loaded it into memory at $4000  (where it was suppose to go according to the header info) with my Alpine/stub system.  I also ran the cdbios31.db script to load the cdbios into dram.  I popped the original CD in the drive and executed the code at $4000 that I previously had loaded into memory.  

 

I got the little "Licensed to Atari" logo on the screen.  It then started playing the Cinepak files on the CD.  There were some glitches hear and there in a couple of the movies, but they mostly played.  It was cinepak clips of Jaguar commercials (Doom, Kasumi Ninja, Video Games 101, Iron Solider 2, A vs P).  It had lo and hi res versions of most of these.  It also contained high res movie clips from Star Wars, Jaws, some cowboy movie, and Back to the Future 3.

 

 

Good job. You isolated the problem down to the boot track. You said you got the boot code extracted and manually loaded it into DRAM and ran it and it played fine. If this is the case, then the movie player code is having difficulty in sync'ing with the movie data. This could've been caused by an extra byte or two being written when the CD was copied.

 

Jaguar CD format is so touchy when it comes to data alignment. This is due to programmers using the long word aligned instructions to quickly search RAM for a particular byte pattern (e.g. looking for the sync information for a movie). If the data is misaligned by one byte, the searching routine can skip right over the data it's looking for. And when people try and use CD copying software to back-up Jaguar CD's it's a hit or miss on whether you get a good copy or not.

 

 

Anyway one of the things I noticed that is different about these two disks then all my other Jaguar disks (all commercial though) is that only the boot track had any of the ATRI and "Atari approved" header stuff.   All the Cinepak movie tracks did not have this. (header or footer)

 

On all my commercial CD's the header/footer information is on every track.  And in the case of Vidgrid which has Cinepak files on it, they also include the headers and footers.

 

 

If what you mean by commercial CD is a published CD (e.g. Blue Lightning) then yes you will find all these headers and tailers on each of the tracks. Atari details the process they would go through when a developer submits the final product for publishing by Atari. These header and tailers help the CD track authentication tool in syncing with the data on each of the tracks to generate the track we all know as the encryption track.

 

In the case of these CD's, the author was probably still developing the player code (probably Scott Sanders) and didn't need the header and tailer's on the CD tracks. You can write code that doesn't need this information on the tracks, but the information does help in knowing where the data actually starts since the CD-DA format is not a precision format for CD data reading. Hope that makes sense!

 

 

I don't know enough about the headers and footers to know if they somehow are getting stripped during the copy process when Curt made copies for me, or if you just don't need them.  

 

I don't understand why his disks won't boot.  I am betting if I took the bin file I ripped from the boot track and remade a disk with it, it would probably boot.  Something seems to be messed up to kill the boot process.

 

Believe me, I've pulled my hair out many times trying to figure this out. A lot of the times it's almost near impossible to figure out exactly why.

 

As for Atari, when they would get a CD from a developer they would extract every track from the CD and create a new set of track files that they would use to make a new master CDR of the game. They used two programs on the PC, one to byteswap the data (byteswap.exe) and the other to search for the header and tailer and remove the extra data that is read when audio tracks are extracted (cdtrkfix.exe).

 

Use these programs with a good audio extraction tool to extract the tracks. Then you will need append two zero bytes to the beginning of each of these tracks to help give them the proper alignment for when they are burned onto a CDR. CDRECORD.EXE is the program I use to make Jaguar CD's with. Nice freeware recording program!

 

 

I ran my little ripper on the CD to Alpine disk also and ran that program on my dev system as above.  It would pop up a green screen that said in small white text at the top "CD To Alpine Loader".  The CD would spin, but nothing would pop up.  I suspect it might have multiple code tracks, but I only ripped the one initially.

 

 

That CD to Alpine program is something that Dave Staugas created for use within Atari. I think this was so when they went to places like CES and E3 they could just bring a single CD that contained a bunch of games that they could load onto Alpine's or flash carts. For this program to function properly it needs read data that is imbedded with the header on each track. The program is trying to read the data to it can create a menu for you to select which game to load. Again this get's into a data alignment problem. The program is trying to find a 4 byte word like 'GAME'. If the data is algined imporperly, then the program could skip right over the word because on one read it could see ' GAM' and on another see 'E#ar'. The word GAME is split up.

 

 

So it would seem in both cases I was able to extract working boot code from the raw boot code tracks saved to disk with isobuster.  But in both cases these disks would not even boot on my Jags.

 

I'm hoping to find someone who has the CES disk who can possibly use ISObuster to read the boot code track and one of the movie tracks out as a raw file, and examine it and or send them to me.  This would let me know if their disk contains the ATRI and other headers for the non boot code track, and also possibly see any differences in the boot code track which might give me an idea why mine is booting.  

 

So if somebody has the CES demo disk I would love to get a raw extraction of the boot code track and the next track (its the low rez doom commercial, so its a small one).

 

Any help or advice with this would be greatly appreciated.  Its driving me crazy!

 

My CD's are packed away right now. But if I run across them, then I'll try and extract some tracks from my CES disk.

 

Well, hopefully I shed some light on the problem for you. Probably didn't answer all your questions. Might of help create some more. I've attached the two PC programs mentioned above to this message.

 

Regards,

Glenn

cd_tools.zip

[belboz]

Sounds like the CDs got minced in the copy process. Neat trick to get around that btw :-)

 

Thanks!

 

The CD-to-Alpine loader is the program that came out of Atari - Matthias's program is based on its source, making it look prettier and adding some new stuff. The reason the CD keeps spinning is because (as you suspected) it's looking for data tracks, which are cart binaries to put onto the Alpine.  

 

Actually if it was looking only for the cart binaries I think it should have still worked. Since I actually had the CD in the cart. Much like how the CES demo worked for me when I loaded my ripped code into memory and ran it with the CD in the drive.

 

I suspect it has other code stored in another track, or possibly information to build the menu.

 

I think Glenn's information about the extra spacing is my problem. I am going to play more with it.

 

Ask Glenn, Robert Demming or Matthias about this since they all know lots :-)

 

Stone

 

I actually PM'ed those three with a link to this thread. Robert and Glenn have already jumped in with some great info already. Now I need to digest it all!

[belboz]

If you view the boot track with ISO buster (sector view), at what offset does the ATRI header start. If it starts to early in the sector or maybe in the previous sector the CD-Bios won't find the boottrack. This happens when I copy a Jaguar CD with CloneCD 4.2.x and my Plextor writer. It writes the track earlier to the cd than then original. A normally written track with CD-record starts at offset $112 on my system.

 

Try to create a copy of the CD by extracting all tracks with ISO buster, byte swap them and removing the zero bytes before the ATRI header and writing the tracks back to CD with CD-Record. Does this work?

 

Robert

 

Robert,

 

I don't have access right now, but I know the ATRI header started around $55000 bytes into the raw ripped bin file. I'm hoping this is just too far out and that is my problem with the data track not loading. Thats around 340K into the boot code track.

 

I am going to try doing exactly what you talked about tonight.

 

I worry some about the zero byte padding in the front, if it is not even padding I think the byte swapping will be messed up.

 

I know Curt said he uses Nero to make his copies. I will have to do some test with various copy programs.

 

I can't figure out how the CD's would boot for him though. Makes no sense.

 

Thanks for all the help Robert. I appreciate it.

[belboz]

The CES Demo was a disk done by Atari to demonstrated the movie playing ability of the Jaguar (compared to other CD systems of the time, i.e. Sega CD, TG, 3DO).  Atari spent a good chunk of money (around $80k for first payment) to Supermac to license the Radius Cinepak technology of video compression.  Jaguar's movie format is a spinoff of Apple's Quicktime (which was one the best movie play formats at that time).  CES Demo disk comprised of 160 x 120 and 288 x 216 screen size versions of their TV commercials (i.e. Doom, AVP, Tempest 2000, Iron Soldier (not 2), VGM 101, Kasumi Ninja) plus full size video bites of Star Wars, Jaws, Maverick (movie trailer), and Back to the Future III.  The 160 x 120 size clips can be rotated and all movies can be scaled in real time to demonstrate the Jaguar's power.

 

Oops. For some reason I thought it was Iron Solider 2.

 

What I picture is happening is that the Stub/94 ROM is allowing you to paritally boot, but the CD's boot code is trying to authenticate the CD.  So you need the developer CD boot code in the ROM.  Even though that hacked version of the CD boot ROM does an alright job, it doesn't quite work on everything.  At the time I made it, I had tested it on about 20 different disks and one would not boot with it.

 

Well even using the bypass rom image in the alpine gave the same effect.

 

 

It sounds like the movie player code is crashing or it's not finding the sync information for it to properly start playing the movie files.

 

I don't think it is ever loading. I think Robert's theory about the padding is killing the ability of the jag to boot the disk. The reason I say that is because in the case of the boot code for both of these problems disks you get an immediate display change before it does any cd access. The CES demo immediately does the Licensed by Atari image, and the alpine loader does that green screen with the CD to Alpine loader text.

 

 

Good job.  You isolated the problem down to the boot track.  You said you got the boot code extracted and manually loaded it into DRAM and ran it and it played fine.  If this is the case, then the movie player code is having difficulty in sync'ing with the movie data.  This could've been caused by an extra byte or two being written when the CD was copied.

 

Do you really think it is an issue with syncing the movie data? Do you think my theory about not even seeing the licensed by atari graphic is good enough reason to believe the boot code isn't even loading. I can keep the CD out of the JagCD and just download my ripped boot code and I get the licensed logo with a red background which I assume is to indicate a loading error. When I attempt to boot the cd for real I get nothing but a black screen, no licensed logo or anything.

 

Jaguar CD format is so touchy when it comes to data alignment.  This is due to programmers using the long word aligned instructions to quickly search RAM for a particular byte pattern (e.g. looking for the sync information for a movie).  If the data is misaligned by one byte, the searching routine can skip right over the data it's looking for.  And when people try and use CD copying software to back-up Jaguar CD's it's a hit or miss on whether you get a good copy or not.  

 

I'm hoping that is the issue with the maverick movie trailer track. It plays for about 3 seconds and freezes. All the other clips play through fine.

 

If what you mean by commercial CD is a published CD (e.g. Blue Lightning) then yes you will find all these headers and tailers on each of the tracks.  Atari details the process they would go through when a developer submits the final product for publishing by Atari.  These header and tailers help the CD track authentication tool in syncing with the data on each of the tracks to generate the track we all know as the encryption track.

 

In the case of these CD's, the author was probably still developing the player code (probably Scott Sanders) and didn't need the header and tailer's on the CD tracks.  You can write code that doesn't need this information on the tracks, but the information does help in knowing where the data actually starts since the CD-DA format is not a precision format for CD data reading.  Hope that makes sense!

 

Yes I did mean commercial/published CD's like Blue Lighting, Myst, etc.

 

Ok. I wasn't sure if the cinepak tracks were corrupt on the copies Curt sent me. Sounds like that wasn't the case.

 

Believe me, I've pulled my hair out many times trying to figure this out.  A lot of the times it's almost near impossible to figure out exactly why.

 

I'm just hoping to manually rebuild these two disks to get them alive again.

 

As for Atari, when they would get a CD from a developer they would extract every track from the CD and create a new set of track files that they would use to make a new master CDR of the game.  They used two programs on the PC, one to byteswap the data (byteswap.exe) and the other to search for the header and tailer and remove the extra data that is read when audio tracks are extracted (cdtrkfix.exe).

 

Use these programs with a good audio extraction tool to extract the tracks.  Then you will need append two zero bytes to the beginning of each of these tracks to help give them the proper alignment for when they are burned onto a CDR.  CDRECORD.EXE is the program I use to make Jaguar CD's with.  Nice freeware recording program!

 

Thanks for the programs.

 

That CD to Alpine program is something that Dave Staugas created for use within Atari.  I think this was so when they went to places like CES and E3 they could just bring a single CD that contained a bunch of games that they could load onto Alpine's or flash carts.  For this program to function properly it needs read data that is imbedded with the header on each track.  The program is trying to read the data to it can create a menu for you to select which game to load.  Again this get's into a data alignment problem.  The program is trying to find a 4 byte word like 'GAME'.  If the data is algined imporperly, then the program could skip right over the word because on one read it could see ' GAM' and on another see 'E#ar'.  The word GAME is split up.

 

Looks like repairing this one might be more work. Kinda fun in a sick way though.

 

My CD's are packed away right now.  But if I run across them, then I'll try and extract some tracks from my CES disk.

 

If you get the time sometime I would appreciate it. I would like to see the boot code track and the maverick trailer (since I think mine is corrupt). I'm pretty sure I can rebuild the boot code track, but I fear my maverick trailer is bad. I would like to rebuild this disk so it boots cleanly.

 

Well, hopefully I shed some light on the problem for you.  Probably didn't answer all your questions.  Might of help create some more.  I've attached the two PC programs mentioned above to this message.

 

Regards,

Glenn

 

Glenn,

 

All your info and help is greatly appreciated! Thank you very much.

[belboz]

Everyone,

 

I was able to get the CES Demo CD to work (except the maverick trailer which is track 10).

 

Here is what I did.

 

I used ISOBuster to rip each track from the CD Curt sent me. I ran the byteswap utility on all but the first two tracks.

 

The first track is the standard audio wav file so I just used Isobuster to rip it as a wav.

 

The second track is the boot code. I used isobuster to rip it in raw mode and then my program to strip all but the actual binary code from the track and byte swap it. I then used the maketrk program to rebuild a proper track image for the boot code.

 

I then had my WAV file , boot code, and all the movie tracks ready to go.

 

I used cdrecord to burn them all out.

 

My first attempted at this booted up and started playing the videos, but some of the videos would freeze or lock up the Jag. About half of them were bad.

 

I decided to rip the data tracks with my CDRW drive this time instead of my DVD drive. I compared the ripped tracks and there were different values for various data in the movie tracks (especially the padding, on my DVD drive many padding bytes were read as $41, where the cdrw read them as $00).

 

So I repeated the above process with the CDRW ripped data and everything worked fine.

 

The only issue was the Maverick video locking up a couple seconds into it, but I believed this one was bad anyway.

 

So if anybody could use isobuster to rip track 10 from their CES demo disk and send it to me, I would greatly appreciate it. That way I can make a fully functional CES demo disk.

 

I'm going to post another message talking about my work on the CD to Alpine loader disk.

[belboz]

Now if your following this saga you know I also had the same problems with the CD to Alpine disk.

 

This disk is formatted a little more wild. It has 4 sessions.

 

Session 1 contains track 1 which is the standard audio track. I believe this one is actually one of the tempest 2000 songs.

 

Session 2 contains tracks 2 through 11.

 

Session 3 contains tracks 12 through 18

 

Session 4 contains one track (track 19)

 

As before the boot code track (track 2) didn't have any boot code until way out around $55XXX bytes into the track. Running my program I was able to strip out the code (this one loaded at $8000) and byte swap it.

 

I went ahead and byte swapped tracks 3 through 19.

 

So I had everything converted as I did with the CES demo disk.

 

I burnt out the various sessions/tracks with cdrecord. Booted the CD and I could see the blue loader screen flash briefly and the screen went blank.

 

So this one didn't get very far.

 

I think as was mentioned by Glenn it is data alignment issue (even after all the above).

 

Part of the problem might be that cdrecord wants me to use the -pad option when burning the tracks. It keeps everything aligned to 2352 byte sectors. From what I can tell the padding occurs at the beginning of the track and the actual data gets appended after the padding.

 

If the menu program is looking in specific locations for the headers to identify the games and demos on the disk it might be what is causing it to fail.

 

Is the code for this Atari written Alpine loader program available somewhere? It might help me figure it out further.

 

If it is the padding I suppose I can pad the ends of the various tracks to keep them 2352 byte sector aligned.

 

I wil also entertain any other ideas on this one.

 

Thanks again to everyone for their help.