Posts by Tobias

That is a known issue - the demo seems very sensitive on chipram timing. Generally for demos the advice is to run them on the platform they were made for ie: disable the turbo card

"The core requires a ROM file in the root of the SD card, called C16.ROM"

1. I believe there is no big (or at all) difference between the emulation quality of the amiga core - it's essentially the same (minimig, as you already said)

2. i like to think the Chameleon C64 core is currently the most compatible one

3. That depends on what you are waiting for - and how long are willing to wait C64 Reloaded will still take some time, due to the current circumstances.

please dont post the same thing in several threads - i have answered here

I can only guess this is about the C64RMK2 - please post in the correct subforum

Same advice as before... wiggle the IC in the Socket a bit, the pins are corroded eventually.

Also, no cursor may be a sign of bad CIA1 - perhaps swap the CIAs against each other. If you DO get a cursor with the NTSC VICII you have, then this PAL VICII might be bad.

Please also tell what the output of the remote menu says under chip detection

Choosing lower write speed is a pointless exercise really. What really matters is that the type of the blanks is known by the writer firmware - if they are, 16x or faster will lead to the exact same - if not better - results. If they are not, the writer will always default to somewhat suboptimal generic parameters which may or may not work well, and that independent of the writing speed. (*)

(*) All that unless you are using really really old hardware and/or questionable blanks. Obviously neither is recommended

modern windows should even be able to burn ISO files out of the box

Since a lot of problems with cartridges are related to the physical cartridge connector, please try cleaning both the C64 Expansion Port and the connector at the card (old toothbrush and isopropanol works great for this - do NOT use "contact spray" please).

Since both the RAM and the Flash are not detected, bad connection seems more likely than a bad memory chip.... if cleaning doesnt fix it, perhaps the CPLD gave up (that we can only check in the workshop)

Quote

he laptop case you could produce a custom one.

That'd make the thing way too expensive to be interesting for anyone

Not with the regular Chameleon core (C64) - we only support VGA right now. (It could be changed perhaps, but i dont have any suitable Monitor to even test it, maybe pwsoft can do it when he is fully back in action).

Some of the other Cores do support 15kHz RGB however.

Reflashing the microcontroller is unlikely to work when it shows no sign of life... so yeah, it might need replacement. Lets see what Jens says tomorrow

Not contrast, but saturation ("color") Simply said, "contrast" controls luma, "saturation" (or "color") controls chroma. In your pictures the colors of the c64 reloaded look much more saturated than the ones from the c64 - which is a bit strange. The reason could simply be different output levels however, which is why i asked you to turn down saturation for the c64r a bit, so its the same as with the breadbin.

As for the cable, i am just guessing here. There is a common problem with using SCART, which is that either inside the adapter, or even inside the monitor, chroma+luma is recombined into composite.

Also, are you absolutely sure that adapter actually connects chroma and luma to the scart adapter, and not composite and chroma (or luma)? That will also kindof work, depending on how the levels of the respective signals are (and this varies from board to board).

Thats why i asked if you can test with a different display and without using a SCART adapter - it takes some uncertainties out of the equation.

MMmh, that sounds like the microcontroller is broken... Jens should be able to repair this.

In any case, first try:

use different USB cables than before, connect the barebones chameleon (no sd card, no keyboard etc) with both USB connections to your PC, then try connecting with chaco again. Also try to run the flasher.exe that comes with the update. If they both fail to connect, it might indeed be the microcontroller.

Quote

It's normal to compare the image of the two machines Breadbin and C64R when using the same video chip. For me, it's a C64 and I expect to have the same quality image and there is no artefacts on the breadbin.

Different boards produce different video output - this is true even for the different original C64 boards, no matter what videochip is in it. So to compare the images, you'll have to either dial down the saturation when the C64Reloaded is used, or increase it when the C64 is used (so the saturation is about the same for both) - because with (too) high saturation the artefacts you are seing are not unusual.

That said, can you test with another display and not using a scart adapter? What you describes sounds a bit like that scart adapter is mixing chroma+luma into composite, which also might explain what you are seeing.

Generally the Picture of the C64Reloaded should be at least as good as with any other C64 Board - so if it is not, its likely something like a broken cable, or broken connector.

Quote

proper 50/60Hz signal for the CIA TOD clocks is generated on board depending on selected video mode. The time base for this is another crystal oscillator, which is running independent of the main C64 clock circuit.

I said to myself that this could possibly influence the picture.

No, that only means that if a PAL VICII is used, then it will use 50Hz TOD clock, and when NTSC VICII is used, it will use 60Hz TOD clock - none of that affects the image in any way though.

First, please upload the pictures to the forum (attach to your post), dont use external image hosters.

Then, it looks like the C64Reloaded produces a much more saturated Picture than your breadbin, which makes comparing them like this a bit pointless - try to adjust the saturation of the monitor so both pictures are equally saturated, chances are they will look very similar (including those artefacts) then.

> The recognition of the TOD is automatic, I tested it at 50Hz but that does not solve the problem

And i have no idea what this is supposed to mean at all - what does the TOD have to do with this?

done

Jens add to wiki page perhaps?

No, i wouldnt know what kind of adjustments to do at this point, sorry.

fixed in 9o - see Chameleon Core update 9p released

This update implements another idea by a user: using a mountlist, several disk images can be mounted and started at once, for this the swaplist file format known from VICE and sd2iec can be used.

The changes in detail:

As always get the update on the Chameleon wiki page.