Posts by pwsoft

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

SNR1 wrote:

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.

turrican9 wrote:

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

turrican9 wrote:

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.

espskog wrote:

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.

espskog wrote:

But, would lag on USB vs. PS/2 for keyboard and mouse usage causes gameplay lag which uses the joystickports anyway ? Maybe I misunderstood

Not directly no. However once there is a USB connecter, users will not able to limit themselves to just keyboards. They want to connect trackballs, game-pads, usb joysticks or as discussed hybrid devices like keyboard and mouse combined. Not even considering USB-hubs, mass storage devices, CDroms, diskdrives and random webcams. Yes USB can get complex quite quickly. The FPGA can't do all those extra tasks, so an additional micro is necessary. To support a good subset of devices without getting lag, when it is in a separate micro is an interesting issue.

In comparison PS/2 is a lot simpler. Four wires into the FPGA and a few small hdl entities. Done. No lag, no drivers, no complex software stack. And also important: fully design compatible with first edition of Chameleon (which we will still want to support with updates in parallel with v2).

There is a very important reason why mk2 has full auto-detection (compared with the manual jumper style on the mk1). The 65xx and 85xx chips require a different supply voltage. Allowing quick access to an override in the menu could cause damage to the retro chips very easily by selecting the wrong option. Or user swaps a chip a few months later forgot that the override has been set and another non-replaceable retro chip bites the dust. So no override.

Although the green LED on the board will be flashing it is only a warning, the SID replacements you listed should still work. It will be treated as a 8580 (as this has the lowest voltage requirement of the two).

False warning by windows defender.

The video mode of the workbench shouldn't matter for ECSv2 detection.

My educated guess is the Vampire 500 blocks access to the required configuration registers.

Did a bit of searching and found this wiki page:

http://wiki.apollo-accelerator…u.php/compatible_hardware

I do not own a Vampire and know little about the inner workings. So I'm not sure if the Vampire can be switched to some more compatible or transparent mode. It should allow writes to $DFF1F2 and $DFF1F8 and reads from $DFF1F4. If the Vampire blocks or remaps one or more of these three (reserved) chip registers it causes the problem you describe.

Yes the docking station is compatible with both versions of the Turbo Chameleon.

What does the menu item "Chipset Info" (I) reports when the unrecognized SID is installed? That makes the "why" a little easier to guess. And it will work as 8580 SID is the fallback mode (as it requires the lowest supply voltage).

SwinSID is not recognized, because the detection depends on very specific electrical behavior of the various SID chips. I expect the SwinSID to still work though, as it should not care about the supply voltage it gets.