Beiträge von LGB-Z

Sounds interesting! I have to admit, there can be bug in Xemu too (or at least lack of emulation ...) to have those extended attributes, at least all of them ... So it's not clear at this point if it should work, and only Xemu's VIC-III emulation does not handle it, or other problem. If I have time, I will simply set video RAM / colour RAM manually to see, if I see the desired result at least according to c65manual, since the extended attributes seems to have kinda chaotic, if I remember exactly. But anyway, it's even not sure, that a real C65 would do the same as the M65 FPGA implementation, and then we haven't even talked about Xemu's emulation of C65 or M65 to be precise ...

Sounds familiar, I had my C64 until the point, then a PC was needed to "follow the world" already, and many things missed by me (like C128, Amiga, whatever). Yes, I was also happy with my C64, but I also feel sorry nowadays that I missed other nice "bigger" machines somehow, so ambivalent kind of feeling ...

Interesting, as usual I'm more in the hardware itself, I didn't even know about the process you've described above ... I guess it would be interesting for others too, if you have some posts about it in the future?

I've just tested that TAB works now (and btw I have to move restore to pageDown, since TAB was used that purpose ... for more, see the mentioned keymap-default.cfg file in the preferences directory, or the source file xemu/c64_kbd_mapping.c).

If someone feels adventurous, the "dev" branch of Xemu on github can be tried (now just from source ...). Currently it has some preliminary support for custom keymaps. On startup both of Xemu/C65 and Xemu/M65 emulators creates a file keymap-default.cfg in the corresponding "pref" (preferences) directory for the C65 or the M65 emulator inside Xemu (preferences directory is platform/system dependent but can be read in the console/terminal, "SDL preferences directory: ..."). That file must be copied, and then customized (the default file is overwritten by Xemu at each startup!!!), and either be loaded with the -keymap option, or can be renamed to keymap.cfg in the same directory to load automatically without any option.

Also, there is preliminary support for extra keys of C65/M65 (over C64 keys, I mean). Some of them are not-mapped by default, but can be done with custom keymaps. See also the comments in the keymap-default.cfg.

Yes, it's still a bit hard to configure Xemu, since it's a config file based scheme, and you must know the SDL scancode names, etc, to be able to do that. But at least, if there are some useful layouts, it can be provided to download for users then, which is still better than modify Xemu source and recompile ... The GUI component of Xemu to be able to configure this graphically would be currently hard, since literally there is no any GUI in Xemu, just a single SDL window ... That would require a ton of works, and also would be not platform independent (ie, Windows, Linux, Mac ...) or a full GUI framework should be developed and/or utilized on the top of the SDL2 ... :-O

Yes, exactly I wanted to mention section 1.5.2 for example, just I had to go to the playground with my kids meanwhile

However, what I wanted to say with all of this: at least for me, at the beginning it was confusing to see monitor addresses like 806000 (hex), I thought since it's longer than 16 bites, they are linear (ie: physical) addresses but they are not, they are just a composite number consist of two hex digit bank number at the beginning, and not so much a direct connection with the corresponding physical address. Honestly, I would prefer a monitor using physical addresses (at least AS WELL). Maybe there is a way, just I am not so much familiar with it ...

Honestly, I don't know too much about C65 BASIC and monitor. All of those seems to have some kind of BANK notion which is not the very same as the MAP thing at all ... There is even the BANK BASIC keyword, which can tell what BANK is used with the next POKE/PEEK (maybe SYS too?). Probably some kind of similar things exists in monitor too. What is my feeling here that "BANK" is simple a pre-defined memory layout for certain modes, even the c65manual.txt have "pictures" on those layouts. The same text says about the BANK BASIC keyword:

I don't think it's directly connected with MAP or anything, it just causes the system sets the desired configuration according to BANK before doing the PEEK, POKE etc commands then ... But I can be wrong ...

Zitat von Gurce

Oh, another Q came to mind. Is there any way to ask the CPU what areas of the cpu-address space have been mapped, and their offsets?

I don't think so ... Especially not on C65. For M65, it would be possible to add some IO registers to query the current map mask and upper/lower offsets, I guess, but at least I am not aware if there is such a feature implemented (M65 itself knows it, because eg hypervisor enter/leave needs to restore MAP settings and probably the freezer functions as well, but I don't know if it's possible for a program to query "itself" too, if you get my point here). Paul may be the only one who can answer this for sure.

It depends what you think on that notion. For me, mapped/not mapped is simply a bit information being a block marked as mapped (so, subject of MMU translation) or not mapped (subject of C64-compatible mapping only but not by MAP instruction!). For _addresses_ themselves, I like to refer them "CPU address" (any address generated by the CPU, so 16 bit by its nature) and "physical" addresses, ie the global memory layout of the machine. Just we must be careful here, even C64-way of "MMU" (CPU port @ addr 0/1) results in CPU_address - physical_address translation, just it's different than the one done initiated by the MAP instruction ... And again, VIC-III ROM mapping is another layer, which overrides everything. So in order of priority:

1. if CPU address refers to a memory area subject of VIC-III ROM mapping, _AND_ $D030 VIC-III register instructs the mapping actually, then the physical address is calculated according this scheme.

2. if the previous condition does not apply, 8K block of the CPU address is checked if it's set to '1' (mapped) or '0' (not mapped). If mapped, then the CPU address is added to an offset ("upper" offset if the CPU address is the upper 32K, "lower" offset if the lower 32K) but excluding the lower 8 bits of the CPU address which is "pass-through". The generated address will be the physical address for the access at system level.

3. if even the previous condition does not apply (ie, not VIC-III ROM "mapped", and 8K memory block is marked as not-mapped by MAP instruction), then the address is subject of the C64-style translation only, so it's done as it would be a Commodore 64, with CPU I/O port @ 0/1. Still, the result in physical addresses is different than a C64, since the construction of the machine is different, but from user point of view at least (what the program "sees") it's the same process.

This also means, that if you want to access I/O area at $D000, it can be done to set non-mapped for that block via MAP instruction, and set 0/1 CPU I/O port which enables the I/O area. This is the only way done by the CPU you can access I/O on C65 (you can do it via DMA though, but that's DIFFERENT, since DMA does not apply the CPU's memory mapping!!!!!!!!!). On M65, the situation can be resolved other way too though (which is not possible on C65). On M65, the actual I/O area (areas ... since there are some, for each I/O mode, let it be VIC-II, VIC-III or VIC-IV ... according to the VIC "key" register) is for real, can be seen as a part of the physical address space as well, though, for that you must either use extended MAP functionality to set the "megabyte slice" for the mapping, or use can instruct extended DMA stuff to address it, or you can use M65's linear addressing mode to generate direct physical address by the CPU itself, without any MMU scheme or such applied. But these are M65-specific, and cannot be used on C65 (you can still use C65 to set DMA to address the I/O space _only_ regardless of anything other). Yeah, I admit, it took a while for me too, to understand all of these, but I had to understand everything well, to be able to write (a working ...) emulator

No-no, don't worry, I didn't say that your wording was wrong. Maybe that's the "official" way. I just told, that for me at least, it's confusing and easy to mess it up, and being lost through the explanation then

But basically what I see, that physical_address = offset + cpu_address, where physical address is the "physical_address" is the "output" of the MMU process, and "cpu_address" is the input. So I guess if you want to "see" a given physical address @ block 1 (from $2000), then the offset should be of course $2000 less, than the physical address .... Since then adding together will form the desired result. But that also mean, that any block then set to '1' in mapped register would use the SAME offset to be added, so you have no arbitrary choice to map blocks for the other mapped blocks in that region (upper/lower). I guess the whole lower/upper blocks are just invented for this, to ease the problem that you have a single common offset, so now you have at least two. But those are strictly separated as lower and upper blocks. In my examples, I assume, offset is simply added, though it's not true, since MMU does not ever alter the lower 8 bit of the cpu addresses, so addition of the offset for real is done only on bits higher than 7, the low 0-7=8 bits are "pass-through" at MMU level. I just excluded this fact for making my point more clear, or such

And for sure, this only applies if other condition applies. Ie, as I've told, if VIC-III ROM mapping is active on a given address, it overrides all of these ... Mapped or not mapped!!! If NOT mapped, then C64 memory "scheme" is active, so there is still a some kind of "MMU" in the picture here, but not C65's (MAP) anymore, but the usual C64 (involving CPU I/O port at phys address 0/1 as we all know) ...

My initial motivation for key mapping was to try to arrange keys resembles the "look" of a C65 keyboard by key positions, and/but using different positions when it was not possible to do so. '+' was placed to "Insert" as there was not enough keys in a row on a PC keyboard mimics the C65 look ;-P So that was so simple theory, but indeed, hard to remember then, even I can't find sometimes :-O

The mapped/non-mapped bit - field is indeed a bit field. It tells which of the 8 of 8K-length blocks are mapped or not. Surely, you can set any number of bits to '1' for being mapped, or '0' for not-mapped. Not-mapped means that there is no modify of the CPU address. However you would think, the same applies if it's mapped, but offset is zero. Still there is difference, if a block is not-mapped, the "C64 compatibility" settings would apply, ie the CPU I/O port 0/1 (which is part of VIC-III on C65 for real, not the CPU if I remember well, but anyway) and also the presence of the I/O @ $D000 (if "C64 style memory setup" requires it). While, if you set up mapped to offset zero for all RAM, you always get only full RAM (regardless of the state of CPU port 0/1). Another complication on the C65 memory management, that VIC-III has some bits (in register $D030) to map ROMs which overrides both of the map/not-mapped state, and the CPU port 0/1 things.

The eight blocks are divided into 4-4 "lower" and "upper" blocks. As far as I can tell, I always thought this is only because to apply different offset registers for mapping, and there is no other difference or reason, that they're separated as "lower" and "upper", the very same otherwise. It also means, if the mapped bit field is (let's say) 11000011 then blocks 7, 6, 1, 0 are mapped (where you see 1s), but since block 7,6 is the among the upper blocks (7-4) they use the upper block offset, while for blocks 1,0 (3-0) they use the lower bit offset to map them.

Personally I find it a bit "hard to understand" to have sentences like you wrote: "if mapped-address = $FC000, and we want it to go to the non-mapped address of $0000"

I always think in "physical address" and the input is the CPU address, which is translated as-is if block is not-mapped (and applying the CPU port btw!!!!!) and to the mapped state calculated with the corresponding offset (lower or upper block). In Xemu, I have physical addresses, and CPU address is mapped to physical addresses by checking the block is not mapped or not, then for not mapped applying the possible effect of the CPU I/O port, and adding the offset if mapped, and oh yes, first of all, even before these, checking VIC-III ROM mapping bits. Then the final generated physical address is checked, what is there at that address in the physical address map. The very same for both of C65,M65, just in case of M65, the physical address map is 256Mbyte width (28 bits).

A while ago, I wrote some kind of blog entry on how to emulate (in Xemu) C65's memory mapping scheme btw, if someone is interested:

http://cubed-borka.blogspot.co…ms-with-commodore-65.html

The major difference between M65 and C65 for the user's perspective of the "real" machines is the "select 1Mbyte range" stuff on M65 (given by the much bigger "physical" address space of M65 ...), and from Xemu's perspective it's the implementation is being different in Xemu but that's because of performance reasons (C65 emulator in Xemu is just OK, to have a nice to follow but slower code, but for M65 emulation it would struggle on slower PCs to keep the desired emulated CPU speeds ....).

I'm not sure I understand your question in relation of offset ... As far as I can see (and remember !!!!) basically this "MAP thing" only adds a given offset to any CPU address which belongs to block marked as MAPPED, and leave it alone if it's zero (not-mapped). There is also the upper/lower blocks, that just give which register to add if a block is mapped. I guess (but I can be wrong!!!!) you have the assumption that you can set different offsets for each block, buy "calling" MAP opcode with one block set to mapped only etc. This is not the case, mapped/non-mapped is a bit-field, if a memory block is mapped, then offset register (lower and upper) is added to the CPU address, that's all. So, if you have block #3 ($6000 CPU address) and you want to "see" some address space there, you must be careful, that the CPU_addr+OFFSET will be mapped, taking account the $6000 as well, when you contsruct your offset. Also, this means, that now you're "fixed" that you can't map other blocks in the lower area to different physical addresses than what you got from these offset ... If you need different, you must use one block from the upper blocks, since it has different offset register, and thus you can do it.

I'm not sure I could explain this in a sane way, sorry about that

Quick google search for "sdl2 kwin crash": https://kde-bugs-dist.kde.nark…-manager-function-weirdly

Interesting, but this bug seems to be 3 years old, so maybe not this very same issue ...

But the bug is responded to be "normal" (???) and suggest to add some rule for kwin or whaterver. Maybe interesting to try? I have no idea, I've never used KDE to be honest for longer than few minutes ....

Honestly, then it's not an Xemu but SDL relatied issue. Maybe also affected by the fact that you're using some kind of VM, "under" it, then the OS, then the SDL layer. SDL_CreateWindow is kinda standard call by SDL apps general, not only Xemu. But to answer your question, no I haven't seen anything like that, though I only tried native Linux OSes, not inside a VM, that's true ... You may want to try other software using SDL2 (_2_ is important) to have the same behaviour or not, to see if it's SDL/VM/whatever related ... currently, this is my only guess as a starting point. To know more, it would be interesting to see running Xemu inside gdb (with debug symbols built) and have a bracktrace on the crash ....

I thought it can be a problem, if no D81 mount request from KS, nothing Xemu can "hijack". And the only reason I can think of not having it, is the missing or bad default D81 on the SD-card image (bad can be, even fragmented - in term of FAT - file thought the filesystem). But then well, it seems the missing MEGA65.D81 is the problem (btw you can change to anything, maybe only the file size matters and the non-fragmented FAT cluster chain, but other than that, if it's a bad D81, it just caused C65 DOS can't handle it ... and even that, external -8 trick would work, since that overrides the SD-card content for the D81). One of my plans to extend Xemu/M65's ability not just create a blank SD-card image file (it it's not there) but allow to place the needed files on that by itself, maybe even the ROM file (though the ROM content itself - since it's copyrighted/etc - must be provided by you on a request, or something similar).

Sure thing. I just mentioned the possibility to "mount" a single PRG file, that it can be useful to test a program being developed which is only a single file, and similar cases. Of course it does not help, if you need more files, proper disk image, etc, etc, that's true, for sure!

Wow, great idea, I almost forgot about it, that its author is Hungarian as well (like me) and had some private mailing on it, and also some bugs with 16 bit relative jump opcodes, if I remember correctly now.

Indeed, it sounds nice, if some want a quick and simple solution, honestly, I still prefer workflow with having separated linking stage and such, but for many and/or for more simple project, tass may be far easier to deal with, excellent post!

Zitat von Zaadii

On my system it just works like this:

"C:\Users\Sadi\Documents\Eigene Projekte\C64\C65\xemu\xc65.exe" "C:\Users\Sadi\Documents\Eigene Projekte\C64\C65\xemu\condisk.d81"

Might be the problem comes from the d81-image.

I have created it with DirMaster v2.1.

That's the C65 emulator not the M65 (Mega65) they works differently, on C65 emulator inside Xemu, the F011 FDC is a "real" entity fed with the disk image, while on Mega65, it's "virtualized" and "mounted" from a continuous squence of blocks from the SD-card. Also, I think at least, you missed the -8 option before the D81 path/filename.

But anyway, you have actually the point here, that it must be known, what it means "it does not work" exactly, it can be multiple totally different reasons.

Also btw (not so much this problem, just I mention it), Xemu supports giving a PRG file as the disk image, in this case, Xemu converts "on-the-fly" the PRG file as a "virtual D81" image, so you can see it as a disk with a single file on it (the PRG file) from C65 or M65 emulation of Xemu (this feature should work in both of them btw).

Just to show, here is a fragment of Xemu's output (the first unaligned access is probably normal, I guess it's part of KS test for SDHC mode test):

As you can see, there is a "mount request" with val=0 (that is the 'data' variable you see in the code), and it's normal. But then, KS gives a mount request (value 3). Since I use -8 option, Xemu overrides it with external source for the disk content. However if KS does not even try to mount the *INTERNAL* and default D81 image, Xemu has no chance to "catch" the val=3 mount request, thus, it won't work for sure.

Hi Gurce,

First of all, if "internal" mount works (ie the MEGA65.D81 on your SD-card image file) works, the external D81 mount should work as well. Basically what Xemu does, is the very same in both cases, only if "external" mount is requested, it dispatches the F011 FDC block read/write callbacks to external file, otherwise to the given offset from the emulated SD-card. So Xemu basically just "cheats" here, "hijacking" the normal mounting mechanism (it ignoring the D81 offset for SD card access and force all read/write calls via the emulated external callbacks ...), KS/M65 still thinks that the regular and normal MEGA65.D81 is mounted from the SD-card image. Surely, it can be a problem, if you don't have a MEGA65.D81 (or to say: the default D81 on the SD-card - image, in case of Xemu), since then KS won't try to mount on "boot", so no chance to Xemu to "catch" the "mount request" and "hijack" it. Are you sure, the default D81 on your SD-card image is there, and it is really mounted, without the -8 option? Because if it's OK, using -8 should work at least, for sure, if the given path+filename after the "-8" option gives an existing, real and accessible D81 image. If even the default D81 *internal* mount (from SD card image) does not work, then external (with option -8) would not work either, no wonder, then that issue must be targeted first.

If this does not help, as always, I would like to see all of the output of Xemu from the beginning in the terminal/console. The purpose of those messages exactly to help to find the possible problems, even if some of them seems to be completely meaningless for most people, excluding me, who wrote the code ;-P

I'm not sure if it's useful what you've found. Maybe that is totally legit, and KS wants to "detach" the possible already mounted D81, and the real mounting would follow, when data variable is not zero then, but you found the previous request, not the actual "mounting" one.

Zitat von sausage

This is definitely tricky.

For function keys, it would be possible for F2 to be accessed by both F2 on the PC as well as Shift + F1 on the PC.

Currently, this is the situation. PC F1 is mapped as M65 F1, F3 as M65 F3, etc .... PC F2,F4,... are mapped to M65 F2,F4...+Shift pressed. Thus, pressing PC key F1 with shift has the very same effect as pressing only F2 with or without the shift, since it's "virtually pressed" anyway. The same way, as cursor up and cursor left is just shifted cursor down and cursor right (though these at least are existing solutions even on C64 for real this way, while with function keys, it's just Xemu does the same not a real C65). Though, this "wastes" available PC keys to be mapped a lot, for function keys, and those are hardly used in my opinion most of the time. So maybe it's better to stick with F1,F2,F3 PC keys to be mapped as F1/F3/F5 ... even if it looks strange we don't run out of keys.

ANYWAY. I think maybe with configurable mapping, it just matter of the user what's used, and maybe just it's me who makes this topic a so huge deal, when it's not ... ?