Hello, Guest the thread was called13k times and contains 298 replays

last post from Snoopy at the

C65-ROM-MEGA-Debatte

  • Bitte den Regenbogen mit durchgehenden Rastersplits im Rahmen vorstellen

    Wenn das mal nicht auf die Kompatibilität geht. Wenn man es allerdings so umsetzen würde, daß der Rastereffekt deaktiviert wird, sobald man einen Befehl ausführt oder das Bild weiter scrollt, wäre das wohl kein Problem. Andererseits sollte man es schon schlicht halten, denn das ROM hat schließlich nicht unbegrenzt Platz, und da müssen noch viele andere Dinge untergebracht werden.

  • IMHO as soon as someone tries to run some utility cartridges or BASIC extenders, this fancy logo will start causing compatibility problems - like the ones you can observe with JiffyDOS Dolphin mod (try to use this Kernal with IDE64...). Why not to go with something simple?


    Code
    1. **** OPEN SYS ROM BASIC VX ****
    2. 64K RAM SYSTEM 61436 BASIC BYTES FREE
    3. READY.


    Whichever code tries to mess with such startup message will most likely produce at least something sane.


    [edit] Various modifications are possible, for example '64K RAM SYSTEM' -> 'MEGA65 MACHINE', or ' ULTIMATE 64 ', or 'REV 30.02.2019'; some branding could be configurable during compile time

  • IMHO as soon as someone tries to run some utility cartridges or BASIC extenders, this fancy logo will start causing compatibility problems - like the ones you can observe with JiffyDOS Dolphin mod (try to use this Kernal with IDE64...). Why not to go with something simple?


    Code
    1. **** OPEN SYS ROM BASIC VX ****
    2. 64K RAM SYSTEM 61436 BASIC BYTES FREE
    3. READY.

    Whichever code tries to mess with such startup message will most likely produce at least something sane.


    [edit] Various modifications are possible, for example '64K RAM SYSTEM' -> 'MEGA65 MACHINE', or ' ULTIMATE 64 ', or 'REV 30.02.2019'; some branding could be configurable during compile time

    Ja, das ist wahr. Aber jede kann es machen, wie sie es will. Einige werden am Meistens von Kompitabilität, andere werden mehr nach Neuigkeiten. Bei öffentlichem Quelltext kann jeder habe was sie wollen.


    Paul.

  • IMHO as soon as someone tries to run some utility cartridges or BASIC extenders, this fancy logo will start causing compatibility problems - like the ones you can observe with JiffyDOS Dolphin mod

    Das ganze ROM wird neu programmiert und ist nirgendwo zu 100% identisch zum Original. Da ist die Einschaltmeldung wahrscheinlich noch das geringste Kompatibilitäts-Problem. Ähnliches habe ich ja auch schon beim Char-ROM gesagt: wenn eines unter 20.000 Programmes deswegen einen Patch benötigt, dann ist das vollkommen OK – weil gleichzeitig wahrscheinlich wegen ROM-Routinen-Inkompatibilitäten 1.000 von 20.000 Programmen nicht laufen werden.


    Es geht hier in erster Linie darum, Rechte-Probleme aus der Welt zu schaffen und nicht darum, eine 100%-Kompatibilität zu erreichen (das kann nur das Original-ROM). Und wegen der Rechte ist es gar nicht so doof, selbst die Einschaltmeldung möglichst komplett anders aussehen zu lassen.

  • Die Idee mit den Rastersplits im Border und der entsprechende Screen von 8R0TK4$T3N sind natürlich geil! Da es wohl erst mal ohne Raster gehen muss, ist es aktuell Retrofan's Version. Sieht doch schön aus?!

  • The work on the Open ROM continues.

    Paul just posted an update, where one of our community members: FeralChild

    is writing about the work he is doing atm. Thanks Roman ! This is exactly, how we dreamed, this project should go, as a communty project !

    but i will stop jibbering at this point and quote Paul's post over here, enjoy !


    Open C64 ROMs Guest post update

    And today we have another guest post, this time from our very-productive contributor to the C64 Open ROM project that we started, so that we can have copyright-problem free ROMs for inclusion with the MEGA65, and also for emulators and other projects to use for the same purpose. But enough from me ...


    Hi all! My name is Roman, I'm from Poland, and I work on the Open ROMs (https://github.com/mega65/open-roms). For those of you who missed previous posts - it's a MEGA65 side project to create free and open-source ROM set for Commodore 64 and every compatible machine. We will, of course, never reach 100% compatibility - but a reasonable degree should be achievable. My personal goal is to create not just a poor-man replacement - I want a ROM which is simply better!


    Currently both KERNAL and BASIC needs a lot of work, for now I decided to focus on the first one.


    I started my work with improving the IEC (read: floppy) support. That took me quite some time and a lot of debugging with specially modified VICE emulator, showing the details of serial communication. As a result LOAD should work now on real hardware too - not only with VICE KERNAL
    hacks. Although IEC functionality is mostly complete now (SAVE being the big missing, somehow I always find more urgent things to do), it will probably still need quite some work to fix incompatibilities with various utilities.


    But not only LOAD works - we've got a built-in DOS Wedge too!




    BlogPost.png


    Another big task was migration from Ophis to Kick Assembler. I needed conditional compilation, Paul wanted to unify the tool-chain across various MEGA65 sub-projects, so Kick Assembler was a natural choice. Boring job, but had to be done. The most important advantage is, that we can now easily configure builds - enable and disable various features (sometimes mutually exclusive, or potentially incompatible with certain existing software) at will.


    Kick Assembler has some nice features - it can export labels to VICE monitor, same with breakpoints (.break directive). And this is fully utilized by our make system - just type 'make test' (or try other test targets), enter VICE monitor, and see by yourself. I also started adding pseudo-commands for common snippets of code, which might be written in a more efficient way on 65C02 and higher CPUs - again, still a lot to do here.


    I have rewritten our utility to place floating routines in memory (floating = not having predetermined addresses). Previous one used a very simple method: take the biggest hole (block of free ROM memory) and fill it in starting from the biggest routine. A new approach is to start from the smallest hole and try to fill it in as efficiently as possible, using a slightly modified knapsack solving algorithm - it prefers solutions using larger routines. The tool can still be improved, to fill in more than one hole in a single step - for now this is not needed, in practice the current solution leaves no unnecessary gaps.


    One of the problems with improving compatibility is how to identify which unofficial routines we need to provide. We don't have a good solution for this yet, but I've extended the warm start routine - if caused by BRK (for now it's a quite likely outcome of failed attempt to call unofficial routine), it prints the actual BRK address. Try it - launch VICE with Open ROMs and do 'SYS 49152'.


    Yet another large task was to rewrite the keyboard scanning. Till recently a TWW/CTR routine was used (https://codebase64.org/doku.ph…orrect_and_non_kernal_way), adapted to be a part of our Kernal. But although this code is really advanced, way better than the Commodore one, from our point of view it has a very serious disadvantage: compatibility problems. The algorithm used requires more memory than the original, it has to use some bytes that are normally free for use by the application/game. On the C64 we don't have memory allocation as in modern operating systems, everyone uses what he believes is free; game can put the final boss behaviour implementation in a place used by extended keyboard scanning, and we won't even notice it. The new routine isn't as sophisticated as TWW/CTR one - but it still prevents ghost characters from appearing (press A+S+D at the same time on a C64, with original ROMs you'll get letter F written). Additionally, it can decode extended C128 keys - currently released build still has some problems with them, fix is on the way.


    In general, a lot is happening 'under the hood', to achieve better compatibility, sometimes using really dirty hacks. FileBrowser64 is now working (other browsers don't work yet), some game cartridges work too (don't bother with utility cartridges, as of yet most of them just crash).


    Starting from recently, all the released builds are versioned. Release string DEV.191025.FC.1 means that this is a development snapshot done 25.10.2019 by FeralChild (my nick on C64 forums and on the GitHub), and this is the first snapshot released that day. If you create a bug report, please always include both the release string, and the build - for now one of: generic, MEGA65, Ultimate64, testing. Right now all ROM builds can be used on any platform, there is no hard dependency yet - but, for example, MEGA65 build won't even try to read C128 extra keys or initialize SIDs at $D5xx. Please also note, that 'testing' contains features that will hurt compatibility, in case of problems it is always a good idea to retest with 'generic'. BTW, don't mix the builds - it will be detected and you'll see a nice KERNAL panic screen.


    For the near future, I'll definitely focus on KERNAL improvements - rather on compatibility, than on the features. Some official routines are incomplete, several unofficial entry points needs to be provided. Once you get involved with a project like this, there is no way to be bored!

  • Bei mir hat der Collision Befehl nicht funktioniert, sowohl auf dem Nexys Board, als auch mit dem Xemu.

    Sprite Collision funktioniert beim MEGA65 Hardware aber doch. Einige Spiele, die es benutzt funktionieren richtig, z.B., Impossible Mission. Es könnte einfach sein, dass das Problem beim BASIC 10 liegt.


    Der VIC-IV des MEGA65s hat alle VIC-II und VIC-III Registers da und die funktionieren richtig. Der VIC-IV ist fast ohne Ausnahme, eine reine Erweiterung des VIC-III.


    LG

    Paul.

  • Hallo Paul,


    das habe ich mir schon gedacht. Es ist nur der Basic10 Befehl Collision, der nicht funktioniert. Daher möchte ich ja auch wissen, welche Speicherstelle für bei einer Spritekollision gesetzt wird. Ist es dieselbe, wie beim VIC-II ($D01E)?

  • 1. Ist das BASIC 10 in seiner Definition und Beschreibung (Syntax, Semantik) vollständig, sodass man genau weiß, was noch gemacht werden müsste?

    2. Ist im ROM überhaupt noch genug Platz dafür?

    3. Gibt es in BASIC 10 echte Integer-Variablen?

    4. Gibt es einen BASIC-7-Compiler, den man nur noch umschreiben bräuchte?

    1. Ungefähr so. Mindestens haben wir einen Dokument, das alles beschreibt wie wir es erwarten. Siehe hier unter "Documentation": https://mega.scryptos.com/sharefolder/MEGA/MEGA65+filehost

    2. Kein Ahnung :) Es wird uns wirklich freuen, wenn irgendjemand daran arbeitet, einen Patch File für C65 ROM schafft, der einige dieser fehlender Dinge rechtfertigt. Der MEGA65 hat noch 128KB mehr Speicher als C65. Deshalb wenn alles nicht im ROM passt, soll es kein großes Problem sein.

    3. Ich glaube, genauso weit (oder unweit) wie im BASIC 7.

    4. Nicht dass ich kenne. Aber irgendjemandem darf natürlich so einen schaffen. Wäre natürlich Super. Einfach ein BASIC 7 nach 10 Umwandler wäre genug. Noch besser, wenn er auf dem MEGA65 selber laufen könnte und ein BASIC 7 Programme einlesen, umwandeln und wieder aufs Diskette schreiben lassen.

    Hallo Paul,


    das habe ich mir schon gedacht. Es ist nur der Basic10 Befehl Collision, der nicht funktioniert. Daher möchte ich ja auch wissen, welche Speicherstelle für bei einer Spritekollision gesetzt wird. Ist es dieselbe, wie beim VIC-II ($D01E)?

    Ja, so muss es natürlich sein, sonst C64 Spiele könnte nicht richtig funktionieren. Der VIC-IV ist abwärts mit dem VIC-III und VIC-II kompatibel. Dies ist schon teilweiser im "MEGA65 Book" beschrieben. Link oben.

    Der Mega65 macht wirklich echt Spass. Das ein Emulator wie XEmu nicht den Spass bringt, ist eigentlich auch klar. Auf einer richtigen Maschine bringt schon das Programmieren richtig fun. Das Projekt ist noch nicht abgeschlossen, so dass man damit rechnen muss, das noch nicht alles funktioniert. Es wäre aber schön, wenn mehr Leute sich für seine Realisierung einsetzen würden. Es sind nur eine Hand voll Leute, die an dem Projekt hauptsächlich arbeiten und das in ihrer Freizeit machen. Die Ergebnisse lassen sich daher echt sehen.

    Ob das Gerät etwas für einen ist oder nicht, ist wohl Geschmacksache. Ich denke, das es für dieses Gerät einen Markt gibt, z.B. Demoprogrammierer. Jemand, der nur entspannt zocken will, wird wohl eher zu einem normalen C64 greifen oder zum Ultimate64.

    Hier kann ich einfach nur sagen: Je mehr Hände an der Arbeit es gibt, desto schneller die Maschine raus kommt! Wir machen es, groß Teils nur weil es so viel Spaß leistet, an dieser Maschine zu arbeiten. Wir laden euch alle ein, in dem Spaß mitzuteilen :)


    LG

    Paul.

  • If the copyright owner would step forward and would tell us in written form: Go-ahead and use the C65s Basic10 at your will, we would definetly finish it. but as long as we don't have that permission, we just can't...

    Ist überhaupt klar, wer der Rechteinhaber ist?

    Ist das Microsoft oder der Commodore Rechte-Inhaber?

    Tramiel hat doch Bill Gates mit einer Einmalzahlung abgespeist. Gilt das nur für das Basic V2 oder auch die darauffolgenden? Was dagegen spricht ist, dass in den folgenden Varianten Microsoft in der Einschaltmeldung als Rechteinhaber angegeben wird. Damit würde sich doch die Anfrage als sehr einfach erweisen.

  • Does that mean, that the Mega65 is being sold without any Commodore ROM? Or just without any changed ROM?

  • iirc, the current status is, that someone from the team is in communication with cloanto, the current Commodore and Amiga rights owner.

    If we are not able to find an official agreement, we will go with our solution, to sell the MEGA65 with our custom made kernel and our custom made charset.

    As long as we're still in development and testing, we can play around with the official ROM, but once we start selling the MEGA65, it's a different story. (Even if we claim, that we don't make profit and it's a community project...).


    The good thing is, since it is just a file on the SDcard, every MEGA65 owner knows, where he could get the neccessary .bin file and just replaces the custom ROM with the one from the c65 if he wants to.

    (This means, if somebody would be interested to play around with the ROMs, maybe implementing missing BASIC commands, they could start already...)


    our motto is, because of possible copyright issues, absolutely clear: better safe than sorry...

  • This BASIC source code release is most likely illegal, we can't use it in any way - see article on OSNews


    Other possible solution: implement our own BASIC from scratch, with BASIC 10 commands. Mega65 has plenty of extra ROM space, we can use SED+SED+JSR method to call the routines from extended ROM. Our Kernal reimplementation is already quite capable (see status - for now I'm working on extended logical lines in the screen editor, there is quite some work needed to make them right), it's certainly mature enough to start BASIC development. Advantage: such BASIC 10 mode would eventually run a lot of C64 software, there would be no need to switch between BASIC 2 and BASIC 10. But we need more volunteers for the job if we want it to be done within reasonable timeframe...