Hello, Guest the thread was called20k times and contains 173 replays

last post from Endurion at the

Emulatoren xemu-xmega65 / xemu-xc65 bauen und benutzen

  • Bei mir tut sich bei Page-UP gar nichts...,


    Ich glaube aber auch, dass ich die File nicht alle richtig konfiguriert habe - ich bin bei den Anweisungen auf GitHub nicht ganz durchgestiegen.


    Ich habe nur "make roms" gemacht. Und später habe ich das automatisch erstellte SD-Image durch das hier aus dem Forum ersetzt.


    Muss man noch etwas anderes hineinkopieren? Muss man noch etwas umbenennen?


    ich bekommen nämlich beim Start auch ein paar komische Meldungen:


    Das image liegt unter ~/.local/share/xemu-lgb/mega65

  • @Freddy:
    Ich glaube Banner & Kickup sind noch Überbleibsel aus früheren Entwicklungsstufen. Ich hatte dieselbe Frage auch schon Paul gestellt.
    Das Freezemenu funktioniert wohl nur, wenn
    A) Die SD-Karte aus 2 Partitionen besteht. (Die eine ist eine Mega Partition, die andere ist Fat formatiert)
    B) Auf der Fat Partition das File FREEZER.M65 vorhanden ist
    (So ist es zumindestens auf dem MEGA)


    @LGB-Z : Can you comment on this ? Do you know, how to get the Freeze menu working in Xemu/Mega65 ?
    I know, that on the real Mega65 you need to have both partitions and in the Fat formated one you need the file FREEZER.M65.
    Is this the same in the emulator ?


    Thanks Gàbor,


    Anton


    OK, ich glaube ich weis wo das Problem ist.
    Xemu/Mega65 erstellt ein Image aber in diesem Image fehlen sämtliche Dateien um den Mega65 zu starten.
    Ich schaffe es aber im Moment nicht, das mega65.img (Die virtuelle SD-Karte) zu öffnen um selber Dateien hinzuzufügen.
    Die Fehlermeldung die Freddy hat zeigt, dass Charrom und alles andere fehlt.


    Wo es mir jetzt an Wissen fehlt ist: Wenn das, in Xemu/Mega65 erstellte SD-Image wie das vom Mega65 ist, müsste die
    SD-Karte 2 Partitionen besitzen. Ich müsste dann auf die Fat Partition die Dateien Charrom.M65, etc.... draufkopieren.


    Ich weis also im Moment nicht, wohin ich die fehlenden Dateien kopieren muss oder wie ich das mega65.img öffnen kann.


    EDIT: Ich habe gerade gesehen, dass unter Windows, wo das Image erstellt wird (User/AppData/Roaming), ausser dem mega65.img noch ein
    Ordner erstellt wird, mit dem Namen default-files.
    Aber auch wenn ich die fehlenden Daten dort hineinkopiere startet Xemu/Mega65 immer noch nicht...

  • @adtbm: Danke für deine Bemühungen.
    Ich denke daß wir über kurz oder lang schon vorwärts kommen werden mit Gabor's Emulator.


    Auf jeden Fall reden bzw. beschäftigen sich schon ein paar Leute mehr mit dem XEMU/MEGA/C65.


    Und das ist auch schon mal was.


    Btw.: Auch ich denke das ein paar 'files' noch fehlen, wie halt der Freezer.


    Nicht verzagen, weiter machen ;-)


    Wie sagte Bryan Ferry noch?
    Let's Zock together, come on, come on, let's Zock together


  • Als,


    wenn ich dass SD Image von Gàbor's Github seite verwende startet der Mega65.
    Auf diese Weise bekommen wir das Freeze menu aber nicht zum laufen.


    Also MÜSSEN wir das fdisk menu im Mega65 verwenden um ein Image zu erstellen.
    Dieses Image ist nämlich dann ein Abbild einer Mega65 formatierten Karte.


    Wie gesagt: 2 Partitionen: 1 x System (Wird für Saveslots, etc. verwendet) und 1 x Fat32: Da hinein gehören die fehlenden Dateien.


    Was wir also benötigen ist ein Program/Tool, welches in der Lage ist dieses SD-Karten Image zu öffnen.
    WinRAR, 7Zip, Daemon Tools habe ich schon - ohne Erfolg - getestet.


    Hat jemand von euch eine Idee mit welchem Program man das Mega65 SD Image öffnen und bearbeiten kann ?
    Gàbor kann uns da wenig helfen, da er nur Linux verwendet und von Windows überhaupt keine Ahnung hat.


    Das Image ist leider zu groß zum Hochladen. Ich hoffe es ist OK, wenn ich hier auf meine Dropbox verlinke, in welcher ein, gerade eben, mit fdisk erstelltes
    SD-Karten Image ist.

  • hmm


    Meine 'originale' mega65.img hat 994816K, deine hat 1024M.
    Dann habe ich noch so eine 'mini' die ist 131072K


    Deine IMG ergibt das Bild -> hypervisor_b.png


    Meine 'mini' ergibt Bild ->hypervisor_c.png


    Wobei bei der 'mini' passiert gar nichts. Egal welche Taste ich tätige. Da lande ich nicht einmal im BASIC.

  • Was du siehst, ist dass Xemu die Datein zu finden in deinem Rechner war. Das heißt aber nicht, dass sie auch im SD Karte Bild sind. Deshalb kann den Hypervisor sie nicht finden. Sie müssen ins SD Karte Bild geladen werden, diese Fehlerberichten zu vermeiden.


    Es gibt auch ein ähnliches Problem, wann du FDISK zu laufen versucht hatte: Xemu weiß noch nicht wie die "Utility RAM" vorbereiten soll. Im echten MEGA65 ist es als "preconfigured RAM" geschafft.


    Aber beim SD Karte Bild öffnen, es kann as "loop back block device" unter Linux mountiert werden. Dann kann man einfach die FAT32 Partition mounten und alles was man mag dort machen.


    Ich hoffe, dass das hilft.


    Paul.

  • Danke für die Tips.
    Wird in den nächsten Tage probiert.
    Loop back, lol daß mir das nicht eingefallen ist :-D
    :facepalm:

  • Ich habe mir ein eigenes MEGA65 SD-Card-Image "gebastelt" was auf den "ersten Blick" anscheint funktioniert.
    Der Win7 Speicherpfad für das Image ist C:\Benutzer\[Username]\AppData\Roaming\xemu-lgb\mega65\mega65.img


    Da es zu groß ist um hier hoch zu laden ausnahmsweise auch mal so... Ich hoffe das ist Okay:
    "---" zuvor aus dem link entfernen -> http://www.media---fire.com/file/6ry3mf82s8c61ap/mega65.zip


    Auf der enthaltenen Disk ist ein altes MEGA65 Demo "RASTER65.MEGA" (Unter dem C64 Modus laden)
    sowie ein bekanntes C65 DEMO von der C= C65 Demo Disk "REGINA65 DEMO" (Unter dem C65 Modus laden)

  • Erstmal auf Englisch, dann auf Deutsch


    xemu kompilieren von Windows 10 aus





    @LGB-Z: You mentioned several times that it should be possible to build the xemu project on Windows 10 using the Windows subsystem for Linux and an "app" like Ubuntu from the Windows store. I can confirm that it is indeed possible. I have compiled xemu with default architecture native (works except for "make deb" where fakeroot fails - but who would build debian packages on Windows?) and with architectures win32 and win64. The hardest bit is to symlink the SDL2 development libs in /usr/local/cross-tools and /opt/local.


    @All: Das xemu-Projekt sieht die Möglichkeit vor, sich Windows-Binaries zu kompilieren, jedoch von Linux aus, was eigentlich sehr elegant ist. Nur Linux-Hasser gucken in die Röhre, weil sie nicht unter Windows für Windows bauen können. Aber: Man kann unter Windows 10 die Emulatoren des xemu-Projektes für Ziel-Architektur Windows aus dessen Sourcecode kompilieren, wenn man unter Windows 10 das Feature "Windows Subsystem for Linux" aktiviert und ein "Linux" (als App aus dem Windows Store) installiert - beispielsweise Ubuntu (dort kriegt man Ubuntu 18.04 bionic) oder auch Debian. Es ist also möglich zu kompilieren, ohne Windows 10 zu verlassen......


    ....aber ist es auch praktisch und elegant? Meiner Meinung nach (ich bin Linux-User) ist es nicht besonders praktisch. Das Einrichten der Arbeitsumgebung dauert seine Zeit. In der Zeit kann man ein komplettes Linux installieren und hat dann keine Einschränkungen. Aber es geht.


    Wer Interesse an mehr Informationen hat, sagt Bescheid. Dann erkläre ich es detailierter.

  • Yes, in fact, with simple 'make' just compiles the Linux version. Also you can build Linux version, even the deb package in WSL (Windows Subsystem For Linux, or kinda similar name, I can't remember) but for deb you need to have fakeroot, ie installing fakeroot package first within WSL (apt-get install fakeroot). But indeed it's kinda pointless to use WSL to build Linux stuff (unless you want to use Windows more and compile for Linux there, as the opposite what I do, when compiling for windows using Linux). Yes, that's kinda lame from me, that the paths for SDL stuff is kinda hard-coded into the Makefiles/etc when you want to build for Windows.


    About the other topic (well, google translator rulZ ....): the choice to need some kind of UNIX'ish (ie Linux in this case) build system is used in Xemu is bascially only my choice. It would be hard to provide multiple very different build environments ... And since I use Linux (but no Windows at all!) since 1995, it was my choice. Surely, in theory, some can replace the build system to another one capable of working without any "Linux madness" though I wouldn't maintain that, first because I don't know about Windows that much level, and second, because it then needs maintain two versions of the build system, one for Linux and one for Windows and all the changes then need to be done in both of them (and I can imagine they are not even similar maybe ...). There can be some cygwin/etc stuff to build Windows version natively indeed, but then it's almost the same, you need to install extra stuffs to be able to build for Windows on Windows, and then it's almost like just to grab WSL for Windows ... It would be even harder to use some MS stuff directly, as Xemu in some places depends on being gcc as the C compiler (or some compatible in terms of command line handling and extra stuff, like clang ...).


    As far as I can see, if someone don't want to build Xemu this way saying "it's too complicated" then it's maybe complicated either way, no difference ... Then it's much easier to use a pre-built binary and not trying to compile it ...

  • MEGA65-user-guide


    Also XEMU auf Rasperry kompilieren hat allles prima geklapt und läuft auch alles so weit. Vielen Dank auch für die bis dahin unbekannten Emulatoren.


    Jetzt meine Frage hat schon jemand versucht die "mega65-user-guide" per latex zu erstellen? Ich bekomme da immer verschiedene Ergebnisse. Die Datei im Anhang hat nur reduzierte Grafiken um sie hier hochladen zu können.


    Wollte eigentlich mal eine kleine Kurzanleitung schreiben.

  • By the way, I tried to put together a bit more sane download + web browser "try it out" page, with the already mentioned URL (I don't want to write it here again, since it seems the forum wants me to wait till I am mature enough for that, ie 2 weeks or something to be able to include external URLs within my posts without being censored).


    First, besides the installers, I put simple ZIP files only with the needed exe+dll files. I also mention there about the report on NSIS detected as virus/trojan by some antivirus software.


    Also, on the "in-browser" demonstration page, I played a bit with the emscripten VFS + html5 file API, so in theory, it's possible now with the web based version as well, to attach a D81 image. But please note, the UI of the emscripen generated emulator is still very ugly, and this D81 attachment thing currently only works with the C65 emulator, and not with the M65 (yet!). Meanwhile, I also ported some other emulators into the web version state, most notable the Commodore LCD maybe.


    I'm still open about any help, suggestions etc about better installer / configuration methods, whatever ... Especially about Windows, but keep in mind, that Xemu should work on MacOS too, just there I am even more unsure how it can be done nicely.


    Ah, and one more thing: if someone wants to use the source, maybe it's better to use the "dev" branch. The master branch can be quite aged compared to the "dev". Though I've just sync'ed the dev to the master, but it can be often the case (but surely, "dev" means dev, so at the other hand, it can cause problems ... I try to update my download page - in fact now it's part of my crude build system that I can do that with a single make command ... - though with some sane versions put-on when I see it should work and it worth to update the pre-built versions there, including the windows material too!).

  • Hi @LGB-Z!


    With my judgement on practicality regarding WSL to build xemu I didn't want to criticize the current cross-make setup of xemu at all. I really like it that one can compile all flavours from Linux. I just wanted to point out to others that installing Linux in a dual boot scenario or installing Linux in a Virtual Box or VMWare has more advantages for a user who is not familiar with either Linux or the strange WSL flavour of bash Linux.


    At this time the only thing that could be improved is the documentation for ARCH=winXX that could state where to get SDL2 development libs for mingw from (https://www.libsdl.org/download-2.0.php) and where to put them in the file system (I explained this in the message I sent you).


    Please don't consider changing the make structure you have created! :)


    It yet has to be seen if the option to build for Windows on Windows solves a real-life problem for any existing user. :)


    Regarding the deb fakeroot topic on WSL: fakeroot package is installed, the problem is somewhere else (but this problem doesn't need to be fixed):


  • Hi baxt3r:


    Wie hast du es geschafft am Image zu basteln ?
    Unter Windows ? Welches Tools hast du benutzt ?
    Hast du die fdisk funktion vom Mega65 verwendet ?
    Und kannst du bestätigen, dass du immer noch 2 Partitionen hast (System generic und Fat32) ?



    Du weisst, das die Anleitung im Moment noch WIP und nicht vollständig ist ?
    Das mit der Kurzanleitung ist eine tolle Idee, wenn es OK für Dich ist, würde ich Dich gerne bitten, dafür einen seperaten Thread aufzumachen, wie z.B.:
    "Mega65 - Handbuch per Latex erstellen"

  • Hi @LGB-Z!


    With my judgement on practicality regarding WSL to build xemu I didn't want to criticize the current cross-make setup of xemu at all. I really like it that one can compile all flavours from Linux. I just wanted to point out to others that installing Linux in a dual boot scenario or installing Linux in a Virtual Box or VMWare has more advantages for a user who is not familiar with either Linux or the strange WSL flavour of bash Linux.


    Oh, I didn't found that a negative critics, do not worry. I just wanted to say, if compiling of Xemu is hard for someone (not you, or any other, I just speaking in general ...) because of the need of WSL or something, then it will be still hard if he needs to install other packages which are not Linux stuff but still needs work to be able to use, like cygwin stuffs. So then, it's kinda much easier to use the pre-built binaries instead, either way, compiling something is not a user level stuff to do for many users, let it be Linux, Windows, or anything at all. That's why I try to play with NSIS etc, and building some ugly download page, so it won't be the issue then for people.


    Quote

    At this time the only thing that could be improved is the documentation for ARCH=winXX that could state where to get SDL2 development libs for mingw from (https://www.libsdl.org/download-2.0.php) and where to put them in the file system (I explained this in the message I sent you).


    Indeed, I've just written about that for you in private, btw :)


    Quote

    Please don't consider changing the make structure you have created! :)


    I won't ;-P Basically, it's more for myself "by design", I think, "average user" (especially when Xemu will be more mature btw ...) should use pre-built versions, let it be Windows exe, installer for Windows, DEB package, or even any fancy thing in the future.



    Quote
    Code
    1. fakeroot, while creating message channels: Function not implemented
    2. This may be due to a lack of SYSV IPC support.
    3. fakeroot: error while starting the `faked' daemon.
    4. /usr/bin/fakeroot: 1: kill: Usage: kill [-s sigspec | -signum | -sigspec] [pid | job]... or
    5. kill -l [exitstatus]
    6. Makefile:58: recipe for target 'deb' failed
    7. make: *** [deb] Error 1


    About the fakeroot stuff, that's funny, but really, why should one use WSL on Windows to build Linux versions then ;-P I guess it's more a problem that WSL uses only a "stub" looks like the Linux kernel done by Microsoft, but it's just some layer over the Windows kernel, and lacks features, like IPC etc, that can be the problem. But I don't think it affects at least the important part: to be able to build Windows version of Xemu on Windows (well, by using WSL on Windows ...).

  • Ich habe mir ein eigenes MEGA65 SD-Card-Image "gebastelt" was auf den "ersten Blick" anscheint funktioniert.
    Der Win7 Speicherpfad für das Image ist C:\Benutzer\[Username]\AppData\Roaming\xemu-lgb\mega65\mega65.img


    Auf der enthaltenen Disk ist ein altes MEGA65 Demo "RASTER65.MEGA" (Unter dem C64 Modus laden)sowie ein bekanntes C65 DEMO von der C= C65 Demo Disk "REGINA65 DEMO" (Unter dem C65 Modus laden)


    Hi,
    läuft gut unter Linux :-)


    Aber RESTORE scheint mit dem Xemu nicht zu gehen - da passiert gar nichts. Auch nicht mit deinem Image.
    Sind da all die Systemdateien drauf?


    Und vor allen - wie hast du das gemacht - mit Linux Loopback mount wäre mir klar

  • Mit mount loopback kann Linux die images offenbar nicht lesen (habe mir einen Mountpoint /mnt/mega65 angelegt:


    Code
    1. marcel@OpenSuse:~/.local/share/xemu-lgb/mega65> sudo mount -o loop mega65.img /mnt/mega65
    2. mount.nilfs2: Error while mounting /dev/loop0 on /mnt/mega65: Invalid argument


    Er will immer das FS nilfs2 nehmen - wenn ich mit "-t" vfat vorgebe, dann meckert er auch.


    Mit Parted kommt man aber ran - nur eingebunden geht nicht. Hier das Image von baxt3r:


  • So, ich kann jetzt die Images lesen/schreiben. Wichtig ist der "Offset". Hier mit dem Image von baxt3r:


    Sind das die richtigen Files auf der Disk?