Path: chuka.playstation.co.uk!scea!NewsWatcher!user From: developer@woodentulip.com (Sean Kennedy) Newsgroups: scee.yaroze.programming.codewarrior,scea.yaroze.programming.codewarrior Subject: Re: GTE asm with CodeWarrior Date: Wed, 10 Mar 1999 13:20:39 -0500 Organization: Wooden Tulip Ltd. Lines: 63 Message-ID: References: <78dk65$nd41@chuka.playstation.co.uk> <36AAF8E8.E85886FB@hinge.mistral.co.uk> <78f5ll$nd46@chuka.playstation.co.uk> <36AB8574.82169D5F@hinge.mistral.co.uk> <78le37$gpd8@chuka.playstation.co.uk> <7958j6$is66@chuka.playstation.co.uk> NNTP-Posting-Host: pro2-208.barrie.connex.net Xref: chuka.playstation.co.uk scee.yaroze.programming.codewarrior:459 scea.yaroze.programming.codewarrior:400 wrote: > > This leads into the next category. > > The ASM.H refers to the R3000 registers as part of the processor definition. > > That is normal. It is part of the support for R3000. As well an R3000.H > > file exists too. > > What I was referring to was the GTE registers. > > Those are not documented. > Not properly but: > 1) The compiler undestands some but not all GTE-related op codes. I think I > now may know why: they're used in the pre-main initialisation in > _pssstart.c. I suspect MW would have yanked all support except then this > code would not have compiled. Yep. > 2) Further browsing the "Targeting Net Yaroze" (i.e. the user manual for CW > for NY) the debugger chapter lists one of the ways of peeking at a running > program is by opening a window to show the GTE registers. This does appear > in the menu when debugging but is greyed out at all times. Yep. > So it looks like GTE support, available in the Pro product according to MW's > web pages, was excised from the cut-down NY version. But some limited > support had to be kept and elsewhere the excisation was less than surgical. Again, R2.X and now 3.X of the tools were part of the build path, but were forked part way though. They both HAD the same functionality, but were stripped. Just Like the LIBPS.A ecoff library. > > Yep, I agree. I found THAT out coding for PowerPC. > The PSX is the first Assembler coding I've done in years: I was spoilt on > the PPC with its FPU which does most everything, including multiply-add, in > a single cycle, at 200MHz on the laptop I'm writing this on. Coding on a > processor that runs at a tenth this speed without the maths power has led me > to rediscover the joys of very low level coding. > John Integrated FPU helps, lots. But I started with R3000 and 88100 code. I never got too pedal-to-the metal with the 88100, and the R3K was mostly Microcontroller interfacing so no Floating Point was needed. The R4700 changed that quite a bit, but then I didn't have to goto ASM to get what I needed. PIC 16C54 on the other hand changed my outlook on RISC and memory storage QUITE a bit... 256 Bytes of Scratchpad/mem/register/stack. Try doing Fpoint in there... ;) Thanks John, for letting me know that there are others in Yaroze who are trying to code in R3K ASM. GTE micro-code I cannot help you with, But I wished I could. Having even minimal access to the GTE module [Mdec and others.] would have been too much of a comprimise for Sony to let Yarozers have it. Even though we always wished to could be so. Sony, who are now in the midst of Litigation with Connectix in relation to the VGS emulator; are probably wondering how Connectix was able to Software Fabricate the State engine of ALL the modules in the PSX.? Does not surprise me at all there is a Intellectual Property issue there. -sean