The following warnings occurred:
Warning [2] Undefined property: MyLanguage::$archive_pages - Line: 2 - File: printthread.php(287) : eval()'d code PHP 8.1.27 (Linux)
File Line Function
/inc/class_error.php 153 errorHandler->error
/printthread.php(287) : eval()'d code 2 errorHandler->error_callback
/printthread.php 287 eval
/printthread.php 117 printthread_multipage



CBMSTUFF FORUM
Side B Atari imaging problem - Printable Version

+- CBMSTUFF FORUM (https://www.cbmstuff.com/forum)
+-- Forum: CBMSTUFF PRODUCTS (https://www.cbmstuff.com/forum/forumdisplay.php?fid=1)
+--- Forum: SuperCard Pro (https://www.cbmstuff.com/forum/forumdisplay.php?fid=3)
+---- Forum: Atari 400/800 disks (https://www.cbmstuff.com/forum/forumdisplay.php?fid=9)
+---- Thread: Side B Atari imaging problem (/showthread.php?tid=277)

Pages: 1 2 3


RE: Side B Atari imaging problem - claycowgill - 12-30-2015

(12-30-2015, 03:36 PM)admin Wrote: You can't have GX jumpered... that should be on EX.

None of my drives have MS jumpered.

My drives have the following jumpered:

DS0
DS2
EX
DC
DA
IE (with a permanent wire on the PCB)

Hmmm.  Not sure what to say, but I've had GX set for the entire time I've had the board and it's been producing working images and writing disks OK, so that's a head-scratcher. ;-)

I have:
DS1
HM (hardwired)
MS (seemingly required or drive won't spin)
GX
DC
DA
IE (hardwired)
PH
RY (hardwired)

If I remove the GX jumper and place it on EX I get an error at about track 11-12 "Read Length > RAM Capacity" on the B-side image I'm trying to pull.  When I try that configuration on another A-side disk that is known good and was imaged successfully earlier (with the GX jumper on) I get that same 'read length' error at about Track 35.


RE: Side B Atari imaging problem - admin - 12-30-2015

Reduce the number of revolutions, that has nothing to do with the jumper. If you want to read the backside of a disk by just flipping it over you must have the EX jumper set. MS is not required, but should not be a problem from what I can tell.

The error message you see is due to the track length x 5 (5 revolutions) being larger than what the onboard memory can hold. Just reduce the revolutions to 4... You really only need one or two, depending on the type of disk.


RE: Side B Atari imaging problem - admin - 12-30-2015

EX works... see:

https://www.cbmstuff.com/forum/showthread.php?tid=278


RE: Side B Atari imaging problem - claycowgill - 12-30-2015

(12-30-2015, 09:00 PM)admin Wrote: Reduce the number of revolutions, that has nothing to do with the jumper.  If you want to read the backside of a disk by just flipping it over you must have the EX jumper set.  MS is not required, but should not be a problem from what I can tell.

The error message you see is due to the track length x 5 (5 revolutions) being larger than what the onboard memory can hold.  Just reduce the revolutions to 4... You really only need one or two, depending on the type of disk.

Ahhhh... I get it now. I was conflating the two issues. I had been using a8rawconv successfully for ~100+ original disks (and it reports "5 revolutions" when it closes the .SCP file), so I was assuming that the "# Revolutions" field in Disk Archiver would behave the same way (ie, set it to '5').

When I drop the revolutions down with the EX jumper set it does indeed work as expected. No idea why I need MS set, but the disk doesn't spin without it, so I'm going to just chalk that up to: "if it's stupid but works, then it isn't stupid". ;-)

Thanks for the help!

-Clay


RE: Side B Atari imaging problem - admin - 12-31-2015

Once Phaeron makes the change to a8rawconv to allow reading the back side with the index OFF (he actually doesn't need the index on with the front side the way he is doing the decoding), then you would be able to use that.

I am sure he must be handling the RAM error when the buffer overflows when reading 5 revs. It's the hardware that generates that message when reading.


RE: Side B Atari imaging problem - claycowgill - 01-02-2016

(12-31-2015, 08:10 AM)admin Wrote: Once Phaeron makes the change to a8rawconv to allow reading the back side with the index OFF (he actually doesn't need the index on with the front side the way he is doing the decoding), then you would be able to use that.

I am sure he must be handling the RAM error when the buffer overflows when reading 5 revs.  It's the hardware that generates that message when reading.

So for anyone reading this later on-- I ended up just rebuilding the a8rawconv executable from the source and 'hardwired' the application to 360RPM and no index pulse required by changing:


cmd[3] = rpm360 ? 0x09 : 0x01;

to:

cmd[3] = 0x08;

In the "bool scp_track_read(bool rpm360, uint8_t revs)" function in the file "scp.cpp".


With that little hack in place I can image B-side Atari disks just fine without any other tweaks necessary.

-Clay


RE: Side B Atari imaging problem - admin - 01-03-2016

Are you doing this under Windows? If so, what compiler and such? I would like to build a version to test with.


RE: Side B Atari imaging problem - claycowgill - 01-03-2016

(01-03-2016, 08:51 AM)admin Wrote: Are you doing this under Windows?  If so, what compiler and such?  I would like to build a version to test with.

Yep, Windows.  I just grabbed Microsoft's free "express" version of Visual Studio: 

https://www.visualstudio.com/en-us/products/visual-studio-express-vs.aspx

(I grabbed the "express for desktop" install.)

12GB of software to change one bit in a USB command buffer. ;-)

The project file in the a8rawconv opens just fine and all you need to do is build.  The executable will be up a directory from the source in the "out" path in either the "debug" or "release" folder, depending on which you have set as the current configuration.

My drive never varied more than a fraction of a percent, so I didn't worry about trying to recalc the rotational speed, but that's probably wise (or just make it a command line switch).


RE: Side B Atari imaging problem - admin - 01-03-2016

Thanks!


RE: Side B Atari imaging problem - admin - 01-03-2016

I already had Visual Studio 2015 installed (I found that out after installing the version you suggested)!  When I compile the program, the executable is quite a bit larger (231,424 bytes) than the executable provided in the .91 archive (182,784 bytes).  I am building as a release version for Windows 32 bit systems.  Any idea why there is the difference in file size?  How big is the executable file that you generating?  I get the same results from both the eXpress version and full version of Visual Studio 2015.