Posts by pwsoft

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.