My guess would be no - it's a common strategy for those chips to introduce new ones that don't work with the old driver, in order to fight clones. At least Prolific has been known to do this
Posts by Tobias
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.
Don't Panic. Please wash hands.
-
-
Quote
Not sure if the driver needs to be adapted for that - I would hope not.
Pretty sure you'll need a driver. You need one for Windows afterall
-
We don't have resources for this in the FPGA
-
No, that can't be done. It needs access to the plain file system, and a device working similar to a CMD-HD.
-
Quote
However, this isn't considered good practise
It's also illegal in many countries - so please resist the temptation to do this
-
Yes, this is due to how the C64 works, anything "external CPU" will halt the internal CPU and make the tape port unusable (as that is directly connected to the internal CPU)
-
(The 0/1 thing is fixed in VICE)
You can transfer anywhere, and select the banking via $01 as needed. However, transfers from/to I/O can be glitchy - they usually work (and there are programs that rely on it), but it is not good practise, and occasionally you might get a broken transfer. Transfers to RAM under I/O (D000-DFFF) are always fine and no problem.
-
> The first divergence I see is that in Turbo Chameleon 2 Hardware Monitor, when one types "m 0", the monitor always displays 00 00 for the first two bytes of the address space, and not the actual CPU Processor Port Data Direction and Processor Port map register values.
THat is by design. The chameleon monitor always shows RAM. The VICE monitor has different modes, by default it shows what the cpu "sees", if you use "bank ram" it will behave like the chameleon monitor.
Interesting issue about the REU in VICE. Since making the REU in VICE as perfect as possible is one of my hobbies I will look at it right now
-
As Jens said, this is not really possible - The monitor in the chameleon menu is basically like the monitor in a freezer cartridge, with similar limitations.
That said, VICE has become really damn accurate by now - so cases where a program runs in VICE, but not on the real thing, can usually be boiled down to the same reasons that would cause problems on different real C64s too:
- "old" vs "new" CIA. That's the easiest to test, just choose the other model in VICE.
- use of uninitialized RAM. This is a bit harder to test - but you can change the "RAM reset pattern", or fill the entire ram with 0s or FFs before loading your program (caution: for these tests make sure NOT to use autostart in VICE, load the program manually)
And also use a recent Development build of VICE, because you never know: https://github.com/VICE-Team/svn-mirror/releases
-
Quote
I find in http://wiki.icomp.de/wiki/Chameleon there is a Beta-9q image. Is that the latest?
Yes. Please update first Eg the clock port behaviour was fixed/changed, it should be possible to use it also when retro replay is not active.
-
-
clbri did you install the most recent update? There were actually some fixes related to the clock port (which was incorrectly disabled in some situations)
-
Not even C64 can be emulated in a useful way on Amigas though
-
Did you update the firmware to the latest release already?
-
Those who still have problems using certain SD cards, please read this
-
Since it appears to be a difficult to reproduce problem here, those who observe this could help....
Apparently there are other cores where those big cards work, when they do not work in the turbo chameleon core - i'd like to know exactly what cores those are (please link to the exact version/binary). Please also tell if you have a v1 or v2 chameleon, and in what slot you installed the other core. Please also tell what kind of SD card you are using (and preferably post a picture of front and back side). And to make it easier to reproduce 1:1, please try with a fresh sd card with minimal contents needed - and tell what those contents are. I'll have to investigate in detail what the other core is doing differently (in the core and the software running on it), and perhaps Jens needs to do some measurements too.
-
I have no idea really - other cores might use the card in completely different ways. I don't have any card that would work in another core but not in the chameleon core either, so its kinda hard to test
-
I posted a test build containing some of my experiments with delays here.
-
So, this one is a quick fix for the problem reported here, plus some other minor things
- some extra delays in the SD-Card init, try init a few times. May or may not make some cards work that did not before
- correctly save and restore IEC sensitive bit when entering/leaving menu
- The last file in a swaplist (.lst) was not recognized when there was no carriage return / line terminator after it
- when CFGTUR was set to the unusual "Turbo enabled/100% speed" config by a user program, the freezer will disable the turbo and not alter the speed setting from the configuration -
Can you make a picture and perhaps describe in a few sentences what exactly you did? That may help someone else in the future