Posts by FeralChild

    I fully agree MEGA65 is not mature enough yet - I'll try to look at this once it is, I hope compiling MP3 is not that complicated. IMHO it could be worth having a separate compilation for M65 - all this will definitely require some space (and other optimizations might be possible - I see GEOS provides some integer math routines, and MEGA65 is going to have an integer math unit in the FPGA core), on the other hand SuperCPU support could be stripped away. I don't think about using the no-turbo drivers, I would just like to get rid of few instructions from the host-side disk driver implementation:

    Code
    1. sec
    2. loop:
    3. lda $D012
    4. sbc #$31
    5. bcc trasnsfer_byte
    6. and #$06
    7. beq loop
    8. trasnsfer_byte:

    this should speed-up the transfer a little.

    (englische Version, maschinelle Übersetzung unten)


    You probably don't need to know the whole MEGA65 memory management (the C65's MAP/EOM is not fun to deal with) - you can use it's 8 MB memory expansion in a similar way you use REU. You need to reserve some memory for a DMA list, fill it in properly, and launch the job. Here is the generic memory copy handling I've implemented (so far it is only used to scroll the screen) - https://github.com/MEGA65/open…board_m65/mega65_dmagic.s, and definitions in files: https://github.com/MEGA65/open…s/%2Caliases_ram_lowmem.s, https://github.com/MEGA65/open…%2Caliases_hardware_m65.s. If MP3 has some abstraction layer for memory expansion with a well-defined API, I can help with writing MEGA65-specific routines.


    There are couple other things to take care about:

    - during the startup, perform "POKE 0, 65" as soon as possible - the lowest bit enables fast mode, where MEGA65 operates at 40 MHz and automatically slows down to 1 MHz for IEC operations

    - remaining MEGA65 extra registers ($Dxxx range), including DMAgic engine, can be accessed when VIC-IV is unlocked (POKE $D02F,$47:POKE $D02F,$53) but you should only unlock MEGA65 registers if you want to do something with them, afterwards it would be best to lock them again (by storing anything in $D02F). Reason: when MEGA65 registers are unlocked, no 'illegal' 6502 instructions are supported (compatibility!), instead you have 65CE02 instruction set with C65 and MEGA65 extensions available

    - you can gain a little bit extra speed by disabling badlines (and probably enabling fast IRQ - I'm not sure what it does) - register $D710, bits 0 (badlines) and 1 (fast interrupts)

    - most likely the GEOS disk drivers (turbo) have some code to wait for appropriate raster position to avoid badlines - but if we have no badlines, these small pieces of code could probably be removed to gain some extra speed

    - RTC synchronization (MEGA65 provides clock with BCD values)

    - last, but not least - it would be nice if the C= symbol from GEOS system font cound be replaced with MEGA65 'M' symbol :)


    Regarding internal drive - true, it has a chance to work with non-turbo 1581 driver, but I would be careful with it; it's DOS can be buggy/unfinished, AFAIK it has problems detecting disk change, etc. Some day in the future SD card could be used to store 'native mode' disk images (maybe not as files, but as a reserved area in the card itself?) - but I don't have experience with MEGA65 SD card controller yet.


    But IMHO it's too early for GEOS on the DevKits. Currently IEC has some problems, most likely timing incompatibilities (regression) - standard CBM protocol usually works, but fast loaders do not.

    -------------


    Sie müssen wahrscheinlich nicht die gesamte MEGA65-Speicherverwaltung kennen (es macht keinen Spaß, mit MAP / EOM des C65 umzugehen) - Sie können die 8-MB-Speichererweiterung auf ähnliche Weise wie REU verwenden. Sie müssen Speicher für eine DMA-Liste reservieren, diese ordnungsgemäß ausfüllen und den Job starten. Hier ist die generische Handhabung von Speicherkopien, die ich implementiert habe (bisher wird sie nur zum Scrollen des Bildschirms verwendet): https://github.com/MEGA65/open…l/board_m65/mega65_dmagic. s und Definitionen in Dateien: https://github.com/MEGA65/open…s/%2Caliases_ram_lowmem.s, https://github.com/MEGA65/open-roms/blob/ master / src / aliases /% 2Caliases_hardware_m65.s. Wenn MP3 eine Abstraktionsschicht für die Speichererweiterung mit einer genau definierten API hat, kann ich beim Schreiben von MEGA65-spezifischen Routinen helfen.

    Es gibt noch einige andere Dinge, um die Sie sich kümmern müssen:
    - Führen Sie während des Startvorgangs so bald wie möglich "POKE 0, 65" aus. - Das niedrigste Bit aktiviert den Schnellmodus, in dem MEGA65 mit 40 MHz arbeitet und für IEC-Operationen automatisch auf 1 MHz verlangsamt wird
    - Auf die verbleibenden zusätzlichen MEGA65-Register (Bereich $ Dxxx), einschließlich der DMAgic-Engine, kann zugegriffen werden, wenn VIC-IV entsperrt ist (POKE $ D02F, $ 47: POKE $ D02F, $ 53). Sie sollten jedoch nur MEGA65-Register entsperren, wenn Sie etwas tun möchten mit ihnen, danach wäre es am besten, sie wieder zu sperren (indem Sie etwas in $ D02F speichern). Grund: Wenn MEGA65-Register entsperrt sind, werden keine "illegalen" 6502-Anweisungen unterstützt (Kompatibilität!). Stattdessen steht der 65CE02-Befehlssatz mit den Erweiterungen C65 und MEGA65 zur Verfügung
    - Sie können ein wenig mehr Geschwindigkeit gewinnen, indem Sie Badlines deaktivieren (und wahrscheinlich schnelles IRQ aktivieren - ich bin nicht sicher, was es tut) - $ D710, Bits 0 (Badlines) und 1 (schnelle Interrupts) registrieren
    - Höchstwahrscheinlich haben die GEOS-Festplattentreiber (Turbo) einen Code, der auf die entsprechende Rasterposition wartet, um Badlines zu vermeiden. Wenn wir jedoch keine Badlines haben, können diese kleinen Codeteile wahrscheinlich entfernt werden, um zusätzliche Geschwindigkeit zu erzielen
    - RTC-Synchronisation (MEGA65 liefert Uhr mit BCD-Werten)
    - last, but not least - wäre es schön, wenn das C = -Symbol aus der GEOS-Systemschrift durch das MEGA65 'M'-Symbol ersetzt würde :)

    In Bezug auf den internen Antrieb - stimmt, es hat die Möglichkeit, mit einem Nicht-Turbo-1581-Treiber zu arbeiten, aber ich würde vorsichtig damit sein; Das DOS kann fehlerhaft / unvollendet sein, AFAIK hat Probleme beim Erkennen von Festplattenwechseln usw. Eines Tages in der Zukunft könnte die SD-Karte zum Speichern von Festplattenabbildern im "nativen Modus" verwendet werden (möglicherweise nicht als Dateien, sondern als reservierter Bereich auf der Karte selbst?) - aber ich habe noch keine Erfahrung mit dem MEGA65 SD-Kartencontroller.

    Aber meiner Meinung nach ist es für GEOS auf den DevKits zu früh. Derzeit hat die IEC einige Probleme, wahrscheinlich Timing-Inkompatibilitäten (Regression) - das Standard-CBM-Protokoll funktioniert normalerweise, schnelle Lader jedoch nicht.

    Well, back then I wasn’t even able to succesfully use the F9 key. Now, as I’m preparing a separate MEGA65-only keyboard scanner for the native mode (with up to 3 key rollover, which is not possible in C64 mode without sacrificing compatibility), I see that $D611 / $D613 / $D614 registers are not supported by XEMU, at least on Hernan’s branch.

    If I remember correctly, there are some delays in the CIA chips, maybe this is not right? If so, many fastloaders won't work. A VICE source code might be a good reference. But this does not explain why my IEC implementation does not work correctly, maybe I have too strict timing requirements?


    I'll try to look into the IEC from software point of view when I finish the new MEGA65 keyboard handler (my initial untested implementation was clearly a bad design, I can see it now) - XEMU doesn't implement the C65 keyboard, so I was unable to test it.

    I thought that only drive 8 is reserved. I did one more experiment - I've prepared a special MEGA65.ROM, where I've replaced the C64 mode Kernal with JiffyDOS Kernal, and tried 2 devices which worked for me with original MEGA65.ROM: petSD+ and FireDrive 2K (modern CMD FD2000 clone). Neither worked correctly this time - the communication with devices was disturbed and one byte every 5-6 was received wrongly.

    Right now I'm getting DEVICE NOT PRESENT ERROR when trying LOAD"$",10. At the beginning, system was hanging after SEARCHING FOR $ - but back then the SD2IEC was set as device 9. BTW, something seems to be wrong with device 9 support in C65 ROM, trying to load directory from it hangs even if I have nothing connected to the IEC port. I have discovered that my petSD+ actually work, I just have to set it as device 10, not 9 (at least with C65 ROM; Open ROMs seems to have some problem and it works randomly, most of the time it doesn't - might be timing issues, but this I'll investigate after I finish with the MEGA65 extra keys support)


    As I mentioned somewhere, I'm waiting for another SD2IEC model, from TFW8b (currently I'm trying to use this model).

    I was not so keen to care, since it seems in official ROMs the C64 and C65 charset are the same. Or at least I remember as they are, but I am not sure now :-O

    AFAIK they are not exactly the same, it's like with C128, where native mode has slightly altered lowercase 'i' (possibly also other tweaks, I don't remember). Open ROMs has 2 slightly different character sets too - the one intended for native mode has some bugfixes, VENDOR+N and VENDOR+M are actually different, etc.

    I mean "GO 64" implemented by Open ROMs (with C65 ROM the command works). Holding MEGA key during the startup definitely won't work with Open ROMs, it's not implemented (and there is no need for it; switching to compatibility mode should happen automatically if C64 cartridge is detected or Open ROMs unaware program is launched).

    I'll probably get the battery much faster by going to local watchmaker. It definitely is working, my workhorse monitor can display the picture (but MEGA65 can't stay nearby, I don't have space on this desk due to permanent home office since the COVID outbreak).

    Definitely - try the current bitstream, current Open ROMs (with the build-in one the GO 64 does not work, if it reproduces with current builds I'll have to investigate it), in a few days I should get a different SD2IEC model too (problem might be related to timing... more experimentation needed). Just not today :)

    OK, assembled (mostly - I'll have to buy a CR 1220 battery somewhere). Broke off a small part of the bottom acrylic element while attaching the left rear element - but it doesn't affect the look from normal angles :) Problems so far:


    1. My 4:3 1600x1200 LCD HDMI monitor I was using with Ultimate 64 for some reason does not display the picture (music plays normally).


    2. Anyone managed to use SD2IEC with MEGA65? Mine does not work - when I'm trying to load a directory, with C65 ROM (both C65 mode and C64 mode) green LED on SD2IEC gets turned on and the system hangs. Tried the same with Open ROMs delivered with the MEGA65 - also does not work (but problem looks differently - the red led of SD2IEC red led starts flashing). Definitely not the SD2IEC power supply problem (same one works perfectly with Ulimate 64).


    OK, I'm tired. Enough experimenting today :)

    --- Maschinenübersetzung:


    Deutlich sein:


    1. 'chargen_openroms.rom' ist der ursprüngliche Open ROMs-Zeichensatz, 'chargen_pxlfont_2.3.rom' ist eine PXL-Schriftart v2.3 von Retrofan. Es liegt beim Benutzer, welchen Zeichensatz er bevorzugt (ich bevorzuge den von Retrofan, daher verwende ich ihn in allen Screenshots). Wenn das Anhängen der Versionsnummer an die Datei aus irgendeinem Grund nicht praktikabel ist (und 'chargen_pxlfont.rom' wäre ein besserer Name), lassen Sie es mich bitte wissen - ich habe damals nicht wirklich darüber nachgedacht, dass Online-Emulatoren die ROMs direkt aus dem Repository abrufen .


    2. Für MEGA65 - true gibt es zwei Varianten des ROM mit unterschiedlichen Chargens. Ich weiß nicht, welche standardmäßig in MEGA65 DevKits installiert werden. Wenn Ihnen die Standardeinstellung jedoch nicht gefällt, beschweren Sie sich bitte im MEGA65-Unterforum.


    3. Es stimmt, es gibt keinen 1541 ROM-Ersatz - und ich habe nicht vor, einen zu schreiben. Ich habe einfach keine Zeit dafür, selbst mit BASIC und Kernal habe ich jahrelang genug Arbeit (insbesondere, dass ich Hardwarefunktionen von MEGA65 und Ultimate 64, verschiedene verbesserte IEC-Protokolle usw. unterstützen möchte). Aber wenn jemand eingreift, um eine zu implementieren, helfe ich gerne mit der Umwelt.


    --- english:


    To be clear:


    1. 'chargen_openroms.rom' is the original Open ROMs character set, 'chargen_pxlfont_2.3.rom' is a PXL font v2.3 by Retrofan. It's up to the user which character set he prefers (I prefer the one by Retrofan, so I use it in all the screenshots). If attaching version number to the file is not practical for any reason (and 'chargen_pxlfont.rom' would be a better name), please let me know - I didn't really think about online emulators fetching the ROMs directly from the repository back then.


    2. For MEGA65 - true, there are 2 flavours of the ROM, with different chargens. I don't know which will be installed by default in MEGA65 DevKits - nevertheless, if you don't like the default, please complain in the MEGA65 subforum.


    3. True, there is no 1541 ROM replacement - and I don't intend to write one. I just don't have time for this, even with BASIC and Kernal I have enough work for years to come (especially that I want to support hardware features of both MEGA65 and Ultimate 64, various improved IEC protocols, etc.). But if someone steps in to implement one - I'll happily help with the environment.

    ubik BBC Basic to fully use MEGA65 features? Quite a lot of work. It's not just adapting to modern assembler and CBM Kernal API:


    - code should be reviewed and adapted to utilize MEGA65 CPU instruction set (which is extended compared to 6502)

    - one would need to rethink and rewrite the whole sound & graphics support; I bet MEGA65 is much different than BBC Micro

    - variable/array support would have to be rewritten to support MEGA65 extended memory

    - to be able to run existing assembler software, text binary format should be reviewed and made CBM-like - otherwise such a ROM wouldn't be able to run even anything like "10 SYS 2084"

    - the CBM BASIC floating point routines (and some others) are used by various software quite often - to be reasonably compatible, you would need to provide these APIs too

    The documentation is not that bad already. We won't get scores of developers, it's 35 years too late for this. This is a retro platform, it has no chance to go mainstream. I bet most of the DevKits will be used for playing, not writing a new software (or updating old titles).


    MEGA65 ported to MiSTer a year ago would be an advantage, but now, when DevKits are going to be dispatched any day, and final machines expected the next year. And Sorgelig is mostly right (it's painful for me to admit it, believe me), right now this core wouldn't be much useful for an average user - maybe except running some titles in 40 MHz mode.

    Even just emulate a "dummy drive" (like what SD2IEC does as well, ie not emulating the internal working of the disk drive, only it can speak the IEC protocol ...) requires at least "speaking" the IEC protocol. Honestly I've tried once, many years ago, but I always found that it's too much for me, to ever understand how IEC protocol works, it's just too weird for me, also maybe timing issues was a problem as well, I am not sure


    The protocol is mostly logical (but far from being optimal, unfortunately) - last year Michael Steil did a really good description, see here. But testing the implementation is really time consuming, at least this was in my case.