FWIW, I have just updated the V810-GCC project patches and build scripts on github to work with the current GCC v10 compiler that is used on recent distributions of Msys2 and Linux.

Enjoy! 🙂

jorgeche wrote:

I already compiled it on macOS Mojave, but I didn’t really documented the process and it was kind of messy and hackish since I had to even modify one of the config.guess files, among other things.

Congrats! I hope that the changes that I made to get it compiling on linux, will make it easier for you to build it on OSX in the future.

The hard part will be, first, to customize the memory handling since I don’t have enough experience on the inners of C++’s compiler and linker so I don’t know if it is possible to instruct it to allocate the virtual tables in specific memory regions or even if they can just be computed at compile time and placed in the ROM area (we load them in DRAM instead of WRAM because they amount to more than 10 KB and they are populated at runtime); and second, to handle the allocation of dynamic objects, although I guess we just have to override the new operator and just use our own MemoryPool to avoid the usage of the heap.

VTables are always constructed at compile-time. For speed on the VirtualBoy, you’re going to want to have the linker put them in either the ZDA section, or the TDA section so that they can be addressed in a single instruction relative to the R0 or R5 registers.

Putting them in the R0 section would be best (IMHO), at the top of your mirrored ROM space so that they show up in the $FFFF8000-$FFFFFFFF region. But, IIRC, that would mean that you’ve have to do some fiddling about with your linker script.

Even then, I’m not sure that VTables are marked at register-relative by the compiler … that may need another hack into the GCC source code.

The recent version of the patches has already started the process of making it possible to distinguish between the VirtualBoy and the PC-FX, so that I can take advantage of your system’s ability to load unsigned bytes-and-words without masking off the high bits afterwards.

KR155E wrote:
I guess we now have a foot in the door for Linux (and possibly OSX) versions of VBDE. 🙂

Yep, I had to change/fix a bunch of things to get the Linux compilation working again, and those should probably help the compilation on OSX.

I also fixed (or at-least tried to fix) a couple of bugs in GCC 4.7 that compiling on the latest GCC brought to light … and generally cleaned-up the code to fix the warnings (or silence them if they couldn’t be fixed).

I’ve found a site talking about how to compile GCC on OSX, and I may take a look at it myself if somebody doesn’t beat me to it!

I really hope that you guys take a look at using the C++ support in VUEngine since you’re already using an object-oriented design.

Using basic Embedded C++ language features should allow you to make your code a lot more readable/debuggable than using all of those cunning-but-fragile macros.

HorvatM wrote:
You can already change the font size in the configuration file. I must be missing something.

Yes, you are.

Sure, you can change the disassembly font size in the Mednafen configuration file, but you can’t change the register font, or watch font, or trace font, or the register alignment, or the memory editor font … and you certainly can’t make it use a larger debug display.

But what I would really like is the ability to have a large debugger display without also having to stretch the game display. I have to stretch it 3 times vertically to fit the debugger with a 9×18 font, but then games are almost impossible to play/test.

You would have to change how Mednafen calculates the window size to use … but that could possibly be done. If you really want it, then you have the option to dig into the source code and make it happen!

And pressing Esc shouldn’t quit the emulator when I’m in the debugger!

The same with this … if you don’t like it, then change it. Compiling Mednafen is really pretty easy, especially since I’ve provided a build script that you can change if you desire.

As folks here may know, VBDE and VUEngine have been using my GCC 4.7 toolchain for a couple of years now, and so I consider it stable-enough for a public release.

I’ve created a project on github for the patches and build script, and have confirmed that you can build the toolchain cleanly on both Windows and Linux.

You can find the project here … v810-gcc

For the adventurous, you can now compile C++ code.

Limitations are that there is no STL, and exceptions are not supported … but that isn’t much of a practical problem on something like the VirtualBoy (where you would be well-advised to limit yourself to the Embedded C+++ language subset).

You need to do a couple of things in order to get compiled C++ source linking correctly, and there is an example of that in the “examples” directory of the “liberis” project for the NEC PC-FX console, also on my github.

Have fun!

This would only be for development/debugging usage, and not for actual cartridges.

It’s questionable whether it’s even needed on the VB, since you can just make the cartridge image bigger … but it never hurts to have more ram for debug traces.

Putting it in the $04000000-$04FFFFFF region seems like it should be pretty safe.

OK, thanks! I guess that I’ll find another way to increase the amount of the VB’s RAM (in the mednafen emulator, for debugging during development).

syncophono wrote:

Thanks, I’ll try it out! Where can I download your 4.7.4 patches so I can apply them to gcc?

I’m sorry, because I know that it’s not the answer that you want … but I’d rather not just give out the basic GCC patches right now, but would prefer to wait for jorgeche and KR155E to release the next version of the VBDE (which includes an updated GCCVB).

That’s because jorgeche and I had to debug a few issues with GCCVB in order to get it to work with the new compiler.

I’m afraid that I don’t have the time or patience to go through that whole process again in order to support a separate GCCVB build.

You might try going to the VBDE thread here and asking them how they’re getting on with the new version.

Guy Perfect wrote:

dasi put together a devkit for V810 that outputs Virtual Boy and PC-FX programs. I’ve been working with him to get certain things implemented, but as I don’t really have much of a clue as to how GCC distributions work, it’s becoming rather out of date and could stand to see a newer build.

Interesting! I look forward to seeing it.

A proper release will include a PC-FX API in the same vein and fix all of the outstanding issues (such as the current incompatibility with the C runtime).

This obvious interests me the most … although I’m not sure exactly what you’re talking about.

If you’re trying to retain compatability with Hudson’s old 1990s PC-FXGA SDK, then I’m not sure of the value, since that means no homebrew without causing a copyright violation.

That’s the point of my work to continue Alex Marshall’s “liberis”, which provides the foundations of a fully open-source PC-FX library.

I’d love to get a committee together to weigh the pros and cons of combining the two devkit projects (GCCVB and devkitv810), but that would be stepping on dasi’s toes.

You may want to take a look at the next release of VBDE when it is made.

VBDE builds upon GCCVB, and jorgeche/KR155E are taking advantage of some of the features in GCC 4.7.4, and fixing/improving some of the things in GCCVB to take advantage of them.

syncophono wrote:
Hey everyone, how’s it going? I would love to start developing for the virtual boy, but is developing on Mac/Linux viable? It seems the only compiler that I can find on this site is available for Windows. Is the source code to GCCVB available so I can compile for Mac/Linux?

My GCC 4.7.4 patches should compile quite happily on linux, after all that’s what they’re supposed to be built on.

I still need to clean them up for an “official” release, but they seem to be quite stable now.

If you want a Mac toolchain, then you’d follow something like these instructions …

https://solarianprogrammer.com/2016/05/10/compiling-gcc-6-mac-os-x/

The older GCC 2.95 compiler that’s in GCCVB is something that I’ve not personally been able to compile with any reasonably-modern set of linux tools. Too much has changed over the years, and the GCC build process was failing for me.

As it was, it still took some hunting down of “compatibility” patches in order to get both binutils 2.24 and GCC 4.7 compiling with the latest GCC toolset.

Guy Perfect wrote:
Before too long, if dasi doesn’t rematerialize, I’m going to push the incomplete devkitv810 public so we’ll have something a little more accommodating for VB homebrew. devkitv810 is compiled for Win32, but works just fine through Wine on Linux/Mac.

Dasi has been missing for a long time now.

What’s his “devkitv810”, I haven’t seen mention of that before?

jorgeche wrote:
I’d gladly try your patches.

Thanks to jorgeche’s incredibly generous help, we’ve found and fixed 2 bugs in the compiler toolchain, 1 serious misunderstanding on my part, and 1 stupid typo.

VBJAEngine and the Platformer Demo are now compiling and running with GCC 4.7.4. 😀

[ElmerPCFX]

BTW, if you want some good information and ammunition to be wary of some of C++’s features …

http://yosefk.com/c++fqa/
http://yosefk.com/blog/c11-fqa-anyone.html

And honestly … as correct as he is (IMHO) … that’s still not a reason to avoid C++ entirely, just a warning to be careful in which features you do use.

• This reply was modified 8 years, 4 months ago by ElmerPCFX.
• This reply was modified 8 years, 4 months ago by ElmerPCFX.

blitter wrote:

Like I said, I don’t care what language you use for your own personal projects– if you love C and want to write in it, great! But starting a topic and making claims like “C is about as close as you can get to machine code without writing architecture-dependent programs, meaning it’ll be about as fast and memory-efficient as they come” and “While the difference in performance is negligible, there’s still a relevant impact when using C++ instead of C” is pretty disingenuous and a bit of a red flag to me.

I’m sorry, but I’ve got to agree with what Blitter is saying here … and I’m someone who treats a lot of C++’s features with suspicion or outright dislike.

In fact, when I program in C++ instead of C, I tend to stick to the features of the language that closely correspond to “Embedded C++” precisely to avoid the costs of rampant overuse of some of C++’s heavier weight features. (https://en.wikipedia.org/wiki/Embedded_C%2B%2B)

But, at the end-of-the-day … it’s still legal C++.

When you do a large project in C, you’re probably going to end up using C’s macros to solve some problems.

That’s fine … but that’s one of those language features that’s going to make porting to other languages much, much harder … not that anyone that I know in the normal world ever actually switches programming languages in a project, because not needing to is one of the major points of writing in a multi-platform high-level language in the first place.

The things that you’ve said, and the way that you’ve said them, really make me believe that you don’t have much experience in software development.

As such … frankly … I would suggest that you use C rather than C++, because you’re less likely to get into a mess of evangelized design techniques that just tend to make things over-complicated and sometimes fragile.

If you write a large project in C, then you’ll be in a better position in the future to judge which language features of C++ (or Java, or Python, or …) might have made things easier and cleaner, and which wouldn’t.

That will be a good programming lesson, and will help make you a better programmer in any language in the long term.

[ElmerPCFX]

Guy Perfect wrote:

Developers welcome, but even if I do the programming myself, I’m totally fine with that. Either way, the project will be open-source and a version-controlled source repository will be open to the public… well, it might be restricted to PVB members, but that’s public enough.

If you want to do it yourself, and have a personal passion to write an emulator, then good for you!

But if you just want a “better” emulator than what’s available, have you considered not throwing away the years of work that other people have done, and to actually save yourself a lot of time and build upon one of the existing emulators and improve it?

Any major project is a huge commitment in time. Lots of people start things, and then the projects die because all the details mount up and things get frustrating and no longer “fun”.

May I ask what major software projects have you completed?

Guy Perfect wrote:

One of my pet peeves with emulators is that they seldom have useful debugging tools. I like to do a lot of hacking, and when I have things like memory-access breakpoints or “step out” at my disposal, things get a lot easier.
…
Anyone else with a hacking background have anything to bring to light?

In the last couple of years I’ve used Mednafen to hack a large PC-FX CD game, and two PC Engine CD games.

Unless I’m hallucinating, it’s already got 70% of what you want, and the rest isn’t hard to add, because a lot of it is already supported on Mednafen’s other emulations.

For instance VRAM viewing/breakpoints don’t seem to work on Mednafen’s VirtualBoy emulator, but they do work on Mednafen’s PC-FX and PC Engine emulators. So the framework is already there, it just needs someone to add the missing bits for the VirtualBoy.

Might that not be an easier (i.e. more likely to happen) route than just starting from nothing?

Mednafen’s debugger certainly has room for improvement … which is why I spent the time to improve it for my own use, and intend to keep on doing so to add more new features.

But that’s because my goal is to use an emulator to do other things, and not to write an emulator.

You just have to be very, very careful to decide where it is that your programming passion (and capability) lies.

thunderstruck wrote:

It would be cool to have a more advanced emulator. Mednafen and Reality Boy are ok but especially when it comes to debugging I have to hop through a lot of loops right now.

May I ask what debugging features you are missing in Mednafen and Reality Boy, and whether you’ve actually tried to do anything about it?

• This reply was modified 8 years, 4 months ago by ElmerPCFX.

I’ll send you a PM soon, hopefully tomorrow.

Just got get something working in a different project and I don’t want to lose track of what I’m doing.

Recursion and variadic functions should be working fine in the new compiler.

Ensuring that “printf” worked properly was one of my big requirements.

Best wishes,

John

dasi wrote:

My GCC 4.7 port hasn’t received enough widespread testing yet to see what bugs I’ve introduced … but Alex Marshall’s “liberis” examples all work properly, and another user has ported a simple shoot-em-up to the PC-FX with no apparent problems.

. . .

If someone is interested in being the “goto guy” for a VirtualBoy version of my patches, then I’d love to hear it.

I’d be happy to help with that and put a build together for testing. There are a few reasonably large Virtual Boy projects around which should give your patches a good workout. 🙂

dasi

Well, dasi has had copies of my GCC patches for 2 months now with no feedback, and he hasn’t logged in here since early May.

If anyone else is interested in helping by testing them out on the VB, now’s the time to step forward!

ElmerPCFX wrote:

You’ll need to patch the linker/compiler (I’m not sure which one off-the-top-of-my-head) because it’s been set up for the PC-FX which has RAM at $00000000 and so starts allocating ZDA memory from 0 and not -32768.

I checked on this, and my previous message was wrong.

Everything seems to be working fine without any further mods to the compiler source … it’s all up to the linker script putting things in the right location, and in the user marking variables/data as belonging in the SDA/ZDA/TDA segments.

An example of doing this in both assembly and C is shown in the test interrupt code earlier in this thread.

blitter wrote:
Top 32KB? Is that because the displacement is signed?

Yes, the memory displacement is signed +/- 32KB.

So any negative references to R0 (which is 0) will wrap around to $FFFF8000-$FFFFFFFF (i.e. ROM space).

You’ve just got to tell the linker that you’re actually running in that location, and then make sure that the compiler/assembler is generating R0-relative instructions, which means putting things in the ZDA section.

You’ll need to patch the linker/compiler (I’m not sure which one off-the-top-of-my-head) because it’s been set up for the PC-FX which has RAM at $00000000 and so starts allocating ZDA memory from 0 and not -32768.

What if gp was set to the middle of WRAM? Then all variable accesses (minus constants of course) could be in the ZDA section. 🙂

That’s exactly where it is supposed to be set.

If you look at any VirtualBoy games that shipped, you’ll almost-certainly see that they do this in their startup code.

If you look at the original V810 GCC patches that we’re all basing our changes on, which are at …

http://hp.vector.co.jp/authors/VA007898/pcfxga/develop/gcc.html

Or just look at the V850 directory in whatever version that you’re using you’ll see this in the linker script …

binutils-2.24/ld/scripttempl/v850.s

  .sdata ${SDATA_START_ADDR} :
  {
	${RELOCATING+PROVIDE (__gp = . + 0x8000);}
	*(.sdata)
   }

That’s so that 64KB of variables/data can be used in the SDA section, which is exactly where you VirtualBoy guys should be putting all your WRAM variables.

You can get the compiler to do automatically with the “-msda=32768” switch, although you might want to use a smaller value, and/or just force specific things in there with “__attribute__¹”.

This is supported with the GCC 2.95 patches, and so I have no idea why the folks that converted the original PC-FX patches for the VirtualBoy didn’t use that capability.

***********

If you look elsewhere in the linker script you’ll see …

  .tdata ${TDATA_START_ADDR} :
  {
	${RELOCATING+PROVIDE (__ep = .);}
	*(.tbyte)
	*(.tcommon_byte)
	*(.tdata)
	*(.tbss)
	*(.tcommon)
  }

That’s for the R30-relative addressing on the V850 in the TDA section.

I’ve changed that in the new V810 patches so that you can get fast access to another 64KB of variables/data using the R5 (aka TP) register that was otherwise unused.

That could be another useful area for fast access to stuff in ROM on the VirtualBoy.

HorvatM wrote:
I can think of three:

1. Your interrupt vectors can consist of a single JR instruction.

2. You can load certain ROM addresses into registers with a single MOVEA instruction. Of course, this requires using a compiler/assembler that does not always mindlessly generate MOVHI/MOVEA pairs. MV810ASM doesn’t. 😉

3. If you arrange your data really carefully, you can load some of it (e.g. lookup tables) with a negative displacement from register 0.

Yep, those are the exact-same advantages that came to my mind, too! 😉

And if you want rewritable RAM-vectors for your interrupts, you can have them too just by putting the vectors right at the end of WRAM, and making them into “jr” instructions back into the ROM. There’s just-enough room to do that with the 26-bit offset in the “jr” instruction.

The GCC compiler should generate register-relative offsets if you tell it that your fast-access-data is in the ZDA section with “__attribute__²”.

Then you’d just have to fix the linker script to make sure that those sections really are put within the top 32KB of the cartridge.

These aren’t huge performance gains, but every-little-bit helps!

blitter wrote:
One thing is pretty apparent to me though: it doesn’t seem to have any other effects on the hardware.

It’s purely a restriction on using WRAM within the first 200us.

Page 4-5-1 “Chapter 5 – Cautions when Using work RAM”.

I’ve tested this particular project on real hardware many times, and never ran into problems. 200us translates to about 4000 clock cycles on the VB, which would pass long before the initialization of data and bss is finished. It is very possible that my luck is due to this project not being terribly dependent on the initial state of RAM, though, so if prematurely accessing WRAM produces garbage, my guess is it simply isn’t affecting my code.

The initialization of those data and bss sections in WRAM is precisely what developers are supposed to not do until 200us after power-on.

I just took a look at …

Mario Clash    : Delay of 65535*4 cycles, followed by 8 dummy read cycles.

Red Alarm      : Delay of 65536*4 cycles, followed by 8 dummy read cycles.

Vertical Force : Delay of 400*36 cycle divisions, followed by 8 dummy read cycles.

Now, I don’t know how folks are testing their code on a real VirtualBoy, but it could just be that whatever the flash-card is, it has a capacitor on the RESET line to stop the V810 from starting until 200us after the power is applied.

Or maybe everyone is just getting very lucky.

Either way … the current startup code would fail Nintendo’s Lot-Check.

For the VBJaEngine/GCC4.4 versions, you are correct. However in my version, notice that I set sp and gp to the same value– the top of WRAM. Thanks to WRAM being mirrored every 64KB, gp-relative accesses work just fine. 😉

Hahaha … good point, you fooled little-old me! 😉

But seriously … how are you telling the compiler that the variables in the .data section can be accessed GP-relative?

That’s one of the main reasons to put stuff in the .sdata/.sbss sections with the “-msda=??” compiler switch … so that the compiler knows to generate GP-relative code.

Are you only accessing variables from assembly language that way?

Are you using your own linker script?

***************

As a side-note, while taking my quick-look at Mario Clash and the other games, it was interesting to see that Nintendo programmed their game as if the ROM were mapped into the top of the 4GB address range (i.e. the ROM is $F0000000-$FFFFFFF), wheras Hudson and T&ESoft programmed their game as if the ROM were mapped into the bottom of the 4GB address range (i.e. the ROM is $70000000-$7FFFFFF).

There are a couple of potential benefits to programming the game to believe that it’s running at $F0000000-$FFFFFFF, although I can’t see that Nintendo actually took any advantage of it.