You are not logged in.
Lost Password?

All Posts (blitter)




#1
Re: Post pics of your VB Collection
Posted on: 4/30 6:56
Nintendoid!
Joined 2007/12/14
152 Posts
CoderLong Time User (8 Years) App Coder
An UncleTusk Dragon Hopper box, cool! Too bad the ESRB icon on it is placed in violation of guidelines. :P
Top

Topic | Forum


#2
Re: A newer GCC compiler.
Posted on: 4/21 6:03
Nintendoid!
Joined 2007/12/14
152 Posts
CoderLong Time User (8 Years) App Coder
Quote:

ElmerPCFX wrote:
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.


Top 32KB? Is that because the displacement is signed? What if gp was set to the middle of WRAM? Then all variable accesses (minus constants of course) could be in the ZDA section. :)
Top

Topic | Forum


#3
Re: A newer GCC compiler.
Posted on: 4/20 4:10
Nintendoid!
Joined 2007/12/14
152 Posts
CoderLong Time User (8 Years) App Coder
Quote:

ElmerPCFX wrote:
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.


I'm not. ;) I write everything in assembly. And you're right-- gccVB doesn't know a thing about SDA variables.

Quote:

Are you only accessing variables from assembly language that way?


Yep.

Quote:

Are you using your own linker script?


Yep. I've attached it, though I can't say I'm all too proud of it. I just tweak it here and there.

Quote:

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.


Do tell! Shifting my ROM up to that area costs me nothing, so if there are extra benefits I'd love to know what they are.

Attach file:


ld vb.ld Size: 1.42 KB; Hits: 5
Top

Topic | Forum


#4
Re: A newer GCC compiler.
Posted on: 4/19 5:03
Nintendoid!
Joined 2007/12/14
152 Posts
CoderLong Time User (8 Years) App Coder
Quote:

ElmerPCFX wrote:
I personally favor doing as-little-as-possible in crt0.S, and leaving non-critical startup functions to calls inside main().


:)

Quote:

The VirtualBoy docs are pretty insistent that you wait 200us before accessing WRAM, and I don't see that crt0.s is actually complying with that warning.


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.

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

Quote:

I can't see that the linker script is actually mapping the .sdata/.sbss sections into the VirtualBoy's WRAM, and I certainly don't see the GP register being set to a "reasonable" value for using GP-relative addressing.

Unless I'm missing something, that means that all your C variable accesses are going to go through slow 32-bit loads, which seems like a terrible waste when you've got the capability for fast-access to 64KB of GP-relative variables.


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. ;)
Top

Topic | Forum


#5
Re: A newer GCC compiler.
Posted on: 4/18 8:22
Nintendoid!
Joined 2007/12/14
152 Posts
CoderLong Time User (8 Years) App Coder
For example, here is a crt0.s that I use for a small project I wrote to test the timer interrupt. It assumes an interrupt handler exists at $07000000 (in my case, provided in a separate .S file) and enables the instruction cache immediately before jumping to it. However if the timer interrupt is not used, that vector can easily be stubbed out as the others are.

Attach file:


s crt0.s Size: 3.58 KB; Hits: 14
Top

Topic | Forum


#6
Re: A newer GCC compiler.
Posted on: 4/18 8:15
Nintendoid!
Joined 2007/12/14
152 Posts
CoderLong Time User (8 Years) App Coder
IMO the startup code that comes with 2.95 (and thereafter crept in to version 4 and later) already does way too much. All the crt0.s file *must* do, from my own experiments, is initialize the registers, set up the data and bss sections, provide the vector table, and call main(). That's it. The 2.95 crt0.s does a whole bunch of other possibly unnecessary stuff like clearing VRAM, clearing audio RAM, setting the column table, etc. With *maybe* the exception of the column table, these things should be done as necessary either at the beginning of main() or where appropriate. I don't use the crt0.s that comes with gccVB but instead provide my own as tailored to the specific project. This includes the interrupt handler as well-- in many cases I don't even use interrupts at all, so I stub out those vectors with reti instructions. I figure since each project needs its own crt0.s anyway because of the ROM info table, I may as well customize it to the project's needs.

Maybe the ROM info table doesn't belong in crt0.s. It should be possible to create a separate .s file that when assembled just contains the ROM info table, and then place that in its proper location within the ROM at link time. In any case, I don't know where this base crt0.s came from, but I think it could stand to be pared down quite a bit.
Top

Topic | Forum


#7
Re: Steps for a Swift iOS developer to make a VB Game
Posted on: 4/6 6:27
Nintendoid!
Joined 2007/12/14
152 Posts
CoderLong Time User (8 Years) App Coder
Quote:

Nitrosoxide wrote:
If Xcode supports writing C code... couldn't I write my C Programs in Xcode?


You can use Xcode as a glorified text editor, but that's it as far as the VB goes. You will need to then drop to a command line to use a V810-patched version of GCC to compile your C code for the V810, since Xcode is hardwired to use Apple's tools. If you like using IDEs, then I prefer Eclipse (or TextWrangler/BBEdit in a pinch).

Quote:

I don't think learning a high-level language like Swift was learning with the "crutch of a modern high-level language ". Honestly, learning it has made a lot of basic programming concepts accessible to me, like variables, functions , etc. None of this made sense before and I've tried to learn to program many times.

A lot of that is thanks to TreeHouse's great lectures on Swift. They have really good visual animations that make it a lot easier to grasp the basics. I highly recommend their lectures.

It's the first place that made this stuff make sense and I actually went to a paid school for programming, which was a colossal rip off / waste of time.

If anyone's interested in Treehouse: Here's referral link that gets me a discount if anyone's interested in a free month.
http://goo.gl/s5mNb3

Having a good grip on Swift and glancing at an overview of the C Programming language... well it's not super different from basic concepts I learned in Swift..
Functions, loops, etc , I know what all these things are.


As Swift can get me employed for iOS development, it's a skill I want and am happy to have.
Learning C is another great skill to have.

And it mixes with Swift since I can when creating programs, Swift and Objective-C and C code can be used in a single program. I can directly use C from Swift.


Learning how to play piano might help me learn music, but it's not going to develop my trumpet embouchure. Yes Swift and any number of other programming languages can teach basic concepts, but if you think that continuing to focus on mastering Swift will make you a better VB programmer, then you're wasting your time. Learn C.

Quote:

By "solid coding background" what exactly, what would you say helped you the most before you tried tackling VB or while adjacently tackling it? Is all I really need just a good C foundation?
Or are there specific areas to focus on in C?


Probably my 20 years of programming experience, but don't let that discourage you. As HorvatM and thunderstruck pointed out, games can be written entirely in C and libgccvb provides convenience functions that can abstract away some of the nitty-gritty confusing details. Ultimately though, it's important to understand that consoles built prior to around the 2010s were very specialized machines and as such, coding for them was and is very different from coding for a traditional PC or smartphone architecture with standard video, sound, and audio interfaces. The Virtual Boy (and I believe the N64) shipped *without an operating system*-- everything had to be provided by the programmer. Contrast this with a framework like SpriteKit, or an engine like Unity, where as ElmerPCFX so eloquently put it, "60% of the work"-- the hard, low-level engine stuff-- is already done for you.

A good C foundation will go a long way to helping you write your first Virtual Boy application. C is a pretty simple language-- there's not really "areas to focus on" so much as there are not really areas to focus on in, say, English. Take ElmerPCFX's advice-- grab a copy of K&R C from Amazon, pore through it, and write some simple command-line based PC apps in C first to get a grasp of how to "speak" C. After that, then you can dip your toes in the red and black pool, so to speak. :)
Top

Topic | Forum


#8
Re: Steps for a Swift iOS developer to make a VB Game
Posted on: 4/3 23:20
Nintendoid!
Joined 2007/12/14
152 Posts
CoderLong Time User (8 Years) App Coder
The Virtual Boy is based on the NEC V810 32-bit microprocessor. To write software for the VB you typically use GCC, which is a free, open-source compiler suite. GCC takes your C code and generates V810 assembly instructions which are then assembled to native V810 machine code intended to run directly on the Virtual Boy's CPU. From there the machine code is fed to a couple more auxiliary tools which package the code into a ROM file readable by an emulator such as Mednafen (or burnable to a FlashBoy). The Tech Scroll I linked details the memory map and hardware registers of the Virtual Boy itself, which when read/written according to the spec will make the Virtual Boy do the special functions it's known for.

The Virtual Boy doesn't have an API or anything analogous to SpriteKit or other high-level frameworks. Anything that isn't handled by the hardware itself has to be written, from scratch, by the programmer in software. There's no C standard library, no STL, nothing.*

(*Well, there are some community-contributed utility and convenience functions in libgccvb, but I typically just hit the memory and registers directly for better efficiency.)

The closest thing available to a Virtual Boy development "tutorial" is the Development Wiki found here: http://www.planetvb.com/modules/dokuwiki/doku.php But ultimately this will point you to sample code which when reading is the best teaching tool available.

If you're expecting some kind of guide that holds your hand every step of the way-- sort of a step-by-step Virtual Boy "Hello World" from start to finish-- I don't think that exists. Homebrew in general, not just for the Virtual Boy, presumes you have a solid coding background and also makes the assumption that you're willing to get your hands dirty in reverse-engineering and bootstrap your own development environment. In my case, I build GCC from source code, install Eclipse, set up a Makefile-based project, write Makefiles that point to my GCC toolchain, then from Eclipse I can edit my code and Makefiles, build my project, and launch my ROM from Mednafen to debug (in assembly, no less). But that's certainly not the only setup, and likely not a very common one since I do my development on a Mac and most VB developers use Windows.

The Virtual Boy is not a good platform to learn to code on, but if you insist, I would recommend finding a Windows machine or VM, going to the Development Wiki I linked above, setting up a development environment using gccVB 2.95 (for now), and trying to build the samples linked under the "Getting Started" section. You're going to find the most support from this forum when using the Windows-based tools.
Top

Topic | Forum


#9
Re: A newer GCC compiler.
Posted on: 4/2 7:19
Nintendoid!
Joined 2007/12/14
152 Posts
CoderLong Time User (8 Years) App Coder
Quote:

ElmerPCFX wrote:
Quote:

blitter wrote:

That is a cool trick! I hadn't thought to investigate the in.* instructions to see what they actually do. I'll have to use that in my projects now, thanks. :)


It's a nice trick since Nintendo made the I/O address space just by a copy of the normal address space ... but note that you don't save the extra cycle on multiple loads that you do with the "ld" instruction.


Do you mean grouping "ld" instructions together to speed up the data fetch pipeline? "in" doesn't follow those rules?
Top

Topic | Forum


#10
Re: A newer GCC compiler.
Posted on: 4/1 5:20
Nintendoid!
Joined 2007/12/14
152 Posts
CoderLong Time User (8 Years) App Coder
Quote:

ElmerPCFX wrote:
The compiler doesn't really seem to understand that "ld.*" is automatically sign-extending a 16-bit/8-bit read from memory.

The compiler doesn't know that it can use "in.*" on the VirtualBoy to zero-extend reads from memory (that trick won't work on the PC-FX).


That is a cool trick! I hadn't thought to investigate the in.* instructions to see what they actually do. I'll have to use that in my projects now, thanks. :)
Top

Topic | Forum