Screenshots from the Matrix Mode debugger

[dansanderson]

Is your feature request related to a problem? Please describe. The m65 command has a "screenshot" feature that operates by using the serial debugger to read and interpret VIC register state, reading VIC screen/colour/char memory based on registers, then rendering that data into a PNG file with a rendering routine internal to the tool. This is clever and very useful for some use cases. It has the disadvantage that the m65 tool is responsible for emulating the VIC's render, and it does not reproduce all VIC rendering behaviors. For example, sprites are not yet supported.

Automated testing would benefit greatly if it could capture a complete VIC frame composite render as implemented by the core itself. For example, an automated test driven by a PC over a serial connection can set a breakpoint then request the rendered image data. A test can diff this image against an expected image and report discrepancies. Given the composite render from the hardware, such tests would catch unexpected changes caused by the core or ROM.

In general, a composite render off of the device would be more useful than m65's internal render for all cases where screenshots are useful.

Describe the solution you'd like Implement a Matrix Mode debugger command that breaks at the end of the current frame, then captures a complete composite render from the VIC and streams the image data in some easy but complete format. The format probably needs to describe at least the size and colour depth of the image, but it doesn't necessarily need to stream a container format like PNG. (The tool making the call can convert the raw format into the desired format.)

Describe alternatives you've considered It's possible to extend the m65 implementation to improve the fidelity of its internal render with the actual VIC render. This feels like a losing uphill battle, and is unlikely to reproduce bugs and oddities in the actual VIC implementation. Those oddities would be a highly useful target use case for this feature, e.g. to assess the impact of fixing a VIC bug on existing software titles.

[lgblgblgb]

@dansanderson I don't think it's possible. MEGA65-core itself is not an emulator (but a hardware), unlike an emulator it does NOT have the whole frame available anywhere/anytime. It creates/generates video signal on-the-fly, the max video info it has in any given time is one scanline, and even that is only there because (among other things) RRB needs to implement the raster rewrite buffer. There is not even FPGA BRAM to implement a full frame worth of video buffer, it would be somewhere around ~1.2Mbyte BRAM (given by the fact that max resolution is needed with 23 bit colour per pixel). What you suggest here is an emulator feature, not a hardware one what a core can implement. If I remember correctly something like 1Mbyte of BRAM the FPGA has at all which is already not enough, and anyway needed to implement the 384K of "fast RAM" MEGA65 has and large amount of other structures like colour RAM, ethernet buffer, various other buffers, and so on. Of course indeed it would not make sense that this "complicated" scheme of screenshot is implemented that m65 tool itself interprets registers etc when a full frame is indeed generated by the core itself, the only reason it's done this way that it's not possible to do the other way, ie, not having a full frame info available at all, but generating video signal real-time/on-the-fly.

[dansanderson]

I understand that there isn't a frame buffer memory region that holds (or could hold) a complete frame of composite image data. I don't see why whatever generates the composite render with the beam couldn't also spit that data out the serial port for a single frame. If there are throughput issues, it could take its time to generate and send the full RAW image with the CPU paused. For example, it could fill a small buffer with a fraction of the frame, output it, then sample the next fraction, and so forth.

I'm completely naive when it comes to understanding the space remaining on the FPGA for new features, so maybe it's just too expensive a request for its utility. Maybe what I need is an external hardware test harness that pauses the CPU, captures a frame off the DVI output, and does something smart to normalize a low-res full-color image for testing purposes. (The same harness could generate test inputs on the I/O ports, etc.)

For some purposes, m65's emulated render may suffice; for others, Xemu screenshots may suffice. In this case I'm thinking about assessing impact of VIC bugs (and their fixes), which I would expect would require the actual composite hardware render.

[lgblgblgb]

I guess, it's of course possible to use more time to transfer the content waiting several frames and transfer only a portion of the screen content as "rolling slice" or something while CPU is stopper Or: for example there can be a new feature added to read out the RRB buffer (maybe quickly stored to a buffer so slower transfer is still possible from there) so you have one scanline, and even if the serial speed is not enough to do in real time within one frame, it may can do eg every 10th scanline or so, then needs 10 frames to have every scanlines covered in an "interlaced" way. Surely the full frame is not available as a "frame buffer" what my key point was, even the full FPGA BRAM capacity is not enough for that probably, if we does not have anything used it, which is of course not true, all MEGA65 memory is there (which is not "hyper RAM" aka "attic RAM" for sure) not even mentioning colour RAM, ethernet buffer, disk I/O buffers etc etc. IIRC the total BRAM capcity of A7 200T FPGA is around 1.5Mbyte or so btw. Full frame storage for 23 bits would require somewhere near 1.2Mbyte as far as I can guess, which is clearly not enough already even now, considering BRAM usage for the existing design not even counting future features (also please note that R2 models of MEGA65 uses the 100T FPGA which has even less BRAM btw).

[gurcei]

This topic gives me flashbacks of earlier days where the fpga had some logic in it to spit out the screen contents over the ethernet port in order to received on a pc by Paul's custom vncserver program, then allowing a vnc-client to connect to his vncserver and see the screen contents (albeit somewhat slowly/sluggishly).

There's still remnants of this vhdl logic within the fpga, though its in a somewhat abandoned state. Paul had intentions of abandoning it, but as these remnants still linger on, maybe there's a slim chance it could be resuscitated and might allow for the ability to screenshot the matrix-mode screen too?

Not completely sure of the feasibility of this, but just thought I'd throw the idea out there :)