| |
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. |
|
... 10 posts hidden. Click here to view all posts....
|
| |
Krill
Registered: Apr 2002
Posts: 2852 |
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: 11136 |
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: 1380 |
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: 1380 |
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: 11136 |
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: 1380 |
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: 2852 |
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 |
