These are some good numbers!

IIRC, v810 is a 5-stage pipleine w/ no branch delay slot. Depending on v810 internals, that may add a cycle per loop for every branch that’s taken, because the next insn after the branch may have already been fetched and is invalid. This may even happen if the v810 has branch prediction.

IF you have not done so already, is there a program you can write to test the cost of a branch taken and account for this in your test program loops?

[cr1901]

Gonna try to prepare version 1.0.0 this upcoming week. Could anyone explain to me how the “Dev mode” of the original FlashBoy programmer application worked? What does it do differently compared to the standard flashing procedure?

EDIT: In addition, could someone test prog-vb with an _original_ FlashBoy (and not the Plus)? I either expect prog-vb to work without problems, or refuse to program it due to a different VID:PID and Configuration String.

In other news, I plan to add the following binaries to the 1.0.0 release:

* Win32/MacOS/Linux i386 (32-bit) binaries
* ARM32/64 binaries (so you can flash from your Pi, Pi clone, Pinebook, etc)

Anyone want to try testing prog-vb on other archs, such as PowerPC? Anything on this page can in principle be tested/have binaries created: https://github.com/rust-embedded/cross#supported-targets

• This reply was modified 5 years, 8 months ago by cr1901.

litephiter wrote:
I just tried out the Mac version with a few different ROMs, some padded and some unpadded. I didn’t encounter any problems. The games loaded right up, exactly as expected.

This is really excellent, because it makes the Flashboy a ton easier for me to use. Thank you for the effort you put into this app.

Let me know if there’s any further testing you’d like done in MacOS.

Excellent, glad to hear it works! I think that’s about it for testing until MultiBoy 32 comes closer to release! I’ll prepare a 1.0.0 release in the next few weeks! 😀

I have release v0.10.0 of `prog-vb`. The major difference here is that ROMs are now automatically padded if less than 2MB. Padding happens transparently to the user. Other differences can be found in the Changelog.

I would especially appreciate testing on homebrew and commercial ROMs < 1MB, and testing on Mac to flush out issues. If I don't hear of any problems in say, about a week, I'll finalize some last few changes and release v1.0.0. That should take us into mid-summer, when MultiBoy 32 is closer to release :D! Binaries for v0.10.0 can be downloaded here.

@litephiter

MacOS release is available here: https://github.com/cr1901/prog-vb/releases

Download the “prog-vb-v0.9.0-x86_64-apple-darwin.tar.gz” tarball and you’ll be good to go!

As I am not capable of testing on Mac, I would really appreciate bug reports/success stories using my tool :D!

[cr1901]

As promised, I have gotten Mac/Linux binaries uploaded to Github. The current v0.9.0 release- and future releases can be found here.

The Windows binary is about half the size of the one I attached here. Hmmm, I guess LTO makes that much of a difference or debug symbols were stripped? I’ll have to check!

Both the Windows and Linux binaries seem to run fine by a simple test (run the program w/o arguments). However, I am unable to personally test the OSX version, and I neither have OS X installed in a VM nor do I have Apple hardware.

Currently, I have uploaded 64-bit x86 binaries for Linux, OS X, and Windows. I have plans to upload Linux ARM binaries at some point so you can flash from ARM SBCs such as Raspberry Pi or Pinebook. If anyone needs any other architectures, such as 32-bit x86 binaries or maybe PowerPC :P, let me know and I’ll make a new patch-level release.

KR155E, if you want to add a screenshot, feel free to add this one :)!

• This reply was modified 5 years, 8 months ago by cr1901.

For those following along in this thread:

* The USB 2.0 error seemed to resolve itself.
* The first time run prog-vb on Windows 10, you might get that dialog. Click More Information and “Run Anyway”. There is not much I can do about this right now.

I’ll look into getting Mac/Linux builds running today. KR155E, is it possible that once I get Releases up and running (they will be provided by Github Releases), we could make a page under the tools section of the website a la FlashBoy Loader?

The “Homepage” would point to the Github Repo. The “Downloads” would point to the Github Releases page (unless there’s a mechanism- REST API, maybe?- to automatically mirror the most recent versions on PlanetVB after CI runs).

Piggybacking off this thread.

I tried to do my own display repair and failed; the flex cable came apart after I _just_ couldn’t get all the connections to work properly.

Is anyone willing to send me two displays which have been properly soldered? I don’t think I have it in me to ever try this type of repair again…

IIRC, Virtual Boy can display up to 4 shades of red at the same time from a palette of 256 shades (0 black, 255 full red). I think the VB hardware initializes the 4 shades to 255, 192, 128, and 0 (someone feel free to correct me), but you can change that if you wish. The higher the number, the more intense/bright the red is- the intensity of the red is what I mean by color drive.

Currently on my VB’s right display, what should be the shade of red corresponding to 255 (max brightness), looks more like, say, 192. And 192 looks more like 128, etc. But none of the colors are actually missing on the right display, so I’m guessing the VIP is reading the relevant palette entries just fine.

This would also be a symptom of the glue losing its effect?

I just want some clarification… it is normal when this problem occurs for one display to have weaker color output than the other display* in addition to horizontal lines? Or would this possibly be two different problems with my VB at once?

I noticed the horizontal lines years ago, but I decided to power up my VB as a test today and I noticed asymmetric color drive in addition to horizontal lines. My left display seems fine, but the right display seems to be in trouble :(. Might as well repair both. In any case, I want to try to repair myself, can anyone recommend a screwdriver for the deep screws?

* Noticable at the warning screen, for instance, which should have the same color intensity on both displays.

ElmerPCFX wrote:
void pointers??? They’re not declared as function pointers???

They’re u32s :P. I just called them void pointers b/c that’s really what they represent. https://github.com/cr1901/vbdemo/blob/master/src/drivers/timedriv.c#L110-L113

ElmerPCFX wrote:
OTOH … It’s getting really, really hard to compile a working GCC 2.95 anymore because modern linux toolchains barf on some of the early-GCC-specific code that’s in there. You pretty much need to find an old GCC 3.x compiler from somewhere.

This is a bit ironic, considering 2.95 can in theory be built with a K&R compiler. I recall there being a “make bootstrap” target in 2.95 that provides an alternate “Stage 1” for compilers that choke on the code?

Also, re: the interrupt handlers, the 4.4 startup code (presumably the 2.95 code as well) provides a few extern vars which map directly to where the CPU jumps on an interrupt. You create your interrupt handler in C, and then convert the handler’s addr to a void pointer and assign them to the desired external vector addresses.

[pedantic]Of course, this can’t be done in ANSI C, but because POSIX compilers require being able to convert function pointers to void, and since [jest]nobody cares about compatibility with VUCC[/jest], no harm done.[/pedantic]

I’m going to be perfectly honest: I’ve lost track of the number of GCC versions for VB there are lol. Perhaps we should document them somewhere in a sticky thread?

I can think of 4 offhand:
* 2.9.5 that’s existed for ages
* blitter’s 4.4
* Dasi’s 4.7
* Elmer’s 4.7

IIRC, the startup code is more or less the same between all but the last one (in fact, I believe blitter’s even reuses the 2.9.5 file for this and relocations).

Last year, I started my own port, that didn’t get far b/c of real life. I would be interested in trying an LLVM port tho at some point, even if it has already been done. V810 is one of the only CPUs where I could reasonably succeed in such a port.

https://github.com/cr1901/vbdemo/commit/bc7e1661e6866ed3376794c659a64428798432c3

If I compile the above unoptimized ROM and run it on a real Virtual Boy, I get different behavior compared to Mednafen. On a real VB, only whole lines are not drawn (and curiously, the lines which do not get drawn vary despite me syncing to XPEND). On Mednafen, parts of lines may be drawn before the scanner displays a column before this little program can plot the next point in a line.

I’m not sure how to interpret this, but it suggests to me that VRAM *is* in fact locked during drawing, or that the framebuffer display start is in general happening in between function calls to draw_line (plausible- create_point() spills into memory)

To save trouble compiling using SCons (it does require a bit of setup if you’re not used to it), I have provided the unoptimized ROM. The lack of optimizations is deliberate for now- there are more lines drawn than there is time to draw them (works fine on -O2; there are also plenty of optimization opportunities in O0). Also, create_point() isn’t exactly lightweight in its current form. When -O2 is enabled, the output looks like this:

I need to take hi-speed video of this. Seriously, do NOT watch on a real Virtual Boy for prolonged periods of time. I’m not responsible for any headaches.

Attachments:

1. vbdemo_pad.vb

What’s the difference between FRAMESTART and XPEND? I was confusing the two, and in fact if I sync to FRAMESTART (at which point, VIP calculations should occur), virtually nothing gets drawn to the screen. Are the display buffers locked while the VIP is doing calculations?

I set: WA[31].head = WRLD_END;, so the amount of time taken for the VIP to draw should be trivial (the only thing I can think of is that the VIP doesn’t acknowledge WRLD_END before my test routine is done plotting to possibly locked display buffers). Even the VB manuals says it’s safe to manipulate framebuffers after the VIP is done drawing.

FWIW, in my test code, O3 works correctly in Mednafen. So whatever that ld.w is doing doesn’t seem to be breaking anything. Won’t be able to test real hardware until later.

Okay, I’m officially confused now as to what GCC 4.2 is thinking here…

Consider the following code- loadfail.c:

#include "libgccvb/libgccvb.h"

void test_load()
{
	WA[31].head = WRLD_END;
}

-O0 produces the following:

	.file	"loadfail.c"
	.section .text
	.align 2
	.global _test_load
	.type	_test_load, @function
_test_load:
	add -4,sp
	st.w r29,0[sp]
	mov sp,r29
	movhi hi(_WA),r0,r10
	movea lo(_WA),r10,r10
	ld.w 0[r10],r10
	addi 992,r10,r10
	movea lo(64),r0,r11
	st.h r11,0[r10]
	mov r29,sp
	ld.w 0[sp],r29
	add 4,sp
	jmp [r31]
	.size	_test_load, .-_test_load
	.ident	"GCC: (GNU) 4.4.2"

Makes sense to me. -O1 to -O3 however, produce something rather weird to me.

	.file	"loadfail.c"
	.section .text
	.align 2
	.global _test_load
	.type	_test_load, @function
_test_load:
	movhi hi(_WA),r0,r10
	ld.w lo(_WA)[r10],r10
	movea lo(64),r0,r11
	st.h r11,992[r10]
	jmp [r31]
	.size	_test_load, .-_test_load
	.ident	"GCC: (GNU) 4.4.2"

Maybe it’s because it’s 4:30AM, but I can see how a load from a control register address (since _WA=0x0003D800, r10 holds 0x00030000 by the time ld.w lo(_WA) rolls around…) is going to help to get the right address of the World Attributes base register into r10 by any stretch of the imagination.

This isn’t a fluke either. By -O2, all address loads in all files seem to be replaced with this optimized form. I can’t really test right now, but doing a load from memory to generate a base address (instead of using movea) seems wrong. Can anyone possibly explain why this works?

EDIT: Wait a second, it’s in the unoptimized version too!

ld.w 0[r10],r10
addi 992,r10,r10

WHY is there a load to r10?! There’s absolutely no guarantee that _WA will be 0, and the addi might generate a bad address!

Yes, I’m glad I could fix a bug by recognizing that it is, in fact, not a bug :P. I do understand why it could be seen as a bug. I haven’t taken a look at the .md as to why this particular code sequence is generated.

Since a repeated JMP misses its destination by a power of two, I can’t help but wonder if that is related to the jump range of -/+32MB…

I think the notion of a crowdfunded CIB VB game is still too niche too succeed. I imagine a digital download (and maybe a port to that OTHER VR system everyone likes) will garner more attention.

Perhaps there is a way to get CIB manufacturing costs down though?

blitter wrote:
Off the top of my head:

1) Biggest problem so far is that GCCVB 4.x will sometimes generate relative jumps that are offset by some power of two ahead of where their proper destination should be. This becomes a huge problem when these jumps are executed repeatedly, as eventually the PC will wrap and wind up in video memory or elsewhere. I wrote a tool that operates on the final .elf file and attempts to correct these bogus jumps, but it’s more of a bandaid than a solution. http://www.planetvb.com/modules/newbb/viewtopic.php?post_id=31203#forumpost31203

3) Found a bug recently in the version of gas that ships with GCCVB 4.x where sometimes a bne instruction– written in the assembly source *as a bne instruction*– will assemble to a be and a jr instruction. There is no reason whatsoever that I can think of why this should happen.

I found a valid reason for 3): Branch instructions have a 9-bit displacement. Relative jumps have a 26-bit displacement. If it’s necessary to jump further than +/-256 bytes, you’ll have to do something like: be/jr.

As for 1), I haven’t looked into it, but is it possible that the gas port doesn’t take into account jumps that span further than +/-32MB? I don’t think GCC would know/care about that information. But binutils certainly would.