Posts by pwsoft

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.
Don't Panic. Please wash hands.

    btw. is there any changes or the speed of changing gfx mode LACE/PAL

    for example some games like Alien Breed, Agony and many demos have some graphics displayed in Lace and the rest in PAL in MK2cr is a slight delay when switching from one to another.

    Could you write something more about it?

    With the AGA mk3 (like it is in ECS v2) you will be able to share a single mode for both PAL interlace and normal PAL by setting the "double line" option. By default it will double the number of lines on the screen to keep the aspect ratio, but on interlace this line doubling is automatically turned off. So your monitor doesn't have to switch to a different screen resolution and it should be almost instant (like 3 half frames or so). I don't remember exactly what the MK2cr does with interlace, probably load a different image from flash or something, which will take a while yes.


    by the way, not once talking to friends we wondered why Graffiti was in IndiECS and it was not in MK2cr.

    Don't know. I didn't work at icomp at that time, so wasn't involved with creating the specifications for that product. I guess it was on a similar "nice to have list", but never made it into the product. Note: Although I did implement part of the firmware for the AGA mk2, it was in the role as an external consultant.

    The reason we don't tell the every feature that is on our todo or planned feature lists, is because there could be technical or planning reasons these features are left out at the last moment, or are delivered in a later firmware update once they are properly debugged. Better to only communicate what we know for sure will work, to prevent any disappointment for our customers.


    Now for Graffiti, it didn't make it to the "for sure" list for some reason, I just thought it did. As aga mk3 is based in large part on the ECS v2 design and that already has Graffiti emulation, so that code was already existing only color depth has been extended from 12 to 18 bits. I already did all that work so that is why I communicated it will be in, not realizing Jens didn't have that confirmed yet. Not sure why though will ask him when he is back from holiday. With all the crazyness in the world at the moment some communication errors are bound to happen. Sorry to see some of that leaked out into this forum.


    Best advice I can give you for your pre-order is read the shop description, that is the product you get for sure.

    Now Jens wrote

    "It's currently on the "nice to have"-list, but not on the "promised to be in"-list"


    It is a BIG diffrence maybe its time for full spec of MK3

    Ok yes, it would be "nice to have" a purpose for the file named indi_aga_mk3_graffiti.vhd that exists in my firmware development directory. That poor little file, not (yet) promised to exist. Ready to spring into 18-bit action when it is promoted to the other list. I'm sure that will happen once we have the mandatory features stable. Until then just assume I didn't say anything... promised nothing... I was just confused about the Question, yes that is it! I thought you meant a totally other feature with a different name that is on the promised list... yes.. well good that we talked that through, almost slipped a non-existing feature right here in the forum.... whew..

    In my A1200 i have a KA 47 Angle IDE 44 PIN with SD Adapter. Will this be in the way for the Indi MK3?

    If it looks similar to this picture. Then the answer is no, it is not in the way and you can mount an indi AGA MK3 (or mk2 as is the case in the pic) in the machine at the same time.



    Nice! Will Graffiti work with HighGFX driver? I mean, will it be possible to use 720p resolution with Graffiti color support?

    I don't know. Depends on the how the application(s) that uses the Graffiti mode will set up the screen. If the application supports 720p I see no reason why it wouldn't work.

    I haven't fully analyzed the complete change-log yet (will do that when we prepare the actual release), but what I can see in a quick glance in the list, is a fix for ANE/LAX illegal opcodes, REU timing fixes, some minor cartridge emulation fixes, a bunch of VIC-II fixes related to dma-delay. And the major change will be the new SID emulation code that has been developed that should offer better combined waveforms and emulates various quirks of the envelope generators correctly.

    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.

    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!


    chameleon_v5_iec_issue_analysis.zip

    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.

    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...

    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.


    indi_ecs_v2_20200327.zip

    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.