Hallo Besucher, der Thread wurde 17k mal aufgerufen und enthält 113 Antworten

letzter Beitrag von Freddy am

Mega 65 emulator

    Freddy On C128 it loads the boot sector of the disk (track 1 sector 0). On C65 for the same action, BOOT SYS must be typed.


    On C65 a single BOOT command is only a shortcut replacing RUN"AUTOBOOT.C65*". Thus the same syntax hides different operations on both machines (also performed at the powerup).


    However BOOT"filename" should work the same way everywhere (and it does work the same as well indeed, except in XEMU for some reason I don't know).

    Hi rosettif , not sure, if i understand your problem correctly.


    On the C65 and the MEGA65 you rename the programm on the disc you want to autoboot into "AUTOBOOT.C65".

    When switching on the C65 with the disc inserted, it will automatically, without an extra command load and start the program.


    If your MEGA65/C65 is switched on already and you insert then a disc, that contains an "AUTOBOOT.C65" PRG on it. than you can use

    the BOOT cmd to launch the autoboot prg.

    (In the attached screenshot, i have interrupted the loading process with RUN/STOP to take the picture).


    Does this helps you ?

    That's interesting, especially if LOAD + SYS works (but BOOT does not), since then it seems ROM does something stupid. The "DMA writes its own registers"means that DMA was instructed of a memory transfer, where the destination hit the DMA registers itself, thus creating a kind of recursive problem. I would have the idea that the program would use an older DMA chip revision than what is currently emulated, but it cannot be the case too much, if it works with LOAD + SYS otherwise.


    Does it happen always even very different PRG you want to BOOT'ed?

    I tested this behaviour with a little program to change the background to light blue. It's the same error as described above.


    Here is the program from $1380 to $1385 to change the background color in $D021 to 3:



    It's saved as "BACKGROUND" on the attached disc image.


    Here is the result with "LOAD" using xc65:



    And here the result of using the "BOOT" command:



    Using xmega65 shows the same behaviour:



    Zitat von LGB-Z

    That's interesting, especially if LOAD + SYS works (but BOOT does not), since then it seems ROM does something stupid. The "DMA writes its own registers"means that DMA was instructed of a memory transfer, where the destination hit the DMA registers itself, thus creating a kind of recursive problem. I would have the idea that the program would use an older DMA chip revision than what is currently emulated, but it cannot be the case too much, if it works with LOAD + SYS otherwise.

    This is why I mentioned I tried both the earliest and latest Kernals (910111.bin and 911001.bin), since the first one relies on the older, while the other on the newer DMAgic (Rev2 vs. Rev5 motherboard). The result is the same with both of them. But when I start up the MESS emulator with the very same two Kernals, both of them are working well.


    Thus, at least one of the two emulators must be false somewhere. (Maybe MESS is too loose and so unintentionally "fixes" an old hardware problem and lets it go; and/or maybe XEMU does something wrong.) It depends on the behaviour of the real thing.


    (By the way it's an interesting side question, how can the DMA come to write its own registers? I guess it always writes to RAM, and the registers are not in RAM, but part of the I/O area, so they can't be reached this way.)

    Zitat von rosettif

    This is why I mentioned I tried both the earliest and latest Kernals (910111.bin and 911001.bin), since the first one relies on the older, while the other on the newer DMAgic (Rev2 vs. Rev5 motherboard). The result is the same with both of them. But when I start up the MESS emulator with the very same two Kernals, both of them are working well.

    Yes yes, I noticed the intent, just it was my first thought, what I also noticed at some cases, but it does not seem to be the case here, of course.

    Zitat

    Thus, at least one of the two emulators must be false somewhere. (Maybe MESS is too loose and so unintentionally "fixes" an old hardware problem and lets it go; and/or maybe XEMU does something wrong.) It depends on the behaviour of the real thing.

    Indeed, I'll check it on a "real" MEGA65 at the evening.

    Zitat

    (By the way it's an interesting side question, how can the DMA come to write its own registers? I guess it always writes to RAM, and the registers are not in RAM, but part of the I/O area, so they can't be reached this way.)

    No. Even on C65, there is a bit in the DMA list telling that you want to target memory or I/O space. On MEGA65 it's even more flexible since there the I/O is memory mapped, though in a high memory address, near the end of the 28 bit addressing space (though in our case it does not sound MEGA65 specific at all, for sure, just I mentioned to be more complete). Actually it makes sense, for example you can quickly fill palette registers with DMA, and then on C65 you need to address the I/O space. There can be other cases as well, when it's useful.

    Now I have tried out the small test program uploaded by Snoopy (thank you, Snoopy!) and have got some interesting results:


    1.) If I simply try to start it with BOOT"BACKGROUND", then nothing happens here.


    2.) If I start it with LOAD + SYS, then it runs (the background gets coloured).


    3.) And here comes the interesting part: if I first start it with LOAD + SYS, then reset the emulator, and afterwards type BOOT"BACKGROUND", then it works again! (Because the first loaded code remains in the memory and can be started again.)


    Thus it gives a clue what's going on. At the end of BOOT command it jumps onto the start address for execution (like SYS), so that part is OK. However, still beforehands, while loading, the BOOT command either does not load anything from disk, or it loads that into somewhere else in memory. And that must be because of the DMA: probably the DMA writes into some wrong place.

    Hi,

    to help a bit, i've tried Snoopy s test PRG now on the real MEGA65 and i can confirm, that it works as intended.


    LOAD & SYS changes the background color


    Boot"Background" does the same.


    Thanks, so no need to wait for the evening when I get home ... Then it seems to be a strange Xemu/F018 emulation bug. Not so much even a clue what can cause this, but anyway, this is already something ;)


    By the way, have you also tried to power-off, power-on (so surely the memory is "empty") and then using a BOOT-method _only_? So we can filter out the possibility that the previous try with LOAD/SYS already loaded into the memory, so about the scenario what @rosettif also explained here.

    Hi LGB-Z ,


    Zitat von LGB-Z

    By the way, have you also tried to power-off, power-on (so surely the memory is "empty") and then using a BOOT-method _only_?

    Yes, i did both variants with a full power cycle before testing.

    So getting the emulator to work.

    I first downloaded the Hernan's installer to get the VIC-IV stuff, but it boots to a black screen and nothing else. So I went back and got the normal stable one and installed it.

    This went a little better as I got some text on the screen, I did the config and then formatted the SD image ( Hernan's did actually make one it seems ) and then it tells me to remove it, copy a rom onto it and put it back in.

    After searching here to find the img's location ( turns out its AppData/Roaming ) and then hunting to find the actual mega65.rom (for those that come after the actual link is https://github.com/MEGA65/open…6c28125bc98aff4b2edff/bin ) I now have no way of getting said rom into said img. As Windows says the image is corrupt so it won't mount it. There is talk of "Use the UI" only X-EMU doesn't have any.

    Zitat von oziphantom

    So getting the emulator to work.

    I first downloaded the Hernan's installer to get the VIC-IV stuff, but it boots to a black screen and nothing else. So I went back and got the normal stable one and installed it.

    This went a little better as I got some text on the screen, I did the config and then formatted the SD image ( Hernan's did actually make one it seems ) and then it tells me to remove it, copy a rom onto it and put it back in.

    After searching here to find the img's location ( turns out its AppData/Roaming ) and then hunting to find the actual mega65.rom (for those that come after the actual link is https://github.com/MEGA65/open…6c28125bc98aff4b2edff/bin ) I now have no way of getting said rom into said img. As Windows says the image is corrupt so it won't mount it. There is talk of "Use the UI" only X-EMU doesn't have any.

    To get the UI (in the form of a pop-up menu): right mouse button click into the emulator window. https://github.com/lgblgblgb/xemu/wiki/MEGA65-quickstart


    If it's what you mean as problem. In fact, you don't even need to know too much where is the image, or anything like that, it's enough to use the UI menu.


    However, I have to admit, I am not so good to write documentations, error messages, etc, so maybe my style is confusing here, and within Xemu as well, or at that document, I mentioned here (the mega65 emu quickstart github repo wiki link). So feel free for suggestions, if something is not clear.

    so when you focus the window ( you need to click on it or the icon in the taskbar which has the same outcome) then press both shifts, then you can then right click and get a menu.

    So then I was able to add the file and now I get a MEGA boot


    Is there a way to disable mouse capture?

    But why do you need to click at the first place? Maybe that's only me, but I never click for focus, that's for ALT-TAB is for (but that's true I use Linux and not Windows, I guess it works there too). And if you really need to click to focus, it's better to click on the title bar. I mean these as a general thing, not only with Xemu, as you cannot predicate the effect a click would do within an application window, you see with Xemu, it enters into mouse grab mode. ;)


    No, currently not, but never heard problems like this from anyone, so now I consider to add option to disable mouse grab mode! Thanks for your suggestion.

    as I have windows, I have a lot more applications. So I have 3 monitors, 13 applications for 23 windows open at the moment(I running a bit lite at the moment). Alt+Tab is not the ideal method for switching between what I want quickly. Although Win+Tab does help sometimes. Click on large window that has thing I want is ;).Clicking on the title bar would usually require some masOS window shuffling. Windows likes to spawn sub windows in the background a lot, since you start with a terminal window then spawn a separate one, its not always on the top or focused.


    Since there is no cursor on the screen its hard to tell it has actually stolen it. It make no sense as its a text window.


    The text that tells you "press shift to disable" is fine on the blue background, but when you first set up the emulator you get the white text on black of which the pop up text is utterly unreadable. I would set mouse cursor capture disabled by default and have it enabled manually. This way it will be a lot easier for people going through the set up process.