Hello, Guest the thread was called823 times and contains 11 replays

last post from LGB-Z at the

Xclcd - question about virtual disc

    LGB-Z : I tried your Xclcd emulator for the Commodore LCD from your github site and it works great! :thumbup:


    One question I had about it: Is there any option or menu, where I can use a disc image?


    After start the emulator with ./xclcd.native in Linux (Ubuntu) I can use a "virtual 1541 disc", but all content will be lost after quit the emulator.



    I tried ./xclcd.native --help, but there will be no option for a disc image shown. :(

    Well, it's not so much MEGA65 related to be at this corner of the forum, though I don't mind, just mentioning. The "virtual 1541" just chunk of memory of course. So surely it will be lost, if memory content lost. The original Commodore LCD used a battery to power the RAM itself even if the machine is turned "off", so as long as the battery is not flat, it should keep the content. So yes, you can ask, why I don't just save memory content automatically and reload on next launch of Xemu. The answer, that it never worked for me. Actually I had to patch the ROM, to even work this way how Xemu/CommodoreLCD works now. Honestly I don't know what the exact problem is ... Maybe the ROM code is still buggy (after all Commodore LCD was never finished). What I experienced that ROM actually checks if you hold a key (already forget which) during power-on, and if it's pressed it's reinitialize the whole memory. Otherwise, it should just use the memory content as-is, with the hope that battery really helped to keeping the RAM content intact :) And now the problem: if I do this (ie, allow the ROM code not to initialize the memory, but use as-is with the "kept" content) then very strange things happens, broken menu screen, crashes etc. So I had to patch the ROM to force memory re-initialization and not using memory save/load (ie "keeping it") ... :-/

    Though, it reminded me, I should add an option to skip the ROM patch, even if it does not work well ... (and anyway adding memory save/restore stuff). Btw it would be interesting to try to sort these out if it works at all or no hope ;) Though interestingly (I've just have a look on my source and the emulator itself) I cannot find (and cannot remember anymore) how I can turn off a Commodore LCD in a way that ROM should know it's prepared to cut the power with the current memory image remaining.

    Thanks for your detailed answers! :thumbup:


    If it's a problem with the wrong forum category, maybe adtbm can move the thread? In my opinion, Xclcd belongs to Xemu and Xemu belongs to the Mega65 and ... at the end it's all about Commodore. :D


    According to this C64-Wiki site, the LCD should have a function to copy the virtual RAM disc to a external disc drive:

    Quote from https://www.c64-wiki.com/wiki/Commodore_LCD#Software

    The main menu offered a few utilities for copying from the internal RAM disk to an external drive ...

    I haven't study your xclcd sourcecodes, but maybe it's an easier solution (as the RAM keep/restore routine) to add the possibility of using an external disc drive e.g. as unit 9? I don't know, but maybe you could use some code from the xc65 or xmega65 who can use and attach d81 disc images? An external disc drive would have the advantages of easier exchange and use of datas between the other emulators (xc65/xmega65) or VICE & Co.


    That's only just an idea which came in my mind ... maybe I'm the only one who plays around with an emulator for the LCD, which is even more rarer as the C65, anyway? So it's just an idea for the xclcd, if you feel very very very bored sometimes. :D

    Well, Xemu is just collection of some "random" emulators, actually MEGA65 is just one, and even much more new kid in the family than some of the others :) Xemu itself is not MEGA65 specific as a whole. But I can understand why people think otherwise :) Even not Commodore specific btw ...


    Yes, emulating an external drive can be a solution, just it must be written :) Which is hard with the current precision of that emulation target, as IEC bus implementation need precise timing, and you also need to emulate a disk drive in addition of the computer itself. That's why there is no such a thing for other Xemu emulators either, including MEGA65 (where you can use the IEC bus to connect even an 1541 in theory ...).


    The problem with your theory to re-use code, that C65 and MEGA65 internal disk drive is easy to emulate, as it's just a disk drive can be be accessed directly by the CPU of the given machine, so you don't need to emulate the working of the IEC bus, and a whole second computer (as a commodore disk drive after all is a full computer, with ROM, RAM, CPU, I/O chips ...). Yes, well, maybe it would be easier to actually implement Commodore LCD emulation inside the VICE project, since it already has got mature emulation of external disk drives :) Even just emulate a "dummy drive" (like what SD2IEC does as well, ie not emulating the internal working of the disk drive, only it can speak the IEC protocol ...) requires at least "speaking" the IEC protocol. Honestly I've tried once, many years ago, but I always found that it's too much for me, to ever understand how IEC protocol works, it's just too weird for me, also maybe timing issues was a problem as well, I am not sure. But otherwise you're absolutely right, an emulator is kinda useless if you can't even load/save from/to the external world ... :-/ A generic IEC implementation in Xemu would be very useful, for many emulators, not just CLCD but C65 and M65 as well! In fact even non-Commodore emulators inside Xemu would benefit (for example both of Z80 based Enterprise-128 and the Hungarian primo had interfaces for IEC optionally, in fact Primo - at least some models, not all - has even built-in by default, though missing ROM code to actually use, so you must load the software for it first ...). Also, the IEC implementation could even help to add "printer emulation". Etc.


    Yes, compared to Commodore LCD, C65 is a very common and easy to buy machine :) According to Bill Herd, maybe 4 or 5 units exists in total (he has one, but he even not dare to power it on in the fear to blow something up, funny, once he wrote me, that if I will to sell my house, maybe I have enough money that he at least consider to sell it to me ...). The number of produced C65 units at least in the magnitude of hundred, if I'm not mistaken.

    Thanks again, your explanations help me to understand the difficulties with the programming of the emulator. :thumbup:


    Quote from LGB-Z

    But otherwise you're absolutely right, an emulator is kinda useless if you can't even load/save from/to the external world ... :-/

    Maybe there is a chance with the rs232 connection of the xclcd to simulate a data transfer with external devices? Or using a virtual datasette? :D


    LGB-Z : Thanks again for your time and detailed posts! :thumbup:

    Well, if you're in of ROM debugging business you can try to reverse engineer, how it handles that virtual 1541 "ramdisk" thingy. With that information, it would be kind of easy to implement direct-memory access by emulator to "sync" the state of that in-memory disk with some persistent storage and/or manipulate via Xemu/etc. Currently only a hack exists to allow external program files to load, it works by injecting into memory if you are in BASIC. But it does not solve the "SAVE" question too much, and anyway it's a very crude hack in general ...

    i've moved the thread into the miscellaneous section of MEGA65

    Quote from LGB-Z

    Even just emulate a "dummy drive" (like what SD2IEC does as well, ie not emulating the internal working of the disk drive, only it can speak the IEC protocol ...) requires at least "speaking" the IEC protocol. Honestly I've tried once, many years ago, but I always found that it's too much for me, to ever understand how IEC protocol works, it's just too weird for me, also maybe timing issues was a problem as well, I am not sure


    The protocol is mostly logical (but far from being optimal, unfortunately) - last year Michael Steil did a really good description, see here. But testing the implementation is really time consuming, at least this was in my case.

    Quote from FeralChild
    Quote from LGB-Z

    Even just emulate a "dummy drive" (like what SD2IEC does as well, ie not emulating the internal working of the disk drive, only it can speak the IEC protocol ...) requires at least "speaking" the IEC protocol. Honestly I've tried once, many years ago, but I always found that it's too much for me, to ever understand how IEC protocol works, it's just too weird for me, also maybe timing issues was a problem as well, I am not sure


    The protocol is mostly logical (but far from being optimal, unfortunately) - last year Michael Steil did a really good description, see here. But testing the implementation is really time consuming, at least this was in my case.

    Yes, once I started to do myself (many years ago) but it always locked up. And I was not sure if it's problem of CLCD ROM, or my implementation ... I planned to re-visit this with my amateurish VIC20 emulator (since it known to work well with IEC ...), but somehow never had time to do so, even if you know, that is the reason there is a VIC20-emulator-like-entity :) within the Xemu project by me ;)

    Hehe :) Once I wanted to have (Ubuntu's) launchpad repository registered, and I've learned that xemu is already taken for some kind of (original) Xbox emulator :) Well in that case "X" + "emulator" makes sense at least ...