| |
Sasq
Registered: Apr 2004
Posts: 155 |
VICE screenshot to PRG possible?
How hard would it be to generate a PRG showing a screenshot of the current frame at some point in time from a modified Vice emulator ?
I am talking about a memory dump of all memory and
all VIC writes and writes to VIC accessible memory, with exact cycles, and generating a PRG that writes the exact same values at the exact same time.
For regular Hires/Multicolor images this would only generate a PRG that sets the video memory and then the necessary vic register once.
For anything that modifies VIC during the frame it requires generating code that begins with a stable raster and then a combination of NOP, LDA, STA through out the entire frame to get the writes correct.
In theory this should allow you to create a C64-viewable screenshot from any demo. |
|
| |
Mixer
Registered: Apr 2008
Posts: 422 |
so.. you want an "unrolled-code" version of a frame of some demo? You could use some debug output to generate such code. There might be some effects that are dependent on stuff that are not "in frame", f.ex timers or certain vic effects, like opening the upper/lower borders (have to start previous frame low border), so that their accuracy cannot be achieved with mere nops. |
| |
enthusi
Registered: May 2004
Posts: 675 |
For simple gfx modes this one will do:
Vice Snapshot Grabber V4.4 |
| |
Sasq
Registered: Apr 2004
Posts: 155 |
But I assume you still only need to record a full frame if you just start in the right position (just before you need to open the top border I guess).
I know how to modify Vice to record the stuff, but I'm not sure how to go about the 6502 code generation... |
| |
chatGPZ
Registered: Dec 2001
Posts: 11114 |
imho you need to record at least two (for interlaced stuff three) frames, so you can analyze the data and find out what method of opening borders was used. at that point you could just aswell record the exact code that was executed, i guess :) |
| |
Sasq
Registered: Apr 2004
Posts: 155 |
Hmm, then it turns into a specialized freezer instead. Record memory accesses to see exactly what is needed to display the current screen. but it will be problematic to repeat the frame(s) then.
But for screenshot, I think you need to assume no interlace and record two frames and turn that it into a single frame loop after the initial setup. Would that be possible? |
| |
JackAsser
Registered: Jun 2002
Posts: 1989 |
Quote: Hmm, then it turns into a specialized freezer instead. Record memory accesses to see exactly what is needed to display the current screen. but it will be problematic to repeat the frame(s) then.
But for screenshot, I think you need to assume no interlace and record two frames and turn that it into a single frame loop after the initial setup. Would that be possible?
Maybe, maybe not. F.e. NUIFLI has an extremly tight memory layout, so if you capture one frame, the another, your code to display it won't fit most probably. Also, to capture NUIFLI you really need to grab the display code. It will take too much memory or be too complex timing to recreate it unless you use the real viewer. (I think). But that's an edge case... |
| |
Krill
Registered: Apr 2002
Posts: 2839 |
This appears to me as a variant of https://en.wikipedia.org/wiki/Halting_problem or https://en.wikipedia.org/wiki/Kolmogorov_complexity or at least requiring solutions to them, which have been proven not to exist for the general case.
It's an interesting topic to ponder about, but it begs the question: why? Why would you want a still frame of a C64 program at a specific time to execute natively on the C64? :) |
| |
Perplex
Registered: Feb 2009
Posts: 254 |
Including screenshots of games or demos in a diskmag is one use-case. |
| |
ChristopherJam
Registered: Aug 2004
Posts: 1378 |
Nah, not halting problem at all; just want to see what code does for a period of 20,000 cycles, which is exactly what VICE does every frame.
Memory layout would be tight for unrolled code, but should be eminently doable; VIC cannot fetch more than 20,000 bytes in the non-shared bus phase, and total VIC plus CPU reads total no more than a further 20,000 bytes. 6502 instructions all occupy fewer bytes than cycles, so there should easily be enough space.
Timing might be a bit challenging when working in with DMA; would have to replicate RMW instructions for example, otherwise their interaction with DMA initiation would go wrong.
Oh, also - may have to do reads from constants in zero page if there are sequences of three cycle instructions interleaved with writes to VIC registers.
Any writes to any RAM read later in the frame (either by VIC or by a CPU zero page read) will need duplicating too; this is possibly where it all falls down, as there may not be time to restore RAM to the correct starting values for the next frame.
25Hz flicker anyone? |
| |
Krill
Registered: Apr 2002
Posts: 2839 |
Quoting PerplexIncluding screenshots of games or demos in a diskmag is one use-case. But do they have to be pixel-perfect? It's meant as a teaser/impression, and VICE screenshots scaled to 320x200 and then converted to NUFLI or similar would be alright in my book. Just look at the actual screenshots (made with a camera) of games on the back of the game packages of yore :D |
... 8 posts hidden. Click here to view all posts....
|
| Previous - 1 | 2 - Next |
