Posts by pwsoft

PAL or NTSC is determined by the Agnus. Every Denise supports both video standards, which is the same for the ECS V2. An "NTSC Denise" isn't a thing. Can you post a screenshot of the problem so we can have a better idea what you mean?

Yes the changes of the hotfix (which should identify as 20190102 on the OSD) are also included in the 20190313 version.

The 20190313 firmware is indeed better as it fixes a few issues with large overscan pictures.

Is it possible to get a PC next to your C64 setup so you can connect the PC with a USB cable to the Chameleon?

Then you could use the Chaco tool start the hardware test (by default available in slot 1 unless overwritten in the past) and check if the keyboard works there. Chaco also allows updating the firmware through USB. Though I'm not aware of any previous firmware that caused this behavior, so an firmware update is unlikely to fix your issue.

It really would be nice if you could test the C64 without the Chameleon. As the Chameleon is not meant as diagnostic tool.

Could it be the IRQ line that has issues? If there is no IRQ there also will not be any keyboard scanning.

- It should run out of the box. It might not be the latest firmware so eventually you want to flash new firmware.

- No ZIP files are not supported, you need to place unpacked files on the card.

- You can use jiffydos images, but there is also RetroReplay emulation build in that also has a disk speeder.

- Both the C64 and the Chameleon output provide audio at the same time. I would recommend to use the C64 audio output if possible as the SID emulation in Chameleon isn't perfect yet. If you plan on using alternative cores (like the minimig, vic-20 or atari core) then connecting the Chameleon audio output might be useful though.

The 6510 is disabled by pulling low on DMA. It also puts the machine in Ultimax mode by pulling low on the GAME line. This results in disabling most of the internal memory of the C64 and prevents I/O to be mapped out, so it is guaranteed to be available. There is an additional small trick we do to feed the VIC-II with data from the Chameleon. The memory in the C64 isn't used at all, except for the color ram. The contents of kernal and basic ROM can be copied, but are not used during normal operation.

The programmers manual of the Chameleon gives details about the boot rom, startup and the menu system memory layout if you want to know more about that subject.

Yes ACA500 can take care of the kickstart requirements, there is no need to change the ROM in the machine.

The configuration tool can be downloaded from this page:

http://wiki.icomp.de/wiki/Indivision_ECS_V2/doc

Quote from SNR1

I just purchased the ACA500+ and the ACE2 for my Rev 5 A500. It is my understanding that the KickStart ROM 3.1 is included with the ACA500+. Does this mean that I do not need to replace the original ROM on the main board with the new 3.1 I just ordered?

That is correct, the Kickstart ROM version that is inside the Amiga doesn't matter with the ACA500+. You can select 3.1 or for backwards compatibility 1.2 or 1.3 right from the ACA500 startup menu.

Quote from turrican9

BTW, when having no real SID or just a SwinSID nano in the C64 while using TC64 V2 and running Sid Meier's Pirates the game comes up with a couple of Error messages saying something is wrong with the SID. Game still works though. This does not happen when using a real SID in the C64. So what could cause this? Something to do with paddle/mouse support? Does the TC64 V2 SID implementation support these features?

Yes the TC64 can handle that, but only in standalone mode. In cartridge mode it uses the real SID for paddle. It could also be the oscillator 3 read-back often used for random number generator that the game checks. Having no SID chip installed in the machine doesn't bother the TC64 itself and you even get sound over 3.5mm, but could give problems with some games that use specific SID features so keep that in mind.

In cartridge mode it tries to use as much of the original machine as possible (the subset that makes sense that is).

Quote from turrican9

Thanks for the information. The SID "emulation" (I don't consider FPGA to be emulation but re-implementation of the hardware) sounds really good and the sound quality is awesome from the 3.5mm jack.

FPGA and emulation is a Yes, no, maybe thing

The voices/oscillators are definitely the "real deal" you get there, they are digital in the original SID as well. The filter has to be emulated as FPGAs can't do analog stuff unfortunately. But thanks for the compliment! I did my best to make them sound decent.

And nice to read you are happy with the device. In the end that is what matters, having fun with retro gear!

I'm not aware of any games that have stereo support, but yes software needs to support it otherwise you just get a single channel. And whatever address that software uses, needs to correspond with address set in the "SID Emulation" option. There are however a bunch of stereo SID files. The SID player in the menu system can handle these stereo files just fine and should automatically use the correct emulation mode (in most cases).

If you have only one SID in your machine. You can only have emulated stereo and then you need to get the audio from the 3.5 mm jack. In that case SID Real Stereo Chip is set to mono. Then the SID Emulation is controlling what the software sees.

Still any type settings will not affect the SID in the C64 itself.

Selecting the SID type only influences the emulation. If you have a real stereo setup you need to set the correct address in Options,Emulation Settings,SID Real Stereo Chip. By default this is mono and then it will only use only one SID in the machine. Once that is set to the address where your real second SID is located. You can enable stereo with the "SID emulation" setting. The address you set there is what the software will see (and can be different from where the SID actually is).

Configured in this way you will have stereo both from the C64 itself and from the 3.5 mm jack on the Chameleon. The last one is emulated sound. Assuming everything is ok with the setup itself.

If I would have known about all the feature creep that would be happening from here to now I would probably never have started

This is a screenshot from 2007, where I'm debugging the differences between my VIC-II emulation and the real one.

Don't remember the function of all the columns, but one of the major ways to verify the implementation, was to compare the 12 lower addresses of the real VIC chip against the lower 12 addresses of the emulated one. The upper 4 address lines are not available on the cartridge port. Any difference in the addresses points to a fault in the emulation.

There was a moment where the emulation of the two disk-drives were added, which are totally not in the original plan. Like Jens wrote above the plan was just CPU + VIC-II emulation with a frame-buffer for VGA output. This also added a lot of requirements to the menu system, which was till then just a single page of configuration settings

Now with such a large part of the machine emulated, not only CPU, VIC-II and most of the buslogic of course, but also a large part of the CIAs for PS/2 keyboard and drive-emulation (So chameleon doesn't need a IEC cable for drive emulation as it replaces part of the CIAs), it was a relative small step to make standalone mode. As many people liked the small form-factor, the next step was the docking station so you really didn't need a C64 to operate the device. Also not in the original plan, but added later due to feedback from the community. The "How can I connect joysticks in standalone mode?" type of affair almost asked daily in our yahoo group (now discontinued).

Yeah and then it becomes obvious that the only thing missing for a complete C64 replacement is the SID emulation, so I needed to add that as well. Two SIDs of course because we like the extra feature creep, so stereo SID it had to be. Fortunately we already planned for an audio output in the design, but that was originally only meant for drive noises (which never got implemented btw) and alternative cores implementing other machines. I admit emulation it is not yet perfect (emulation of the filter is tricky), but much better as having no sound.

And that is why the FPGA is now 90% full, keeping in mind that the first prototype only had a 16 kLE FPGA, but was increased to 25 kLE due to the "add drive emulation" idea (I think). The first prototype actually had a slot so it could act as a co-processor for the C-One, which got later re-purposed for C128 80 columns mode input, which then got dropped when we discovered the C128 doesn't implement Ultimax mode correctly. It is impossible to access the color registers from the cartridge port and some other issues I don't remember. So we dropped C128 completely as requirement. Half solutions are no solution.

Yes, there is lots of history in this project.

TC64 is a low power device using about 2 watts only, so it won't generate much heat. It is definitely safe to have it on for long periods. Still not ideal thinking "green planet" and such to waste energy though.

No the cartridges work, but require the correct .crt or rom-image to be loaded. It sounds like you configured the slot to a certain type without loading the required rom. Only the retro-replay rom comes standard in the firmware. The others need to be loaded from sdcard.

Quote from espskog

Will you make the motherboard the same as the last version for a direct physical fit in the breadbox? It would be SUPER COOL if the ReloadedMK3 would be just a small board but with a IO connector to break out the userport,cassport,iec,cartridgeport,joyports,etc so that the user can also mount this inside a custom case and then you can sell a standalone connector-board which hooks up to the MK3 board IO connector and the connector-board is just a small PCB-strip with all the connector so that the user can screw that to the existing holes in a breadboard box to get the connectors.

For me -- I want your board -- but I don't want it because it is the same size as the original PCB: hence, I cannot retrofit it into smaller case (e.g. a rebuilt laptop case).

...well, that is just my two cents

That would be a hell of an IO connector! 24 for userport, 20+ for keyboard and joystick, What is the cartridge port again? 42 something. With the remaining IO that is over 100 lines. Then you get the complexity of something like USB or HDMI or other modern stuff that will throw on mk3. Those are picky from a signal integrity point so you can't use a edge connector. It needs to be some proper connector. That is not something you can easily solder yourself for a custom laptop case.

Ofcourse it is something we discussed internally already, mostly due to the cost of a big multilayer breadboard motherboard, but even if we split it up into "brains" and a I/O board I'm not sure you could use the "brains" without the mainboard as it might have things like power supply etc.

You need to swap the VIC-II chip from a 8566 to a 8564 type. So just a jumper change on the CSG8701 is not enough.

Trojan.Generic sounds very ehh generic. My guess is that it triggers some heuristic in the virus scanner.

To be fair the tool is a bit peculiar.

- Compiled with a non-microsoft compiler

- Using various API calls normally only used by device drivers and system components.

- It contains routines to scan the registery for device names

- And about 80% of the executable consists of embedded firmware images that the virusscanner can't understand.

I don't know how suspicious serial communication routines are nowadays, but it might be enough to nudge the tool over the edge. And the virusscanner goes: No not on my watch!

The public fpga_examples repository has been updated with the latest Chameleon v2 support files.

The repository can be found here https://github.com/pwsoft/fpga_examples

And as Tobias already mentioned the corresponding documentation, "the core developers manual" (chameleon_coredev) is currently being updated and should become available in a couple of days.