HorvatM wrote:

while (VIP_REGS[XPSTTS] & XPBSYR);	// Wait for the screen to stop updating.

This seems to be much faster. However, I can’t test it on hardware. How does that work? The Nintendo VB development manual describes XPSTTS simply as “drawing control”. According to vip.h, it contains a number of flags. Is XPBSYR clear when it’s safe to write to the screen?

I think “XPSTTS” is an abbreviation for “piXel Processor STaTuS” and yes, it’s a register full of flags. XPBSYR is defined as 0x0C, which is 1100b. In that code snippet, XPBSYR is used as a mask for the bits XPBSY0 (0100b) and XPBSY1 (1000b) which are set when the first and second framebuffers are being drawn, respectively. However when both of those bits are clear, the XP is idle, (VIP_REGS[XPSTTS] & XPBSYR) == 0, and thus the do-nothing while loop exits at a point when it is safe to update the areas in RAM that the XP will read from at the top of the next frame.

Self-built GCC 4.4.2 with M.K.’s, dasi’s, and a couple of my own patches
http://www.planetvb.com/modules/newbb/viewtopic.php?post_id=13509#forumpost13509

Might want to try removing the “CFLAGS=-Wno-error” from the binutils phase in the GCC 4.4.2 build script,… I think I left that in there from the Mac build– it’s necessary there for some reason.

What version of GCC? (I used 3.3) Are you building for a 64-bit or 32-bit host? (I built for 32)

DogP wrote:
BTW, I see there’s a precompiled GCC 2.95 for download here: http://www.planetvb.com/modules/tech/index.php?sec=utils&pid=gccvb … is this what most people are using?

How about the others that are using GCC 4.x? I see some references here: http://www.planetvb.com/modules/newbb/viewtopic.php?topic_id=4125&forum=2 and http://www.planetvb.com/modules/newbb/viewtopic.php?topic_id=3883&forum=2 .

Is there any disadvantage to using GCC 4.x, with all the patches? Is it possible to make a precompiled version of GCC 4.x that can just be downloaded, rather than needing to be built? I’d like to get working on the library, but I really need to set up the environment for whatever GCC version we should call the “standard”… and IMO if there’s nothing wrong with GCC 4.x, I think we might as well jump to that.

Thanks,
DogP

I started with that precompiled 2.95.2 version for Windows many moons ago but have since rolled my own versions of both 2.95.2 and 4.4.2. I prefer 4.x since 2.95.2 no longer builds in newer versions of GCC– I couldn’t get it to build in anything >= 3.0. Plus, I do iPhone dev professionally so my primary environment is Mac OS X 🙂 GCC 4.x obviously sports a lot of newer features (the .incbin directive, dead code elimination…) and I haven’t run into anything yet that makes me want to go back to 2.95.2. (There is apparently an issue with PC-relative calls, but I haven’t encountered it in optimized builds) I think it would make the most sense to work on fixing up the GCC 4.x patches going forward rather than focus our energies on an older version already several generations behind.

If you’re interested, here are the versions I’ve been using most recently– I’ve applied Mednafen’s/dasi’s latest patches as well as a couple of my own:

GCC 2.95.2 sources: http://blitter.net/etc/vb/gccvb-2.95.2_src-20101124.tar.gz
GCC 2.95.2 Mac OS X/PPC binaries: http://blitter.net/etc/vb/gccvb-2.95.2_macosx-20101124.tar.gz
GCC 4.4.2 sources: http://blitter.net/etc/vb/gccvb-4.4.2_src-20101123.tar.gz
GCC 4.4.2 Mac OS X/PPC binaries: http://blitter.net/etc/vb/gccvb-4.4.2_macosx-20101123.tar.gz

I haven’t built these for Windows yet but I did adapt the make_v810.sh script so in theory it should build fine in an environment like Cygwin or MSYS/MinGW. YMMV as always… 😉

Replying to myself again… 😛

Here’s the final version of my routine for anyone interested:

void CopyBits(u32 destBitOffset, u32 srcBitOffset, u32 stringLength, u32* dest, u32* src)
{
	register u32 destBitOffsetReg asm ("r26") = destBitOffset;
	register u32 srcBitOffsetReg asm ("r27") = srcBitOffset;
	register u32 stringLengthReg asm ("r28") = stringLength;
	register u32* destReg asm ("r29") = dest;
	register u32* srcReg asm ("r30") = src;
	asm volatile(""
		"movbsu"
		: "=r" (destBitOffsetReg), "=r" (srcBitOffsetReg), "=r" (stringLengthReg), "=r" (destReg), "=r" (srcReg) /* output */
		: "0" (destBitOffsetReg), "1" (srcBitOffsetReg), "2" (stringLengthReg), "3" (destReg), "4" (srcReg) /* input */
		: "memory" /* clobbered */
		);
}

You’ll need to apply another patch to GCC to build this– again, a likely carryover from the v850 renames r30 to “ep” (element pointer). The v810 doesn’t have an element pointer and gccvb partially acknowledges this; however there are still bits of code left that translate r30 to ep in the intermediate assembly code, leading to errors at build time. I applied a quick patch (attached) that adds ep as a recognized register name mapped to r30, though a better solution would probably be to clean up any remaining references to the ep register.

Attachments:

1. r30patches.zip

Finally solved this issue.

According to this page, it looks like the v850 uses r29 as the frame pointer and this likely carried over into the v810 patches. The frame pointer is useful for debugging but without a working debugger it’s pretty pointless for VB dev. The easy fix is to build passing -fomit-frame-pointer as an argument to GCC. A more appropriate solution is to fix GCC to assign a register to the frame pointer that isn’t already reserved for internal use by the v810. I chose r25.

I’ve attached patches for both GCC 2.95.2 and GCC 4.4.2. HTH. 🙂

Attachments:

1. r29patches.zip

DogP wrote:

Yeah… I’d like to get the USB link adapter set up to work with GDB… but I don’t know nearly enough about GDB to do this at the moment. Do you know the inner workings of GDB to help with this?

I wish I did– as it is I’ve had to blindly slog through the GCC code trying to fix a couple of bugs.

Back in college, I did some Game Boy Advance dev using the HAM engine and SDK. The IDE we used integrated with GDB over a TCP/IP link to a local Debugging version of the VisualBoyAdvance emulator. USB link to hardware would be cool but I was thinking more along the lines of the setup I just described. Work done to get a v810 version of GDB working would also be beneficial to both the VB and the PC-FX homebrew communities. Ideally I would hope this could lead to (pie in the sky idea here) getting the Mednafen team interested in supporting a similar setup going between your GDB client of choice and Mednafen– I believe Mednafen borrows some code from VBA anyway (not sure what parts, so it may be irrelevant).

GDB. ‘Nough said. 🙂

Just an update:

I built GCC 4.4.2 using the experimental patches found here and not only does this not solve the problem, I’m now getting an error message when compiling the “working” version (not very helpful):

main.c: In function 'CopyBits':
main.c:345: error: r29 cannot be used in asm here

Hmmmm… Why not?

GCC 2.95.2, using the sources and patches from this site. (Is there a newer version that works better?)

Does the v810 have a write buffer like the v830 does?

No I haven’t done any quantifiable benchmarks with these new routines yet– my subjective estimation of “faster” is based entirely on perceived performance of a direct-draw renderer I’m working on after switching from bitmasking/byte copying to using the bitstring instructions. These actually sort of fell out of my work on that– honestly I got tired of looking at the C versions when referencing the gccvb library, they made me cringe (no offense to whoever originally wrote them 😛 )

I did skim over the timing of the bitstring instructions in the NEC Architecture Manual and at first glance it looks like my versions would be faster for large block transfers but not so much for smaller blocks. Again, just going off of a hunch– haven’t yet run any tests to quantify performance. I’d be interested in testing against DogP’s ASM implementations– where could I find these? In either case, agreed that both would perform better than the unoptimized C versions commonly used.

I may write a test app later this week testing under various conditions, such as instruction cache, wait-state, ROM vs. WRAM vs. VRM vs. DRAM (aside: are the VRM and DRAM shared? The official Nintendo VB dev manual details the VRM R/W bandwidth but curiously not the DRAM)

RunnerPack wrote:
Which doc did you read that “aspect ratio” comment in?

The VB Programmer’s Manual, page 8:

The column table helps correct for any distortions caused by an imbalance in the scanning mirrors used to make up the display. The table could be reset by the user to change the aspect ratio of the display, and to cause a certain region of the display to distort. This table must be filled in and the screen given time to stabilize (about 20 seconds) before turning on the display. Otherwise the user might suffer from eyestrain if the mirrors have not stabilized and an improper stereo image is displayed.

If I wanted to, say, make each pixel 10% taller, could I use the column table to do that? Even if it meant sacrificing a few rows/columns on the edges of the screen?

Also, where does it say the column table is 512 words per screen? Isn’t COLUMN_TABLE located between 0x3DC00 and 0x3E000? (1024 bytes / 2 screens == 512 bytes per screen?)

Here’s a first draft of my interface schematic. It’s mostly based on the MIDI electrical spec but with the MAX3100 (http://datasheets.maxim-ic.com/en/ds/MAX3100.pdf) acting as a UART for the VB. Looking for feedback on the following, forgive my ignorance on the electronics as I freely admit to being a n00b at this…

1) The numbers coming off the left side of the MAX3100 correspond to the VB link pins. Is it safe to connect these directly?

2) I’m confused what “Clock” means on the VB side… is that the clock signal, or a pin for an external clock if desired? If the latter, I’m assuming the Synch In/Out pins make up a clock signal– would it be possible to combine these to satisfy the MAX3100’s requirements? I’m aiming for bidirectional MIDI communication.

3) Is the 10K resistor a suitable pullup for the COMCTL line?

There are probably other things that need addressing/may set off some alarms… Any and all additional feedback would be appreciated before I start ordering parts. 🙂

Attachments:

1. 

   midiboy_rev1.png
   

RunnerPack wrote:
Well, if blitter wants the VB to generate MIDI messages to control a synthesizer, it would only be a producer and the controller port wouldn’t be useful at all…

Correct. The driving force behind this project is that sound on the VB– music in particular– frankly sucks. 😛 The basic idea is to make up for the VB’s lack of its own soft-synth and patches by having it drive an external synth while in-game.

DogP wrote:
And yeah… if you want to modify a cartridge, you have a lot of options, like adding a UART to the cart bus, as well as mixing the raw audio into the audio stream right on the cart.

Mixing in the audio via the pins on the cart, now there’s a good idea! Hadn’t thought of that. 😀

You don’t get any manual control of the Rx and Tx lines in software… basically, you load an 8 bit register, then tell it to go… in Master mode, it clocks those bits out at 50KHz. It’ll clock them out faster in slave mode, but you’ll need an external crystal (which you could possibly make work using a crystal at 8*31250). The 8 bits are automatically clocked into a register. You do have software control of one open collector pin, but that’s not very helpful if you need bidirectional communication.

OK… I assume that open collector pin is the Ctrl line on the link port… how is this controlled in software? David Tucker’s VB Programmer’s Manual doesn’t provide much documentation on that, and neither does the Dev Wiki at the moment… does anybody know?

IMO, I’d use a microcontroller between the VB and MIDI to convert the synchronous signal to asynchronous… or possibly even just use an SPI UART device (the VB link port is very similar to SPI).

Thanks for the suggestion– after doing some further research I think I may have found a solution with the MAX3100 SPI UART driven by a 1Mhz crystal. Now I’m not a EE/CE major– my degree is in programming– and electronics are more of a budding hobby for me, so I admit I don’t know much. 🙂 Do you think the +5v pin on the VB link port could handle a total draw of ~10mA for the entire circuit?

tarsius4 wrote:
Just to follow up on my compilation problem: I successfully built GCC 4.4.2, used it to compile the VB demo from the dev wiki, and ran it on Mednafen.

Did you need to also download gmp, mpc, and mpfr and if so, what versions did you use? I’m trying to build the 4.4.2 toolchain on my Mac OS X machine and although I can get binutils and gcc built successfully at first, building newlib results in a segfault upon processing the first file:

v810-cc -B/Users/blitter/Downloads/gccvb.org/newlib_build/v810/newlib/ -isystem /Users/blitter/Downloads/gccvb.org/newlib_build/v810/newlib/targ-include -isystem /Users/blitter/Downloads/gccvb.org/newlib-1.17.0/newlib/libc/include -DPACKAGE_NAME=\"newlib\" -DPACKAGE_TARNAME=\"newlib\" -DPACKAGE_VERSION=\"1.17.0\" -DPACKAGE_STRING=\"newlib\ 1.17.0\" -DPACKAGE_BUGREPORT=\"\"  -I. -I../../../../../newlib-1.17.0/newlib/libc/stdlib -O2 -DPREFER_SIZE_OVER_SPEED -mv810  -DMISSING_SYSCALL_NAMES -fno-builtin      -g -O2   -c -o lib_a-__adjust.o `test -f '__adjust.c' || echo '../../../../../newlib-1.17.0/newlib/libc/stdlib/'`__adjust.c
../../../../../newlib-1.17.0/newlib/libc/stdlib/__adjust.c: In function ‘__adjust’:
../../../../../newlib-1.17.0/newlib/libc/stdlib/__adjust.c:44: internal compiler error: Segmentation fault
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.
make[5]: *** [lib_a-__adjust.o] Error 1
make[4]: *** [all-recursive] Error 1
make[3]: *** [all-recursive] Error 1
make[2]: *** [all] Error 2
make[1]: *** [all-target-newlib] Error 2
make: *** [all] Error 2
macbookpro:newlib_build blitter$ 

Any other VB devs out there using Macs? FWIW I’m building using gcc 4.2.1 from Apple’s latest XCode devkit.

celebi23 wrote:
I’m trying to compile it for Mac OS X (thanks to the instructions posted in this topic
http://forum.fobby.net/index.php?t=msg&goto=1273 ) & I’m having some problems.

I’m able to get through the first 2 steps no problem but, when I try “make install”, I keep getting the following errors:

make[2]: *** [pce_psg/pce_psg.o] Error 1
make[1]: *** [install-recursive] Error 1
make: *** [install-recursive] Error 1

I’m running Mac OS X 10.6.4 & I have the latest version of Xcode (plus the iOS 4.1 GM SDK)

For that error all I did was comment out the INLINE macro on line 578 of mednafen/src/hw_sound/pce_psg/pce_psg.cpp so that it looked like this instead:

/*INLINE*/ void PCE_PSG::RunChannel(int chc, int32 timestamp, bool LFO_On)

The only other thing I remember I had to change to get it working in Mac OS X was commenting out lines 551-552 of mednafen/src/tests.cpp:

// if(!DoAntiNSOBugTest())
//  return(0);

That test fails at launch time for some reason, but the VB emulation seems fine regardless. (Does anybody know what the “AntiNSOBug” is?)

HTH 🙂

KR155E wrote:
hey blitter, how did you actually change the path? i executed the script up to the point where i get the error, and used ultra edit to replace all occurences of “C:\gccvb\bin” with “/cygdrive/c/gccvb/bin”, then continued, but still get the exact same error.

I have C:\cygwin\bin added to my PATH in Windows, as well as created a variable GCCVB that contains “/c/gccvb” — you can change these variables by going to My Computer->Properties->Advanced->Environment Variables in XP.

I’ve built the toolchain in Vista once before and I believe the procedure is very similar. You shouldn’t have to change anything in the tarball or the make_v810.sh script at all.

KR155E wrote:
has anyone successfully installed the new gccvb on vista yet? i am using a full cygwin installation and follow the guide, but keep getting the following error:

/bin/sh: line 5: C:gccvbbin: command not found
make: *** [all-libiberty]
Error 127 Error: building binutils

I think Cygwin interprets the backslashes in “C:\gccvb\bin” as escape characters… I ran into this problem and changed the path to a UNIX-style “/c/gccvb/bin” — note the use of forward slashes. This seemed to fix my build errors.

I also have MSYS installed which I think allows the C:\ = /c convention to work, so you might have to use /cygdrive/c instead.

HTH. 🙂