(Leave this as-is, it’s a trap!)

To delete this post you must be either the original author or a designated moderator.
The content of the post will be removed but the name and date will remain.

  • The post will be removed completely from the thread, rather than blanked
  • Only posts on the last page of the thread can be removed completely (so as to not break permalinks)

RE[32]: Another c64-ish motherboard in development.

Daniël Mantione

IMO, I prefer to judge things by how ugly it is to maintain compatibility: If you need all kind of unelegant hacks or lots of "switch on advanced functionality" switches, it is better to sacrifice some compatibility. After all, one of the goals of the Mega65 is also to show people how simple and understandable 8-bit computers were, you impair this if the hardware has lots of ugly mode switches that the programmers needs to care about.

Of course it also needs to be weighted against how much software benefits from a certain compatibility feature, if you need one little hack to achieve compatibility with a huge amount of software, it is probably worth doing it.

As the development team has a limited amount of resources, I think it is most worth to spend time on a finished product without significant gaps in the main functionality. I.e. it is absolutely no problem if the Mega65 doesn't support FLI at launch, but adds that later. However, if the VIC-III features would only be partially implemented, the Mega65 would fail one of its primary goals: Showing the world what the Commodore 65 would have been. IMO the Commodore 65 functionality doesn't need to be 100% perfect, but does need to be complete at launch.

Speaking about FLI, a different approach could be to make the VIC IV support a FLI like graphics mode in hardware (compatible framebuffer/colour RAM layout), so that you no longer need complex and timing sensitive raster interrupts to implement it. That way, you facilitate modification of software for the Mega65, so that programmers can simply remove the raster interrupt code that implements FLI, and don't need to rewrite the entire program to a native graphics mode. Once the timing sensitive code has been removed, programmers can then safely enable the 50Hz CPU mode in order to unleash the compute power of the Mega65.

IMO, should there be a desire for 100% Commodore 64 compatibility, a viable approach would be to create an alternative FPGA core for it. People could then reboot the Mega65 into a C64-only core, absolutely no additional functionality, that does attempt 100% compatibility.

Your friendly neighbourhood moderators: Deft, gardners, Ralph Egas