Posts by LGB-Z

  • MEGA65 and "Open" Software

    That's indeed a strange view. Linux is free and open source (but surely, we must be careful what "Linux" means, usually only the kernel, or we refer for a Linux distribution more, often mentioned as "GNU/Linux" since many tools/components - other than kernel - is from the GNU project ... though those components are open source as well), but surely there are commercial software for it, you must pay for, and no source code at all for them. In fact, leaving open for commercial titles are important since there can be some bigger projects some people want to have money for. Now the choice: not to allow them, and we will miss those, or have them (but not free) so everybody can decide at least it worth to pay for, or not. I think the second is better. The "platform" being open source it's just the "platform", not the things other people writes for. But as it's said, sure, your colleague can decide if he wants to pay or not for a given a software, there is no problem here. The problem more, if somebody misunderstand things and feels "fooled" that it's a trap: "but it was said it's fully open source, now it's a trap, that I must pay for some software still, after I thought it's completely free and I jumped in the project?".


    In fact, something "being open source" does not mean too much for the 99% of the people, since they have no value on having the source, if they don't know what to do with the source code :) Imagine how much people would use Linux, if they have only source code, and not actual builds, distributions etc (which installers, binaries, packages ...). Also, worth to mention, there are software which are open source, still not free, technically.


    Honestly the logic of your colleague it's like when you're informed there is a free-to-use road built, and then he cries that he needs to BUY a car also the the fuel, it's not open at all ... Surely the software case of this story is still better since there are "free cars" (ie software) to use on the platform, just not all of them are that.

  • ROM legally to buy

    Personally I feel khmm errr indeed almost everybody knows where to download those ROMs free of charge, but if someone wants to be really "nice" and legal, why they just can't pay for it, especially that this way the copyright holder gets some money at least ;) Though hmm maybe that would cause some issues to try to ban "download free" kind of ROMs, if it's official that you can buy it. So I'm really not sure ...

  • MEGA65 ROM Benchmark Results

    These are interesting questions. However as far as I feel, even if it's not the "open-rom" with all the own goodies it's already not "pure c65" ROM, ie using MEGA65 extensions to work, and would not work on a C65. For example, direct manipulating bitplanes are not possible in the C65-compatible way, since those are in bank4/5 now, which is not possible on C65 (and thus meaning some problem if a program directly want to access bitplanes in the memory bypassing BASIC routines to draw etc). Also, kind of "dos wedges" were common even in the C64 era (though indeed, not "original Commodore" things). That's however a good question if there can be a "pure C65 ROM" would work even on a C65 "only" with fixing some of the bugs, and unimplemented details of the original ROM. I can't answer this, but as far as I feel, it's maybe too much to ask, nobody has that amount of time to take care "only-C65" versions when the all project is about MEGA65. But I can be wrong, and I don't mind here at all if I am wrong ;)

  • Pi1541 query

    I would say, it should work, as it "speaks" the IEC protocol like 1541 and other "usual" drives, and MEGA65 also has an IEC port. So in long term, I see no difference between using Pi1541, SD2IEC or "real vintage IEC drive". However keep in mind, that currently AFAIK there are some issues with IEC on MEGA65 in general, but hopefully sooner or later those will be (maybe are? ...) fixed.

  • BBC BASIC for the MEGA65?

    That's an interesting topic. Personally, I don't know too much on BBC BASIC, but AFAIK, RISC OS at least includes ARM variant of BBC BASIC later on. Since RiscOS seems to have even open source version (v5 versions?) under the Apache License, I'm wondering if anybody behind RISC OS "nowadays" may know about more the rights of the 6502 implementation at least.

  • The C65 in the press ...

    Interesting. Judging by the national keyboard printout on the screen, I guess it has a custom charset for German/Austrian which can cause some characters to have different shapes, thus the brokenness of the stripes. But for sure, I'm just guessing.

  • MEGA65 ROM Benchmark Results

    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.

  • Work is underway to make open-source replacement ROMs for the C64

    Quote from FeralChild

    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.

  • Amiga core for the MEGA65

    Quote from RexRetro

    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 ;(

  • MEGA65 ROM Benchmark Results

    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).

  • Amiga core for the MEGA65

    Quote from RexRetro

    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 ...

  • MEGA65 ROM Benchmark Results

    Quote from Snoopy

    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.

  • Work is underway to make open-source replacement ROMs for the C64

    Quote from FeralChild

    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).

  • Work is underway to make open-source replacement ROMs for the C64

    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.

  • Announcing the Eleven Development Environment for the MEGA65

    Quote from ubik

    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).