Problem with drive emulation

Caution: Non registered users only see threads and messages in the currently selected language, which is determined by their browser Please create an account and log in to see all content by default. This is a limitation of the forum software.
Don't Panic. Please wash hands.
  • Hello.

    I have a TC64 with latest firmware connected to a real C64.
    I'm having problems with mounted images.
    I can mount a D64 image but when I'm back to BASIC, if I try to load a program using LOAD"$",8 or LOAD"*",8 it shows the SEARCHING FOR... message and does nothing else. It just stays there until I reset or press RUN/STOP+RESTORE.

    I can load games directly from the file browser (on the same D64 image) and they work, unless they require to load anything from the disk. In that case, the game will still there forever. That means that I can only play single-file games.
    I though that it could be a CIA problem (as I had the same problem years ago with a C64+1541) but tried to replace them without luck.
    Eventually I had the chance to test the cartridge in standalone mode and I had the same problem.
    My settings for Drive:
    Emu Drive 1 Device ID 8
    Drive 1 write protect off

    Emu Drive 2 Device ID off
    Drive 2 write protect off
    Update mounted images always
    IEC bus connection normal (internal)

    Real C64 IEC bus on (also tried this setting off)


    Is there something I'm doing wrong with or is it a cartridge problem?

    Thank you.

  • Please do the following steps:


    - reflash the latest firmware: http://wiki.icomp.de/w/images/b/b5/Chameleon_Beta-9i.zip

    - the flashing will reset the settings to defaults, so enable drive 1 id 8. leave everything else alone. save the settings

    - powercycle the device


    now the best test would be mounting a d64 in standalone mode, without any external drive connected. mount the image in the file browser (Alt/CBM+M) and try if it works in basic.


    the behaviour you describe typically happens when there is some kind of problem with the IEC bus, like two drives with the same ID... did you have an external drive connected perhaps?

  • Hello, Tobias.
    I did the reflashing. Initially I had updated the TC64 directly from the card, so this time I did the reflashing from Windows. Everything worked well.

    But the test results are the same:

    - Mounted .d64 image
    - Go to BASIC
    - LOAD"$",8
    - SEARCHING FOR $

    - Nothing else happens


    I do not have any external drives connected.

    This happens in stand alone mode as well as connected to a C64 and with different .D64 images, even one created directly from TC64.


    Am I missing anything?

  • Odd, and this is with default settings and just drive 1 enabled on ID8?


    No idea what could cause this... as said, when it hangs at "searching for" it usually (with real hardware) means something on the IEC bus is wrong (dead CIA, broken 1541 or sth like that). But that really shouldnt be the case when you are testing in standalone mode :)


    Please try another thing... In the main menu press "1" to start the retro replay image, press f7 to go to basic, then "@" and return. this should give you the DOS status message... does that hang too?


    pwsoft any ideas?

  • Thank you Tobias.

    Yes, all default settings except for enabling drive 1 with ID 8.
    No luck with the Retro Replay, though. Using @ just hangs until Run/Stop+Restore.

    I tried loading a 1541 ROM from the File menu, just in case, but it didn't help either.

  • It is V1.

    I have had it for a long time but I was unable to use it before because my PAL C64 had a 6572 VICII (Argentina) which didn't work with the TC64.
    I did use it for a while in standalone mode and I don't remember problems, but after an update I am sure it wasn't working anymore.
    I didn't pay much attention, as I started to use an SD2IEC on my C64.

    But recently I received a 6569 VICII and wanted to use the TC64 and came back with the issue.

    By the way, my C64 is running with a C64 Reloded motherboard.

    Thank you.

  • I see... For V2 it is possible to do some self diagnostics with the hardware test (which would be my next suggestion if you had a V2).

    Unfortunately for V1 the hardware test requires a special loopback cable to verify the IEC drivers on the TC64.

    The TC64 does work on a reloaded motherboard no problem.


    I doubt the cause is the firmware update, as we test drive emulation on all firmware versions that are released. A directory load is just one of those things that just works (tm).


    Maybe you can set the "VGA Debug Overlay" in options/VGA settings to "mem+cpu+drive1" and see if the emulated drive is actually running any code. Not direct a solution, but might give some more info what is going wrong here.

  • To my knowledge, switching off the IEC but on the cable loom is not an option of the core - however, this would be required to tell if the hardware causes a problem.

  • Correct only V2 has a presence detect on the cable that switches the off the internal connections. On V1 it is always active.


    @DiegoZan In cartridge mode did you have the cable-loom (the one with the keyboard, mouse and IEC) connected? If you did, try cartridge mode without the cable to see if it is the cable that is faulty. If it doesn't work in cartridge WITHOUT the cable attached, the problem is most likely in hardware of the Chameleon itself.


    Jens: CPLD maybe?

  • Maybe you can set the "VGA Debug Overlay" in options/VGA settings to "mem+cpu+drive1" and see if the emulated drive is actually running any code. Not direct a solution, but might give some more info what is going wrong here.

    Ok, I tried that. I'm not sure what I should see here as I never used it before.

    The second line, which I assume is the Drive info, shows a series of quickly changing numbers for all registers (PC, IR, A, X, Y, S) and at the end the numbers 1/1 01. Nothing changes when I use the LOAD command from BASIC.


    @DiegoZan In cartridge mode did you have the cable-loom (the one with the keyboard, mouse and IEC) connected? If you did, try cartridge mode without the cable to see if it is the cable that is faulty. If it doesn't work in cartridge WITHOUT the cable attached, the problem is most likely in hardware of the Chameleon itself.

    When running in cartridge mode I do NOT use the cable at all.


    I'd hate that, as returning the unit from Argentina and back will be a pain, expensive and may take months (worked on COVID-19 shipping exclusions in the shop system for over 2.5 hours this morning).

    Don't worry, I will not ask for that at this time!
    I had the cartridge for so long not being able to use it that a few more months won't change much...
    If this can't be solved remotely, I will keep playing single file games for the moment.

  • The second line, which I assume is the Drive info, shows a series of quickly changing numbers for all registers (PC, IR, A, X, Y, S) and at the end the numbers 1/1 01. Nothing changes when I use the LOAD command from BASIC.

    Yeah that is the processor status of the emulated disk drive. The 1/1 means first mounted disk from a total of 1. The 01 is the current disk track. If the registers are changing it means the drive CPU is running and doing "something".


    If this can't be solved remotely, I will keep playing single file games for the moment.

    I think we worked through the list of reasonable things to try to resolve it remotely.

    By elimination we already excluded problems in the cable harness, configuration issues, a C64 board issue or a firmware issue.

    Some additional tests could be done, but if it is indeed a defect in the hardware, it will not be fixed by doing more tests.


    I strongly suspect a problem with one of the CPLD pins, but like Jens said sending it in for repair is a bit tricky currently with Covid-19.

  • Since we have scheduled some Chameleon work for next week anyway, maybe it's a possibility to back-port the switching-off option from Chameleon V2 - however, since we don't have a presence-detect line, this would need to be a settings option, something like "ignore IEC cable".


    Let's do a very simple further test to see if the IEC is really blocked by a defective CPLD - a look at port A of CIA#2 may show this. Please launch the computer with floppy emulation enabled and type:


    PRINT PEEK(56576)


    ...and let us know what the output is. The upper two bits are interesting, as they show the state of the CLK and DAT lines.

  • Thank you for following up this.

    Result is 23 both with the drive emulation turned on or off.

    After you mentioned this test, I searched and founded this on a page (https://ist.uwaterloo.ca/~schepers/MJK/dnp.html)


    /CLK -> "1" : POKE 56576, PEEK (56576) OR 16

    PRINT PEEK (56576) AND 64

    /CLK -> "0" : POKE 56576, PEEK (56576) AND 239

    PRINT PEEK (56576) AND 64

    If the "1" POKE results in "0" and the "0" POKE results in "64", the /CLK line is ok.


    /DATA -> "1" : POKE 56576, PEEK (56576) OR 32

    PRINT PEEK (56576) AND 128

    /DATA -> "0" : POKE 56576, PEEK (56576) AND 223

    PRINT PEEK (56576) AND 128

    If the "1" POKE results in "0" and the "0" POKE results in "128", the /DATA line is ok.


    If either the /CLK or /DATA line is invalid, your CIA does not recognize logical bus levels correctly; replace it.


    The first 3 tests are ok but the result for the last one is "0" instead of "128".


    Then, I tested the same directly in the C64 and all of them were ok. Just the ?peek(56576) with the computer just turned on (and with no drive connected, as I don't have one) resulted in "151".


    So it look as there is a "broken CIA" in the cartridge...

    Another thing I noticed was that when not using the Cartridge, if I try LOAD"*",8 I get a "Device not present" message, but with the cartridge, even with the emulated drive disabled, I get stuck at "Searching for *".

    So that should be more evidence that one of the emulated CIAs is broken.


    Broken CIA means bad CPLD?


    This is probably a silly question, but is there a possibility of using the cartridge just as a disk drive and not emulating the whole computer, thus using the hardware CIAs?


    Thank you.

  • Yeah so first: The problem isn't really with the "emulated CIA".

    On the C64 main board the IEC bus (diskdrive bus) isn't directly driven from the CIA, there is a driver chip between the CIA output pin and the actual connector. On the Chameleon V1 hardware the CPLD performs basically this exact same function (it does a few other tasks as well). So a CIA chip can be perfectly fine, but if the driver-chip is broken you still have a none working IEC port. What it really sounds like here is that one port of the CPLD has died and now is permanently stuck at 0. Obviously not the complete CPLD chip is broken otherwise Chameleon probably would not work at all. It is still possible the CPLD is fine and there is a short on the board (a small solder blob or a very small conducting particle, a broken connection or something like that), but my bet is still on the CPLD itself just has lost a working leg.


    Now for config options: In cartridge mode the Chameleon does kind of a trick where it reads the CIA inside the C64 and COMBINES the result with its own emulation. This allows real drives to be combined with the emulated ones (with a few limitations). For SX64 users (where the diskdrive is fixed inside the machine and can't be physically disconnected), there is a method to disable the C64 part.

    So if it was the C64 side that was broken, it could be disabled and the Chameleon breakout cable be used instead. However there was never any need to disable the Chameleon part of the IEC, so there is no way to disable it in the standard firmware for this specific scenario you encounter. On V2 this option exists as it can be detected if a cable is plug-ed in or not, but alas not on V1.

    There is a "drive emulation only" option in the menu "somewhere", but that disconnects the emulated drive and the Chameleon IEC bus from the emulation completely. So instead of hanging forever, it turns into "device not found", so again not really useful for you as a solution.


    The only way I can really see trying to get that thing working remotely, as a last attempt, without shipping it across the world, is making a custom firmware for you where the IEC bus of the Chameleon is ignored completely (like a V2 would do without the cable). You won't be able to use real drives anymore, but there is a high chance that the emulated drive will start to function correctly if the signals coming from the CPLD are ignored inside the firmware.


    Now if that is something we want to add to the menu-system as an option for all users going forward, I don't know. This specific issue never came up before as far as I know.

  • Yeah, so... euh I made a file thing, with a software thing on a computer thing, or something.

    As it is around twelve in the night and I really shouldn't be working at this time of day, I just took what was in my development environment, reconnected IEC outputs back to inputs in the design and did a recompile.
    I only performed a quick test if it starts and can load anything in standalone, as I have my Amiga setup and there is no room to add C64 gear. That kind of work is scheduled for next week ;-). Lets hope this gets you through the Covid-19 period...


    Flash with Chaco in combination with the rom-menu.bin found in the UPDATE directory of latest official release. And lets hope it works... Exciting!


    chameleon_v5_iec_issue_analysis.zip

  • Well, as it turned out, the file thing, with the software thing on a computer thing was * A M A Z I N G *
    Sorry for the awful picture but I wanted to show it working and now here it's almost midnight too...

    Everything worked as expected and until now I didn't find any issues at all, but this weekend there's gonna be a marathon of games and if anything happens I'll let you know.

    Thanks a lot (a big fat LOT) for all the effort.

    Best regards and have a wonderful weekend!