I/O Capture cartridge

typically this is one with big/costly logic analyzer...
...
I would like you elaborate more on the memory allocation, strobe signals , data rate , length of replay ...

If we capture signal a 3.57MHz ,if weconsider 32 signals to capture , that makes 12MByte/sec without compression.
Lets say if we want 1min replay we need 800megs , recoding in an SD card is then mandatory , SDs canreach 20MB/sec
in some modes ( not MMC one we use in SD interfaces, to get the specs of these you need to affilitate to SD org , 5k$/yr)

So i think we need some trick : do we capture only /IORQ's ? that could save a 10x ratio at least but are we missing something ? memory mapped registers ...

There replayer would be the msx and its Z80 , right ?

If we focus on replaying cartridge games , dont the msx player can help ?

Cant we capture in emulator andreplay on real hardware ?

typically this is one with big/costly logic analyzer...
...
I would like you elaborate more on the memory allocation, strobe signals , data rate , length of replay ...

I have absolutely no idea about these things and I think you did not get my idea quite right. I was just thingking more simple way:

OCM has MSX-bus and VDP emulation. If we remove all functionality related to actual screen drawing, command handling and status registers we get a VDP with only registers. If we now add way to read those registers trough memory we have basically what I was thinking of... I'm not sure if it is a problem that there is real VDP and "virtual VDP" on same I/O ports, but I don't think so as long as this "virtual VDP" does not return any values to bus.

I had no plans to store bus history or anything like that!

No... forget the CPU and let it run normally. If you can get time from it you know the status of it.

I actually want to enhange VDP, OPLL etc. features by adding possibility to read back their registers.

The plan is to add some virtual devides that work on same I/O ports as the original chips just listening what MSX tells them.

When you have possibility to read the status of VDP etc. You can for example exit to debugger and then return to original software, because you know what was the status when you exitted the software at the fist place.

For example 90% of memory mappers you can already read back the status that was written to the mapper select. This would add a standard way to read it back 100% sure with the exact value and not only the lower bits as you usually get if you have <4MB mapper.

I'm not thinking here any ultimate hardware debugger... Just little enhangements for existing chips in order to get a standard way of reading back the status they are in... For example as a programmer I can ask PSG if it is outputing sound or not... This is not possible with OPLL.

With this extension it would be possible... I could for example write a little routine that records all registry changes in OPLL on each interrupt and that way record existing music to another format... Just as another stupid example... Sure this all means writing TSR routines for this debugger cartridge.

so i see a cartridge working with /IORQ and /WR ,

i can imagine a ram with databus on d0-d7
sram's/WR on /WR
sram's/CE on /IORQ
A0-A7 of ram on A0-A7 of cartrige port.

so a little ram ok 2kb like 6116 sram can record io's state.
most of the ram is unused of course.

for read back we need to make
sram's /CE = /IORQ and /sltsel
sram's /OE = /sltsel or /rd

so with a and gate and a or gate and sram it can make it.
i guess a 74LS139 can do the job.

do you see it ?

ok i see , in that case fpga seems mandatory, an FPGA on cartridge ...