Bug reports

[admin]

Ok, fixed the issue with new image files not being able to be converted to .g64 images. I forgot to change the code associated with g64 conversions for the changed .scp image file format.

[LordCrass]

Looks okay now!

Turns out my directory loading problem is actually due to track 18 not being index aligned for whatever reason the original duplicator thought appropriate. You can still do a LOAD"*",8,1, but trying to load directory fails due to gap-in-sector.

Any plans to implement conversion of multi-revolution scp images into g64? Right now this is the only thing preventing me from just creating non-blind images of all my c64 stuff.

[admin]

Yes, there will be support added for non-blind conversions for all format types to various disk image formats. I am working on Atari ST and Amiga first.

[DrCoolZic]

v0.99 - As I said I was able to image disk with image size 67MB
But after several disk I got the following message "Read lenght > Ram capacity" after reading 2 tracks? and 400KB file written?
quit and restart the program and now block for any image I try to do?

made more tests.
Awesome disk 1 - 5 revolutions imaging works - write 67MB no problem
Awesome disk 2 - 5 revolutions imaging works - write 68MB no problem
Awesome disk 3 - 5 revolutions imaging fails after writing 100-400KB after imaging 2 to 4 tracks?
if after fails I restart the program and retry with 4 revolutions fails immediately
I have unplug / replug usb to reset board
Awesome disk 3 - 4 revolutions imaging works - write 60 MB
retest 5 rev "ram > capacity" ?????

unplug plug again board : now unrecognized peripheral?
I have rebooted my system wait for the system to fully reboot and plug the board via USB still getting peripheral not recognized does that mean my board is dead?

I have uninstalled everything unplugged everything - reinstalled everything - rebooted everything and now it works again
very scary !!!!
Waiting for next version 1.00 final

[LordCrass]

Wouldn't the next beta be v.100?

[admin]

The message about the RAM has to do with the fact that 5 revolutions does not fit inside of the 512K of RAM on the SCP hardware. I am going to have to split the reads when >4 revs are requested, or use the spool option.

As far as the file size - let's look at the the facts with 4us being the shortest bit cell time:

Total size = 160 tracks * (number of bit cells * 2) * number of revolutions.

So, if the number of bit cells * 2 of the maximum possible (200ms/4us) = 200000us / 4us = 50,000 * 2, so:

160 * 50000 *2 * 5 = 80000000

80000000 / 1024 / 1024 = 76.2939453125 MB

This means that the maximum possible size with 5 revolutions is ~76.3 MB with only 160 tracks. Is this was a high density disk, with 2us being the shortest bitcell duration, you can double that size.

Every motherboard handles USB errors differently. With my HP system, I don't have to do anything except unplug the USB device, wait 10 seconds or so and then plug it back in. But with my ASUS motherboard, I have to reboot the computer. You never have to uninstall/reinstall software. Just boot with the USB device not connected and then plug it in after seeing the Windows desktop.

[DrCoolZic]

But how come I get an error message after reading two tracks? and the program stop and hang

[admin]

You could get an error message with the first track when reading 5 revolutions - that could exceed the 512K of RAM. This is likely why 4 revolutions has no issues. If the track has high density data, then 5 revolutions definitely won't fit in, in fact it may 4 revolutions may not fit.

I will need to split up reads of 4 or more revolutions or use the USB spooling option (which I don't like because USB can be affected by other devices and other tasks).

[LordCrass]

If you split up the reads, you won't be able to piece them back together perfectly, which defeats some of the purpose of having multiple rotations. Unless you force the number of revolutions to be even, and then break them up after every two rotations, which would at least ensure that each read contains one unbroken gap-to-gap image of the track.

I'm not a fan of streaming from USB either. You'll get people who are used to heavy multitasking or slower computers having problems with their reads and writes.

[admin]

Huh? The ONLY thing that can shift is the index sensor relative to the current (or next) bitcell. I can easily piece them together, so that's never going to be a concern. I have a routine that can overlay every revolution and show just the differences in the bit cell durations. When you have a wildly varying degree of changes (like from weakbits) its easy to spot. It's also easy to spot write splices this way. I will probably end up using this routine for most of the copying routines in the future.

I don't want to rely on the spooling because you can use either the serial ports for transfers without the USB ever being used.