Posts by LGB-Z

    Very interesting indeed! Though with some "patchwork" ROM (ie some parts are from older ROM, if I understand correctly) there should be some test if really everything works (well to some extend, even the latest ROM can have bugs of course ...). Also I'm thinking if there exists at least and old screenshot/monitor photo of a C65 running this ROM so we can see the checksum and compare ...

    LGB-Z : Many thanks for your answer!


    I have another question: :whistling:


    Is there currently a way to connect/use the Xemu (xc65 or xmega65) to the net (via the host PC) (by simulating Ethernet or something like that)?

    Yes and no, mostly no ... I mean there is ethernet emulation, but not so much usable because:


    1. works on Linux only (OS specifc tun-tap interface usage)

    2. very bad threaded code, often fails ... :-/

    3. emulates the old ethernet behaviour of MEGA65 not the current design ... :-/

    4. even the problems I've described, the other problem that some may need a bit deeper network administration knowledge to make it work, like creating tap device before, and such


    And sure, since only MEGA65 has ethernet, not C65, only applies to the MEGA65 emulator not the C65. The code should be rewritten because of the problems above. I'm especially unsure what to do with Windows (or Mac) though.

    Xemu supports two SIDs, left+right, though on MEGA65 emulation they're fixed and no mixer abilities. For C65 emulation, is kinda what it should do. Just SID emulation in general in Xemu has the problem that it takes account of SID register changes only at every audio buffer fill, which cause "strange and wrong" results, and absolutely render digi playback impossible ... :-/ at least for now.

    Though I can't speak German, it's important to note, that the official method of Xemu/MEGA65 installation is just using the context menu to "SD-card -> Reformat image" then "SD-card -> update system files". The second procedure will ask you the ROM image. That's all. Surely, formatting the (emulated) Sd-card (thus the image file) can be done with the utility menu as well, "DELETE EVERYTHING" etc, that's true. Btw documented here: https://github.com/lgblgblgb/xemu/wiki/MEGA65-quickstart

    I guess you can 'underclock' a pi 400 as well, in fact, pi 400 IIRC is overclocked pi4, because of having a newer revision of the SoC, allowing that more safely, and also has a huge heatsink metal plate making it safe by default :) About Xemu/MEGA65: as soon as Hernan's changes are merged into the "mainline Xemu" with probable modifications though (optimizations etc), I really want to introduce framedropping to allow to run on slower machines at the price of not every emulated frames being rendered though ...

    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.

    Ah, OK, I see. Honestly I am not even sure what those do :-O MEGA65 has so much registers to implement/emulate ;) The problem with F keys, that usually even emulator users expects F1 be F1 and F2 (on PC) be F2 (on C65/MEGA65), however since PC has keys for all, but C65 kbd uses the C= typical shifted version for every second, I decided to support both usage cases on the PC kbd, thus using up quickly all the available PC F* keys. Other than that, there are some stone age remainment in Xemu being some keys used for special functions by the emulator itself. These problems are more like "how to do the layout/mapping", the first itself, is not though, that's really lack of emulation, indeed.

    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.

    Which features are you missing exactly? Yes, there are some missing parts, but in general C65 keyboard is supported. However some keys are not mapped in the default mapping (you can replace it with a mapping config file), I wasn't able to find a good layout to have all keys, PC has too few keys available :-O

    Nice one, however seriously it's more material for Xemu/C65, for Xemu/MEGA65 I should stick with MEGA65 compatibility ;)

    MEGA65 hardware doesn't support it, and might not for a while, as it requires an extra BRAM. T100 based boards are unlikely to get support for it, due to this. So I'm inclined to just not implement it, since very little existing software (if any) depends on it.


    LG

    Paul.

    Oh, then my memory modules (in my brain, I mean) should be replaced, I thought it's done by mega65-core already :-O

    I was planning to build one :) Do you know some existing project can used to follow to DIY? I mean schematics, maybe even ready to use PCB, though I can design my own PCB, I guess it would not be trivial with my suboptimal experience in the field ;)

    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 believe you, but still the reason isn't - of course - this one not to implement in Xemu right now, but the other things. But indeed, of course that a missing feature must be done some time ... Probably near the time when merging VIC-IV stuffs from Hernan's experiments and my ongoing other changes. Anyway I've booked a new issue 213 in Xemu's issue page, so I hopefully won't forget this one.

    It seems that XEMU does not implement bit 6 (CROM9) of the $D030 (VIC control register A). Same problem with MEGA65 DevKit (see bug report https://github.com/MEGA65/mega65-core/issues/309), also Open ROMs builds incorrect image not providing a character set at $9000 offset.

    I'm aware of that (in case of Xemu), for a long time mega65-core did not implement this either and (IIRC) solved the issue to double the size of the character-rom storage (which is not really the ROM, but an other part of the memory). 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 Implementing this Xemu should wait now, since it needs to alter the global memory mapping also maybe needs a more decent hyppo to initialize (though in theory that can be "tricked") otherwise the "wom" (write-only memory from the view point of the CPU, used as chargen ROM for real by VIC-IV) won't be initialized. However a decent Hyppo update currently won't work with Xemu because of many missing things to be implemented and/or changed in the design of mega65-core since then.


    However that's interesting you tell mega65-core has problems with this, AFAIK it solved the problem already, just Xemu does not emulate that change. Hmmm.

    About a command-line driven solution:

    Code
    1. git clone https://github.com/MEGA65/mega65-tools.git
    2. cd mega65-tools
    3. make bin/m65


    I use this under Linux. No idea about Windows, though. The last line should be "make bin/m65.exe" then, but it fails to cross-compile for me, under linux at least with mingw32. I haven't tried that too much since I don't need the windows version anyway.

    I would say this material in general is very sensitive, I always brake it somehow, and I don't talk about the devkit here (since I haven't ordered), but in general about this material. For example, screwing something too tightly is a great way to crack it. But this was just one example about fasten screws too tightly, maybe that even does not apply to the devkit.

    Plexiglass is anyway very strange material I have not even a single thing which is not broken (at least once, somewhere ...), have some plexi parts and had to assemble myself :-O But at the other hand it's fancy because of being clear transparent ;)

    Hmm, that's a bit problem, I guess, if you go to 40MHz :-O But that's not surprising, more accurate VIC-IV emulation requires much more CPU resources ... Even all possible future optimization, maybe even a newer raspberry pi (like the 400) would be not enough for real-time emulation when all the features (ie 40Mhz too) is used. However framedropping can be also implemented, ie render only every n-th frame, if real-time emulation is not possible.

    Thank you for the answers. I haven't really understood what bitstream is? What does it do?

    Bitstream is what configures the FPGA to behave as the desired hardware wanted to be implemented (in our case, to implement the MEGA65 hardware). So if there is some bug fix, new feature, or whatever, you need a newer bitstream. On power-on, the system loads the bitstream from the on-board flash memory. But that flash memory can be re-flashed for newer bitstream, or optionally as a temporary test or something you can push newer bitstream without flashing it, just trying it etc, but on next power cycle, surely the one from the flash will be presented again. Also in theory, if you someone is keen to do - let's say - a C128 implementation working on the physical MEGA65, it needs the specific bitstream which configures the FPGA to behave as a C128 hardware (but this is a side-topic, and nothing to do with MEGA65 too closely ...). Others may well call bitstream as "firmware", but I really don't like that, since firmware usually means a software, run by a CPU of some kind, while FPGA realizes more like a hardware solution, based on the details described by the bitstream. But anyway maybe that's too much details and care on my side at this point ;)

    Awesome, we talked with LGB-Z many times about some Pi / ARM setup.

    Well, yes, it's an old idea (like Commodore Pi tried to do) to implement a bare-metal emulation to achieve the max from the hardware also giving the impression "no underlaying OS" (in case of Rasp.pi, ususally Linux). But creating a bare-metal emulator means it's the OS as well, and that is, in its own, a whole featured project requires large amount of time (though nowadays we have kinda-ready-to-be-used solutions in source form to implement such things, but still, it's very far from being a trivial problem to solve).

    Just in case you missed it: It has been done for VICE: https://accentual.com/bmc64/ :)

    Yes, I aware of that, however Xemu is very different in its internals so this fact does not help here too much ... Though at least a nice example to show the point, that's true.