Posts by RexRetro

    E.) Die armen Mädels mussten fast alle ihre Kleider verkaufen, um sich zusammen einen Mega65 leisten zu können


    F.) Was haben die getan, damit sie den Mega65 schon 2014 (!) bekommen haben ???


    G.) Sind das die sogenannten "Spielerfrauen" vom 1.FC Mega Team ?

    vicjack

    Da gibts ja tatsächlich in jedem Handbuch vor dem Stichwortverzeichnis ein paar Seiten mit den ‚Supporters‘.

    Hab ich garnicht gewusst.

    Hui, und mit ein paar € Spende bin ich nun unsterblich verewigt...8\|


    BTW: für wen ein C65 viel zu modern ist, der kann ja auf den Sol-20 Nachbau warten:

    https://hackaday.io/project/181676-sol-20-reproduction


    OK, allzu leicht zu durchschauendes Ablenkungsmanöver meinerseits... :schande:

    adtbm

    Wenn ihr auch jetzt noch nicht ganz genau wisst wann es losgeht, könnt ihr den eine Aussage wie ‚nicht vor dem 22.09‘ machen.

    Dann müssten nicht alle hier in diesem Thread rumhängen.

    Es sind aktuell den ganzen Tag über sehr viele in diesem Thread, fast wie in einem Wartezimmer.

    Das hier ist doch nur Ablenkung für die Uneingeweihten. Die echte Warteschlange ist ganz wo anders. MR2 vom a1k Forum hat es schon aufgedeckt:



    ;-)

    Eigentlich gar nicht so blöd: Für 1000 EUR ein DevKit gekauft, konnte schon paar Monate damit rumspielen. Jetzt kurz vorm Release für 1500 EUR verkaufen und damit dann für ca. 700 EUR einen MEGA65 kaufen. Das hat dann alles in der Summe für ihn gerade mal 200 EUR gekostet.


    Jetzt braucht er nur noch einen, der die 1500 EUR auf den Tisch legt. :D

    Vorher noch mit Goldfarbe ansprühen. Dann geht es sicher für 3000€ weg ... ;-P

    Du kannst unser Alps Laufwerk nicht mit dem Laufwerk des Amiga vergleichen. (oder besser unseren FDC) egal ob MFM, GCR oder RLL wir können alles :-D

    So wie der MEGA65 das Standard Alps PC Laufwerk anspricht, kannst du dies eher mit einer Lösung wie Kryoflux oder Greaseweazle vergleichen.

    Wir sind in der Lage, jedes x-beliebige 3.5" Laufwerk darzustellen und wenn wir wollen könnten wir jede x-beliebige 3.5" Diskette von jedem System lesen, schreiben und formatieren.

    Von daher ist es überhaupt kein Problem unser Laufwerk in einem Amiga core als vollwertiges Amiga Laufwerk einzubinden.

    Absolutes Killer-Feature! Ich komme mehr und mehr zur Überzeugung, dass ich einen Mega65 brauche. Schon allein, um möglicherweise einige Disketten zu retten.

    Vielleicht wäre es besser gewesen, Commodore hätte den Amiga nie gekauft, dann wäre der C65 offiziell rausgekommen und wäre so etwas wie der Apple IIGS geworden.

    Ohne den Erfolg des A500 (ab 1988) wäre Commodore sicher noch schneller am Ende gewesen. Andersrum kann man argumentieren, C= hätte nicht 1990-91 Ingenieure beim Amiga dafür abziehen sollen, um den C65 Prototyp fertig zu bekommen, sondern die AGA Amigas schneller bringen müssen. Oder bessere PC-Clones :-(

    Schon klar, es ist auch immer leichter im Nachhinein jemandem die Schuld zuzuschieben, das ist klar. Es ist halt einfach doof gelaufen bzgl. der OpCodes, aber ich verstehe auch dass die neuen OpCodes auch einen Nutzen haben. Man sieht ja nun dass das MEGA65-Team letztendlich vor den gleichen Schwierigkeiten stand und ebenfalls eine Entscheidung treffen musste, die die C64-Kompatibilitaet einschraenkt.

    Und das Mega Team hat einfachen Zugriff auf ausgereifte, 100% kompatible 6510 Softcores. Auch C=/MOS konnte nicht mal 1990 noch schnell einen 4510 R6 designen und fertigen, der zwischen 6510 und 65C02 Modus schaltbar ist.

    Freddy das ist schon "richtig", aber spaetestens Ende der 80er haette man ja bei Commodore auch wissen sollen, was Demo- und Spiele-Coder so mit der Maschine anstellen, und dass die illegalen Opcodes vielleicht doch nicht ganz unwichtig sind. Natuerlich kann man sich auf die Specs berufen und sagen, tja Pech gehabt.

    Die Entwicklung lief halt anders:

    1. jemand will einen CMOS 65xx
    2. jemand (Bill Gardei) entwirft einen WDC 65C02 Clone
    3. keiner bei C= braucht diesen
    4. Gardei spielt mit der neuen CPU, macht einen VIC-III und will einen C64++
    5. Commodore macht alles mögliche (C128, SX-64, C64DX, Amigas, PCs, 1.FCB Trikots, 64er golden ansprühen)
    6. C= Management will (teilweise) eine low-end 8-Bit Gaming Kiste um NES/SEGA zu kontern
    7. Gardei's "pet project" wird der C65
    8. diverse Leute haben Bedenken bzgl. Zielgruppe, C64-Kompatibilität, Fertigungskapazitäten
    9. C65 Projekt wird nach vielen Prototypen begraben

    Keine Ahnung, wie viele solcher "Leichen" Apple, IBM oder Atari im Keller hatten, und ob das Management dort viel planvoller war, aber bei C= schien das Verzetteln und last-minute Scheitern schon extrem.

    Dass ausgerechnet die C64-Kompatibilitaet leiden musste, weil sie die illegalen Opcodes auf der CPU entfernt hatten, war ein richtig dummer Move von Commodore.

    Das klingt ja gerade, als würdest Du dem Commodore Management unterstellen, bzgl. der illegalen 6510 Opcodes irgendwelche Pläne gehabt zu haben. Also als hätte da irgendwer irgendwas bewußt entschieden. Aber nach allem was in Bagnalls "Commodore - the final years" zu lesen ist, war es eher wieder unbewußte Inkompetenz auf Seiten des Managements.

    Irgendwann 1984 sagte man wohl der Semiconductor Group: "Macht mal einen CMOS 6502, der von WDC ist uns zu teuer." und setzte dann einen neuen, jungen Chip Designer darauf an. Und dem waren die illegal Opcodes und die 6510/C64 Kompatibilität erstmal wurscht, bzw.der WDC 65C02 hat statt derer ja auch schon neue, sinnvollere Instruktionen und Adressierungsmodi.

    - Yes we know, that alot of modern high end C64 demos won't work in the MEGA65s C64 mode due to this reason, but: ...
    ...at the moment there is work ongoing in the background to port the excellent C64 core of the MiSTer over to the MEGA65, especially adapted to the MEGA65

    like Cartridge support and support for the 3.5" drive.
    We believe this approach makes the most sense, so if somebody needs a 99% exact C64 with illegal Opcodes, he will be able in the future to boot into the C64 core

    and he'll have his 99% compatible C64 (with dual SID support (or maybe Quad SID support) in an excellent case, with an UBER excellent keyboard.

    Also we think for the future it makes more sense to be able to work on the different cores seperately.

    Perfect. This sounds great and IMHO like the way it should be done: let the MEGA65 core be a real re-implementation of the C65 with it's limitations in C64 mode and provide a more compatible C64 mode as a separate core.


    This approach is going in line of what we think how the MEGA65 should be used:

    - a MEGA65 core with a partially restricted C64 mode but alot new features (in both modes) to explore.

    - lots of other 8 bit cores that will feel natural on the MEGA65 like VIC20, C64, C128, Amiga, Spectrum, Schneider, etc...

    Ouch. My beloved Amiga is no 8 bit system but 16/32- to 32 Bit ;-)

    C128 sounds ambitious. AFAIK there is no C128 FPGA core anywhere. Not sure if Z80 CPM is needed (there are alternatives) but C128 mode alone would be great.

    (was natürlich eher emotional als real ein Vorteil ist)

    Zumindest fuer die Commodore 8-Bitter waere es ein Vorteil, denn man hat die korrekte Tastaturbelegung inkl. PETSCII-Symbolen :)

    Fuer Fremd-Rechner entfaellt dieser Vorteil natuerlich.

    In der 8-Bit C= Welt ist man mit C64/C65 beim Mega65 schon gut bedient. Keine Ahnung, ob es da Leute geben wird, die noch PET/CBMxxxx/VC-20/C16/Plus4 Cores haben wollen.

    Hatten die eigentlich alle genau das gleiche Tastatur-Layout (bzgl. PETSCII) ?

    Mit nur 8,3 MB wird es halt kein high-end Amiga, zumal 512K schon für's ROM abgehen. Für OCS/AGA Spiele wird es natürlich locker reichen.

    Andererseits: die üblichen Verdächtigen (a1k) werden sowieso weiterhin ihre 68060er-Amigas pimpen oder eine :fleder:kaufen.

    (In der Hoffnung, irgendwann auf dem "produktiv"-Amiga eine moderne Webseite - also 5 Megatonnen Javascript-Framework-Gefrickel - wenigstens in Ultra-Zeitlupe rendern zu können. :schande: )

    Ich sehe es auch so: wer heute einen Mega65 bestellt, sollte dies in erster Linie für die Features tun, die es schon gibt. Das Haupt-Feature ist nunmal ein fertiger C65-Clone mit Extras.

    Trotzdem kann ich den Wunsch nach alternativen Cores für möglichst viele Systeme nachvollziehen. Das Ding wird recht teuer, da will man den Nutzen maximieren.

    Wenn es viele Mist(er)/SiDi Cores auf dem Mega65 geben wird (oder würde), dann stellt das einen Mehrwert von 100-250 € dar.


    Und es hätte gegenüber diesen allround FPGA-Retro-Systemen den Vorteil, ein Tastaturcomputer im klassischen Design zu sein (was natürlich eher emotional als real ein Vorteil ist).

    Mist/SiDi sind mehr oder minder kleine Metall-Kistchen. Die machen nix her; die wecken null Emotion. Dazu dann eine normale PC-Tastatur und Maus. Gähn.

    Der Mister ist ein modulares DIY-Gefrickel pur oder verpackt im Irgendwas. Von ästhetisch fragwürdigen, 3D-gedruckten Gehäusen bis Plexiglas-Gebastel. Auch das mag höchstens "Maker" begeistern.


    Wenn der/die FPGA(s) im Mega65 es hergeben, alle möglichen 8- und 16-Bit Retro-Systeme zu implementieren (bzw. von Mist(er) zu portieren), dann wird es früher oder später wohl auch passieren.

    Sofern der Mega65 bei seinen Preis eine ausreichende Verbreitung findet, ist das IMHO nur eine Frage der Zeit.

    clarkkent Man kann einen MiSTer core nicht einfach in den FPGA des Mega65 laden.


    Der Cyclone V hat kein Linux. Er muss dann vieles mit dem FPGA machen, was im MiSTer über das Linux gemacht wird.

    Sicher ein Verschreiber: Du meinst der Artix A7 im MEGA65 hat kein Linux.


    Ansonsten ist die Lösung des Problems von clarkkent doch einfach: einfach Mister und Mega65 kaufen. Mister ins Arcade-Kabinett und den Mega65 mit seinem stilechten C65 Gehäuse vor den Monitor/TV.


    PS: ein anderer Faktor, der die Portierungen größerer Systeme vom Mister zum Mega65 erschweren, verzögern oder gar verhindern könnte ist die Speicher-Ausstattung und Anbindung (Größe, Bandbreite, Latenz). Die größeren Systeme nutzen auf dem Mist(er) 32MB 16-Bit SDRAM mit bis zu 120MHz. Bei Mister gibt es auch 128MB SDRAN Module. AFAIK brauchen das vorwiegend einige NeoGeo Spiele.

    Zumindest der Minimig-Core kann auch noch einen Batzen des 1GB DDR RAM des DE10-nano mitbenutzen (das wird aber auch von dem ARM Cores -also dem Linux - und dem HD Framebuffer für's HDMI genutzt). Glaube es sind 256MB mehr "FastRAM".


    Und was hat der Mega65? Ich habe wieder keine Ahnung, aber mal was von 16MB PSRAM gelesen. Aber ich finde es nicht einfach im Web. Das Projekt sagt, es sei alles Open Source Hardware und Software (und man betont, keine "closed source" ARM CPUs zu brauchen). Aber wenn man verständliche HW Doku sucht, bekommt man zwar viel zum (virtuellen) C65/Mega65, aber sehr wenig zur realen HW, die nun verkauft wird. Es gibt Infos zu den Nexys4 /A7 Boards. Aber was ist mit RAM, was macht der Intel/Altera MAX10 "Utility" FPGA genau? Wo sind Schaltpläne oder PCB Designs?


    Vielleicht suche ich an der falschen Stelle. Vielleicht bekommt jeder die Infos einfach auf Nachfrage. Aber im Gegensatz zu Mist, Mister, SiDi sehe ich nicht, dass da was einfach auffindbar und dokumentiert sei. Tutorials und Templates zur Core-Entwicklung sehe ich auch nicht. Und all das lässt mich etwas daran zweifeln, dass sich eine von M.E.G.A. unabhängige Community entwickelt, die massig Cores von Mist(er) auf Mega65 portieren wird.


    Daher würde ich sagen: der Mega65 ist ein tolles, komplett fertiges Produkt, ein C64/C65(++) System für Anwender und Programmierer. Ob er aber FPGA-Retro-Emulations für alle möglichen Systeme werden wird, bleibt abzuwarten. Mir scheint es, der M.E.G.A e.V. müsste da mit mehr Support und Doku nachhelfen.

    Da ja jetzt klar ist, dass man einfacher MiSTer Cores auf den Mega65 umsetzen wird können - könnte man nicht das bisherige Core-Auswahlmenü im Mega65 erweitern? So weit ich mich aus einer Präsentation erinnern kann, gibt es ja 7 oder 8 Slots für Cores. Das ist zwar grundsätzlich schon mal gut, aber für den MiSTer gibts ja schon hunderte (leicht übertrieben;) Cores. Ein Core-Menü ähnlich dem MiSTer wäre dafür natürlich besser, sonst müsste man, wenn man alle Slots mit Cores gefüllt hat, ständig welche austauschen. Vielleicht sogar die selbe Auswahlmethode wie beim MiSTer - diese ist einfach und übersichtlich. Der zuletzt ausgewählt Core soll einfach aktiv bleiben.

    Zuerst: ich kenne mich nicht mit dem Design des Mega65 aus - daher ist Folgendes spekulativ:

    die 8 Slots des Mega65 könnten daher rühren, dass der FPGA seine Configuration aus einem Flash-Chip bekommt, in den halt genau 8 verschiedene Cores reinpassen.

    Bei MiST(er)/SiDi übernimmt ein ARM Core die Initialisierung des FPGA und diese ARM CPU ist halt "schlau genug" um die Cores von einer FAT32 formatierten SD-Card zu lesen.

    Daher kann man problemlos beliebig viele Cores haben. Ebenso werden passende ROMs gelesen (die ja bei 16/32-Bit Homecomputer auch schon ziemlich groß sein können, zb. 512K für ein Amiga OS 3.x).


    Der Vorgänger des SiDI - der Sidewinder - hatte z.B. keine CPU und hat die Cores auch von SPI-Flash-Modulen gelesen (die man austauschen konnte, aber das war natürlich umständlicher zu "befüllen" als über SD-Card).

    Anderes Beispiel ist der Odroid Go (kein FPGA sondern ESP32 MCU), wo die "Cores" auch im internen Flash sein müssen. Will man einen anderen Core von SD-Card, muss ein Flash-ROM Slot erst umgeflasht werden (dauert etwas und das Flash lebt natürlich nicht ewig, jeder Schreibvorgang nutzt es ab).


    Wie gesagt: kann sein, dass man auch beim Mega65 mehr oder weniger direkt Cores von SD-Card lesen kann, evlt. über ein mehrstufiges Schema, wo erst ein kleiner SoftCore (also eine CPU im FPGA) vom Flash gelesen wird, der seinerseits dann die SD-Card liest und den FPGA "umprogrammiert".

    Man darf ja auch jedwede Umgebung verwenden, die auch bei den diversen monatlichen Challenges schon benutzt wurden. Assembler/BASIC sowieso, Millfork, TRSE.


    Ich empfehle aus naheliegenden Gründen natürlich C64Studio :)

    Das im übrigen gerade nach und nach Erweiterungen für die dem Mega65 eigenen Grafikmodi erhält.

    Schleichwerbung!

    Ne, im Ernst: cool, das es da schon Support gibt für diese ja doch (noch) esotherische Platform