Posts by LGB-Z

    Yes, and also it makes no sense to call "junk", if it's really meant that way there is nothing after BEND, they can check if it's the case and actually producing some error. Just silently forget about things is dangerous business at the best, clearly just a workaround to document things this way.

    Great! I've checked the hmw branch, works for me too! Just a question - is it possible to put additional custom file into a virtual SD card (is it emulated at all)?


    I want back to my Z80 simulator - I'm trying to get the Z80 Instruction Set Exerciser Working (implemented a small CP/M simulation, with crude support of the only system call it needs), for now I am experiencing problems with loading the binary from the DevKit SD Card.

    Well, it's an SD-card image file. If you see the output of Xemu (if started from a terminal emulator, not by some GUI ...) it will print where is that file exactly. You need to treat that file as a real SD-card image, it's even have MBR, partitions etc. So in theory, you can use any tools which can deal with image files. Unfortunately there is no true way yet in Xemu to add custom files, Xemu itself can do it, to help people starting (ie it can write the ROM and some other files there, so users do not need to deal with this problem!), but that's a very well fixed scenario only.


    So, you can do that "manually" manipulating the image file (preferably when Xemu does not run ....). Other, not so well tested method is the "virtual in-memory SD-card" feature of Xemu. In this mode, you need to specify command line options:


    -sdimg path_and_filename normally selects the SD-card image you use, however in this mode, it should specify a DIRECTORY on your host OS ("host OS" => the OS runs xemu) AND the -virtsd option (it does not take any parameter, unlike -sdimg) to signal Xemu that you want use virtual SD-card mode. In this mode it creates and keeps the SD-card image in-memory only on-the-fly, by keeping only the already written blocks (thus Xemu in this mode won't allocate 4Gbytes of memory) according to a block-directory object in memory. Also, in this mode, Xemu automatically "formats" and "fdisk" the virtual SD-card, and, given the directory input from -sdimg in this mode, writes those files onto the in-memory disk image. This is intended for developers, so for sure, any modification on the "sd-card" won't be persistent, since the sd-card itself lives in the memory only. However this makes it possible to drop things you need into a directory on your OS, and tell Xemu to use that directory as a source of a "temporary and virtual" SD-card on start-up. But again, I'm not sure how usable that is currently or it works at all ;) Anyway just give a feedback if it does not work, and I'll try to have a look, if you need this feature seriously.

    Doesn‘t the Mega come with some external SRAM or SDRAm?

    No. It comes with something called "HyperRAM". I don't know about the exact details but it's basically something (??) like SPI serial access but with more bits, maybe octal-SPI or such. But still does not have "classical" bus like with usual RAM chips that you have address bus and data bus separated etc (OK, honestly even DRAM chips already have RAS/CAS stuff to deal with addresses, so ... but still it's different). Anyway someone should answer this have more knowledge on the topic than me ;(

    Indeed. I'm still wondering (though I'm not involved in this work) if there will be willpower and time to do ROMs for C65s, ie even real C65 owners able to use that, which then fixes at least some bugs and unimplemented parts of the original C65 ROMs (surely without MEGA65 added advanced features not possible with C65 and this is about speed too, as many of the MEGA65 optimizations is to use MEGA65 specific CPU addressing mode which is much faster than doing MAP all the time, or issuing a DMA transfer just for a single byte [!] in some cases).

    I’m quite sure that the Xilinx FPGA of the Mega65 can cope the the MinimigAGA core, as it still fits the Cyclone3 with 23000LEs in MiST and the even smaller Cyclone4 in SiDi.


    Even RTG graphics was possible to add to the MiST.


    But surely the HDL code needs some adaption and IO might be quite different. MiST(er)&co use ARM CPUs to handle USB devices and onscreen menues.

    I'm really not sure, but maybe the problem is more the memory, that HyperRAM in MEGA65 is not fast enough for that. I would assume, FPGA may be enough for the core itself ... But speaking of its internal BRAM it's not, but surely external RAM is intended to use in this case (I mean external to FPGA ...) but there is the worry than about its speed. Though, I have no idea what speed would be needed for an Amiga AGA chipset implementation from the memory, and if the mentioned HyperRAM is fast enough for that or not ...

    This resulting - I call it - "MEGA65 ROM" (because it doesn't work with the C65 emulator xc65 from LGB-Z anymore) is still in development and I'm glad that I was allowed to take a look at the current state 920116 already.

    I'm sure you got the point but of course it does not work in xc65 (that is, the Commodore 65 emulator in the Xemu project, not the MEGA65 one), as those ROMs uses MEGA65 features does not present on the Commodore 65.

    Great, thank you!

    OK, done. It seems to work. The only problem, that in "baseline" Xemu, VIC-IV things are not so great, so you can see only the upper half of the screen, and using precise video address causes strange effects from time to time. Yes, indeed, it's the fault Xemu (at least the lack of VIC-IV merge still ...). So I've decided to break my own rules, and merge this into the "hmw" branch for now (that is, the mirror of Hernan's branch). Testing with that, the result is much more nature experience, at least at the first sight, and for me. It's currently building (MacOS version is already on the download page, Windows is always slower, not because it's Windows, but there is a huge queue of Linux VMs waiting for boot at Travis-CI nowadays ...), but it will be there sooner or later. Check out the page https://github.lgb.hu/xemu/ and look for the VIC-IV experimental build for now. And sure, it also means, this "hmw" branch though having many VIC-IV things, lack 99% of the Xemu development I did meanwhile (1% being this feature for now, hehe).

    OK-ok, I am not against this of course, quite opposite, I'd like to understand it to be able to emulate! :) That's the only reason of my posts here. A bit confusing for me, as you talked about only $D607 and $D608 before, but now $D613 and $D614 ... Also $D613 and $D614 according to iomap.txt are "DEBUG" only registers.


    As you wrote: "It uses registers $D607 and $D608 for scanning the keyboard (these registers are much more convenient to use than CIA), which are not emulated."


    So that's why I am wonder now how these $D613/$D614 comes here then. Sorry that I still can't understand now the whole picture here :(


    Also, $D611 is more attached to $D610 in my mind, which is the hardware accelerated keyboard scanner (but that uses ASCII values not matrix positions, though indeed, for just $D611, it's nothing to do with that and only shows the state of the "modifier keys"). Btw, $D610 and $D611 is already emulated.

    Ah. That might explain the error! Could it be that BitShifters ROM enables the vic-iv by default?

    It is possible ... Snoopy also had some "binary patches" here for the official ROMs do similar things ... And so on. So if basically this is the problem, it won't work on real MEGA65 either, using "stock" C65 ROM which uses VIC-III (aka "C65") I/O mode by default in C65 mode.


    And one possible trap: I am not sure, but IIRC there is also the "trick" that C65 ROM sets I/O back and forth even in IRQ routine (or just when doing disk I/O? I can't remember ...) thus even if you try to "key" vic-iv I/O mode it may have been reset to VIC-III by the ROM. The same even applies to projects written in assembly, C, whatever, if original IRQ may work in the background. Of course a "patched" ROM using VIC-IV I/O mode always instead of VIC-III would workaround this problem, but it always have its dangers that we forget to set I/O mode and then program does not work with ROMs (including "stock" ones) does not do that (as on C65 of course there was only VIC-II and VIC-III I/O modes).

    IIRC keyboard registers are outside of vic, so they don‘t need vic-iv enabled...

    I don't think it's how it works. It's I/O mode (called VIC I/O mode, that's true, kinda confusing), like even changes how CIAs are decoded for example CIAs has "echoes" in the memory map in VIC-II mode (thus being compatible with C64 in this regard - though I am not very sure about this one ...). And so on. As you can see MEGA65 memory map, the whole I/O area have three instances for the three I/O modes at "very high addresses though". For the "legacy" I/O area at $D000 (if it's visible) you'll see the one corresponding of your actual I/O mode. If you see iomap.txt in mega65-core repo, in theory, all registers in the $DXXX area marked as GS are only available for MEGA65 I/O mode (also called VIC-IV I/O mode), C65 marked ones are in C65 mode (also called VIC-III I/O mode). At least this is how I understood and Xemu at every places on decoding ANY I/O area access works this way. So if it is not true it would have caused already many-many problems everywhere, I think. Maybe it's called "VIC" I/O mode since the register is in VIC to "key" the mode. But even in C65 it's not clear that "VIC is only VIC", see for example that VIC-III can map ROMs ... Which wouldn't be VIC's task strictly speaking.

    AFAIK not anymore. It uses registers $D607 and $D608 for scanning the keyboard (these registers are much more convenient to use than CIA), which are not emulated.

    I'm not sure what it means. AFAIK D607 and D608 are only used to access extra C65 keys over the usual C64 matrix. At this point iomap.txt is totally crazy about these registers I cannot figure out how it should work, as it's already used on C65 for the mentioned purpose, now on MEGA65 it can use for any keys? :-O Hmmm.

    Re Xemu: Eleven uses the keyboard modifier scanner at $d611; I suspect that‘s not yet implemented in xemu, so the alt detection would not work. Maybe LGB-Z can shed some light on this...

    The hardware accelerated keyboard scanner (D610-D611) is supported in Xemu. As far as I know without any major problem (till now?). I even use that feature to test programs of mine using D610. So "it should work" as I usually say. In the "next branch" at the download site, there is one little fix recently that key repeating did not worked, but even without this fix it shouldn't cause not even be able to type at all.

    One small addition, since then, if someone use the "next" branch, it also automatically formats the newly created SD-card image, thus the main part of confusion may has gone. Surely, the adding the ROM process cannot be eliminated easily since it's more a legal issue than technical one (that I cannot include the ROM).

    What are these extra large values in the window title? Is it running on raspberry-pi 400? :) Sounds like Xemu here cannot reach real-time emulation performance (86%, and at least 115% of the current available CPU time would be needed for achieve 100%).

    Hey, it's not 1st of April yet :)


    I was fooled with this one several years ago, though it should have been suspect to have C64 version, ie C65 emulator running on C64, with 6K size of PRG ;) Also I like the list of supported systems for the emulator, MacOS X, but also Coherent UNIX, kinda divergent support ;)

    Now I've got it running on the Xemu C65 too. :)


    The decisive difference was that I've now used the method Snoopy described above, not the way via the right mouse button to load the prototype ROM.

    Hmm, that's interesting. Then it seems, this C65 ROM not properly initializes VIC-III so only loading a ROM run-time causes problem and requires the full VIC-III state to be reset, ie running emulator from the start with new ROM. I guess it relies on some default settings of VIC-III to be there already and it does not set everything by its own?

    The difference can be, that character ROM is not in place in the ROM image ("where it should be"), thus having garbage instead of normal characters on the Commdore 65 emulator. However, MEGA65 works differently, it does not take the character ROM from the actual ROM image but uses it's own area called "WOM" (Write-Only-Memory, funny, but you can really only write and not read, only VIC read it, not the CPU). There is also a bit to tell the source of chargen from ROM, two different addresses, which may not worked the same on early C65 models, and not even implemented in a real MEGA65 and would require double the size of WOM, as far as I remember about the problem. Anyway ...

    It's not impossible that early models of C65 for real have their own "discrete" ROM for chargen, thus not part of this ROM image, or it worked different way (mapped to another address than later C65 models what Xemu also assumes).