| |
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 |
| |
Krill
Registered: Apr 2002 Posts: 2839 |
Quoting ChristopherJamNah, 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. Yes, and the state required to get to display frame N is defined by the code executed in all preceding frames. Including hidden state in VIC itself, etc. Now it may be possible to somehow distill the CPU writes that would produce the desired (correct) VIC video output, but guts feeling tells me there are a lot of corner cases and unforeseen problems where this falls flat. |
| |
chatGPZ
Registered: Dec 2001 Posts: 11114 |
Quote: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.
you need knowledge about the previous frame too (state of border latches, sprite positions, DEN etc) |
| |
ChristopherJam
Registered: Aug 2004 Posts: 1378 |
Good point about hidden VIC state.
Is there anything that couldn't be determined from a register dump plus the previous frame's writes though? |
| |
ChristopherJam
Registered: Aug 2004 Posts: 1378 |
I did just have a hideous thought mind; not that I've seen it done, but it's entirely possible that someone could rely on an IRQ pushing a sequence of values onto the stack at least one of which is immediately displayed as part of a charset or bitmap. Now *that* would be hard to replicate.. |
| |
chatGPZ
Registered: Dec 2001 Posts: 11114 |
or you could disable badline fetching just after the vic fetched vram, keeping the state of the videodata shiftregister (like xbow did in some demo) :) |
| |
ChristopherJam
Registered: Aug 2004 Posts: 1378 |
Ah, nice. Reutastic only reads the VM once per frame for the first ~30 chars, but I hadn't considered disabling badlines altogether for an entire sequence of frames, while still making use of whatever's in the buffer. |
| |
Sasq
Registered: Apr 2004 Posts: 155 |
Yes I was toying with the idea of automatically generating screenshots for demos you put on your sdcard so you could browse demos by screenshots...
Speaking of REU - If you could rely on that, how hard would the problem be then? Now you have enough memory and a way of writing everything during a frame with a REU transfer. |
| |
Krill
Registered: Apr 2002 Posts: 2839 |
I guess the problem with a typical REU is that it only transfers memory consecutively, in big chunks (or all to the same byte). You'd probably want a more generic DMA engine that may write to arbitrary positions for every cycle, with a list. Now that would probably be something easy for 1541U (and is maybe already supported, no idea). |