Problems dumping games
#11
I ordered an external power supply, and I will see how that goes.

I don't think the floppy cable is faulty, as my 3.5" drive and other 5.25" drive don't seem to have any issues using this cable.

I'm currently trying another drive (360K TEAC FD-55BV-06-U) , but having similar issues of wild flux values at times.
Reply
#12
There is technically no "max" track length defined in the official .g64 specification. Long tracks are apparently not supported in Hoxs 64. The .g64 converter built into the SuperCard Pro software generates the exact track length, and the buffer length needs to be long enough to accommodate tracks that are very long.
Reply
#13
I don't think the power supply is bad. I think the drive is bad based on the flux data.
Reply
#14
Quote:There is technically no "max" track length defined in the official .g64 specification.
but there is. at offset 0x0a in the header there is the maximum length of tracks inside the image, and that number is smaller than the longest track in these images - which is wrong. (VICE would show an error when trying to access such a track, i don't know what other emulators will do in that case)
Reply
#15
The value at 0x0A is length of the space that holds each track entry.  That is fixed at a length of $1F90, which is just a bit larger than the longest track possible with a 1541 drive.  The value of $1F90 is in fact so large that Hoxs 64 has a problem with it.

You could make the value at 0x0A anything you like (up to 64K).  There is no defined "max" limit in the .g64 specification.  I set it at $1F90 because that is the largest size you will ever need to hold any track. So, that value is definitely not "smaller than the longest track in these images", it's larger.  The only down side to do this is that it makes the .g64 image larger.  But it's not an option if you want to have all of the data.
Reply
#16
The 5.25" drives seems to be working better, using an external power supply. But still no luck getting G64 disk image to work in emulator.

I'm uploading fresh images to my Google Drive.

I uploaded images for GhostBusters for comparisons too, which is the only game I have been able to get working under WinVICE so far.
Reply
#17
Well, that drive is better but it, and likely your disks, are very dirty.  See attached.  That's what a dirty disk looks like.


WaterFront is the only disk that is not index'd in the group of disks you imaged.  So, it will not convert to a .g64 correctly (it will of course copy just fine using SPLICE mode).  Everything should convert to .g64 once the head/disks are cleaned. Back to the Future II loads up to track 25 where the data is dirty and it errors out. I would start with that one. Don't be surprised if you have to clean your heads for every disk you dump. Magnetic media didn't fair well with time.


Attached Files Thumbnail(s)
   
Reply
#18
I tried cleaning the game disks from the outside as best I could, but it made no real difference. I'm not going to go as far as cutting the disks, and cleaning the disk surfaces directly, as that destroys any value the disks had. The disks heads have been cleaned multiple times, especially after the worse disks (which tend to really screech) that still only seem to show garbage for the directory listing.

Unfortunately these disks really seem completely worthless, I got the games from a large batch of C64 disks (100+) on eBay, and looks like I'm going to have to put a claim in for a refund. I'm going to stick to only new disks, and tested disks on eBay in the future.

Thanks again, for the attempts to help.
Reply
#19
Quote:The value at 0x0A is length of the space that holds each track entry.
the value at 0x0A is the length of the longest track inside the g64, and if any of the tracks contains more data than this number, then the image is broken and will not work. not in VICE anyway.
Quote:So, that value is definitely not "smaller than the longest track in these images", it's larger.
perhaps actually look at the images before writing whatever.

for example CalGames.g64:
Code:
0000:000a | 90 1F    <- max length in header ix 0x1F90
0000:000c | AC 02    <- track 1 is at offset 0x02AC
0000:02Ac | A9 20    <- track 1 contains 0x20a9 bytes, which is longer than the 0x1f90 specified in the header, and thus will not work
Reply
#20
(09-17-2015, 10:07 PM)Kirben Wrote: I tried cleaning the game disks from the outside as best I could, but it made no real difference. I'm not going to go as far as cutting the disks, and cleaning the disk surfaces directly, as that destroys any value the disks had. The disks heads have been cleaned multiple times, especially after the worse disks (which tend to really screech) that still only seem to show garbage for the directory listing.

Unfortunately these disks really seem completely worthless, I got the games from a large batch of C64 disks (100+) on eBay, and looks like I'm going to have to put a claim in for a refund. I'm going to stick to only new disks, and tested disks on eBay in the future.

Thanks again, for the attempts to help.

Don't cut the disks!  There is no need to do that.  You can clean the disks in their sleeves.  You just need a soft cotton and alcohol.  Lightly drag the saturated cotton across the disk surface and then do the same with a new clean cotton swab.  Repeat until there is no visible debris on the cotton, and then rotate the disk in it's sleeve and repeat.  Do that one full rotation.  Keep in mind that the bottom of the disk is actual location of data for a 1541 disk.  If it's double-sided, clean both sides.  Cleaning works great for this old disks, but it does take a lot of time.

If a disk makes a noise "like screeching", it is exceptionally dirty and will not work until completely cleaned.
Reply




Users browsing this thread: 1 Guest(s)