No, just normal s-video cable (that's the whole point of having that connector)
Are you sure cable and adapter are OK? Do they work with another source?
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.
Also users that are not logged in can not create new threads. This is a, unfortunately needed, counter measure against spam. Please create an account and log in to start new threads.
No, just normal s-video cable (that's the whole point of having that connector)
Are you sure cable and adapter are OK? Do they work with another source?
Inevitable question: What kind of powersupply are you using? Also, could you please post the result of the chip detection the remote menu?
Please be patient - Jens is on vacation, he'll be back in two weeks
It looks like there are resistors on that board, so it might be fine to connect directly - but Jens can tell for sure, i don't know A1200 details
No, this is not normal. First thing to do would be making sure all ICs have proper contact in the sockets... to do that, "half open" the sockets, and move the ICs a bit back and forth, so the pins are scratching against the contacts.
perhaps its a good idea to check the c64 keyboard itself? "anykey" is an excellent tool for this: https://csdb.dk/release/?id=218803
I'll have to experiment with inserting some delays at strategic places in the SD code... that's the only thing i can think of that might help, we'll see
OK, so some results. IMHO this shows clearly a connection to power issues....
All SanDisk SDHC cards:
A: 32GB Ultra 120MB/s (silver)
B: 32GB Extreme 100MB/s (gold)
C: 32GB Extreme Pro 100MB/s (black)
The test was: i used the card as is (preformatted), copied a directory full of demos to it, then insert into chameleon and use it in the file browser
Short story: all cards work on V1, all but one show issues on V2
A) seems to be "on the edge". With V2 it seems to hang at init, however quickly removing/inserting the card makes it go further. Sometimes it would still run into a timeout and show "no files". Sometimes you can still trick it into working by re-reading the directory (cbm+r).
B) is an interesting case. It is generally the most stable card - with a twist. On V2 this is the (only) card that works acceptable. With V1 the chameleon resets when inserting the card - however after this, the card remains usable (This is the "heavy inrush current" situation clearly)
C) shows no sign of life with V2 (hangs at init and/or "reading directory)
To be honest - wouldn't it make more sense to connect the switch directly to the rp4, so it will also allow you to power ON? With Keyrah you can only send ACPI "sleep" or "power off" - there is no way to power on via USB (chicken and egg problem :))
Quotemake SIDPlay program work with Chameleon to play SID files directly from File Browser?
The short answer is: Unfortunately it doesn't work. Not like you'd want it to work anyway (That was one of the reasons to add the builtin player)
The long answer is: that sidplay program (i assume you mean the program by GRG) expects the .sid files on a regular commodore drive, and loads them via kernal calls. So typically, you'd put that program, plus the sid files, on some sort of huge storage device (like a 1581 disk, or a cmd-hd, or perhaps sd2iec). However, such thing does not exist on the chameleon - the menu system accesses the SD card "directly" and, besides that, there are just the two emulated 1541 drives. There is no way for a C64 program to "see" the content of the SD card, except by directly accessing it like the menu system does (and sidplay has no support for this, and probably will never have - it would basically have to support "MMC64").
What would work (but probably is not what you want): copy the sidplay program plus some .sid files into a .d64 and mount/run that .d64 - perhaps it can be an option to make small playlists with ~20 files or so
QuoteI suspect there is no chance to make SD cards "bigger" than 32GB work properly with Chameleon, because they are all SDXC cards.
We don't "officially" support them, but SDXC should work fine, if you format them with FAT32
I'll do some experiments with the cards jens bought...
Actually i also fixed some tape things - but that was long after the super old VICE (2.4) they use
Quotethe last what i may could try is to reflash with 9q but i guess that would make not much sense
Thats pointless
QuoteIt would be nice to have a list of confirmed working sd cards if something like that exist ?
Long ago we started listing some that show problems, see here - however, as said before, such list isnt very useful. You cant really take it as an indicator for what works and what does not, because vendors do randomly pick the cheapest flashes and controllers, so two cards of the same "type" are almost never actually exactly the same thing (unless they are from the same production batch).
That said, a very interesting test would be trying such "non working" card on chameleon v1 (since the software is exactly the same, when this shows a difference, its not the software :))
QuoteI don't understand, what do You mean by "DD image"?
A raw image of the SD card ("dd" is a commandline tool that can be used for this, typically on Linux)
Quoteit doesn't matter if I format or just delete files. In both cases when I put a single directory on SD card's root, I got endless "Sorting directory" info.
Creating smaller partition (or resizing down capacity of SD card from 32GB to any smaller size) gives me nothing, the same "Sorting directory" infoissue.
I see. And in the meantime i completely filled up that 64GB card with directories and files and i can browse the directories copied last (so well beyond 32GB) no problem. I dare to say it is very unlikely there is a software problem
I am just copying HVSC to that 64GB card (this will take a bit...)
It would be interesting what the minimal setup is to produce the problem. Ie format the card (do not just delete the files), then put a single directory on it - will this still not work? That would be very odd, since that should not produce larger sector offsets than a filesystem on a much smaller card.
Another good test would be creating a much smaller partition on that card, and then repeat the above.
Edit: copying done, entering directories works fine (which isn't surprising to me actually)
So the card works in the root directory? That sounds even more strange, so initializing actually works... *shrug*
Could you try filling the root directory with many files (a few hundred), and see if reading that large directory still works? And if it does, that loading files "at the bottom" (really: the files that were copied last) also works? (This checks reading beyond sector boundaries both on the filesystem and the flash)
I don't know what else to try, perhaps Jens could try to reproduce the problem and make some measurements (but he might need one of those cards - its close to impossible to buy "the same" card, due to how vendors randomly use different chips)
I doubt we have the logic space to implement a 6551 core, so small chance this could happen - we still have a bunch of bugs on the TODO list
I am *really* baffled now, i would have never thought the adapter could make the difference.
Quote(I have several adapters: One works fine on my MiST board but won't work on my TC64v2. One which works fine on my TC64v2 won't work on my MiST!)
That really makes me wonder... aren't those adapters completely passive?
Edit: WTH! Out of curiosity i did a quick test... the 64GB SDXC card that was basically doing what the OP described works just fine in the V2 Chameleon here - when i use a SanDisk Adapter instead of the Samsung one i was using before!