-
Notifications
You must be signed in to change notification settings - Fork 32
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
MEGA65: integrate Hernan's ideas/work on VIC-IV enhancements with the possibility of re-factoring meanwhile #29
Comments
Waiting for issue #32 to see the performance effect and other issues what full frame render -> scanline based emulation change may cause. It can help to decide how to emulate VIC-IV then in a more precise level. |
Still waiting for other issue, #26 as it would be important to consolidate memory access (also accessed by VIC-IV) and I/O (so the CPU can access VIC-IV). |
Now I would be able to move on, however it seems not it's worth to wait Mega65 to be "stabilized" ie 1080p mode will be used and possible other changes, so I would like to wait for the more-or-less final solution to be there in Mega-65 project itself. |
MEGA65 palette handling is implemented (right now in the vic branch, will be merged back to dev + stable). It's now possible to use more than 4 bit per channel colour depth, also the 4 colour bank works. Renderers should be trained though to use sprite bank for sprites, and the alternative bank for the 16 bit char mode "use alternative bank". Still TODO: implement ROM palette. On MEGA65 this would mean to fetch colours from bank 3. I'm not sure though if it's true for all (for sprites, ...) and for all selected banks. This should be done with more "quasi-banks" since always checking colour index is less than 16 is pricey at every pixel in renderers! |
#97 is basically this issue, so let's close that. |
Palette handling in the dev branch now: 95c8168 |
Hernan has his own branch playing with VIC-IV. Probably I close this issue being too general. It does not mean it's resolved as whole, still, of course! |
Re-opened with new meaning :) |
Using spinlocks to try to avoid race conditions between OPL3 and SIDs in the "sample renderer" phase (called by SDL2 as thread) and the "register write" phase, done by the emulation core via the I/O space from the main thread. Log to #29 as well.
Note: it seems increasing the number of SIDs to four (originally for #277) triggered some race-conditions between the audio callback thread of SDL and the main thread of emulation. I try to "decorate" things with spinlocks to avoid it, hitting another strange bug meanwhile, may be workarounded ... |
#280 should be fixed (problem with V400 bitplane mode). Also needs to be checked that no problem with other modes (not bitplane!) with V400, maybe this is a common problem, not restricted to bitplane mode only? |
PROJECT: merging the merger branch #29
Well, it's over ... |
Currently, M65 emulation has a VIC-III entity with only a slight modification. For real, VIC-IV should be handled as it is really implemented, ie some "compatibility hot registers" are only used to set VIC-IV registers up and basically using always the VIC-IV internals. Also some VIC-IV notions should be implemented like logical size, etc etc. Scaling stuff is another (and not so easy to answer) question. Maybe SDL should be directed with RenderCopy to do that dynamically, exploiting the GPU of the PC which runs the emulator?
The text was updated successfully, but these errors were encountered: