MCL64 - MOS 6510 Emulator for the Commodore 64

[MicroCoreLabs]

I ported my 6502 emulator to the 6510 footprint which seems to work in the Commodore 64. I will post the source on GitHub shortly.

https://microcorelabs.wordpress.com/202 ... modore-64/

[BigDumbDinosaur]

MicroCoreLabs wrote:

I ported my 6502 emulator to the 6510 footprint which seems to work in the Commodore 64. I will post the source on GitHub shortly.

https://microcorelabs.wordpress.com/202 ... modore-64/

Is this a piece of hardware?

[MicroCoreLabs]

It's a 6502 emulation running on a Teensy 4.1 which is an Arduino-like micro controller board which runs at 600Mhz. A small PCB was made to route and buffer the signals to the 6510 pinout so it can be used as a drop-in replacement inside of a Commodore 64.

[BigEd]

Nice work!

[rpiguy2]

MicroCoreLabs wrote:

I ported my 6502 emulator to the 6510 footprint which seems to work in the Commodore 64. I will post the source on GitHub shortly.

https://microcorelabs.wordpress.com/202 ... modore-64/

Fantastic! Will be interesting to see if some commercial games work that use the mapped memory regions (over BASIC, etc.) or GEOS.

[MicroCoreLabs]

One amusing note is that, when run in accelerated mode, the MCL64 appears to be around 2X faster than the Super CPU Commodore 64 accelerator board!

https://microcorelabs.wordpress.com/202 ... modore-64/

[MicroCoreLabs]

I posted an update to the MCL64 project: https://microcorelabs.wordpress.com/202 ... 64-update/

It appears that a number of Commodore 64 games rely on a few of the unstable undocumented opcodes, so I updated the code to support them.

[rpiguy2]

MicroCoreLabs wrote:

I posted an update to the MCL64 project: https://microcorelabs.wordpress.com/202 ... 64-update/

It appears that a number of Commodore 64 games rely on a few of the unstable undocumented opcodes, so I updated the code to support them.

This is very impressive. Hopefully in 2022 I will have time to build one.

[rpiguy2]

Any thought of adding REU functionality to the accelerator?

You could probably add 256K-512K using the onboard memory of the Teensy.

The recent port of Sonic to the C64 requires an REU and this has put them into sudden demand.

There is currently an FPGA project for it (which has its own thread elsewhere here), but why not do it in software with the Teensy?

https://garrettsworkshop.github.io/GW43 ... index.html

[MicroCoreLabs]

I don't see why not. Cartridge ROMs and RAM blocks have already be emulated using the Teensy's large memory, so adding a paging system for a large memory expansion would probably be easy.

[65f02]

MicroCoreLabs wrote:

I posted an update to the MCL64 project: https://microcorelabs.wordpress.com/202 ... 64-update/
It appears that a number of Commodore 64 games rely on a few of the unstable undocumented opcodes, so I updated the code to support them.

Hmm -- I thought the C64 also allows the video memory (screen buffer) to be mapped anywhere in the address space. And I recall reading that game programs commonly use this to alternate between two screen buffers to obtain a flicker-free animated display: Prepare the next screen content in a second buffer while the first one is displayed; then switch video buffers when the content is ready.

If video RAM can be "anywhere", and that's determined by the individual program at runtime -- how do you use internal RAM in the Teensy to accelerate the C64? If you cannot know in advance whether a certain RAM area will end up being mapped to video RAM later, you can't make it internal to the Teensy, right?

Do the memory maps need to be manually adjusted depending on the program one wants to run and accelerate? That should work, but would be a bit cumbersome. Do you have a better solution, or am I making things more complex than they are? Thanks!

[MicroCoreLabs]

Quote:

Hmm -- I thought the C64 also allows the video memory (screen buffer) to be mapped anywhere in the address space.

I'm sure you are correct.

Quote:

If video RAM can be "anywhere", and that's determined by the individual program at runtime -- how do you use internal RAM in the Teensy to accelerate the C64? If you cannot know in advance whether a certain RAM area will end up being mapped to video RAM later, you can't make it internal to the Teensy, right?

True, there is no way that the video RAM can reside in the Teensy because the motherboard cannot access it

Quote:

Do the memory maps need to be manually adjusted depending on the program one wants to run and accelerate? That should work, but would be a bit cumbersome. Do you have a better solution, or am I making things more complex than they are? Thanks!

It can be as complex as one wants to make it I suppose, but probably not worth the investment of time.

[BigEd]

In the Beeb816 we need it to be able to cope with a variety of memory maps including the video memory being movable. Some games and demos will even change the video memory mapping mid-frame. So what we do is monitor writes to the devices which look after video, and adjust our internal mapping in synchrony with the host machine mapping. It's difficult to get right, and it might be that not every physical possibility can be accommodated, but we got pretty close. (For example, IIRC, it's possible to point the video system at page 0 and 1, but if those areas are modelled with write-back it slows things down too much. So we have a low water mark for how much of host memory we will write-back.)

Quite true though, from the point of view of designing, implementing, and testing the in-socket system, there are diminishing returns and it can be a lot of work, and one has to stop somewhere.

[ciccior2003]

rpiguy2 wrote:

Any thought of adding REU functionality to the accelerator?

You could probably add 256K-512K using the onboard memory of the Teensy.

The recent port of Sonic to the C64 requires an REU and this has put them into sudden demand.

There is currently an FPGA project for it (which has its own thread elsewhere here), but why not do it in software with the Teensy?

https://garrettsworkshop.github.io/GW43 ... index.html

I think emulating the REU is not difficult.
Teensy has to store the registers from $ df00 and $ df0a in the cache and loop from paging system when the $ df01 command is executed.
it is possible to have a 16mb REU by adding extra ram .
extra ram -> https://www.hackster.io/news/adding-mor ... e527855502

[Greg816v2]

65f02 wrote:

MicroCoreLabs wrote:

I posted an update to the MCL64 project: https://microcorelabs.wordpress.com/202 ... 64-update/
It appears that a number of Commodore 64 games rely on a few of the unstable undocumented opcodes, so I updated the code to support them.

Hmm -- I thought the C64 also allows the video memory (screen buffer) to be mapped anywhere in the address space. And I recall reading that game programs commonly use this to alternate between two screen buffers to obtain a flicker-free animated display: Prepare the next screen content in a second buffer while the first one is displayed; then switch video buffers when the content is ready.

If video RAM can be "anywhere", and that's determined by the individual program at runtime -- how do you use internal RAM in the Teensy to accelerate the C64? If you cannot know in advance whether a certain RAM area will end up being mapped to video RAM later, you can't make it internal to the Teensy, right?

Do the memory maps need to be manually adjusted depending on the program one wants to run and accelerate? That should work, but would be a bit cumbersome. Do you have a better solution, or am I making things more complex than they are? Thanks!

Typically on an accelerator all writes will be copied to the main system bus, so it would end up in main RAM as well.