MEGA65 FORUM

Another c64-ish motherboard in development.

append delete Solei

Seems like Gideon - the maker of the 1541 ultimate cartridges is quite far in the process of making an all new enhanced replacement c64 motherboard:

http://1541ultimate.net/content/index.php?option=com_content&view=article&id=74&catid=9

And to stir things up a little - the ultimate64 even got a socket for a real sid chip, something that the Mega65 should also have onboard as originally planned (IMHO).

Reply RSS

Replies

append delete #26. Daniël Mantione

Exactly, and that is a good thing.

append delete #27. gpz

perhaps, but its the opposite of being compatible to anything. expanding things and staying compatible are mutually exclusive.

#28. Daniël Mantione

This post was deleted by its owner

append delete #29. Daniël Mantione

There will be C64 software that runs on the Mega65 and there will be software that won't run. In general software that stays to the documented side, including more advanced stuff like implementing a split screen via a rasterinterrupt should work. Hacks like FLi, DMA delay and so on probably won't work and neither will code using illegal opcodes or that depends on cycle exact timing work.

As I do have a real C64, and I expect most Mega65 owners will have a real C64, that 100% compatibility is not achieved is not the end of the world. In fact I even think it is good thing at this puts some pressure on Mega65 owners to make software Mega65 compatible. While fixing the software, one might add a few small things that take advantage of the more advanced hardware.

So yes, incompatibility sucks, but minor incompatibilities are probably also just what is needed to kickstart software development for the Mega65.

append delete #30. PGSmobile

We are still planning to support illegal opcodes and at least the common timing related tricks. FLI and DMA delay are both on the list of things we are aiming for. Whether we achieve them, that's a different question.

append delete #31. LoveMega65

I agree with Daniël Mantione. I have Commdore 64c with real disk drive 1541-II so yes...I don't care at all for backward compatibility that much for mega65. If it can achieve 50% of software and even then it may seem little fast due to faster CPU speed I am 100% fine with that. I am getting mega65 for future mega65 software and games honestly not for backward compatibility.

So the author of mega65 please, please don't put focus on compatibility that much and waste development time on that. Focus on mega65 basic v10 and it's hardware...I have a c64 here, I have vice if I need it..don't worry we have what we need for c64 software library.

append delete #32. 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.

append delete #33. LoveMega65

There are already too may C64 and C64 compatibility and clone hardware as it is. FPGA Arcade, the new FPGA C64 released by ultimate II team, Chamelo 64 or whatever it is called, C128/C128D and the actual C64 variations, let us not forget vice and frodo and so on. So you have many choices to get c64 working. I would honestly don't mind if mega65 is mega65 only and not backward compatible.

append delete #34. Daniël Mantione

It is important that Mega65 have some software library to start with. If every program needs to be written from scratch, like file copiers, text editors, sprite editors, 6502 assemblers and whatever, it will probably be too much for C65 owners to develop on their own. Therefore some compatibility with the C64 is important, and, as there will be a C64 mode, I'm confident the Mega65 will have a large software library to start with, giving Mega65 owners a base to build on. I think the Mega65 team is doing exactly the right thing by the way. My confidence that the Mega65 will be a success is growing.

append delete #35. PGSmobile

Thanks for the vote of confidence :) we do try to balance these things. For c64 compatibility, if space allows it we will be adding a vic-ii as well as vic-iv to the main core which will be activated together with 6502 mode of CPU for compatibility - hopefully automatically.

append delete #36. Betzelel

I had a question, I remember back to the days when I had a c64, and I remember that some of the old programs that you bought at a store on floppy disk has protection scenes where it would read a serial number from the floppy disk that Prohibits copying to another floppy, or tape back... how would we be able to use some of those old programs now that the floppy no longer exist?

append delete #37. gardners

Well, the MEGA65 will let you use a 1541 disk drive with it, as it will have a real disk drive port for exactly that purpose.

More generally is possible to make perfect images of disks with the right hardware. In theory, the FPGA floppy controller on the MEGA65 should be able to connect a 5.25" PC floppy drive and use that to image disks at a very low level. However, some copy protection is super crafty, and requires precise track-to-track timing relationships, that may still be difficult to reproduce, especially if the floppy drive lacks an index hole sensor.

append delete #38. Daniël Mantione

Well, coming back the original topic, for those situations, Gideon's Ultimate64 will simply be the right product: His 1541 simulation is near perfect and gives 100% compatibility, even with copy protected games.

With nibbler copiers like Maverick you can transfer games from a real floppy to a simulated floppy drive on Gideons 1541 Ultimate. I haven't yet encountered a single copy protected game that would not work after such a transfer.

It would cool if the Mega65 could be compatible with the 1541 Ultimate, but it is a cartridge that does a lot of low-level tricks, so it won't be easy to provide such compatibility.

P.S. For me floppies do exist, I use them very regularily in my C64 usage.

Reply

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

There is no need to “register”, just enter the same name + password of your choice every time.

Pro tip: Use markup to add links, quotes and more.

Your friendly neighbourhood moderators: Deft, gardners, MARCOM