Original Post

Hey,

As some of you remember, I made a PC<->VB link cable using the PC parallel port a few years go… eventually I made some changes and broke my code, then lost interest in trying to fix it. Anyway, I decided I wanted to make a USB PC<->VB link cable, and finally got around to getting the hardware, wiring it up, and writing code to use it. I’ve done some simple code that transfers data back and forth between the VB and the PC and it works great (and can transfer data at a max of ~235kbit/sec).

Of course there’s several things that the PC<->VB link could be useful for, but one of the main features I’d like is the ability to debug the code running on the VB from the PC. My plan is to have the VB run as a slave device, start a transfer and enable interrupts at the beginning of the program, then when the PC wants to talk to the VB, send a byte, which will cause the interrupt. Then handle everything wanted inside the interrupt, and when done, start the process again.

Anyway, inside the interrupt I can receive commands telling the VB to either dump memory locations, write data to a memory location, dump registers, load registers, or set the address trap (breakpoint). Alone, this stuff doesn’t help much, but I believe these should be enough that a debugger on the PC could get/set everything that it’d need.

That’s another problem… the PC side debugging. I’m familiar with using GDB, but I’m not familiar with how it handles the debugging info in the binary, and if/how it can handle talking to a remote device instead of a locally running application. Is anyone familiar with GDB? I know David Tucker talked about using GDB in the past, so I’ve emailed him asking about any details he has… but I’m interested in hearing info that anyone has. The other option I’m considering is just importing an objdump, which has memory locations of the variables and functions. This should be sufficient, but probably less elegant than the true GDB.

So… my question for everyone else… what am I missing? What else should the debugger be able to do, and what other uses would the PC<->VB link cable have? The other uses I can think of are a cart dumper/writer, linking games over the internet, using the VB as a PC display (Alberto’s Virtual-E project), and using processing, data, or peripherals from the PC side on the VB. Of course the link is limited, but I think some cool things can be done with it.

DogP

4 Replies

incredible, this will open up so many new possibilities! again great work, pat! πŸ™‚

i assume it is not possible to stream roms from the pc? like using it to transfer binaries to the vb out of ultra edit for testing during game development? for this purpose, this would even be faster way than the flashboy.

luckily i’ve got all the parts here to build one of those (or a dozen if i wanted, heh), because i wanted to give building a link cable another try.

I think the no$gba debugger has got a good debugger, but its not for free. Maybe you can ask him. But he seems to be a little “strange” at least what I read on his internet page. Btw he is german.

As for the PC-link cable, I would like to try out that OpenGL – Virtual Boy thing. And a doom version whichs connects to a vr32.de server would be awesome too πŸ˜‰

Awesome work DogP!
Would it also be possible to use it to stream the video ram to the PC to use the PC as a VB display (reverse Virtual-E project πŸ˜› )
That would eliminate the need of a TV-out adapter πŸ˜€

i assume it is not possible to stream roms from the pc? like using it to transfer binaries to the vb out of ultra edit for testing during game development? for this purpose, this would even be faster way than the flashboy.

I’ve considered that… but you definitely couldn’t stream the ROM in real time. If the program was small enough you could load it into WRAM, but that’d be limited to 64KB minus the size needed for variables and stuff. I do have a lot of SRAM chips, so I’ve thought about making an SRAM only cart that could be loaded over the link cable, but I’m not sure that it’s worth the hassle when loading a flash cart doesn’t take that much time, and usually the emulator is sufficient.

As for the PC-link cable, I would like to try out that OpenGL – Virtual Boy thing. And a doom version whichs connects to a vr32.de server would be awesome too πŸ˜‰

I hope Alberto is able to get the OpenGL driver working for his Virtual-E project… that’d be really cool! I do agree about an online FPS… that’d be sweet to have an online deathmatch on the VB 😎 . Next time I order parts I’ll have to get another USB module so I can modify one of my link games to link over USB, and make a PC app that’ll pipe the data over the internet. Then it’ll be up to someone to make an FPS πŸ˜‰ .

Would it also be possible to use it to stream the video ram to the PC to use the PC as a VB display (reverse Virtual-E project )
That would eliminate the need of a TV-out adapter πŸ˜€

STFU! πŸ˜› Heh, no… you couldn’t really stream the video RAM to the PC, for several reasons… one is that you wouldn’t be able to have the game running, so you could stream a single screenshot one at a time, but it wouldn’t really be playable while streaming. Also, you’d have to modify every ROM that you wanted to output over the link port… and the speed couldn’t do full framebuffers at anywhere near the full frame rate (without very good compression, which would take a lot of processing power, which would slow down transferring data).

DogP

 

Write a reply

You must be logged in to reply to this topic.