Well, I’m not good with C++11, and in my experience dealing with GCC’s machine descriptions is easier than dealing with LLVM IR.

Nevertheless, since this a months-long thing, it’s worth a try, and I already have my own personal fork of LLVM to play with.

I’m just going to go ahead and use my best judgment to combine the incompatible patches.

Most of the work is obviously done… my first step is to examine the machine description language and see if I can’t figure out what’s going on.

Against my better judgment, I may attempt to just port against a clean GCC tree- I recently figured out how to add a dummy i8086 (not a typo) target just for kicks, and it’s not like the .md format has changed significantly. It’s more work though :/.

Also, I want to make something clear- this is a project that will take me months on and off working on it. Mainly getting used to the GCC source tree and finding things that work and things that don’t. But it’s worth a try, just to say I did it :P.

Using an Ubuntu 12.04 machine…

Binutils compiled ok with blitter’s script, since -Wno-error was on :P.

JWeinberg’s patch to the predicates machine description file does not apply correctly:

What gcc/config/v810/predicates.md actually contains (line 79):

(define_predicate "special_symbolref_operand"
  (match_code "symbol_ref")
{
  if (GET_CODE (op) == SYMBOL_REF)
    return (SYMBOL_REF_FLAGS (op) & (SYMBOL_FLAG_ZDA | SYMBOL_FLAG_TDA | SYMBOL_
FLAG_SDA)) != 0;
  else if (GET_CODE (op) == CONST)
    return (GET_CODE (XEXP (op, 0)) == PLUS
            && GET_CODE (XEXP (XEXP (op, 0), 0)) == SYMBOL_REF

            && GET_CODE (XEXP (XEXP (op, 0), 1)) == CONST_INT
            && CONST_OK_FOR_K (INTVAL (XEXP (XEXP (op, 0), 1))));

  return FALSE;
})

What the JWeinberg’s patch thinks is at that location:

(define_predicate "special_symbolref_operand"
   (match_code "symbol_ref")
 {
+  if (GET_CODE (op) == CONST
+      && GET_CODE (XEXP (op, 0)) == PLUS
+      && GET_CODE (XEXP (XEXP (op, 0), 1)) == CONST_INT
+      && CONST_OK_FOR_K (INTVAL (XEXP (XEXP (op, 0), 1))))
+    op = XEXP (XEXP (op, 0), 0);
+
   if (GET_CODE (op) == SYMBOL_REF)
-    return (SYMBOL_REF_FLAGS (op) & (SYMBOL_FLAG_ZDA | SYMBOL_FLAG_TDA | SYMBOL
_FLAG_SDA)) != 0;
-  else if (GET_CODE (op) == CONST)
-    return (GET_CODE (XEXP (op, 0)) == PLUS
-           && GET_CODE (XEXP (XEXP (op, 0), 0)) == SYMBOL_REF
-           && ENCODED_NAME_P (XSTR (XEXP (XEXP (op, 0), 0), 0))
-           && GET_CODE (XEXP (XEXP (op, 0), 1)) == CONST_INT
-           && CONST_OK_FOR_K (INTVAL (XEXP (XEXP (op, 0), 1))));
+    return (SYMBOL_REF_FLAGS (op)
+           & (SYMBOL_FLAG_ZDA | SYMBOL_FLAG_TDA | SYMBOL_FLAG_SDA)) != 0;

   return FALSE;
 })

Perhaps this was an oversight that wasn’t caught? I only found it by accident, tbh.

[cr1901]

blitter wrote:
See also this post: http://www.planetvb.com/modules/newbb/viewtopic.php?post_id=30370#forumpost30370

Oh look, me bringing the exact same topic up months ago and not following through XD. What else is new in my life?

Erm, do you know if the 4.8 patches are floating around?

I have a Linux box in the living room. I think I want to massage the patches out on that before I attempt a MinGW build. One problem with MSYS for me is that builds using ./configure and make are slow as molasses due to POSIX emulation.

EDIT: I found your download link which includes just the patches. This permits me to apply to a unmodified source tree which is exactly what I wanted. Nice!

Where did the files binutils-2.20.1-vb.patch, gcc-4.4.2-vb.patch, and newlib-1.17.0-vb.patch (without authors appended) come from? Were those from back when v810 support was in the main tree?

EDIT 2: Is there any particular reason that the newlib patch needs to be 300kB? Most of the patch seems to be autoconf macros and other build system BS.

• This reply was modified 9 years, 1 month ago by cr1901.
• This reply was modified 9 years, 1 month ago by cr1901.

VirtualChris wrote:
Work on this began several years ago when I was just getting into C and learning about it. That’s why much of the code is (apparently) unreadable and looks the way it does. I don’t want to change it because it works and I may break something if I attempt to. Since work begun on this, I have learned stuff about C I would have never known. I want to work on this project again, but I don’t know what to do next.

The one thing I can suggest from experience: don’t do a rewrite. Slowly go through your code that already works and massage it into a more readable form, making sure that you don’t remove the working logic before ensuring that your changes are functionally equivalent.

See: Netscape for what happens when you DO do a rewrite :).

That said, the commas (manual sequence points) as a substitute for semicolon (statement termination) in the original second-to-last line do amuse me for some reason.

KR155E wrote:
The gamiac project hurts to cancel after several years of development and before it could even open its doors. The vision was to scale up the concept of PVB and create an in-depth multi system game database plus social network like community features. It would also have been a network of websites with a central user account where each site (like PVB would’ve become one) has its own niche and pulls only the data relevant to the covered system(s) from the central database. It was largely finished and not too far from release, but getting it out and maintained would’ve killed me. I guess it was a way too huge undertaking for a single person after all.

Certainly I understand changes in private life, but why not put the project on the backburner for the time being until things are more settled (while still rolling out the PVB code)?

I mean, a project like this in and of itself will be relevant for a long time to come :). See: Planet VB :P.

In case you didn’t know:

The cat sprite is not hidden. It appears if you have the misfortune (really, the only difficult opponent in the game) of battling him again during your title defense.

The cat’s name is Milky, and his robot’s name is Bamsham.

With that said… REALLY nice find!

I HATE to be the one to bring this up, but perhaps it’s time that some of us take a look at GCC internals to see what’s going wrong? I’m taking a bit of a break from VB coding (call it “guilt that I’m letting my other code rot”) anyway, and I probably could take a look if I had some code that is known to generate bad jumps.

Alright, my Python tool for converting BMPs to C is working (not as user-friendly as HorvatM’s but it does the job for automating asset conversion). First thing I did was take the focus screen, split it into two, and add parallax. This was the result: http://imgur.com/VBeYXxE

I have attached the BMPs and generated C files (same conventions as list time). I feel this focus screen’s much better! Thanks for the suggestions. 🙂

Attachments:

1. 

   vblogo_l.bmp
   

2. 

   vblogo_r.bmp
   

1. vblogo_r.c
2. vblogo_l.c
3. cfoc-1.c

Kick. Ass! Mind if I use it for my Focus Screen asset?

blitter wrote:
I’ve built gccVB 4 under OS X, both PPC and Intel, and combined with Eclipse is how I do all my VB development. The FlashBoy software though is relegated to a PC with I believe a flaky motherboard, so I’ll have to find a solution for that one of these days. As far as I know the FlashBoy software is Windows-only, so you’d either have to use WINE/CrossOver or write one yourself– seems somebody has figured out the protocol… http://www.planetvb.com/modules/newbb/viewtopic.php?topic_id=3673&post_id=8666#forumpost8666 …

Has anyone gotten FlashBoy to work using WINE/CrossOver?

In any case, I suppose it doesn’t matter- system board was replaced, and now my setup is back to pre-failure state. Lenovo worked incredibly fast o.0;- failure to fixed in 4 days- I’m impressed.

RunnerPack wrote:
It looks pretty cool, but it lacks the grid of pixels that make it easier to adjust the focus, and two of the corners aren’t as visible, which might make it harder to adjust IPD.

No problem, I can always edit the post later. I’ll just open PAINT.NET and… oh… XD

Jest aside, when I have access to my Windows OS again, I’ll add an extra layer for the grid BG and make all 4 corner the same. Additionally, the real focus screen has two corners visible for each eye (necessitates two BGs or 16 (4corners*4objects) objects + 1BG).

I don’t think Pinta is going to be able to do what I want, but I’ll see.

Fishbone was cute and fun, Faceball I didn’t enjoy too much, but I’m glad it exists b/c it proves a 3d renderer with filled objects for VB is possible.

Bound High was AMAZING. Wish it was released for real (or CIB was still available).

I wonder if a Dragon Hopper prototype will ever show up…

RunnerPack wrote:

cr1901 wrote:
[…] my […] hard drive […] decided to go kaput, and I cannot reliably boot into it. […] There is a possibility that I’ll be going back to Unix full time.
[…]
Fun while it lasted, but this is beyond my control :/.

I don’t get it… are you trying to say that Windows ruined your HDD? If you’re going to get a new drive to install Linux on, can you not just as easily reinstall Windows (and the VB dev tools) to it, as well? None of this sounds “beyond your control” to me, so I must be missing something.

I left out some details, but in the worst case, I will have to send out my laptop for repairs- the last time I did that, it took me a month to get everything back to normal prior to my hw issues.

It’s less of an issue of reinstalling everything and more that “real life doesn’t stop because my laptop is busted.” Also, I had a number of things fine-tuned for my UI that chances are will be lost, and will have to do intense Googling to figure out again :P.

I have spare Linux hard drives, so there’s no need for an adjustment period- I tuned them/set them up for my preferred use a long time ago :P.

TLDR; I just expect to be busy- and this really wasn’t something I needed to break my concentration writing code.

HorvatM wrote:
It compiles and links fine with GCC 2.95.2 (or at least it seems to in the simple test I used). However, it complains with “video.c:26: warning: `/*’ within comment”.

Oops… will fix in a bit.

SOUNDREG contains explicit padding, and everything is byte-sized. Everything in WA (WORLD, actually) is halfword-sized, and it’s a power of 2 in size, so what’s the problem?

Nothing, because the logic of why padding is the way it is is sound :P. It’ll PROBABLY work in VUCC (as long as they use the same logic as you/GCC do for padding), just no guarantees, and I have no means to test.

I don’t see the inline keyword being used anywhere.

I defined it out using a macro for now :P.

As for inline assembly in VUCC, if you search for “asm” in CGRIND.EXE with a hex editor, it seems to support it, as well as literally implement Greenspun’s tenth rule. 😛

I think I don’t want to know…

Still interrupt vector logic will need to be changed- I highly doubt VUCC implements the interrupt vectors as extern variables embedded in its runtime like GCC does (which is also technically undefined behavior in ANSI, but few compilers are that “broken”- I’ll have to see if VUCC accepts converting fcn pointer to void/data ptr when I can test).

Does VUCC not accept int main?

I do not have the means to test right now. I simply went by what the “Sample Soft for VUE Programming” source did, which uses void main(). Again, neither one is wrong, but it may be confusing to those who decide to use VUCC.

Just wondering- has anyone attempted to compile and link against the github-host libgccvb using GCC 2.95 or another version besides GCC 4.4?

I’d like at some point to see the library also be VUCC-compatible (for authenticity :P), but there are a few things that would need to be altered.

In particular, the SOUNDREG and WA structs quite possibly will not work as is. Since compilers tend to add padding to speed memory accesses up, and both the listed structs depend on having no padding whatsoever, I’m a little surprised that they work at all (the sad souls- errr, dedicated hobbyists- who ported GCC did their homework 😉 ).

Additionally, there are a few GCC extensions used in the code, particularly inline, asm- these can be conditionally defined depending on the compiler used. I do not know what extensions to ANSI C that VUCC supports, but I highly doubt it supports all of GCC’s extensions. From what I gather (Googling :D), VUCC was a compiler that Nintendo contracted out to Green Hills. The assembler was from Intelligent Systems. As described below, assembly dependent code may simply not be shareable between GCC and VUCC.

The signature of main() also differs between VUCC (void main) and GCC (int main). Since they’re both freestanding, neither of them are wrong (ANSI says it’s compiler-defined), but perhaps a macro could be defined which uses one signature or the other depending on the detected compiler?

Lastly, can someone tell me WHY the interrupt vectors are defined in the C runtime for gccVB (RunnerPack??! I’m 99% certain that the way interupt vectors are assigned will not work with VUCC. I know GCC doesn’t have a problem with this, but converting fcn pointer to data ptr is undefined in ANSI C (has something to do with Harvard Architecture support or something? Idk.). From the sample demo code, interrupt vectors seem to be defined in a separate asm file for VUCC.

Any thoughts? Since my original post, I’ve learned that a number of people contributed to libgccvb in the past- perhaps new functionality can be added for ease of “jumping into VB.”? Besides the 6 simple demos, of course :P.

Part of what bothers me re: using emulation as a hardware replacement (i.e. Hardware with a CPU/OS kernel solely dedicated to console emulation) is that consumers WILL most probably stumble upon behavior that’s not consistent with the real hardware. That breaks the immersion and authenticity of the experience of the consoles being brought back from the dead.

The only emulator I’m aware of so far that can justifiably advertise itself as cycle-accurate is higan (the SNES portion specifically). In short, I wish there wasn’t a market for these types of products until more consoles are emulated to the cycle-accurate level.

As for the Retron 5, don’t waster your time on that or really any Reproduction console. They’re all cheaply made pieces of junk. Spend the extra money and buy the real deal.

While I agree in general with that statement, I think in the next few years, the state of Genesis emulation will be such that cycle-accurate (or near-cycle-accurate) FPGA implementations will be realized.

Re: the Retron5… well, from what I understand, it doesn’t actually READ the cartridge in real time, but compares the cart checksum to an internal database. That seems a bit dishonest to me- you are essentially paying for a form-factor without the ability to archive your (legal) ROM collection.

Retrode has a similar principle, but that has no delusions in being a 5-in-one hardware console.

In addition, most of the code that Hyperkin used for the emu cores was used illegaly: http://www.libretro.com/index.php/retroarch-license-violations/

Greg Stevens wrote:
Maybe I’m being too simplistic but if just need to count down ticks and it needs to be able to grow dynamically why not use a linked list of “timer counters”. Add nodes to the list when you start the “event” being timed, subract 1 tick from each counter in the list, when you hit 0 remove the node and handle the event. There will probably still be a limit of some sort for max timers 50, 100 and just use that max for an array of available counters. Im writing from my phone so I won’t be sending any code examples and I’ve never tried it so its just an idea/theory

I did exactly that, insulating the game logic code from the timer driver using an interface. I got a base driver done tonight, and it works! For those who want to see it, you can find the relevant commit and files here.

The relevant files are:

include/backend/timedriv.h
include/intrface/timerif.h
src/drivers/timedriv.c
src/gamemode/focscrn.c
src/timerif.c

All the code does right now is make sure the game loop waits two seconds using the timer driver callback before continuing. It’s a toy example that REALLY doesn’t need this sort of framework, but more complicated examples will let me update multiple objects and conditions asynchronously, especially the sound registers.

As is, the function run_inuse_comparators() pseudo-implements the Observer Pattern, hence the struct TIMER_OBSERVER in include/backend/timedriv.h. If anyone has any feedback, I’d appreciate it :).

… I REALLY wish I didn’t need to declare all those volatile void pointers though XD.

Weird. Anyway, do you immediately jump after sei?

No, the code attempts to set up a call frame (below the frame set up to enter the jump_to_reset() C function) before the unconditional jump. This indicates to me that the absolute address called is SUPPOSED to end with a “jal” instruction.

Now that I think about it, the function I used to jump to the reset vector is probably not meant to be used with code that doesn’t expect to return.

And for once in my life, I didn’t mess up the SEI/CLI order :P.