Jump to content

JimDrew

Members
  • Content Count

    130
  • Joined

  • Last visited

Community Reputation

78 Excellent

About JimDrew

  • Rank
    Chopper Commander

Profile Information

  • Gender
    Male

Recent Profile Visitors

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

  1. 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
  2. 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.
  3. 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.
  4. 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?
  5. 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.
  6. @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.
  7. @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
  8. I am thinking in the $69 range... depending on quantities, maybe less.
  9. 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.
  10. 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.
  11. 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.
  12. 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.
  13. 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.
  14. 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.
  15. It supports RDY, which I assume is your HALT line? If so, as long as you adhere to the 6502 timing requirements (pulling it low during PHI1) then it should have no problem. I actually control PHI1 and PHI2. I can change these asynchronously to the PHI0 to increase the speed of the 6502 without needing a faster external clock. That is one method of operation, which seems might work pretty well with the Atari if it has 15ns RAM (as stated above). Otherwise, with the 65xxT you set accelerated/non-accelerated regions that you want. This is to allow things like VIAs to operate at their normal clock speed. You can also move any ROM into the 65xxT's internal memory map so that it is always accelerated. There is 32K of cache memory and the zero page and stack can always be (or never be) cached. It's pretty fast, with the ability to execute up to 8 complex instructions within 1us. A single complex instruction normally requires 6+ cycles. Currently, the 65xxT supports the NMOS version and all of my testing so far has been done with the Commodore 1541 disk drive. So, all illegal opcodes are supported. I am currently working on obtaining information for the hundreds of various stand-up arcade machines because this can be used as a diagnostics tool to test RAM/ROM/Peripherals (who knew?). I plan to add support for the 65C02 as well as make different pinout versions for the 6510, 8502, and a couple of other 6502 variations. This same design will also be spun into a version for the Z80 and 6809E. The board uses a dual core 190MIPs microcontroller, with the code written in hand optimized assembly. I will say that I do have an Atari 400, 800, and 800XL here - but I have only looked at them enough to know where the 6502 is physically located to make sure that the 65xxT will fit. Other than that, I couldn't tell you how to boot a disk with an Atari system. I do have a couple of 1050 drives though should I get brave enough to try! My focus has not been on Atari systems, but I will doing some testing when I get some free time. I plan to release this at CRX 2019, to be used with Commodore 1541 disk drives, and VIC-20s... maybe more system (Apple II, Atari, etc.) by then? We shall see.
×
×
  • Create New...