Hallo Besucher, der Thread wurde 28k mal aufgerufen und enthält 227 Antworten

letzter Beitrag von LGB-Z am

XEMU - VIC-IV implementation update

    I've got a problem with changing screen viewport. I mean - I can change the character data start address by altering $D060-$D063, but I don't know how to change colour memory start address; altering $D064-$D065 does not seem to work.

    To see the problem, get a test MEGA65 ROM from https://github.com/FeralChild64/open-roms/tree/master/bin and do the following:
    - type GO 65, confirm
    - scroll screen downwards using the arrow keys (you can scroll it back with up arrow too) - you'll see characters being scrolled, but colour attributes stay in place

    Just please don't press RETURN while in MEGA65 native mode, the CHRIN is not adapted yet, so the results might be unpredictable.

    Zitat von mega65

    So you know there is only 32KB of colour RAM? You can only choose the offset within that 32KB range, not put it anywhere. The colour RAM is its own RAM area, but the first 2KB is mirrored on top of the top of the 128KB at $1F800-$1FFFF. (Note that some models may have 64KB of colour RAM.)


    LG

    Paul.

    I'm not sure though, that Xemu (if the question was in general or in relation of Xemu ...) supports "precise address" within the colour RAM. Actually I am sure it does not, however what I am not sure if Hernan's branch supports it ...

    Yes, I'm aware of the 32KB limitation (I'm using $FF8xxxx addresses, not the 2KB window) - I just need 12KB or 16KB (for 80x150 or 80x200 virtual screen, haven't really decided yet). It felt strange to me, that I could adjust screen memory up to a single byte, while I couldn't do anything with the colour memory offset, it behaved as it was always 0. OK, not a serious problem - for now I'll set the virtual screen to 80x25, this will eliminate the need for using non-zero colour memory offset.

    What about DMAgic extensions described here: https://c65gs.blogspot.com/201…controller-interface.html - are they emulated? I was planning to use them for scrolling.

    Zitat von FeralChild

    Yes, I'm aware of the 32KB limitation (I'm using $FF8xxxx addresses, not the 2KB window) - I just need 12KB or 16KB (for 80x150 or 80x200 virtual screen, haven't really decided yet). It felt strange to me, that I could adjust screen memory up to a single byte, while I couldn't do anything with the colour memory offset, it behaved as it was always 0. OK, not a serious problem - for now I'll set the virtual screen to 80x25, this will eliminate the need for using non-zero colour memory offset.

    What about DMAgic extensions described here: https://c65gs.blogspot.com/201…controller-interface.html - are they emulated? I was planning to use them for scrolling.

    The fixed colour RAM thing in Xemu is from the era when it emulated only C65. That was rewritten and later forked inside the project by me to have MEGA65 emulator as well, now they are separated entities. But it also means, there can be cases where I forgot and/or had no time yet to modify things for the MEGA65 way. This is the first category, honestly I haven't even noticed YET, just now as you wrote about it. Though I cannot say anything about Hernan's work, again YET!! Part of the summer and holiday madness (I mean, at my side ...), he did most things alone in relation of some great VIC-IV better emulation goodies, but hopefully in the near future, these works will find its way in the main Xemu repository with possible modifications/optimizations etc, but of course it's still very important to mention how nice that he experienced with this topic a lot so now even I have much easier task to see these things from the viewpoint of an emulator.


    About your DMAgic question: yes, it should, at least Paul's nice MEGAMAZE experiment uses many MEGA65 specific DMA tricks, like adjustable stepping and even fractional stepping which works in Xemu. However again, MEGAMAZE does really work in Hernan's branch more, but not because of the DMA, but because of VIC-IV related things. What Xemu misses in DMAgic emulation, is the transparency stuff, now I can't mention more missing DMA features in Xemu at least (though it's possible there are more issues just never met problems, of course ...).

    Hi LGB-Z and hernandp,


    since i also watch the XEMU progress for a while now and even if i am involved more with the MEGA65 R2 & R3 QA,

    i am astonished by how well XEMU developed.

    And i am absoultely certain, once you've been able to merge both branches into one, you can even work more effectively, since you both are working then on the same built.

    It is great to see, how you both team up !

    While the XEMU emulator constantly evolves, Hernan just posted a nice video,

    showing the Raster65 Demo for the MEGA65 running on EMU at same speed.


    Have a look

    Xemu Update 200826

    Hi Friends. Another work-in-progress update you can get from my megawat branch repository and soon from the LGBs experimental "VIC-IV" binaries.


    This version of the emulator is the first to offer full-frame rendering (at 50/60fps depending on video mode) with better timing , allowing to run e.g: RASTER65 at full speed. Due to this you will notice higher CPU consumption when the emulator is booted up, but the top CPU usage wont differ -relatively- too much.


    Exiting the emulator will yield some performance stats, which may have great variance due to operating system scheduler influencing, but it will give an approximate idea of performance. Frame skipping is not available but will be included if you are CPU-performance limited in some scenario. Here are my own benchmarks https://github.com/hernandp/xemu/wiki/Benchmarks . As I expected, both RASTER65 and the Owl Demo will peak at 40-45% CPU time in my system, averaging 30% which is fairly good by now (expect many optimizations in the future).


    Other enhancements you will see:


    * C65 cursor keys work again.
    * -prg command line will inject & boot a program now (you may need -go64 if required)
    * COLPTR color RAM offset works.
    * If a sprite has MULTICOLOR and 16COLOR modes selected, MULTICOLOR takes precedence.


    As always, report back any issue you find.


    Thanks and have fun,
    Hernán

    This really is great and groundbreaking work!! I used all the tricks I could think of in that little demo and was expecting that it would take ages to run on the emulator! The Emu team rocks hard, thank you @hernandp and @LGB-Z !!


    cheers

    deft

    Snoopy That one was good.:thumbsup:

    I tried this emulator and the progress is very good.

    Thanks LGB and Hernand for the good work.

    But on youtube videos i saw Paul playing games on mega65 in c64 mode.

    I tried it in the emulator and it seems, that no C64 games run on it.

    Some games won´t start, other games starts but it seems, that sprite collision is not working.

    I don´t know, if the reason is, that the C65 is not fully compatible to C64 or the early emulator state.

    How it works on the nexys Board?

    Is it in future possible, to replace the c64 with the mega65?

    Thanks for answering, and keep on the good work.

    Sprite collision is not implemented at all (in Xemu), currently (and may never be totally correctly, since it's insanely hard and slow to do for an emulator, but hey never say never!!!!!). Also note, that Xemu/MEGA65 is currently most focused on MEGA65 specific features it lacked a lot, but surely, the C64 compatibility is important too, to the level at least what MEGA65 itself can (and will) offer, but not further (in the past I got bug reports that some C64 titles did not run in Xemu, which even shouldn't work too much on many C64 !!! emulators either ...). Just available time, and priorities here.


    But one thing is clear, even MEGA65 is not so much expected to be 100% C64 compatible (maybe as a form of alternative core?), though it's always planned to refine its compatibility as much as possible. Even just current situation of MEGA65 itself (not Xemu now), already did many enhancements, since original C65's C64 compatibility is very poor ...


    From a viewpoint of an emulator, the emulated machine (MEGA65) must be emulated, thus its C64 compatibility is important here. However as I've told above, it's currently at lower priority to work on, and not because it's not important at all, but somehow we have to decide what we work on, at any given moment. And surly most people would be more interested on using MEGA65 specific software on the emulator initially, as they can try C64 programs on existing and mature C64 emulators. But from just a developer's point, yes, it's also important to reflect MEGA65's emulation even with C64 things better, as people may be interested to see how there programs compatible with a MEGA65, even if it's targets mostly a C64, for example. Or some similar scenarios.

    Zitat von hernandp

    ... allowing to run e.g: RASTER65 at full speed.

    Because I have to search a little bit for this "raster65" demo program, before I found it here in the mega65-core git, I made a D81 image with the two demo programs and attached it here for easier use.


    Go to the 64 mode with go 64 and switch to 40 Mhz mode with POKE 0,65 before running the raster65 demo!


    It works really great with the new Xemu update! :thumbup:


    Hi Snoopy, we are, at the moment in the process of restructuring the files for and around the MEGA65 to make them more easily find-. and manageable.


    But cool, that you found it and that you can confirm running !