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.
Hoi Paul,
Tobias is on holiday at the moment. I can say the answer is yes, there is still work being done on the Chameleon firmware. Hard to predict a exact release date for the update. but is "soon-ish" a valid date?. Corona has been (and still is) messing with our development planning, projects are shifted around often to deal with delays on shipments etc.
Can't promise a date for 1.0 either, making a perfect emulator is playing the long game.
individual Computers Jens Schönfeld GmbH
Im Zemmer 6
52152 Simmerath
That is great to hear! Have fun with your retro setup and enjoy your weekend!
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!
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.
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.
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?
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.
This really starts to sound like a hardware issue with the Chameleon itself, which version of the TC64 do you have there? Is it a V1 or a V2?
The Amiga 500 was really designed in this way, to be extended by plugging in boards on the left side.
The processor and therefore all the required signals are in that left-front corner on the PCB. Those don't really lend themselves for extension cables as the signals are high-speed (ish) and there are many of them. The only way this maybe work as a product is putting the logic in in the 68000 socket and move the card slots to the floppy, which still require many signals, so a very wide cable, again with possible signal integrity issues.
Ignoring for a moment that it would turn into a completely different kind product to be developed, there probably would not be enough space around the CPU for an important feature: The ACA500plus has a connector for Amiga1200 accelerators and I really doubt you can fit the resulting construct inside without conflicting with "something" people have installed in their machine. Keep in mind the keyboard sits close above the main PCB so there isn't much height to work with in that area of the machine. And I'm not sure how many will be fine with loosing their internal drive to have CF card slots put there...
wow. I had just finished replying to your last post and here you are with a possible fix for Border Blank! Will test it and report back!
Yeah I had the A500 setup still on the development desk, so before I all put it back in the box, I was like.. lets try this fix first.
Ok discussed issue with Jens. Signal was indeed omitted on purpose to make it compatible with more Amiga models. We looked together in design of the Indi ECS v1, and there we found an alternative implementation for border blanking without requiring the sync/blank input of the chip. So I've implemented that method in the v2 firmware now. Let me know if that solves the blanking issues you observed.
I'm aware of the blanking behavior, no easy fix I'm afraid.
The Denise chip only really knows about single lines, which is also true for the emulated one in the Indi ECS v2. The vertical blanking is controlled by the Agnus chip and there is a signal called CSync/Blank, this is not connected on the Indi ECS v2. That either is an oversight or more likely done to make the product compatible with more Amigas, so it can live on a Paula adapter for example. I might have to ask Jens about his reasoning there. That said I did implement an emulation of a part of the Agnus sync logic to get video modes like the SuperPlus mode to work. Those mode kinda creep in into what normally would be sync area (and therefore require the ECS chipset to work). I only implemented the minimum there to get those mode work. And that is the very top part of the screen. So yes the bottom part doesn't have proper blanking behavior at the moment.
A possible fix for the reported overscan issues. Seems the flickering borders and the missing pixels in Arkanoid do have the same underlying cause.
Unpack the archive and transfer the included rbf file to your Amiga. Then use the "Flash firmware File..." under the "Firmware" menu in the IndivisionECSv2 configuration program. I've tried to minimize the impact of these changes. So I hope it doesn't create any regressions in the functionality. Let me know if it solves any of observed over-scan issues.
Sure, when we look into it, we will consider both bugs. I can't tell how difficult it will be to fix at this point in time. It could be that both issues share the same underlying problem and the different visual appearance is just the way the games configure the screen. So fixing one also fixes the other. However it could just as well be two different bugs. You can never tell with these emulation issues, it is often a complex interplay between the chip-set behavior and the game code.
Tried all firmwares from 1.7 and onwards. The first 1 or 2 firmwares have an even bigger border (missing overscan on the right side. Then from there on all of them have a small missing right overscan area.
That is correct. We have implemented a fix for overscan in the past so very old firmwares will show more overscan issues as newer firmwares. Those fixes were for the game "Siedler" if I remember correctly. For some games it is only a few pixels that are missing and don't impact the game play. We do understand that a flashing border is undesirable and so we need to look into that. As the bug is likely located in the Denise emulation part of the product it will impact both RGB and VGA output in the exact same way.
Have you stopped supporting this product?
No, as this product is still produced and sold. It is still under support. We have been testing the games you mentioned last week.
I strongly suspect this is also true for the original expert. Simply copying 8 Kbyte into the cartridge in PRG mode is not enough to get it working. You really need to load from disk. This might have been part of a copy protection scheme. Where you can't simply copy the software by reading out the cartridge RAM. There is a chance it works when using very early versions of the expert software.
How about instead of creating a c128 core, you could just implement a “c128 in C64 mode” core which would mean having vdc available in software like novaterm/striketerm. You wouldn’t create a new machine, but give 64 users the ability to have higher resolution/text.
Even ignoring for a moment the relative large amount of development effort for only a handful of programs (while that time could be spend on fixing bugs in the C64 part of the design instead for example). The current architecture simply isn't capable of displaying 80 column text or the required 640 pixels. The framebuffer logic that eventually creates the VGA display only supports 400-ish pixels in horizontal direction (with 16 colors). I did play with ideas like that the past, but for example SID emulation that wasn't planned originally uses up most of the previously unused FPGA logic now. So each time a new proposal like a VDC (or for example SCPU as a recurring theme) it is always a question what can be removed to make room. Answer probably is nothing. I don't want to remove 1541 emulation or SID emulation or the whatever other feature added with good reason to make room for a VDC that only a handful of programs are going to use. Yes you could make multiple cores each with a sub-sets of features, but that will surely disappoint somebody somewhere as (s)he wants VDC plus whatever feature that was axed.
Ports on pin-headers where customers make their own "solutions" to connect to existing hardware sounds like a support nightmare waiting to happen. I guess for adventures in a complete custom C64 like that, the Turbo Chameleon+docking-station is a possible starting point. Small enough that it can be modded into whatever.
