Path: chuka.playstation.co.uk!tjs From: tjs@cs.monash.edu.au (Toby Sargeant) Newsgroups: scee.yaroze.programming.gnu_compiler Subject: Re: Toby's question (not an answer). Date: 24 Aug 1999 22:26:13 GMT Organization: PlayStation Net Yaroze (SCEE) Lines: 51 Message-ID: References: <86n1vj5c6o.fsf@foo.mel.cybec.com.au> <86wvuld1vd.fsf@foo.mel.cybec.com.au> NNTP-Posting-Host: longford.cs.monash.edu.au X-Newsreader: slrn (0.9.4.3 UNIX) On 24 Aug 1999 18:22:30 +1000, Toby Hutton wrote: >Psxfer has a stack of parameters for loading files into PSX memory, so >I gather is wasn't intended to *only* put it into rdb mode. But it >always does... Nope, this is _all_ done via rdb mode. The rdb protocol gives you a broad spectrum of memory read/write commands. And to top it off, the RDB psx serial I/O is written much better than CIP. CIP does _weird_ things with handshaking, which is why the unix port of siocons is so broken (and, indeed, why it busy polls, consuming 100% of your spare cpu time). >You're actually using gdb to do file transfers? Have you set up some >macros to handle AUTO files that DOS Yarozers create? Never tried that. I use a small program for up/downloading, and then run gdb and attach to the same connection. Basically, I have a server program which creates unix domain sockets in /tmp which allow various userland processes to talk to the AR without root privs (which you need temporarially for unprotecting the IO ports that the AR uses). Userland programs like the up/download tool, gdb, and the fileserver attach to the unix domain socket, and talk to it just like they were talking directly to the right code on the other side; the server transparently multiplexes and demultiplexes the data stream. It's really quite neat. The entire data segment is also relocatable as well, so once it's flashed onto a cart, it will have essentially zero fixed address footprint. >I noticed when building a cross compiled gdb there are about half a >dozen remote targets, mainly for embedded systems work I suppose. Is >your AR stub based on any of these? They're all serial targets I >think, where the AR is parallel? The only difference, once you're past the hardware interface is speed. (Oh, and for people that are used to the serial transfer rate, I'll reemphasise that: __S_P_E_E_D__). The protocol is based squarely on the standard gdb remote protocol. Or at least it was before I went 8 bit to get more speed out of the connection. The different remote targets are for systems that already have a debugging interface. Given that I had the rather dubious luxury of building the debugger stub from scratch (*shudder*; it's _not_ fun when a bug in a debugger stub causes the stub to crash and recursively call itself.) I got to choose the protocol, and the list of features to support (which turns out to be almost all of them). Additionally, while I was still playing around with this stuff, I found out how to use the AR firmware to set hardware watchpoints, so when I finally get round to polishing things up, I'll be able to add support for that too. About the only problem with the AR is that I won't be able to use it with my laptop. Might have to find out about the parallel port version. Toby.