Path: chuka.playstation.co.uk!news From: Toby Sargeant Newsgroups: scee.yaroze.freetalk.english Subject: Re: yet another siocons replacement Date: Mon, 16 Feb 1998 12:09:26 +1100 Organization: Forefront Software Services Lines: 70 Message-ID: <34E791C6.11462516@forefront.com.au> References: <34E38880.724EB908@forefront.com.au> <34E78654.7984419F@cybec.com.au> NNTP-Posting-Host: ws19.forefront.com.au Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailer: Mozilla 4.04 [en] (WinNT; I) Toby Hutton wrote: > A disassembler? What does this have to do with serial comms with the Yaroze? > How would it integrate with the standard siocons stuff within your API? (gdb > disassembles my code already. nm already dumps my object files.) Agreed, but the point is that this will provide a way for any executable to gain access to the disassembled code, so rather than just seeing a text view in GDB, you'll be able to get any kind of view you'd like (assuming you have the time to write it). Examples might include a disassembly browser that's more simple to use than the gdb interface, or even a display of speculative code coverage, to help with optimisation and tracing. Essentially the aim of this project is not to reinvent the wheel, but to provide information that's already available in a more uniform and accessible manner. > > Depending on whether I find documentation on the R3000 opcode format and > > the HSS protocol, I'll also support RDB, so as to provide simple hooks for > > debugging. > > I assume you have the source to the siocons that has already been ported to > unix. There's probably all the HSS info you need in there. Yep, that seems to be the consensus. It's a pity. the FSF tend to be good with their documentation, but this is one area that really isn't documented at all. > > > > It's all written in python, so as long as I can find a good serial I/O > > module for each operating system, this will also work on > > win95/NT/dos/OS2/MAC. Long live cross platform programming. Python also > > has excellent support for OLE and CORBA, so I'm not planning on leaving the > > C/C++ programmers (completely) out in the cold. > > Is CORBA well supported under Linux, FreeBSD and NetBSD? Look at ILU, ftp://ftp.parc.xerox.com/pub/ilu/ilu.html ... It's an implementation that supports most unices, as well as W95/NT. > > Suggestions as to things that you'd like to see an API provide above and > > beyond straight mappings of the siocons commands are very much welcomed. > > Given that I would like to see this as a possibilty to create a labour > > saving device for many people out there, the more feedback I have, the > > easier it is to reach my goal. > > A really nice way of doing transfers during runtime would be great. Is this > possible at the moment? So data could be loaded at the beginning of levels - > a client using your API acts as a persistent storage interface for the PSX > app, down the wire. Yep, I can see this being possible. One thing I'd _like_ to do is to then be able to combine the fileserver data stream with the HSS data stream, so that you could use it while you were debugging. I admit, I'm assuming that this doesn't already work for GDB, but I think it's a pretty fair assumption, based upon the fact that sharing serial ports tends to be tricky. > The way the current siocons for un*x works sucks, because you can't break out > of it unlike the DOS version. ESC doesn't work. 'kill' from a different > terminal does. I'd like to see an app. that works as I believe psxfer is > supposed to - a command that can be batched together in scripts. Psxfer > doesn't work for me, it always goes into rdb mode, and doesn't load my models > properly. I'll make sure that this works with my implementation, don't worry :) I still haven't decided yet, whether the sample interface that I'll provide will be text or graphical. > Toby. > > (A different Toby, also in Australia) Toby.