Patents can be very useful … I’ll have a look. Hooray for breaking international patent law reverse engineering!
The hardware (PSX XPlorer FX) isn’t dead, but the flash ROM on it is corrupt, now! I put Caetla 0.37 on it which worked great. But then it wouldn’t let me restore the original XPlorer ROM. I guess there’s always X-Flash, which “can be used for repairing broken Xplorer cartridges.” Perfect.
Pat: I’ve looked over the document about 100 times over the years, and peering into it again has refreshed my memory quite a bit. It still doesn’t contain the kind of information I’m looking for. Funny how written documents are static, like that… The closest it comes to explaining any timing information for the XP is on page 5-19-2:
When SBOUT is set to 1, it maintains that status for about 56 µsec.
That’s good to know, but it doesn’t say how long you should expect it to maintain a status of 0. 😉
Page 5-20-1 also has some useful info (heck, the whole document is useful!) but it’s not quite enough to fully understand the XP’s inner workings.
And yes, I meant the servo board; honest mistake, silly typo.
With my DosBox-parallel port hack project finished (I used it to kill the hardware after successfully interfacing with it! Yay!) I can focus on VB more. At least, until my prototyping boards come in, then I’ll be working on N64. (See! I told you I was busy…)
The need for a more accurate codebase is the reason I decided to start writing a new emulator. No, VUE32 doesn’t do anything interesting to end users, yet.
Sounds like a plan. And I concur with your sentiments on lack of documentation for GCC hacking. I have only looked at the assembler to be honest, though. I haven’t even bothered to delve into the inner working of the C compiler.
I just made a few very quick changes to Vue32 (the VB emu I have been writing forever) I haven’t touched it since last March, but the code is surprisingly well-written. (I don’t know how I managed that.) it doesn’t do much other than simple CPU and framebuffer emulation. Meaning it is little more than something to log CPU activity without any additional hardware emulation, or even CPU interrupts. I think I’ll upload it to my sourceforge account when I can work up the nerve to deal with CVS.
I recently downloaded the latest binutils sources and planned to add v810/NVC support to the v850 ‘core’. But it sounds like you have already started that process.
The current “GCCvb” is unfortunately quite old. It would be nice to have something newer, and maybe even get it into the official distribution so our changes will automatically carry over to new builds. 🙂
I think most people have similar ideas when they first set out into the strange world of video game development. I know I did. After many failed attempts, I began to see some real issues with the idea. For example, RPGs are mainly selfless in the story and how the game progresses, while first-person shooters are more self-centered (selfish, even).
The closest I have ever seen to “first person game with puzzle elements” was the Half-Life series. Valve Software did a fine job with it in that respect, but the puzzles were usually quite lacking any real amount of logic. For a fine example of a puzzle which requires a high level of thinking, look no further than the ‘ice block key puzzle’ in The Legend of Zelda: The Minish Cap… Or any number of puzzles in The Legend of Zelda: Link’s Awakening.
Well, good luck to you, if you choose to go through with it.
Oi…. ;(
I’ve never liked VirtuaNES. So when some friends and I needed some debug tools for NES, we built them into FCE Ultra. I’m sure our “debug builds” of the emulator are not so difficult to find, depending on where you look. (*cough* ZD) The tools available there far outdo anything from any other emulator. Ever.
Some of those suggestions are good, but they certainly don’t hold priority. That would go exclusively to emulation accuracy. On the other hand, debugging tools contribute significantly to working on accuracy.
On final note, the last thing I did with VUE32 was the CPU core. As far as I could tell, it was running with decent speed and accuracy, though incomplete. No I/O is emulated (including controllers, audio, video…) but it has a running core, anyhow! Actually, there is a bit of video emulation, (framebuffer display) but it’s really quite insignificant.
It would be 50 FPS total. The reason I said 100Hz is because it’s evenly divisible by 50. On the other hand, 60 and 75 (etc) are not. Displaying 50 frames per second on devices set for 60/whatever would be quite nasty. Imagine trying to skip frames with shutter glasses! It pains me.
Oh, and I’ve not heard of 50Hz monitor output… So there you have it!
Possibly a RAM overflow. Remember that VB has a slim 64KB of WRAM to use. If the core contains a lot of variable, arrays or structures, it may be using too much RAM. The linker script in gccvb does not check how much RAM a compiled program uses, so it can be difficult to track down these kinds of bugs.
One way to check is by using objdump to dump the section information:
objdump -t objectname.o > sections.txt
Where “objectname” is the name of the object file created by gcc. The create “sections.txt” file will contain many lines that detail all parts of the object file. The first few lines can be the most important:
SYMBOL TABLE:
07000000 l d .text 00000000
07001890 l d .rodata 00000000
05000000 l d .data 00000000
05000014 l d .bss 00000000
0500001f l d .comment 00000000
If the .comment section is placed too high in memory (say, 0500E000 or higher) then it’s quite likely to cause a stack overflow. If it’s greater than 0500FFFF, then you have a fatal overflow. These problems can only be solved by declaring large structures and arrays as const wherever possible.
It shouldn’t be too difficult to write a small program that can parse a sections.txt file and tell if there’s a WRAM overflow. The format is simple, and looks something like this:
Sounds great! I have always wanted to compile my own copy (with updated binutils, and adding those NVC-specific instructions). I guess I never got around to trying it. I was also quite interested in getting newlib or libc to compile for v810, since the standard libs are almost a necessity. One problem I can imagine would be memory usage. Poor VB only has 64KB WRAM, so the standard libs would have to be quite lean. You can bet that things like malloc() would cause problems.
Otherwise, that is really great news! Now all that is needed is [another!] fixup to the linker script and crt0. The linker script is missing support for memory overflow checking. It’s really too easy to overflow WRAM. Especially when you forget to declare large, static arrays and structures as const. As for the crt0, the publically available version is missing interrupt support, and the interrupt support in the current revision is nasty, at best. It just saves all 32 GPRs, rather than only the volatile GPRs. (r1 – r5, and r30, I believe. though the bitstring regs (r26 – r30, or so) may also need saving). Blah. 🙂
One day we’ll have a completely stand-alone copy of gccvb!
One interesting idea is that Nintendo may have provided an “operating system” with the VUE kits. Something like a standard library to provide the low level hardware routines. This would explain the similarities between the games.
VUE came with an assembler from Intelligent Systems named ISAS. It appears to be capable of “operators equivalent to those used in C language”, so the assembler was probably pretty high-level for an assembler. For example, you could use a generic type of if-then-else pseudo instructions, rather than comparisons and branches.
Now personally, I don’t mind how I program. Working with C and assembly are equally fine for me. The crt0 in gccvb was written in assembly, obviously. But most of the lib is written in C.
On a sort-of-related note, I did write a test ROM in both C and assembly at one point. The job of the ROM was to dynamically generate an instruction in RAM and execute it. After executing the instruction, the PSW would be read and returned to the ROM, where the flags would be printed to the screen. (Helped locate the CPU bug that killed Wario) All of the stuff that ran from RAM had to be written in assembly, as well as the “long jump” routine used to get the CPU into RAM. (I think this was included in the lib?)
So that’s a pretty simple example of how I perfer to program; Use C at all times unless you need the performance gain (or special hardware access) provided by assembly.
Just remember; though both screen are able to display 3D graphics, only one screen at a time will be able to (hardware limitation). Unless someone finds a way around this limitation, you will probably not see any games using both screens to their fullest potential.
One problem that comes to mind with shutter glasses… VB’s refresh rate is 50Hz, so your PC monitor must be set to AT LEAST 100Hz for the 3D effect to work while displaying every frame.
In my case, my monitor only supports 60Hz max. That and the fact that I do not own a pair of shutter glasses… It will be incredibly difficult for my to impliment shutter glasses support without the necessary hardware.
DogP was porting a GameBoy emulator (GNUboy, I think?) to Virtual Boy. The problem with that is how dreadfully slow it runs. It’s also running very short on available memory, since VB only has a mere 64KB RAM.
It’s best to write emulators for Virtual Boy in 100% assembly. That way, you can get as much speed from it as possible. An emulator written in C just won’t do.
We are in the planning stages for a completely new Virtual Boy emulator. It’s just getting too difficult to maintain Red Dragon.
I will keep any suggestions in mind through-out the development process. But that does not mean I will be able to impliment them. After all, I do not have any shutter glasses hardware, or experience programming for them.
