We're using cookies to ensure you get the best experience on our website. More info
Understood
@yeti_dudeRegistered April 28, 2012Active 5 years, 11 months ago
22 Replies made

So now just “worlds” and the framebuffer tabs?
The registers in the VIP are pretty extensive, will there be a tab that just collects all those together?

Great work Guy!

I’m trying to work out how you’re going to have to pull this off. The character memory looks good; I like all the options. So now you have to do the Background Segments, Object memory, and Windows. That’s going to be intense!

Since those sections of memory all reference char memory, are you going to be able to visually show each of those memory spaces? Maybe if you’re looking at a background segment, when you hover over a tile, you can see the values of all the fields in that cell.

And then with all the VIP registers, it would be cool to have those all transformed in to a readable table. It’s just too cool man!

Guy Perfect wrote:
This is a work post.

Right this moment, I’m sitting in front of the most progress I’ve ever made on this project. I can see what the CPU sees, and I can change registers and memory. It’s all fairly simple stuff (heck, it came together in a week), but it’s more than I’ve ever had in the past. At first it was trying to implement the emulation core with no real output for debugging, and then it was trying to figure out the best way to make a cross-platform GUI. But now… all of that’s been solved and new tech has been implemented. We’re about to dive into unswum waters!

What do you say we have us some graphics by the end of the week? That’d be cool, right?

Oh Guy! How many iterations of the graphics code have you managed in the past? You know it always takes a few whacks at it.

To Do – Week of May 7, 2018

Do it all. All the video things. While the VIP is by a wide margin the most complex auxiliary system component, it’s still far simpler than the CPU, which is already implemented. It has maybe like, I dunno, 20% as much going on as the CPU, so this should come together pretty quickly.

• Document VIP operations in the Tech Scroll

The vast majority of the content of the Tech Scroll is the CPU, but in a distant second place is VIP. It has several individual things that need to be researched and documented, but all-in-all it amounts to little more than a bunch of [font=Courier New]struct[/font]s.

Last time I was looking into this, certain behaviors resulting from abnormal configurations of VIP data structures were… perplexing and difficult to describe. For the time being, I won’t be trying to nail down everything in minute detail, so be prepared to see several editor’s notes calling for additional research.

Up until now, revisions of the Tech Scroll have used fairly descriptive names for I/O ports and logical constructs. In particular, I despise the name “world” for describing the windowing functionality, but I think it’s better in the long run to use the official names where available. KR155E rejoices, but let the records show that I decided in this way for reasons not related to his objections!

“Graphical elements are arranged into Windows, known in some circles as “worlds”, which themselves are arranged on the screen and can overlap with one another. The contents of Windows consist of the other types of graphical elements and various effects like clipping regions (analagous to “scrolling” on other systems) and affine transformations are available.” <- This is how the tech scroll reads right now. As you're rewriting the VIP portion of the tech scroll, make sure to switch over to KR155E and community's terminology.

• Implement a VIP debugger window in the emulator

I’m thinking a conventional tabbed dialog like other emulators have should be sufficient. There will be tabs for characters, background segments, objects, worlds, frame buffers, “current” (see below), the column table, palettes, miscellaneous (see below).

The characters tab will display all 2048 character patterns in a scrollable area with a selectable palette. They can be scaled to some degree (up to maybe 4x?), and clicking one will bring up its data in another panel for editing. The index, address and mirrored address of the selected character will be displayed.

The background segments tab will have a spinner for selecting or entering the index of a segment to display. The image itself will be displayed in a scrollable area with custom scaling. By clicking on a cell within the segment, the cell’s properties (character, flipping, palette, etc.) can be edited. The cell’s address will be displayed.

The objects tab will contain a spinner for picking a particular object, which is displayed in its appropriate position in a mock frame image. Its properties (character, flipping, palette, etc.) can be edited and its address will be displayed.

The worlds tab will contain a spinner for selecting a particular world, which is displayed fully-rendered in a mock frame image. Its properties (position, size, mode, etc.) can be edited and its address will be displayed. Additional controls for h-bias and affine worlds will be available where appropriate.

The “current” tab shows in a mock image what the next frame will look like whendrawn, with all worlds fully rendered and layered according to their order. Individual worlds can be toggled on and off in the display. Various statistics regarding the scene will be presented, such as the number of worlds, characters and objects that are in use.

Guy, you can do it! This would be a huge boon to VBDE and it’s sprite engine.

The column table tab contains… um… Honestly, I’ll need to think on this before deciding how to design it. For the time being, column table controls might just be relegated to the misc tab and edited per-column.

The misc tab contains all other VIP settings not included in any other tab. These include the version ID, palettes, brightness levels, interrupt status, the frame repeat setting, drawing and display status/control, frame buffer index and object groups.

I know it’s blasphemy, but it wouldn’t even be the end of the world if the column table wasn’t fully emulated. Like, what good is it anyways? There’s a standard column table that seems to do a good job evening out all the pixels out over the fluttering LED mirrors.

• Create some simple test software

This is a homebrew VB program to run on the hardware for research purposes. It’s not a fully-fledged “VIP Workshop”, but it will allow modification of all element properties to inspect their effects on the VIP.

Let’s see if you can get graphics emulated within a week AND then a home-brew demo! Next step looks like VSU, and then busses?

What if the PC emulator could make copies of raw rom & ram data: graphics, instructions, registers and interrupt routines? Let the user edit the code or graphics and then save out a usable home-brew resource.

Woot! The Guy is back and ready for action! I remember trying to help out with some C library stuff you were fooling around with 6 or 7 years ago. Well, in the meantime I’ve had 3 kids and teach math full-time at a High School here in Las Vegas, so VB has fallen by the wayside.

Next year will be my first year teaching Computer Science and one of my objectives is getting students working on home-brew projects for old systems (teaching low-level programming, computer architecture, and graphics). A VB emulator for 3DS sounds intriguing, as many of my students may have one and be willing to give home-brew for VB a try.

I don’t think I’ll be able to contribute in a meaningful way to the programming of a Planet VB emulator, but I do have $80 burning a hole in my Venmo account right now. If you like cash money it’s yours brother! If you have Venmo I can shoot it over to your lickety-split man.

You can do it Guy! I’m still patiently waiting for the VB Tech Scroll. I feel like a robust emulator and debugger are some of the last few pieces for VB home-brew. Think about what’s out there now: VBDE, Home made carts, Link Cables. People complain about the current emulators not always mimicking the hardware well enough. Add a capable emulator and debugger and suddenly its much easier to do everything!

Guy,
If only we could get in touch with Dasi and get the devkit rocking and rolling. The initial hurdle I faced when getting in to VB home-brew was the hodgepodge of tools available. Thank you for your efforts in creating and modifying tools so that everyone else can home-brew better! One day I know we will have a full suite of tools that work together where it might even be somewhat easy to create home-brew VB games.

Yaaay!
It sounds like so many awesome things are taking place this year. Keep up the good work guys. When my masters is done in May I’ll have to catch up on all the developments and recreate my development environment.

Guy, is there any way to get some of the tools you’ve been talking about. Could you make even devkitv810 available. I know gccvb is compiling at higher versions and I’d like to get a hold of that.
Also, do you have libVUE integrated to devkitv810?

blitter,
I’d like to hear how you compiled gccvb4 in Mac OS X. I have all three systems in my house. On my Linux computer I use Wine and VBDE. I’d like to be able to compile gccvb4 in Linux at some point, but knowing how to do it on a Mac would be excellent too.

Guy writes V810 machine code by hand in hex, so I figure he’s the best possible person for this job. I don’t know how the heck a emulator is programmed, but I assume Guy knows his stuff about that too.

I would like to update the gccvb compiler to a newer version of GCC, even though Guy hates GNU. I do most of my work on GNU/Linux (Grrrr GNU) and my optimizations do not work. I’ve started looking in to the patches made to binutils and gcc that’s included on this website. This might be a worthwhile project for me to learn a little more about the V810 processor instructions.

As for the SDL, there are two major versions of SDL out these days. SDL 2 came out a little while ago and I don’t really know much about it. SDL in any version is great for handling graphics, sound, and input. Most resources online are about SDL version < 2. All I know is that part of my issue doing VB work in the past was no good way to debug my programs. Mednafen is about as good as it gets and I think Guy has found Mednafen to be lacking in many aspects as far as emulation and debugging go.

Guy, count me in to help (even though I might not be the best help). I’m just about to be out on summer break after my first year as a high school math teacher. Now I need to get my programming chops back so I can teach CS. I’m advanced enough in C to know what a function pointer is but not so advanced as to know how to use it for an emulator. But I’m willing and ready to learn! When can we start?

Ayi-yi-yi!
This thing looks sweet! Sign me up for one once this gets tested.

Hey Guy,
I’m probably one of the few guys around here who has screwed around with doing pure assembly for VB. That said I still don’t know a ton of what’s going on with the system, and I’ve certainly never attempted to hack code in a hex editor
All I’ve really been able to

do so far is get an assembly version of DisplayOn working. The gccVB compiler will take assembly files and create working object code. Also, the really awesome thing to use is Mednafen and its debugger. Mednafen is one of the emulators out there. It’s debugger will show you all the registers (even VIP) and let you root around in the loaded memory space. You can set break points and do single stepping as well. Since you seem to know how to read/write assembly, this is probably a must-do for you.

Keep on keepin’ on brotha!

I just found a copy of “Silver Surfer” on NES. I’ve not managed to beat a single stage.
I’m also working on my high scores for my VB games so I can post stuff on the website!

Here’s some extra advice to help streamline the development process for us Linux users. Most of my tips are for the VBDE set up created by KR155E, but everything that follows should work for gccvb 1.0 as well.

The absolute MUST for compiling in Linux is using the compilers through Wine. Until we can compile gccvb in Linux, using the precompiled binaries of gccVB will be the way to go. So, once you get VBDE/gcc 1.0 downloaded and unpacked on your computer, there are a few things you can do to make compiling easier. Since the notepad++ way of compiling seems broken in Wine/Linux, compilation has to be done the old fashioned way. There are a few things to do which will make this MUCH more manageable: the PATH variable and Make.

Assuming your VBDE is unpacked and sitting somewhere in the virtual C drive wine uses. This can be tricky as the /.wine folder is hidden in your home directory. You can unhide it in the Nautilus file manager with ctrl+H or just append /.wine to your home directory path. From there you should see “drive_c”, aka C:. Unpack the VBDE stuff anywhere in C:. Now get to a terminal and enter DOS mode: $ wine cmd.exe. Locate and note the location of the folder in the VBDE directory with v810-gcc, v810-objcopy, etc… Then, in cmd.exe, type “regedit”.

The registry edit (regedit) window should pop open. We need to navigate through the folders shown in the left panel to find our path variable. Here’s a breakdown of where to find the path variable:
HKEY_LOCAL_MACHINE -> System -> CurrentControlSet -> Control -> Session Manager -> Seeions Manager -> Environment, You should see the PATH variable in the middle of the right pane.
Use this website as a reference to find the path variable if the above is confusing:
http://wiki.winehq.org/UsefulRegistryKeys
Now modify the path variable to look something like this; “C:\windows\system32;C:\windows;C:\VBDE\gccvb\bin;C:\VBDE\emus\rboy;C:\VBDE\gccvb\make-3.81-bin\bin”
Notice I also stuck in the path for the Reality Boy emulator and Make. Now close the regedit window and then type “Exit” back in the terminal to leave wine (the regedit update doesn’t seem to take immediate effect). From here on you should be able to just type in the name of the program you want to use (v810-gcc, v810-objcopy) without specifying horrific pathnames either for the program or the source file.

If you don’t want to bother with the last step that is fine, creating a good makefile is really what will save you headaches. But first you’ll need to find a decent makefile from a demo project to build on. Go download some homebrew titles with source and browse the makefiles to get a sense of what kinds of commands and invokations creates playable .vb files from the .c and .h files. Here’s a quick reference of what steps have worked for me:

wine cmd.exe
cd ..\.wine\drive_c\VBDE\projects\YOUR_PROJECT
v810-gcc -x c -o main.o main.c
v810-objcopy -O binar main.o main.vb
v810-padder main.vb 20 main.vbh

There are, of course, a billion different errors that could arise during any of those steps but that is the basic outline. If you edit your PATH variable in Wine, then that should simplify what types of commands to place in your makefile. I’m in no way an expert of this build process of the right way to do things; I can only say what has worked for me so far in getting source to playable .vb. If you look through several makefiles you are bound to see extra options passed to the three programs above. What I listed above was the absolute minimum I used to get something to run in Reality Boy. Maybe someone in the know can chime in with other important options that may make or break your code. But with a little practice and a little patience, demos should start compiling for you with minimal source file edits. Good luck!

It’s alive!!

I thought I’d weigh in on this thread for posterity’s sake.
First off, Greg’s instructions worked pretty well for getting gccVB 1.0 working in a Linux environment using Wine. One adjustment I had to make was to take out comments around the vector definitions in crt0.s. At first I didn’t have make.exe so I downloaded that and then the “make” direction worked perfectly.

RunnerPack’s suggestion about VBDE is I think another good option for LiGNUx users. The major obstacle I’ve encountered so far is that the compile feature in notepad++ does not seem to work. That said, using the command line to manually invoke the utilities seemed to work. With a sufficient makefile, the VBDE utilities should work just as good as using gccVB 1.0. My problem is I’m fairly clueless editing makefiles so maybe Runner has some good advice for this. I liked the gccVB 1.0 method of having one global makefile that works for multiple projects.

Thanks Greg. Everything you said worked great for me. The only thing I didn’t try was gccVB v.1. I managed to figure out DOS well enough to get all the other utilities working in Windows and through Wine on my Linux netbook.
As for the CGE recap: I found a copy of VB Golf for 3 bucks so I picked that up. There was one vendor who had a few VB games with boxes: Red Alarm, Teleroboxer, Nestor’s Funky Bowling, and even Mario Tennis (that was going for 100$!). He was also selling simple VB accessories and I even picked up a nice stand from him (my stand clip is broken). Other than that there was Atari, Atari, and a good bit of Atari homebrew. There was also plenty of NES, SNES, era stuff from a lot of the vendors but the main focus of the convention was definitely pre-NES.
Everyone who I could get to listen enjoyed hearing about the cool stuff that’s been done with Virtual Boy by you guys. They were all impressed to hear about gccVB and Flashboy. Overall it was a cool experience and anyone who likes the oldest eras of gaming would enjoy it.

I’ve been trying Reality Boy through Wine but I haven’t gotten the controls to work at all. No button on my keyboard seems to make any of the games work. I’m running crunch-bang Linux (Debian based) on my NetBook. The Dos based assembler hasn’t been any better for me but that’s probably because I don’t know how to do the Dos stuff through Wine very well. I’m going to keep fiddling around with everything so that maybe I can give some demos of the cool stuff others have done in the VB dev community.
It turns out that my family friend who goes to CGE is good friends with one of the three main organizers (Jersey guys) so I’d really like to make an impression to some of the people at the expo. My friend was floored when he found out that there was a C compiler for VB, let alone all the rom and bitmap editing tools and the flashboy. What’s drawn me to dive in to VB stuff is the untapped potential of this system. And I think others in the retro gaming scene might get excited too if they only knew of the great strides that have already been made in VB homebrew.
Just as an FYI, a table display booth at the classic Game Expo costs 100 bucks. Anyone interested in chipping in for a PlanetVB table for next year?

So it looks like I’ll be attending the CGE this weekend. I’d really like to have some VB stuff to show off on the computer except that my little laptop is running a version of linux on it. I’ve been trying real hard to get any of the emulators or gccVB working properly but to no avail. The emulators will start up but I can’t seem to get any controls to work and building gccVB fails in the binutils stage.

Has anyone else had any success getting any of these VB applications running in Linux?

RunnerPack wrote:
Are you more familiar with Intel (x86) or AT&T (gcc) asm syntax? I’ve only dabbled in x86 assembly, so I don’t have the Intel syntax baggage, which probably makes it easier to study the V810 architecture (which differs quite a bit from that of the x86).

In my class this summer we used nasm which is Intel syntax but we also fooled around on a MIPS architecture using Qtspim (which is RISC like the 810). From what I’ve read of the hardware manuals the assembly is pretty clean and easy.

I’m not sure what you mean… There’s only one ROM file format for the VB. It’s just a straight dump of the contents of the ROM chip. The layout of said dump is pretty simple, too: it’s just a big chunk of code and data with a fixed-size header stuck on, at the very end of which is the interrupt jump-table.

SWEET! Everything you just said here makes me super excited to do VB programming. A great advantage of assembly over C is the way you can handle interrupts in a more direct way. One major problem I wanted to avoid with VB was being fixed to “polling” to deal with input, but having control of the jump table should provide a good deal of flexibility in the important places.

That’s an easy one:

v810-objdump -d main.o > main.s

Here’s where I think it’ll pay off to know assembly and be able to look at C code compiled to assembly. I know the basics of calling conventions that can let your C programs call assembly procedures. But being able to write all the code in C and see how it compiles to V810 assembly is essential for learning about the system and it’s areas for optimization.

Sounds like a plan. Be sure to check the Wiki and ask questions here if something is unclear.

Thank you for answering my questions so far. It’s very encouraging to know there are such knowledgeable people who are willing to help a newcomer get on their feet.

And thank you for taking the time to see what makes our little red outcast tick. The more experienced programmers we have, the bigger the VB library will grow!

Maaaan… The Virtual Boy was cool as heck when I was 10 and nothing has changed since. Considering the VB’s technology, just the idea that this system is so raw and untested provides the right incentive to make me want to experiment! And let’s be honest, the only outcasts are the ones who kept away from the VB and it’s glorious potential.