Posts by r.cade

    I don't see how it can damage the floppy drive loading faster... It doesn't stress the electronics to do it.


    If anything, it's the opposite. The drive has to run longer to load slower. :)

    I think I did test this version and the result was less than satisfactory. If memory serves, there was a lot of noise even when nothing was playing. Flashing the Lazy Jones fix firmware solved the problem. I can, however, also find Swinkels's 20120524 firmware in the same directory of my hard drive, so I might actually have accidentally flashed that one, believing it was the test firmware you mentioned (also present in the same folder of my hard drive). When I get the chance, I'll see if I can test the 20141027 test firmware a bit more and will report back here.

    I have the Swinkels 20141027 version for a while and it also solves the issue with LazyJones, and also sounds better with 180... I have not noticed any problems.

    To clarify this... This firmware works on some C64's and not others. On some machines, it works perfectly and has no noise, and on others it has all kinds of noise.


    I have two 250469 Rev.4 boards - one has the problem and one doesn't.

    I also have two 326298 boards - one has the problem and one doesn't.

    All work fine with the CK lazy patched version.


    I can't really pinpoint the difference, but it must be timing somewhere.

    I have had monitors like this, and an SX64, that were left next to a speaker, or a wall in my basement, for a long time. I have a strong degauss coil, but I can never get the discoloration out. It seems permanent on mine, unfortunately.


    Sometimes you can move the monitor around in my basement and it will go away or change. I have had people tell me I am crazy and the earth magnetism is not enough to affect a monitor, but here I am. I can make a video that proves otherwise.


    I train myself not to notice.

    I'm not sure how a disk comes from the factory. In nibtools, I write all "0" bits to the disk on every halftrack, so no flux transitions at all. This shows up as "noise" to the 1541 because of how it works, but I have not tried to image such a disk with KF. I will do so in the next days to see which result this matches.

    This is what a fresh, never used Maxell disk looks like imaged with GW and loaded up with SCP.

    It looks just like the disk you show erased with KF, for comparison.

    This looks also exactly the same as a disk from 'nibtools -u'.

    Thsi looks also exactly the same as a disk erase with Greasweazle "erase" function.


    The reason it looks like this is the AGC in the floppy drive amplifies the absense of any signal, i.e. it is just noise from the amplifier.


    Note and remember that the floppy data seperator is designed for one thing only- to detect flux change. There are none here in any of the examples. The noise would never be detected as any kind of data, or interfere with it. It is "not there" like a ghost. The pattern will be different each time you read it.


    I don't know what signal SCP is recording on here that would show it as different, but that is not how a new unused disk looks. I wrote a disk as all sync (nothing bit 0x11111111) and it showed up as the second attachment.


    The 3rd attachment is from HxC Visual Floppy disk. Erased disks identical to the new one from the box.

    If you don't fully erase a disk formatted in an 80-track drive, it will not always work properly in a 40-track drive. There is leftover data on the halftracks that is not erased, and it will confuse the 40-track heads. You will get odd problems like described in this thread.


    It's best to erase the disk completely using nibwrite -u first. I think Kryoflux can also wipe the disk completely, and maybe other tools can as well (SCP or GW). A magnet will not work well enough, it just makes a mess.

    What currently trips up the device?


    I tried Commando (NTSC) G64 and it has trouble reading some tracks and fails to load. However, many other things load fine.


    Is it something that steps the motor too fast, or certain fastloaders?

    Seems to be... but remember I have 1.3.5, not the latest revision. Does that make any difference?


    PCB runs with good heads. OSC is 24MHz.


    I tried to downgrade firmware to 1.2.2 and that just says "Waiting for SD-Karte" and won't recognize when one is inserted. This problem doesn't happen on 1.3.0- I can browse and choose images. Maybe there is something here...


    EDIT: Nevermind, it sees the card after power cycle. Still same thing, though. READ ERROR


    There is something in the old install docs about cutting the BYTE READY signal on the gate array on 1541-II. This is a regular 1541. Do I still have to sever that connection on 1.3.5 board, and where is that on the 1541 board?

    Do I need to disconnect any of the existing drive circuitry at all? I disconnected the heads...

    You don't need to, but it might help. Maybe the pins aren't fully inserted because the pcb is sitting on the plugs.


    Thanks, I've raised it up with no change, and double/triple checked all pins seem to make connection to the PCB.

    Will it work on a regular 1541 board?

    I'mrunning it on a 250442 (see several pages above) without problems.

    I've built it and flashed the AVR and set the fuse bits as found earlier in the thread. All I get is backlight on the LCD, though. Drive comes up, but when I load anything I get DRIVE NOT READY. Is there a way to "fly blind" to see if the board is actually running and I just have no display?


    EDIT: I am a dummy. Let me put a POT on that 10K spot

    Hello all,


    I have built a board some months ago, but I think it is an earlier version than current (1.3.5).


    Anyway, I may assemble next week and had a couple of questions.


    Will it work on a regular 1541 board? I have stacks of these with bad Mitsumi R/W heads.


    Any modifications needed from 1.3.5 to 1.4.0 or is it just layout changes?

    Some cartridges don't initialize the SID chip before they run. The SwinSID both has to "boot" and also doesn't start with the same exact state as a real SID, so this can happen.


    You don't commonly see it because the C64 kernal does initialize the SID, but cartridges short-circuit this since they are detected and run very early in the boot process.