Jump to content

JimDrew

Members
  • Posts

    131
  • Joined

  • Last visited

Profile Information

  • Gender
    Male

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

JimDrew's Achievements

Chopper Commander

Chopper Commander (4/9)

79

Reputation

  1. I just saw this post! Atari 8 bit disks, just like any system without an index hole sensor, will likely need 2 revolutions to encompass all of the data. SuperCard Pro was not really designed to have an automated process of decoding and writing data back to a disk. You can certainly manually copy any disk that a drive can physically write using the editor/analyzer at a flux level. There are a bunch of different utilities that can frame .scp image files. The correct method for allowing an exact copy is to capture 2+ revolutions and then the writing phase you write 1 full revolution plus as much data as necessary - up to the track gap (where the write splice occurs). SuperCard Pro does have a "SPLICE" mode that works pretty well for doing this automatically at the flux level, but it is not perfect. The SPLICE routine scans the flux data and looks for invalid flux that commonly occurs when the write head is turned off (during the mastering of the original disk). When the head is turned off there is a "smear" that occurs as the write circuitry powers down. That almost always (but not 100%) generates invalid flux and can be used to queue where the write splice is. There are cases where that smear ends up creating a valid flux timing value and so nothing appears abnormal. The double-sided capture is not accidental. If you don't want the other side's data then just ignore those TDH entries.
  2. Atari 400/800, Commodore, Apple II, TI-99/4A, and other single sided formats should only be dumping one side and the tracks are laid out in the image file like it has half-tracks (blank if they are not enabled). So a 40 track disk looks like an 80 track disk. Here is a conversation with Jeff (HxC) about single sided disks. This might help explain things better... https://torlus.com/floppy/forum/viewtopic.php?f=2&t=3865&p=22674&hilit=scp#p22674
  3. Any drive (including hard drives and tape drives) that uses a 34 pin interface and adheres to the floppy standard should work with SuperCard Pro. I have 2.88MB 3.5" drives that I have successfully used.
  4. I thought about this some more and then it dawned on me that I can use the index time vs. the bitcell times to determine the drive speed stability. So, as a recap - you did the media test and it passed on the JU-475. You then did the media test and it failed with the FD-54B drive. You created image files of the failed disk with the JU-475 and the FD-54B drive. Both of those image files have the exact same bad data. The index time vs. bitcell time varies from a few hundred nanoseconds to just a couple of microseconds, well within the normal realm of drives. The index time is the time that goes by from index to index (one rotation of the disk). The bitcell times is the total amount of time of all of the bitcell times added together. In a perfect world, the index time and bitcells time would be identicall. So, I don't believe you have a speed problem after all. This looks like something done electronically, like the drive electronics glitch during the write. SuperCard Pro does everything on the board itself. It doesn't actually need a USB device to spool flux data. The USB is just used as a glorified serial port (it's actually a parallel to USB interface). So, this is not a USB transfer error. It could very well be that your caps are an issue, but I don't think it would be the caps on the motor unless this problem goes away when the drive has been on and working for awhile, then maybe the reads and writes would be normal. There are lots of variables here, but my best guess after looking at this all again this evening is that something is bad in the write circuitry of the FD-54B drive. Personally, I would not waste my time with the drive and find another one. You could be chasing this problem forever and drive yourself nuts. The JU-475 drives are the absolute best drives you can use for imaging *any* 5.25" disk format. Don't let people try to sway you with myths about 48TPI drives reading "better" because the head is wider. That is nonsense. I get far better recovery out of 96TPI drives.
  5. So, what I need to do now is add an option that checks the drive speed variances vs. the flux data to determine when the problem is really media related or drive speed related. Have you tried doing the drive speed test?
  6. So, it seems that you should run to the trash can with your FD-54B drive in hand and deposit it. That drive is the issue, not the media. You already confirmed that yourself by doing the media test with the same disk on a different drive, which passes. There are some very severe and seemingly random drive speed issues with that drive. You will never be able to use that drive for making images or copies of disks. I loaded your files into SCP's editor/analyzer and clicked on the FLUX DISPLAY button to show the flux graphically. You should see a straight line of flux data like this: For some of those tracks that you had to ignore (and there were a lot of them!), they were like this: These lines not being perfectly flat can only be caused by drive speed variations. That CAN be caused by the disk being too tight in the jacket to be easily turned by the motor, but you would hear the disk making a loud "swoosh swoosh swoosh" sound as it spins. I have seen this before with drives that are not properly powered (12V). Maybe this drive uses more current for it's motor than the JU-475 does, or what your power supply can handle. You could measure the 12V supply to the drive when the motor is spinning (with a disk in) and see if it is stable.
  7. @cwilbar, Run the media test on a disk (you can select IGNORE to do the entire disk if you want to) and then make an image of that disk using INDEX mode and send it to me (data @ cbmstuff.com) and I can tell you exactly why the media test is failing. The media test writes a single frequency to the disk, reads it back, and analyzes it to determine if there are spurious emissions that are typical for bad media. Usually when someone reports this, there is an issue with the drive not outputting data correctly or within a timely manner. If you use the editor/analyzer to read the track and then click on the FLUX DISPLAY button you can graphically see what is going on. If you see *any* amount of red in that flux display then there is an issue with the drive sending data. This could be a problem with drive electronics delaying the read data. Typically if that is the case then the drive is not a good candidate for archiving disks because the data start vs. the index mark would be off a lot when a read is attempted.
  8. @phaeron, Last month I clarified the track layout for single sided disks in the .SCP specification. I also added the some of the new information for the RLL/MFM hard drive and tape drive support that is coming. https://www.cbmstuff.com/downloads/scp/scp_image_specs.txt
  9. I am thinking in the $69 range... depending on quantities, maybe less.
  10. So, I re-spun the 65xxT board to have a jumper option for pins 34 and 36 (R/W) and added pin 35 (/HLT). So, next month I will start doing some testing with an Atari 400 or 800 to see if the halt line works correctly.
  11. Yeah, I guess comparing pins 34 and 36 would be a good thing. So, I looked at the early CPU board schematic. I see how the HALT works. This won't be a problem implementing. It's just a simple condition.
  12. Thanks for the info! I will check the schematics to see how the external halt logic works, that will tell me what I need to know. Is there any reason why R/W could not be on both pin 34 and 36 at the same time? Pins 35 and 36 are normally not connected internally with the 6502 - but I am wondering if some slick hardware engineer found that these pins make great "vias" and used them that way in some design. I would hate to have add another set of gates and control logic just to handle pins 34 and 36 individually, if I didn't need to.
  13. Well, you definitely got that right! I had no clue that the Atari had a custom 6502. I was thinking that since it ran at >1MHz that the 'C' version (6502C) was the 4MHz capable chip! So... some questions for you... It seems that the pinout for Sally is identical to a standard 6502 with the exception of pin 36 now being R/W. Is pin 34 also the exact same R/W signal? I don't see pin 34 connected in an Atari schematic I found. Pin 35 is the /halt line, and that is very easy to support. I can take the address and data bus offline at any time - I do that already for the /RST signal. Is there some type of correlation of when the bus should go Z-state after the /halt line goes low? Most everything depends on a cycle state, such as RDY. Is there any documentation at all about Sally? I am going to make a 65816 emulation in the 6502 pinout so you can just drop this in an have a 65816. The emulation will run a bit faster than the 6502 emulation because the microcontroller I am using is a 16 bit version, and I am having to strip and swap bytes because it is little endian and I have to get the low byte for flags and register results. I don't have to do that when the 65816 is in 16 bit mode.
  14. My 65xxT just might be ideal for the Atari machines. You can set speed to be normal during any hardware accesses (mapped to whatever I/O addresses are needed). Taking the CPU off the bus (Z-stated) when forced to via the RDY signal is already supported, so there should be no issues with anything that needs the bus for access video memory. Since I control PHI1 and PHI2, those can actually follow the normal PH0 relationship, but multiple instructions can be executed (in a single PHI0 cycle) from internal memory when they don't require any slow down. So, the 65xxT is actually a variable speed CPU.
  15. Was this directed at me? The 6502 only has RDY as a means to halt it. I will have to take a look at the Atari schematics to see how/why they are needing to take the 6502 off the bus. BTW, I can make the 65xxT support the 65816 instructions by just changing the firmware. This is something that I will be doing for David Murrary's project, now that it has gone to a 6502.
×
×
  • Create New...