Xemu C65/M65 news

[LGB Gábor Lénárt]

Hi All,

Hopefully nobody has problem with the idea another thread to be created here so I can post news on Xemu (in relation of C65 and/or M65 emulator, since Xemu is about more others too, even not related to C= at all). These news are always related to the latest source in my (!!) github repository, master branch (if it's not stated otherwhise). Though, I have some binary builds in bintray, it's not always up-to-date to the sources. "In C65" (or M65) emulator means, that it's related to that emulator only, not the other. Surely it often means it will be (especially in the case that many things are easier to test/develop in the C65-only emu first, before M65).

Ok then:

* As I've noted already (in another topic), there are some window borders now in C65 emulator. As VIC3 core in Xemu/C65 is scanline level precision only, you can't expect more though, than the ability to change colours (both of border and background) at every scanlines but not within a scanline.
* Preliminary C1351 mouse support in the C65 emulator, it's highly problematic currently though
* OSD-framework I plan to use later even for menus etc maybe (currently used only in the C65 emulator, at one point, see below)

To test the mouse support, I suggest get a newer C65 ROM which knows BASIC keywords like "MOUSE". 911001.bin seems to be OK. However it also needs the "new DMA behaviour". Xemu does not fully support it, only a light hack which allows the newer ROM to be used at least. So in nutshell, you need to say something like this to launch Xemu/C65 (for the ROM, you  need to give the full path if it's not in the current directory etc etc, xc65.native here is only the name of the Xemu/C65 binary itself):

xc65.native -rom 911001.bin -dmarev 1

Do not forget the -dmarev 1 switch ...

Now, enable mouse pointer/tracking in BASIC with:

MOUSE ON

Please note, that maybe you would need a decent sprite shape for mouse pointer, but anyway, hopefully you see something, if no other than a black box or whatever the sprire pointers and the pointed memory area contains.

At this point, it won't move, since you need to enter "mouse grab" mode to allow Xemu's SDL event loop to grab the mouse and send the events. So click on the emulator window somewhere with the left mouse button.

Now, you see the OSD feature as well, telling that mouse grab mode is ON (that is, you can't see the normal "PC" mouse cursor etc etc), and you can exit with pressing ESC. The OSD notification fades away autmatically.

You can try to move your mouse now. As you can see, there are some ugly glitches etc, but honestly the 1351 mouse emulation is extra ugly currently, I wouldn't even call an emulation here too much :-D

Surely, you can press ESC on the keyboard to leave mouse grab mode at any time.

The HID layer of Xemu is a bit chaotic (surprise, surprise ...), so there are odd things. Like, Xemu supports joystick emulation with an USB joystick/game controller (I tested with an Xbox controller btw, and worked even on a raspberry Pi connected to), or with the numeric keypad. However, for USB joy, only the first two axes are supported, and it's hard to know which control belongs to that on different controllers/joys :( Secondly, the joystick emulation is for control port 1 or 2, and you can select it with ENTER key on your numeric keypad. It also affects mouse emulation, since 1351 buttons are handled the same way as joy direction UP and the FIRE. So if you want to test 1351 with mouse buttons as well, you may need to switch between joy ports with keypad ENTER. Also, currently it's not limited that CIA in fact can select which control port is routed to SID POT's what is used, but it's not a big deal now. Also, for real, in C65 only one SID is used for control ports POT stuffs, it's not the case with Xemu/C65 currently. And so on :)

[Ben-401]

Hi Gabor,

No problem, I think this is a good place to announce etc the development of xemu, especially because it is of high interest to us to monitor the progress of xemu/mega65.
Thanks for keeping us updated.
And I can see at
https://github.com/MEGA65/xemu/network
that our repo is 4 commits behind yours. I would expect that every-now-and-then we will merge in your work to our fairly static xemu repo.

Cheers, Ben.

[LGB Gábor Lénárt]

Hi Ben,

Actually I have write rights to xemu repo in MEGA65, so I can merge things from time-to-time. Though I have no information than any other commits ever went there other than merges from my repo, but still, we can even say (for example) that I merge things there only, after something interesting or "hopefully more stable" (etc) point is reached with my personal primary repository (though to be honest, I'm a bit lame with GIT, with cross-fork merges, I always end up using github's merge, what makes me feeling odd, as the merge itself is also a commit saysing "one commit ahead" which is actually was only the commit to reach the state of my repo ... my fault with git, I know ...). If it's OK for you (as plural you). Currently, I did a minor fix only what I told about the devel/master mega65-core branch merging, ie the problem of lack of emulation on "UART is ready" stuff, so with newest KS, and FPGA switch-12 turned on, Xemu caused KS to executes forever waiting for UART being ready. https://github.com/lgblgblgb/xemu/commit/bcfa5336485bfd861b63d9d252f35e0197a1a4ea

[Paul Gardner-Stephen]

Hello,

Just always push your changes, if the head of our master matches the head of yours.

Paul.

On 20 March 2017 at 00:02, LGB Gábor Lénárt <lgbl...@gmail.com> wrote:

Hi Ben,

Actually I have write rights to xemu repo in MEGA65, so I can merge things from time-to-time. Though I have no information than any other commits ever went there other than merges from my repo, but still, we can even say (for example) that I merge things there only, after something interesting or "hopefully more stable" (etc) point is reached with my personal primary repository (though to be honest, I'm a bit lame with GIT, with cross-fork merges, I always end up using github's merge, what makes me feeling odd, as the merge itself is also a commit saysing "one commit ahead" which is actually was only the commit to reach the state of my repo ... my fault with git, I know ...). If it's OK for you (as plural you). Currently, I did a minor fix only what I told about the devel/master mega65-core branch merging, ie the problem of lack of emulation on "UART is ready" stuff, so with newest KS, and FPGA switch-12 turned on, Xemu caused KS to executes forever waiting for UART being ready. https://github.com/lgblgblgb/xemu/commit/bcfa5336485bfd861b63d9d252f35e0197a1a4ea

--
You received this message because you are subscribed to the Google Groups "C65GS Development" group.
To unsubscribe from this group and stop receiving emails from it, send an email to c65gs-development+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[LGB Gábor Lénárt]

Btw, one thing is clear for me: indeed, it is great to support newer C64 ROMs (but it requires newer DMA chip revision). I also came up with the idea, that it seems older ROMs has no, or not working BASIC 10 commands. For example to test mouse emulation, I needed the MOUSE command, which seems doesn't work in the older ROMs. Surely there can be many other examples like this, as we've already talked about that somewhere and sometime :)

[Paul Gardner-Stephen]

Hello,

Yes, I agree adding support for the new DMA chip in the emulator would be good to do.  The differences aren't very big.

Paul.

On 22 March 2017 at 06:23, LGB Gábor Lénárt <lgbl...@gmail.com> wrote:

Btw, one thing is clear for me: indeed, it is great to support newer C64 ROMs (but it requires newer DMA chip revision). I also came up with the idea, that it seems older ROMs has no, or not working BASIC 10 commands. For example to test mouse emulation, I needed the MOUSE command, which seems doesn't work in the older ROMs. Surely there can be many other examples like this, as we've already talked about that somewhere and sometime :)

--

[LGB Gábor Lénárt]

Hi,

On Wednesday, March 22, 2017 at 12:22:51 AM UTC+1, Paul Gardner-Stephen wrote:

Yes, I agree adding support for the new DMA chip in the emulator would be good to do.  The differences aren't very big.

What I wanted to mean here also, that for the real M65 as well ... :) Since I was kinda surprised what things are done in newer ROMs, eg MOUSE ON, and I have usable mouse cursor by the basic (which really works with C1351, it seems!), wow :)

On the emulator side: Xemu currently supports the newer DMA revision but ignores any "subcommand", so it's only merely enough (according to my tests) to be able to run the newer ROMs without that infamous ?PROGRAM MANGLED error :) However I am still not sure what's going on: with the newer ROMs + with the trick above to have some "hacked newer DMA" support, I still has odd problems, for example many programs reports "SCREEN NOT OPEN" and similar errors even if I want to LOAD something, I am not sure how screen is concerned then. But yeah, maybe it's because it would use other DMA features from the "new things" which I don't emulate ...

[Gábor Lénárt]

Hi,

Maybe I've already asked that in the past, I am unsure. Do we have an exact table about the cycles needed for a given opcode on M65 to be executed? I mean on 48Mhz, but also when it's "only" C65 speed and "only" C64 speed.

http://pastraiser.com/cpu/65CE02/65CE02_opcodes.html

I used this table for 65CE02 in general, but for sure, I know, M65 is not exactly the same timing.

I ask this, since I plan to re-new some old ideas from me. One is the CP/M 8080 software emulator on M65. Because emulating one CPU is kinda resource hungry stuff even on 48MHz M65, it's very important to know what solution is the best. Eg, I can use INW opcode to increment a word on ZP and using then  LD (zp_loc), Z or such, or even the 32 bit linear addressing etc. However on normal 65CE02 at least, INW is kinda slow! I am better with the method to keep low byte of ZP "pointer" zero, and using "Z" as the low byte instead, even if I need to check if there is a warp-around on Z after each INZ for example (and incrementing high byte then "manually"), longer and uglier code but still faster than using INW! And since it's done at every emulated 8080 opcodes (even multiple times sometimes!), it's essential to choose the optimized solution. Even if it's rather ugly ... I even have a solution where emulated 8080 PC's pointer is "something" on ZP (not even zero low byte) and Z is only an offset, and correcting the zp pointer only if I need PC value (eg, push PC on CALL) or if Z turns into >127 (only this, because that can be "sensed" with a simple BMI after INZ, and then after that I am free only using INZ after the "parameters" of a 8080 opcodes, and only do the inc/check-for-adjust task on the main opcode decoding handler).

Thanks!

--

Gábor

[Paul Gardner-Stephen]

Hello,

I haven't documented the current instruction cycle counts -- but this would be worth doing. I'd recommend making a program that calculates the instruction cycle counts, since they are still likely to change as the CPU is revised, and especially if I ever finish the complete CPU re-write, so that we have a CPU with separate cores for emulated floppy drives.

In general, the M65 CPU is 1 cycle slower for any instruction that reads from memory, but some other instructions are faster.  Most single-byte instructions are, however, only 1 cycle.

Probably the best way to see the difference to a real 6502 for instruction classes is to use Synthmark64 on both, and compare the relative speed of each of the test classes it performs.

Paul.

--

[Ben-401]

I confirm that the "SYNTHMARK 64" program is on the "MEGA65.D81" image,
just for this purpose.

I have found that when GO64, Y, LOAD"SYN*",8,1

scores of about "0.9x" are seen.

Then, POKE 0,65 puts the processor in 48MHZ mode. So then when RUN,

scores of about "40x" are seen.

I understand this does not answer the LGB question of an exact table,
unfortunately.

I could post images of the current results of SYNTHMARK, if requested.

[LGB Gábor Lénárt]

Hi,

Now, I have more or less working 48MHz mode in Xemu/M65 emulator. Currently only, if the command line switch -turbo is given to start the emulator. Surely, it's only a temporary solution not to introduce problems may show only with this mode.

Moreover: POKE 0,64 and POKE 0,65 to set "force_fast" works now (surely, only in a sane way with the mentioned "-turbo"). It was not handled before and wrote CPU DDR register instead ... There is no "speed gate" yet, as with CAPS LOCK stuff on M65 (according to the VHDL at least, I tried to use as reference)

Hypervisor always set fast mode on enter (but only 48MHz, in case of "-turbo").

Current CPU speed is shown in the window title (only 1 / sec refresh though). The ">3.5MHz" title shows that it would run on more (48MHz) but "-turbo" is not enabled.

Unfortunately there is no "C128 fast" (2MHz) mode yet, so for setting M65 speed with the possibility to set C128 fast first (instead of C65 fast) wouldn't work ...

There was some interesting bug with snapshot saving, to interpreted by the speed control to be in hypervisor mode, it has been (hopefully) corrected.

DMA is now updated as the CPU, not as before to run the full DMA operation with everything stopped (even SID, VIC, ...) meanwhile. Though the timing may not be correct at all (now it's CPU speed control dependent, 1/2/3/4 cycles per iteration for fill,copy,mix, and swap operations, if I remember correctly by heart).

+ an older commit (not now): there was a bug in my 4510GS emulation with the 28 bit linear ADC addressing opcode, a kinda lame typo. It has been corrected.

Though I haven't tested all things too much yet ...

[Paul Gardner-Stephen]

All sounds great :)

--

[LGB Gábor Lénárt]

2MHz mode now should work ... I removed the -turbo switch, if anyone has problem, please tell. So now that's the default, ie 48MHz works if it should run on 48MHz ... In case of problem, some can still use the -c65speed command line switch, which cause to limit CPU clock to the C65's one at max, so it won't allow to run at 48MHz. This version is also available now as a binary form for win32/win64/OSX/Ubuntu DEB 64 bit (and experimental RPM based Linux package, but that's only a converted deb, I have no idea ...) at the usual place: https://bintray.com/lgblgblgb/generic/xemu#files

Please note, that I haven't test the binary builds, especially not OSX/Win32/Win64 ones, since I don't have those OSes, I can only cross compile for them (or using Travis OSX service in case of OSX) ...

[LGB Gábor Lénárt]

In lgblgblgb/xemu respitory there is now the result of a huge change, though its impact on a user is quite low. It's about rewriting the whole memory and I/O decoding and some more stuff. Though it doesn't have to much "visible" effect, it's kinda important for future work, and also for performance reasons (now on emulated ~48Mhz, it's about using the half of the CPU as it did before on my Linux box at least). However because of the size of the change there can bugs ... So anyone has access to MEGA65/xemu, please do not merge my master branch yet!! And for sure, if anyone want try the new version, feedback is welcome, even if it's about some bugs :) One of the visible effects though, is the tunable "fast clock" by default it's 48Mhz, but the  -fastclock command line switch allows to set it to other value (given as a number, meant in MHz). Other than that, there are some minor changes, like the preliminary C1351 mouse emulation from xemu/c65, OSD framework, windows system console, and things like that, most of them are not so much used yet for anything sane though at this point.

[Ben-401]

Hi Gabor,

Its great to see you develop further the already amazing emulator.

We now have a couple new peoples using the master branch of MEGA65/xemu.
I do not expect our people to be making any changes to the MEGA65/xemu.
We welcome your development to your LGB/xemu and when that is stable,
Yes we would love to test and then merge into our repo.

Ben.

[LGB Gábor Lénárt]

Hi Ben,

I have write access to MEGA65/xemu too, so I will merge when it seems to be OK. Just I wrote my note, that others should not merge my repo either till that point. The other point that I have (though more or less untested) binaries for Xemu, for win32/win64 though they're "native" ones, I mean not cygwin etc is used (actually I compile them with Mingw on Linux but that does not need any additional stuff like cygwin DLL or something like that, other than the SDL2.dll). However there is a little glitch there, that debug interface (for m65dbg) is not supported then on win32/win64 because of the lack of Windows native UNIX named sockets. It will change if I switch to TCP/IP sockets then, with more features (what m65dbg will support too, of course).

Currently, I am thinking some very light but maybe quite user-friendly change: to allow to download and "self-deploy" needed files at the first run (honestly, I have not so much plans to implement "low-level" HTTP downloader etc inside Xemu for every supported OS, but using external utility available by default, eg I guess OSX has curl installed by default, and on Windows, maybe powershell Invoke-WebSomething ... I can't remember ... not as nice as it could be, but quite light but still useful addition in my opinion at least). Surely, the proposed license problems are there, but I think, it can't be too serious with things like 8 bit computer ROMs, and anyway, it's downloaded from the net, with the will of the user and I can also warn the user that they will allow the download at their own risk. Xemu would do the download then automatically. For Mega-65 though, an SD-card image is quite large, so there I would ask user if it's ok to download ROM, and may build an SD-card image then using the ROM too. I think this can be useful, as some users may don't want to deal with "image files" and things like that, just expect to use the emulator, and that's all. Surely, if you use -sdimg or other parameter Xemu would still use that, it's only for the default non-overriden config, if no defaults found there.

[LGB Gábor Lénárt]

Hi,

A question, I am curious what others think on this. What would be the better?

To include *all* needed stuff in Xemu binary itself (ie: KS, CRAM utils ...) so everything except for the ROM itself of course (since it's a copyrighted material, and anyway, KS would load that from SD-Card), or not to have anything, and Xemu should load everything from files as most emulator does. The first option is more comfortable (but surely, this STILL allows you to specify your own KS, utils, etc to load in command line!!!), user does not need to figure out how they can get those files at all etc. At the other hand, it's maybe not so nice to have embedded stuffs in the emulator, even if the license is not a problem here (they are from mega65-core, and the source there is available, and also GNU/GPL etc).

If "embedding" stuffs is OK, user need to get the ROM only not too much more. One thing: even now, if there is no default SD image, Xemu asks if it can create one, to help the user. Now, if fdisk etc stuff works out of the box, user can even create filesystem and partitions, etc on it then. With a little addition, we can also arrange, that with valid FAT32 on partition #1, Xemu can check if there is the MEGA65.ROM file on that, and if not, it can ask the user to download at least that at their own, but then allowing and offering to copy the user downloaded ROM image into the SD-card image, so then user don't even need familiar how to put files into a disk image file which is also a partitioned and raw one.

If we don't want to embed stuffs Xemu too much, even not the open source components which can be done on the legal side of the story, then user anyway needs to download a bunch of supporting files to do anything useful with the emulator. Though, it's true, that at least for the "free" files - like KS, etc - Xemu can offer to download them ... so I'm really not sure what would be the best practice to follow ....

I ask this, because I plan to create a new branch in Xemu with the intent to "fix" things for the new KS soon and since Xemu has already has a KS built-in, it raises the question that's it a very ugly half-solution to have KS embedded, but not eg cram utils, and should be unified somewhat to clean the mess a bit ... This is also a common source of problem, that Xemu's built-in KS can be old, and specifying a cram util to load maybe not even "match" with KS Xemu uses ... So I think the only sane solution is not to do "half" things. Either having *all* stuff built-in (of course - as I've mentioned above - they can be overrided still via command line!) or *nothing* and user must have the default files in Xemu's "preference directory" (where the SD-card image and other stuffs are, as well).

[Paul Gardner-Stephen]

Hello,

How about having an environment variable that xemu reads and then looks in that directory for the files with expected names?  That way you can have the comfort, without being stuck with old versions of things.

Paul.

--
You received this message because you are subscribed to the Google Groups "MEGA65 Development" group.

[LGB Gábor Lénárt]

Hi,

Xemu uses SDL2's function to provide a 'storage' to its files, it's up to SDL what it uses on a given OS (ie windows, Linux, OSX), on my machine (Linux) for my user, it's: /home/lgb/.local/share/xemu-lgb/mega65/
Xemu also searches for a "common place" which is also OS dependent but usually read-only and system-wise, ie, in this order for search path (these are not for Windows surely, but UNIX-like systems): /usr/local/share/xemu/  /usr/local/lib/xemu   /usr/share/xemu   /usr/lib/xemu
Surely, the second version is mostly for system-wide installation mostly with objects not needed to write, so not so much for the SD-image.
It would be trivial to override these using whatever way (like an environment variable).

But I didn't mean this way my question now. What I meant, that imagine, a user (new to Xemu) downloaded Xemu for his/her OS. If xemu does not contain KS, pre-initied-character-WOM, and maybe even the cram utils built-in the Xemu binary itself, it won't work at all, so whatever trick we use to say what directory it must search for, user still need to get those files.

However, currently Xemu has a built-in (in the binary itself) KS and pre-inited-character-WOM. So even with *NO* no files at all installed for Mega65 emulation, the emulator will do "something" at least. However the situation is a kinda awkward, since currently it does not contain the "in-CRAM-utils". What I meant: if I include all of these, user will be able without *ANY* data file installed to launch Xemu, and partition + create SD card image (as Xemu can create at least a blank image with only zeroes in it) using the Mega65 FDISK software itself, as it would be a real M65 hardware. No additional file have to be downloaded. Well, except for the ROM image, that's true, and I can't include that for obvious copyright/license issues. But I can help the user to "ask" from him/her the ROM (but then it's not Xemu's responsibility how the user can get that file at all ...) to copy it automatically onto his/her brand new SD card image file. So it's more like a real M65, but more unlike other emulators used to work, ie expecting the user to download all ROMs, data files etc and install them to be able to use that.

Since the current situation is kinda asymmetric (Xemu has built in KS but no CRAM-utils including FDISK) I would like to change this policy, but I have to decide how: let Xemu contain all other components which are allowed to embed (so except for the ROM), so it has got - almost - everything, or purge any "binary blob" (KS, etc) from Xemu's binary, and depends on user download everything needed for work, including the ROM image then too, for sure.

To unsubscribe from this group and stop receiving emails from it, send an email to c65gs-developm...@googlegroups.com.

[Gurce Isikyildiz]

I think in the long-term, it'd be nice to have all of those dependencies either in-built, or easily downloaded automatically by the app.

As I think that's what the average, casual, curious user will be hoping for when they download an emulator, that quick-and-easy, all-in-one experience.

But since most of us that are using the emulator are devs working on the project, I think we don't mind chasing up all the bits and pieces. And being devs, I guess we all understand that it takes time to refine and evolve an app to that level.

So I reckon, yeah, all-in-one is a nice idea, just whenever you have the appetite for it. If there are other xemu tasks that you feel are more juicy and exciting right now, no worries, enjoy them first :)

BTW, I think the latest version of your app has already gotten considerably friendlier than the version I tried a year ago. I appreciated it now offering to make me the sd-card image, and prompting about the files that were missing and what path I should place them into. So I feel it's already taken some steps in this 'friendly' direction :)