JimDrew
-
Posts
131 -
Joined
-
Last visited
Content Type
Profiles
Forums
Blogs
Gallery
Events
Store
Posts posted by JimDrew
-
-
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
-
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.
-
1
-
-
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.
-
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?
-
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.
-
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.
-
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.
-
1
-
-
On 8/19/2019 at 12:00 AM, mytek said:
That's great news Jim ? . I think a lot of people will be very interested in getting something like this. Any ballpark on the cost?
I am thinking in the $69 range... depending on quantities, maybe less.
-
2
-
-
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.
-
2
-
-
Might be interesting to scope pin 34 and see if there is any output.
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.
-
2
-
-
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.
-
On 6/28/2019 at 8:44 AM, mytek said:
The majority of A8s use Sally, not a standard 6502. Adding circuitry such as what was done in the early 800 to allow for /HALT wouldn't make sense when it can probably be emulated within Jim Drew's 65xxT. Coming from the CBM/Apple community Jim probably wasn't aware of the custom nature of Sally vs. a normal off the shelf 6502, so there was a bit information that needed to be exchanged before his board can be expected to work in an Atari. as to whether or not that happens, that'll of course be entirely up to Jim. There will be other concerns as well, such as physical fit in our systems, and compatibility both physical and operational to get along with other upgrades.
Here's an excerpt from Atari Mania describing Sally and a bit of its history...
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.
-
1
-
-
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.
-
1
-
-
10 hours ago, Rybags said:
/RDY isn't suitable as a replacement for Halt, BA etc since the 6502 ignores it if it's performing consecutive write operations.
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.
-
2
-
-
23 hours ago, mytek said:
I'll have to check that out. It certainly looks intriguing, but if it is to be used for our A8 systems it would need to also support the HALT line to pull itself off the bus.
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.
-
4
-
-
Well, it's coming! I am negotiating with a couple of programmers right now to add the ability to mount a floppy disk through SuperCard Pro (USB interface) as a drive letter under Windows. It will first be MS-DOS format, but the filesystem handler will be modular so you will be able to choose the filesystem (or perhaps that can be automated based on the disk type) for Amiga, Atari ST, Atari 400/800, C64, etc.
-
3
-
-
So, since I am not Windows device driver guy I have put up a project on Freelancer to find a Windows programmer that can create a Windows device driver/file handler where I can fill in the Windows code required for reading/writing sectors with the SuperCard Pro board. If I can find a person to do this we will be able to "mount" drive A: (or B:) on the Windows desktop and read/write floppy disks. I also want the filehandler portion of the code a separate module so it could be replaced (or added on to) to support Atari 400/800, C64, Atari ST, Amiga, etc. disks as a standard Windows drive letter.
-
1
-
-
Can SuperCard Pro work with native file systems? Specifically MS-DOS 5.0 and MS-DOS 6.22?
Sorry, but I just found this thread!
No, I don't have any software (or firmware) where the SuperCard Pro can emulate a USB floppy drive. If someone knows how to write the Windows side filesystem handler, I would immediately add whatever support was necessary for sending sectors any whatever disk format was required. I just don't know driver level programming in Windows.
You can use HxC Floppy Drive Emulator software to convert .scp image files to/from dozens of different disk formats commonly used with emulators. Several emulators also support either direct hardware access and/or .scp image file format.
-
I have one and it works fine except on my C128D and my C64 Reloaded MK2. There are other ones from other suppliers as well. Some come in nice cases.
It works fine on the C128D, that's what I used for my original development. You need to change a jumper pad for the C128/D to work with BURST mode loading. This is due to the UP9600 baud hack support, which is not compatible with the C128/D. I made a jumper pad where you can disable the UP9600 support if you are using a C128/D.
ANY USER port device, from EPROM programmers to audio capture devices does not work with the C64Reloaded Mk2 board without video interference. The WiModem is the same. For the Mk1 board you can remove the fake 8701 chip and replace it with a real 8701 chip and the video is now perfect - with any USER port device. There is a problem with the C64Reloaded Mk2 board (and Mk1 w/fake 8701) being too sensitive to the 5v rail due to the 8701 logic.
-
Not hardly. The WiModem232 is my own hardware design and my own firmware, written from scratch. In order to make the communications truly asynchronous (so file transfers work perfectly) I also had to re-write part of the ESP8266 library. There are literally hundreds of hours into the WiModem/WiModem232 coding to make it 100% fully Hayes compliant. This is why people can (and do) use it for running a BBS. You might also want to note the timeline in history. The WiModem for the C64 came out years ago, long before other solutions started appearing. The WiModem and WiModem232 are commercial products with lifetime warranties.
-
1
-
-
The WiModem232 responds to all Telnet commands with DON'T/WON'T. This seems to be enough to get telnet stuff running. With a WiFi modem you don't need a telnet connection, and frankly I am a little surprised that they are used at all because Telnet was used mainly for controlling remote dumb terminals (width, number of lines, speed, etc.) We don't use dumb terminals, we use terminal software which handles all of that. Telnet dramatically reduces the through-put and has difficulties with flow control as well. 99.999% of the time when you are "calling" a BBS nowdays, it is a direct TCP/IP connection - no telnet.
There are literally hundreds of telnet commands that would have to be supported in order to be fully "telnet compliant". Since I didn't even know about telnet for 2 years after releasing the WiModem, I would say it's probably not worth the effort to try to support it for a handful of cases. I doubt there is enough code space left for full support as well.
-
6
-
-
If you isolate pin 2 on the user port from the user port device, you can supply a separate 5v supply to device (along with ground of course) and that will resolve the issue. As long as the Mk2 is not supplying the +5v to the user port device then there are no video issues.
-
Apparently using any user port device that requires power with the Mk2 cause the same display issue, not just the WiModem.
-
The only thing I have found that causes 'Issues' on the MK2 is the Wimodem as it sends 5v pulses that cause display interference.
That's a myth. There are no "pulses" sent by the WiModem. The problem is with the C64Reloaded's 8701 replacement circuitry. It is too sensitive to changes in the 5 volt rail. The exact same problem exists with the C64Reloaded Mk1 board *if* you use the fake 8701 board. If you use a real 8701 with the C64Reloaded Mk1 board there are no issues. Likewise, if you put the fake 8701 board into a C64 you will then have the issues. Also, if try to use several other user port devices, such as Jason Ranheim's EPROM programmer, the PP64 EPROM programmer, or the Covox Voicemaster with the fake 8701 board or the C64Reloaded Mk2 board, you will also have the exact same issue that is seen with a WiModem.
So... let's recap:
C64Reloaded Mk1 board with fake 8701 and WiModem, EPROM programmer, or digitizer = video artifacts
C64Reloaded Mk 1 board with real 8701 and WiModem, EPROM programmer, or digitizer = perfect video
C64Reloaded Mk2 board with WiModem, EPROM programmer, or digitizer = video artifacts
C64 with fake 8701 and WiModem, EPROM programmer, or digitizer = video artifacts
C64 with real 8701 and WiModem, EPROM programmer, or digitizer = perfect video
Like us on Facebook
Follow us on Twitter
AtariAge on Instagram
Watch us on YouTube
Chat on Discord
a8rawconv, a new raw disk conversion utility
in Atari 8-Bit Computers
Posted · Edited by JimDrew
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.