I/O Capture cartridge

Enlighted (6033)

10-02-2010, 15:52

Now that there are plenty of hardware developers and all kind of FPGA & PIC chips available for reasonable price. I've been wondering would it be possible to have an cartridge for MSX that would record all I/O port communication from the MSX databus and store the writes to write only I/O devices to it's own memory?

This kind of device could be used to implement something like "Action replay" for MSX... Expetially if it would also have some memory and it would include pushbutton to generate interrupt or reset MSX.

I mean the device could have some RAM or flash for debugger (for example in address space #4000-#77FF) and then rest of the visible area memory area could be used for reading back last values written to commonly known MSX-devices... For example like this:

#7800 - #782E VDP registers
#7900 - #791F VDP palette
#7980 - #7983 Copy of Mapper I/O #FC-#FF
#7A00 - #7A38 MSX-Music registers
#7B00 - #7BC8 MSX-Audio registers

(just an simple example for you to catch up what I'm trying to think)

What do you think?
Would it be Hard / Easy to implement?
Expensive / inexpensive?
Most importantly would it be usefull or would you consider it Useless because of all the emulators around?

I think this would be handy for developers. This could be also used for using existing cheat databases on real MSX, running more than one application at a same time (for example some existing debugger & game). etc. etc.

By Tanni

Hero (556)

10-02-2010, 16:59

As far as I remember, such kind of hardware did exist back in the early days of homecomputing. I saw something similar to what you propose in a computer magazin concerning C64 or so. It was a hardware development tool. But I skipped over it, because there were so many new and interesting things back then, and hardware development were too far away for me, then.

By Leo

Paragon (1236)

10-02-2010, 17:12

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 ?

By Tanni

Hero (556)

10-02-2010, 17:14

Thank's, Leo, it was a logic analyzer, of course!

By NYYRIKKI

Enlighted (6033)

10-02-2010, 22:46

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!

By Leo

Paragon (1236)

11-02-2010, 13:24

I try to figure out ....

Would it be something close to a debugging tool ? or "in system emulation"
Very often you can find debugging tool that allows to do program breakpoint when some conditions are reached by cpu like PC=value , or
do step by step execution with a link between code and PC, but this applies only to CPU and not its peripherals.
Are you talking about such tool that is able to freeze one state of the entire system , and then read what are the values of vdp registers
and other peripheral ?

Yes i think this is it you want to freeze a whole MSX state and be able to re-start from that point , and like that switch from one application
to another , right ?

By NYYRIKKI

Enlighted (6033)

11-02-2010, 14:48

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.

By NYYRIKKI

Enlighted (6033)

11-02-2010, 15:50

Actually now I think I didn't get you right...

Yes, I would like to "freese" the system... and by that I mean two different things...

1) Get CPU's attention = Jump to my own program.
I think NMI would be best for this purpose, but unfortunately there is no NMI line on cartridge slot so I think regular INT is best we can get...

2) Be able to do a "save state" using custom program = Read back values from VDP, OPLL etc. (See previous post)

By Leo

Paragon (1236)

11-02-2010, 22:21

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 ?
iledefra01.free.fr/msx/DSCF7669.jpg

By NYYRIKKI

Enlighted (6033)

12-02-2010, 13:16

That is enough only for memory mapper....

You still can't read back VDP registers or OPLL registers. VDP is a bit harder as it contains also internal counters for register write and color palette. MSX-Music & MSX-Audio are a bit more straight forward... How ever way much more complicated than the solution you suggested...

By Leo

Paragon (1236)

12-02-2010, 16:09

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