Posts by Tobias

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.

http://wiki.icomp.de/wiki/Indi…vision_AGA_MK3_components

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

That seems to be the case - see here: https://www.breadbox64.com/mec…64-assembly-instructions/ somewhere at 3/4 down the page

Hu? Isnt it a 1:1 replica of the original keyboard? That should work just fine! How is it "not recognized"?

The only problem i see there is that the auto detection of the VICII will not work correctly, which may or may not cause problems.

I don't know of any customers that have a "Kawari" though, so can't tell. Generally we can only guarantee (and recommend) original MOS ICs to work for that matter (but that doesn't mean others will not work - we just have no way to test all those replacements)

Quote

Do analog signals even have pixels? Aren’t there just lines that are drawn?

Technically.... a "pixel" does not equal a "dot" In the analog world, there exists a certain speed at which the beam moves from left to right and "draws" the screen. Now the chipset changes the color at a certain frequency, which produces the "pixels" (and the maximum frequency the chipset is capable of is what defines the horizontal resolution). Ideally this results in fragments that are as wide as high (ie square pixels), but in the real world this is often not the case (eg a bunch of "classic" PC resolutions for example are stretched or skewed in one way or another).

So yes, in the analog world "pixels" are basically "line fragments". However, when the signal is sampled and converted into digital (like Indivision does - and which is also what a modern monitor does with analog signals), each of those "line fragments" will (ideally) result in a single square dot, and the monitor will display a single dot per such fragment (if the resolutions match, else more scaling comes into play). And this is the reason for why some resolutions can not fill the entire screen on a modern monitor (without further scaling).