_________________

You most certainly can if the disk has dual index holes. However, there ARE several floppy drives that I have here that either have jumpers for the index hole bypass or do not require the index hole to be functional when the motor is enabled. SuperCard Pro supports the flippy mod that was devised by the KryoFlux team as well, so there are many options for duplicating the back side.

_________________

While I certainly do not need to answer to you or anyone else in these forums, I will post a list drives that ignore the state of the index hole sensor during motor power up and selection. Some drives can be fooled by simply turning off the motor and then turning it back on before the internal time out period expires. Some drives require the /DSKCHG to be valid before operating, while others do not. The flippy mod (at least mine) on pin 33 pulses the index sensor on the drive using an interrupt driven routine to simulate a 300 RPM drive's index pulse (1.5ms of low and 198.5ms of high).

Hey Jim please don't waste your time on proving something to people who clearly take pleasure in attacking you. Don't feed the trolls and they stop trolling.
Congratulations on the device and program. I'm sure 99% of the C= community appriciate your efforts. And of course we prefer program's written in assembly that actually works than some C or java nonsense. Keep up good work.
_________________

_________________

Cant we all just get along on these forums? This is a hobby for christsake. Cant we look at people in the scene who contribute in any manor on their own accomplishments. Why do people constantly flame other people in this scene. Its ridiculous. Lets just enjoy the the computers and software that we all have an affinity for and drop all the personal attacks that go on.

I have programmed in FORTH, PASCAL, FORTRAN, APL, COBOL, and many other languages.

The reality is that most people can't grasp the assembly concept, and C (prefaced by LISP and similar languages) was created to make things somehow easier to understand, and to be portable - all at the expense of horribly unoptimized and bloated executables. Assemebly code is cleaner and much easier to understand. Anyone with decent assembly experience should be able to code at least as fast a someone doing the same app in C.

I can program in C, but I do not program in C because is it poorly structured, and you have absolutely no control of the executable. To make matters worse, your executable can change size and often times not function the same when compiler changes occur. Its a great language for making things easily portable, and that's about it.

In the embedded controller market, speed and size are critical for cost. I do a lot of C conversions to assembly (about one a week for the last several years), especially with Atmel AVRs. I can typically take C code and convert it to assembly using a CPU having less memory. The end result is a faster and less expensive option. I have done many conversions for repeat customers where they get their product working with C code and have me convert it/reduce it for their final product.

you can do all that but you cant convert a dll import header file to VBA because "you are not a c programmer". that totally makes a lot of sense now!
_________________

No, I never said that. I stated that converting the header for a .DLL inclusion from C to VB is not a straight forward conversion. You can't simply take the EXTERN and arguments and place them into a VB Declare Function statement.

LOL. ofcourse. you convert C to asm by hand all day but you cant possibly do THAT kind of trivial stuff. your shit flies - right into the fan.
_________________

_________________

I don't convert Windows C code to assembly code, only microcontroller based C code to assembly code. With microcontrollers there are no .DLL's, and typically you try not to use any Windows API or external .DLL's in VB due to memory requirements and possibility that the .DLL is replaced and no longer functions the same. Because of this, I have very little experience with VB using .DLLs - hence my request for information on converting the header files to something that VB will actually use. Fortunately, I now have that information so I can support OpenCBM through the application, which was the goal.

I already had all of the USB interface code done in VB6 using the FTDI FIFO chip, along with the sector editor interface, file requestor support, and numerous other things. It was the easiest/fastest means for initially testing the hardware. I just decided to build upon that test setup.

Hey, Jim: 2 quick technical questions, and a request.

JimDrew wrote:

The flippy mod (at least mine) on pin 33 pulses the index sensor on the drive using an interrupt driven routine to simulate a 300 RPM drive's index pulse (1.5ms of low and 198.5ms of high).

I'm curious how you are measuring the motor speed with a single-hole flipped disk? I was under the impression that the only way to do that was via the index hole/sensor, which won't work if you're overriding it. And, if you're not measuring the speed constantly, how are you accounting for the speed variations that you mentioned in a previous post?

Similarly, if you're overriding the sensor on the flip side, how are you ensuring proper angular positioning of the tracks, relative to each other?

And, the request: could you use a different pin than 33? It would be helpful for those people who already have a KryoFlux and modified drive who want to also try out your solution if they didn't have to either swap the flippy mod between the KryoFlux version and yours, or get another drive. There are plenty of GND/unused pins on the connector.

Thanks!

With drives like the EPSON SD-600 you are kind of screwed when it comes to drive speed. It varies so much that this drive is really only usable for dumping data to disk for things like .g64 creation. I would recommend a Teac 55 series, as those have an extremely consistant (+/-10ns per revolution) rotational speed.

Although there is no way to locate the index hole on the flip side without an additional index hole sensor, you can certainly align tracks on a copy. You do this by measuring the actual drive speed, step duration time, and write circuitry activation time.

To measure the drive speed, you wipe the track and place a marker. You measure the time from marker to marker and that is your drive speed.

To align the tracks you have to calculate the amount of time it takes to perform the step and write gate activation. This requires a few reads, writes, and head stepping to determine the total overhead.

Once you have this information you then pre-format the disk (using a wiped track with a marker) so that all of the tracks line up when checked. When it's time to write the track you just read the data until the marker is found, turn on write gate, and proceed writing the track data.

Obviously this is a bit over-simplified, but that is the basic concept behind creating aligned tracks. I started doing this with the last version of the SC+ software. I got the idea from my Bounty Bob Strikes Back copier, where I had to do the same thing to duplicate the half tracks.

If you have the flippy mod then you can use that instead of doing it the way I described above. The clock on SuperCard Pro is accurate to +/- 30ppm (with stability obviously much better), so for our application here an index pulse simulation is all that you really need to have. You just measure the drive speed (using the method I stated above) and adjust the index pulse clock to match your drive speed. After that, the interrupt driven fake pulses drive the index pulse line just like the index pulse sensor was really there. Again, there won't be any reference to the actual index hole, but the tracks will be aligned during the write.

Since the flippy mod is on the drive itself, you don't need to do anything to have it supported with SuperCard Pro. You just unplug the drive from the KryoFlux board and plug in into the SuperCard Pro board. You then have flippy support the same way the KryoFlux board does. I don't see a reason to change the pin required on the drive as that would make it incompatible with the KryoFlux board.

Thanks for the details, Jim. That's an interesting approach to determining the speed of the drive. A couple of follow-up questions:

I see that approach can work for writing, but how do you determine the disk speed when making an image of the back side of a disk?

Similarly, for reading, how do you ensure track-to-track relative positioning?

Can you explain a bit more about your flippy mod? You talk about using pin 33, but also talk about driving the index signal, and it not conflicting with a drive modified for use with KryoFlux. I'm not sure how that works in practice. For example, if you're just driving the existing index hole data line (rather than reading it, not sure if that would even work), then I'm not sure what pin 33 has to do with anything. If you're plannning to feed your index pulses down pin 33 to the index sensor line, then that would A) cause the KryoFlux track zero override to trigger, potentially affecting your zero position, or B) cause you to have to disconnect that mod, and connect your index signal injection mod.

Thanks!
Robert

Thanks for your continued responses, Jim! I think that I've got a pretty good set of answers to my questions, with one exception, and I'm sorry that I'm not making my scenario clear.

My question is specifically around reading/imaging the back side of a commercial disk, using your flippy technique. As I understand it, the speed of various drives varies from drive to drive, day to day, and even (possibly) disk to disk. So, determining the actual speed of the drive at read time is important for making accurate images. On a commercial disk, you can't write a timing mark to do your speed measurements. So, on a flipped disk without the index hole that you can't write to, how are you measuring the speed? The only way I can think of is to use the A side to get a measurement for the drive/disk, flip it over, and use that speed for the back side. But, that seems like it might be less than ideal.

re: your mod vs. KryoFlux mod contending for pin 33, thanks for making the change.

Thanks,
Robert

In our case we don't care about the speed of the drive during the read because we have the bit cell timing and the total number of bits on the track, which is all you need to reproduce the track. You can read from a 360 RPM drive and write the data back correctly to a 300 RPM drive, all without having an index sensor. So, with or without the index sensor, you have to adjust bit cell timing so the track fits perfectly.

You can of course determine the speed of the drive by only reading. To do this you must identifying a singular occurring data pattern such as a sync with header, and use that to start/stop the timer during the read. This is really no different than writing a blank track and a marker. The marker is some known entity, like a sync/header combo, series of bytes, etc. Depending on the disk format, you might have use a few different cases for testing the speed. You obviously know the drive speed is going to be within a certain window. So, if you look for a string of bytes and that string repeats several times within 200ms (a 300 RPM drive) you know that you must change the string to something else.

Well, I got a few more things done with the analyzer. I now have the colors displaying for valid GCR (cyan), invalid GCR (light blue), syncs (white), and header starts (red). I will probably end up displaying the entire header string like I do with my GCR editor for the C64/128. The image below shows the data from the Defender of the crown image provided by the KryoFlux team. Note: the first two invalid GCR bytes shown are actually the .g64 track length info... I am removing that shortly.





I am considering adding pop-up help that tells you about the data the mouse pointer is over. For example, if the pointer was over the first byte of a header after a sync, the decoded header info would be displayed.

Jim, that's a very interesting approach to dealing with the "flippy" issue. I look forward to seeing how it turns out.

Thanks,
Robert