MEGA 65

Dieser Bereich ist nur in englischer Sprache verfügbar.

It works like…

The MEGA65 is my new hobby. It lets you relive a never happened Commodore chapter. It also is a replacement for a Commodore 64 and other retro computers. This is possible because it uses FPGA technology to cycle exact process instructions of the old platforms to run software a hundred percent compatible. There is no latency which makes FPGA much more accurate than emulators.
  • The project website gives you pictures, videos and lots of further links to begin with:
    www.mega65.org
  • I am checking the discussions about the project in a regular manner. Find me as nobruinfo at:
    discord.gg/5DNvESf
Should you decide to order an own MEGA65 you'll have to consider a waiting list. The project got surprised by delivery shortages multiple times already.

The modern platforms provide plentiful options to bring your games and applications over. You could move SD card media from PC to the MEGA65 and back. Much handier it also allows you to use a serial or the JTAG port to do so. Later the also built-in Ethernet port is planned to be used for transferals. But how about managing diskettes and files if the PC is switched off? Yes you can use BASIC commands to access disk image files on the storage and the MEGA65 has a real diskette drive.

My work…

Then I thought "why not use a two-paned little file management tool like we had in the times of «Norton Commander» ?" This tool was ubiquitous and later also ported to Linux as «Midnight Commander».

That's why I'm currently programming «Midnight Mega», the name now already explained. Currently there's not that much going on but some folks from the MEGA project were not uninterested. The source code is openly available.
  • Please find my project at Github:
    github.com/nobruinfo/midnightmega
Using C compilers/linkers there is one big chicken-and-egg problem. No matter whether you're using KickC or llvm-mos your variables will occupy zero page memory. The bigger your project the fuller it gets. Should you then decide to call ROM functions your project will clash with ROM routines usage of zero page memory.

With KickC there is a documented way to move variables completely out of the way. Not only this will make your code unstable but tend bigger KickC project to become like this anyway. With llvm there is currently no way to move variables out of the way. You may say it's not all variables and you are right. It is what they call «imagenary registers» and those are used to overcome argument passings with only processor registers.

In the end we only receive a more or less stable C code project by not using ROM routines. This is the reason Midnight Mega is currently invoking its own drive access routines (DOS) and therefore facing many issues by the many ways disk drive contents is being handled on the Mega65:
  • Mounted from one of the two possible storage cards the tracks and sectors of a .d81 image file are provided as a simplified track/sector numbering not taking into account where the physical track/sector/head block actually resides. This is making testing without a real Mega65 hardware impossible.
  • The built-in and one optional additional drive are connected across a F011 controller. This provides a somewhat complicated but well documented way for the currently implemented but only on a at emulator level tested working file handling. Unfortunately users reported back this not to be working on the real hardware.
  • Should there later be additional drives connected over the on the Mega65 also available IEC DIN connector this would make for an additional and completely different implementation. Having both interfaces along the limited code space would then fiercely cut on features of this file commander utility.
At the moment «Midnight Mega» is undergoing some new handling routines which hopefully consider logical sectors in pairs when transfered to/from physical sectors.
Editoren werden geladen...