Posts by igel65

    Ich denke in BASIC sieht die CPU andere Speicherbereiche wie in Assembler (nach dem SYS Aufruf).

    Genauer kann ich dazu nix sagen, denn das Thema Speicherverwaltung ist beim C65/Mega65 ziemlich komplex.


    Du kannst hier mal reinschauen:

    https://github.com/MEGA65/c65-…ster/c65manualupdated.txt


    Das ist das ursprüngliche Pflichtenheft aus der Entwicklungszeit des C65 Ende der 1980er.

    Aber die Speicherverwaltung/Aufteilung ist aktuell noch die gleiche wie die im original C65 Modus.

    Du musst dir ab Kap. 1.5.2 anschauen.

    Das fand ich sehr erhellend, als ich mich damit mal beschäftigt hatte.


    Ich hab mir die Speicherverwaltung bzw. den MAP Befehl der CPU mal genauer angeschaut.

    Aber irgendwann bekommt man Kopfschmerzen, und dann bin ich da ausgestiegen.

    Das ist alles sehr speziell beim C65/Mega65.


    Die Beschreibung des SYS Befehls kannst du dir auch mal anschauen.


    Sorry, weiter kann ich dir nicht helfen.

    Wenn ich im Attic-Ram bei $8000D020 die Rahmenfarbe direkt im ML-Monitor ändere, macht er das zwar.

    Kann es sein, das der ML-Monitor einfach nur abgeschmiert ist.

    Du hast ja eine 32bit Adresse (8 Zeichen) angegeben.

    Und ich weiss jetzt nicht, wie er auf deine Eingabe ($8000.D020) reagiert.

    Evtl. musst du $0800.D020 angeben?

    Wobei, an der Adresse einfach nur ein Byte des ATTIC RAMs liegt?


    Der Adressraum des C65 ist ja 28bit (256MB), also 7 Zeichen (hex), ($000.0000-$FFF.FFFF)

    Die VIC Register (II, III und IV) liegen auch beim C65 irgendwo bei $D000-$D3FF.

    (oder $000.D000-$000.D3FF)

    (siehe Kap. Seite M37-M47 in Gesamtdoku).


    Das ATTIC RAM ist doch nur einfach (langsameres) RAM, das sich bei

    $800.0000-$87F.FFFF befindet.
    (siehe Kap. Seite F6-F8 in Gesamtdoku)


    Vielleicht hat der ML-Monitor beim Abschmieren noch die Rahmenfarbe in $D020 reingeschrieben.

    Das 32k Color RAM des VIC IV liegt bei $FF8.0000-$FF8.7FFF.

    Die 4k davor das Character ROM

    (siehe Seite F6-F8 in Gesamtdoku).


    Ich hab das jetzt nicht weiter ausprobiert, nur kurz ins Handbuch geschaut.


    Vielleicht hilft es.

    Bzgl. ROM herrscht ja jetzt Planungssicherheit für Entwickler.

    Da kommt jetzt sicher irgendwann eine große Softwarelawine, nachdem die Weiterentwicklung des ROM eingestellt wurde. (BitShifter hat sich jetzt ein anderes Projekt gesucht)


    Das wird die Verkäufe des Mega65 sicher stark ankurbeln.

    Snoopy

    Welche sinnlose Randale beim Spectrum Next?

    Der ursprüngliche FPGA wird nicht mehr gebaut.

    Der Nachfolger ist erst 06/2023 lieferbar.

    Das war im Kern deren Aussage im März.

    Oder hab ich da was verpasst?


    Was mich wundert, der FPGA Ersatz (Nachfolgegeneration) wird wohl deutlich teurer als die ursprünglich vorgesehene Version.

    Wie finanzieren die das, denn es geht wohl nicht nur um ein paar Euro oder Dollar pro Stück?

    Die werden wohl kaum 30€ Verlust pro Stück auf die knapp 6000 Geräte der zweiten Kickstarter Kampagne machen können.
    ??

    Da hast du meine volle Zustimmung. Ich sehe das genauso.

    Aber das Team hat grosse Angst das jegliche Aussage als ein Lieferversprechen gewertet wird.

    Meine Meinung ist ja auch, das z.B. eine Aussage wie „Ende September werden die letzten Bauteile erwartet“ in keinster Weise eine Lieferzusage für den ersten Oktober ist.

    Und die Community wüsste wohin die Reise (wahrscheinlich) geht.

    Alle zwei Woche ein paar Sätze in einem Thread wo nur ein oder zwei Personen schreiben dürfen. Dann könnte man immer mal nachschauen, und müsste dazu nicht ganze Foren und Discord absuchen.

    Aber das sieht das Team anders.


    Ich meine von einem Teammitglied gelesen zu haben, das man ein Statement vorbereitet, das man in nächster Zeit geben will.


    igel65

    Hauptsächlich scheint es ja um den Read-Modify-Write Instruction Bug zu gehen. Den sollte man zugunsten der CPU beseitigen.


    Ich finde es nach wie vor absolut schwachsinnig, C64 Programme mit Mega65-Features hochzurüsten, die dann sowieso nur am Mega65 laufen. Und nur darum geht es mir in meiner Argumentation.

    clarkkent

    Speziell dieser ‚Bug‘ wird in der Mega65 CPU so nachgebildet, wie er im 6520 des C64 vorliegt.

    Nachzulesen auf Seite G4-G5 im 1100 seitigen Gesamtwerk.

    Damit ist der GO64 Modus vom Mega65 deutlich kompatibler als der C65.


    Wie dieser Bug genau funktioniert, ist auf Seite G4 gut erklärt.

    Die VIC III und IV Features sind doch standardmaessig ausgeblendet, da sollte es also aus meiner Sicht keine Probleme geben.


    Vielleicht gibt es aber auch in Zukunft ein paar gefixte Versionen von Spielen, so wie "fuer Easyflash-angepasste Versionen", koennte es ja auch "MEGA65-GO64-angepasste Versionen" geben. Vielleicht ist es ja bei einigen Spielen nur eine Kleinigkeit...

    ZeHa

    Nee, die ganzen Neuerungen, also VIC III/IV, sind auch im C64 Modus zugänglich.

    Warum man das gemacht hat, und ob man das braucht, weiss ich nicht.

    Aber das war im C65 schon so vorgesehen.

    Die CPU des C65 wich auch schon vom 6502 ab.

    SIDs in Stereo gehen auch im C64 Modus.


    Der portierte C64 MiSTer Core ist doch eine super Lösung.

    Der GO64 Modus des Mega65 ist für mich auch ok so wie er ist.

    So kann jeder wählen was ihm lieber ist.

    Daher bin ich wirklich an einer möglichst hohen Kompatibiliät des "hauseigenen" C64-Modus interessiert und hoffe, dass er diesbezüglich noch weiterentwickelt wird.

    Das wäre auch in der Hinsicht wünschenswert, weil man mit dem C64-Modus des MEGA65 auch auf die erweiterten Features des MEGA65 (z.B. 40 MHz CPU-Geschwindkeit) zugreifen kann, was mit dem C64-Core natürlich nicht geht, weil der "nur" den C64 kennt. ;)

    Nur das genau diese Unterschiede zum C64 genau die sind, die die Inkompatibilität darstellen.

    Die neue 4510 CPU und die erweiterten Möglichkeiten des VIC III/IV stellen ziemlich exakt die gesamten Inkompatibilitäten zum originalen C64 dar.

    Mehr zusätzliche Features -> mehr Inkompatibilität.

    Die aktuelle Kompatibilität des im Mega65 integrierten C64 (GO64) ist meines Wissens nach kaum noch zu steigern.

    Es gibt zwei wesentliche Unterschiede zur originalen C65.

    1. Die ganzen illegalen Opcodes des 6502 kann der 4510 nicht, bzw. die Opcodes sind jetzt mit funktionierenden neuen Befehlen belegt.

    Die 4510 CPU ist also nicht 100% kompatibel zur originalen 6502 CPU.

    2. Die ganzen zusätzlichen Funktionen/Register im Mega65 (speziell VIC III und VIC IV) sind im C64 Modus sichtbar, und wohl auch nutzbar. Auch das kann zu Problemen führen.

    Wenn z.B. C64 Programme Registerbereiche beschreiben, die im VIC II nicht belegt waren, aber im VIC III/IV neue Funktionen beherbergen, dann kann das merkwürdige Effekte zur Folge haben.


    Diese beiden mir bekannten Unterschiede lassen sich nicht einfach weg optimieren.

    Da macht der portierte MiSTer Core durchaus Sinn, denn die beiden oben gelisteten Unterschiede gibt es schlicht nicht.


    Weiss jemand hier, ob es noch etwas im Mega65-C64 gibt das sich weiter optimieren lässt, so das der C64 Modus kompatibler wird?

    Du vielleicht Snoopy?

    Das würde mich mal interessieren.

    man könnte ja den MiSTer in den Mega65 einbauen 😎

    Das Mega65 Gehäuse soll doch später mal separat verkauft werden.

    Dann noch die Mega65 Tastatur dazu….

    Wobei das Tastaturinterface des Mega65 etwas speziell ist.

    Da gehört auch ein weiteres FPGA dazu, wenn ich mich recht entsinne.

    Korrigiert mich, wenn ich falsch liege.


    Meinen MiSTer hab ich mir vor zwei Jahren zusammengekauft.

    Das Mainboard (DE10 nano) hat damals ca. 135€ gekostet.

    32MB SDRAM dann ca. 20€.

    Damit kann man grundsätzlich schon alles machen.

    Gehäuse, USB Hub, IO-board noch dazu, da war ich bei guten 240€, wenn ich mich recht entsinne.

    Aber heute mit der ganzen Chipkrise liegt man eher bei 350-400€ für ein komplettes MiSTer System.

    Immer noch nur die Hälfte des Mega65 Systems.


    Wobei der Mega65 mit seinem Gehäuse und der Tastatur durchaus seinen Reiz hat.

    Man hat aktuell halt nur einige wenige Cores.

    Bei der Auswahl der Cores liegt die MiSTer Plattform weit vorne, ich würde sagen fast uneinholbar.

    AndiS

    Der MiSTer hat sogar zwei Sorten RAM.

    Einmal die 1GB welches für die beiden 800MHz ARM Cores für das Linuxsystem genutzt wird

    Und dann muss man noch ein SDRAM Modul auf das DE10 nano Board des MiSTer stecken um die ganzen Cores überhaupt nutzen zu können.

    Es gibt ein paar wenige Cores, die ohne dieses SDRAM Modul laufen.

    Das kleinste SDRAM Modul hat 32MB (ja, Megabyte und nicht Gigabyte ;-) ).


    Und die von dir gepostete Liste der für für das MiSTer verfügbaren Cores kann nur ein Auszug sein.

    Ich hätte gesagt es sind vier bis fünf mal so viele.

    Schau mal hier:

    https://github.com/MiSTer-devel/Main_MiSTer/wiki

    Snoopy

    Bitteschön:

    https://misterfpga.org/viewtopic.php?t=5001


    Warum sollte sich der Mega65 Core nicht auf die MiSTer Plattform portieren lassen?

    Ja, der FPGA im Mega65 hat 200k LEs und der FPGA im MiSTer nur 100k LEs.

    Aber solange der Mega65 Core komplett auf den NEXYS FPGA passt, sehe ich da überhaupt kein Problem. Das FPGA des NEXYS Boards hat auch nur 100k LEs.

    Ich weiss, es gibt noch andere Unterschiede zwischen den Intel Cyclone FPGA und den Xilinx FPGA.

    Aber ganz grob lassen sie sich über die LEs vergleichen.


    Ausserdem kann einiges vom Mega65 Core auf der MiSTer Plattform anders bzw. einfacher gelöst werden.

    Soweit ich den Post im MiSTer Forum verstanden habe, und auch nachdem was ich über die MiSTer Plattform kenne.

    Z.B. hat jeder MiSTer min 32MB schnelles SDRAM, denn fast alle MiSTer Cores setzen die 32MB voraus.

    Dann kann einiges auf das Linuxsystem ausgelagert werden (2x 800MHz ARM CPU mit 1GB RAM).

    Als da wären, SD-Kartenanbindung, USB-Keyboard, USB-Joystick/Controller, usw.


    Da auf der MiSTer Plattform Systeme wie die Sony PSX, Amiga 1200, ACORN Archimedes oder auch ein PC mit 486 CPU (90MHz, bis 256MB RAM) nachgebildet werden können, würde ich meinen der Mega65 Core sollte kein Problem sein.


    Der Mega65 hat nur 8MB ATTIC RAM (seriell angebunden), und ca. 1,5MB schnelles internes RAM im FPGA. Es soll möglich sein noch RAM an einen Stecker dazuzustecken.

    BTW, steckt auf dem Stecker jetzt nicht bei einigen die Ersatz RTC?

    Wie schnell lässt es sich denn auf das seriell angebundene ATTIC RAM zugreifen?

    Aber lt. Aussage von Paul soll es für einen Amiga oder Atari ST schnell genug sein.

    Nichtsdestotrotz sollten die parallel angebundenen 32MB SDRAM des MiSTer ein Vorteil sein.


    Aber ich mag mich da täuschen.

    Wir werden sehen wie die Portierung des Mega65 auf die MiSTer Plattform in ein paar Monaten aussieht.

    Ich bin gespannt und lass mich überraschen.


    Wenn man sich mal die ganzen Systeme anschaut, die bisher auf die MiSTer Plattform portiert worden sind. Das finde ich schon mehr als beeindruckend.

    Hier dazu mal eine Übersicht von GitHub:

    https://github.com/MiSTer-devel/Main_MiSTer/wiki

    Wenn man sich die "KeyFeatures" zum Mega65 durchliest, dann gibt es das schöne Statement:


    AMIGA™, ATARI™ ST and other cores being developed or ported, or make your own core


    Ist wirklich was in der Mache? Hat vielleicht jemand was auf "Discord" oder sonstwo gehört?
    Oder geht es nur darum, dass sowas theoretisch möglich wäre, falls jemand reichlich Zeit und Ahnung hätte?

    Ich denke Letzteres.

    Bisher hab ich noch nirgends etwas von einem konkreten Projekt zur Umsetzung eines Amiga oder Atari ST Cores auf den Mega65 gelesen.


    Interessant vielleicht:

    Seit Neuestem gibt es ein Projekt zur Umsetzung des Mega65 auf die MiSTer Plattform.

    Auf der MiSTer Plattform gibt es dann alles was bis Anfang/Mitte der 90er existierte.

    Seit Ende letzten Jahres wird sogar die PS1 portiert.

    ZX Spectrum Next gibts auch, und wie gesagt, alles andere auch.

    KSimcomal

    When you‘re in BASIC mode you can use the area $1600-17FF without thinking to much about memory banks or the complete memory mapping.

    The C65 uses very special technics to handle memory.

    See BASIC command SYS and BANK, etc.

    Screen memory starts at $0800 (2048).

    Maybe many C64 routines work, if you adapt them to this new Mega65 areas.

    C64 cassette buffer -> $16000
    C64 screen -> $0800


    So if you assemble your program to start adress $1600 you can start the programs with BASIC command SYS $1600.


    As far as I know there is no official documentation for the first 8k of RAM for the actual Mega65 ROM.

    Here you‘ll find the first 8k documentet for the old C65 (ROM 911001).

    Wide areas should match the actual Mega65 ROM.

    Except $1800-1FFFF. This area is used by BASIC65 for graphic routines.


    https://65site.de/map.php

    (Click on ‚152 „C65 MEMORY MAP“ PDF‘)


    Have a look here in chapter 1.5

    After reading you may have an idea about how memory is handeld in Mega65 (C65).

    Handling memory is to 90% the same than in the C65.

    https://github.com/MEGA65/c65-…ster/c65manualupdated.txt

    Höchstens CPC Plus wäre cool, aber dafür gibt's nur wenig Software. Zum programmieren würde ich da aber eher den M65 nehmen.

    JamiroDrache

    Da solltest du mal auf archive.org nach ‚TOSEC Amstrad‘ oder ‚TOSSEC Schneider CPC‘ suchen.

    Dann hat sich das mit ‚zu wenig Software‘ erledigt.

    Ich hab mir mal das BASIC (Locomotive Basic?) des CPC/Amstrad angeschaut.

    Das ist wirklich gut und umfangreich. Sehr viel besser als alles was ich damals von CBM kannte.


    Übrigens, damals hab ich keinen CPC besessen. Damals hatte ich kurz mit dem CPC 464 mit Grünmonitor geliebäugelt. Aber irgendwie bin ich erstmal beim C128/C64 gelandet.

    Ich hab mir den CPC Emulator mal auf meinem MiSTer angeschaut.

    Wie gesagt, ich war doch beeindruckt.

    Nach einem Post von BitShifter gestern auf Discord werde ich das Gefühl nicht los, das er ‚den Kaffe auf hat‘.

    Ich denke er ist ganz kurz davor sich ein neues Hobby zu suchen.

    Wenn er das tut, dann habt ihr es geschafft.

    Ihr habt ein finales ROM.


    Ich stelle mir manchmal vor was wäre, wenn wir alle nur das ROM 911001 nutzen könnten.

    Ihr könnt dem Mann auf Knien danken, das er das ROM auf den aktuellen Stand gebracht hat.

    Paul wiederholt das immer wieder, das er völlige Freiheit hat das ROM weiter zu entwickeln und vor allem auch neue Festures einzuführen.

    Vom Team wird ihm da keiner reinreden.

    Daran würde ich mich als Käufer und Interessent des Mega65 einfach gewöhnen und es akzeptieren.


    Warum Gründet nicht jemand eine Interessengemeinschaft ‚Stabiles finales ROM für Mega65‘.

    Das ROM 920371 gilt dann (nach demokratischer Abstimmung) für Clubmitglieder als gesetzt.

    Alle Nichtmitglieder können dann weiter neue ROMs und Cores probieren.

    So wäre doch jedem geholfen.

    Und wenn dann ein Nichtmitglied ein ganz tolles Programm für das 371er ROM findet, dann bekommt er es sicher hin sich ein ‚altes 371er‘ zu installieren um sich da Programm mal anzuschauen.


    Wenn jetzt jemand beschliessen würde, das das ROM 920371 als ‚vorerst final und stable‘ gesetzt wird,

    und viele Entwickler oder sagen wir BASIC Entwickler halten sich daran.

    Was würde ich wohl machen und/oder denken, wenn ein Programm meldet ‚Ich laufe nur mit 920371‘?

    Formulier ich mal anders.

    Was würde ich mit einem Win Programm machen das mir meldet ‚Ich laufe nur unter WIN7‘?

    Denkt mal nach.

    Das ein Entwickler sich nie um neue Firmware/OS-Versionen kümmern musste, hat es nur in den 80ern auf 8Bit Systemen gegeben. Und das nicht mal auf allen.

    Seit CPM/DOS und den richtig guten Computern Atari ST/ Amiga/Macintosh hat es das nie gegeben.



    So, jetzt hab ich tatsächlich alles hier hinzuschreiben, was mir gerade durch den Kopf geht.

    Übrigens, ich will niemanden hier angreifen!