| |
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. |
|
... 8 posts hidden. Click here to view all posts.... |
| |
ChristopherJam
Registered: Aug 2004 Posts: 1359 |
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: 2804 |
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: 2804 |
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: 11088 |
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: 1359 |
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: 1359 |
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: 11088 |
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: 1359 |
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: 2804 |
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). |
Previous - 1 | 2 - Next |