I haven't logged onto these forums in a long time, but thank you SOOOOOO much Guy!!! I've been DYING for a VB emulator on the 3DS and I'm really surprised there hasn't been a good one released yet. You are doing the lord's work.

I registered just to say THANK YOU, I have been thinking about this for years, the 3DS is perfect for VB-titles. I wish they would release a VB-collection. I don't understand the technical stuff here, but would it be possible to make physical copies or a "everdrive" cartridge of some sort? I would LOVE to have some physical copies of VB games in my collection. Sorry if I sound stupid, I'm just dreaming. :)

It shouldn't be an issue, but testing will tell for sure. While the vanilla 3DS's CPU is only around ten times as fast as the Virtual Boy's, emulated software generally isn't running full-throttle during the entire frame interval. As long as it gets to its halt point/waiting loop in time on the 3DS, it will function just fine without issue, even if the exact number of simulated CPU cycles was less than the actual amount of time that went by.

As a bonus, there's another CPU in the system that can be used to off-load certain tasks such as video processing and communications. So the faster processor can be dedicated to the simulation and the slower one can take care of auxiliary tasks.

Worse comes to worse, there's always the recompiler option: take the Virtual Boy program code and transform it into genuine 3DS machine code that runs directly on the CPU. This vastly improves the performance of the simulated software, as most instructions are processed on a 1:1 basis, but the trade-off is that there's more sophisticated infrastructure required to pull it off.

Either way it has to be done, it will be done. The 3DS is absolutely powerful enough to do anything the Virtual Boy can do, so it's more a matter of making sure the simulated software turns into the right commands within the right time frame.

Quote:

Raverrevolution wrote:I've been DYING for a VB emulator on the 3DS and I'm really surprised there hasn't been a good one released yet. You are doing the lord's work.

My pleasure! I've been wanting to do this for years and years but never really had the opportunity. But benefiting from the support of people in the community can really make it happen, and I'm glad to be a part of it!

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?

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 structs.

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!

 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 when drawn, 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.

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.

 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.

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.

Quote:

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 structs.

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." Quote:

 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.

Quote:

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.

Quote:

 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.

Hey, some actual feedback and discussion... I don't know what to do! (-:

Before anyone gets disappointed on Friday, it's looking like this week will only have documentation to serve up. Between researching specs across multiple sources, formatting and rewriting a document and producing testing software, it's taking longer than I would have liked. But it's gotta be done, and I need to make sure that everything in the Tech Scroll is 100% accurate.

As of the time of this post, I've put all my current additions to the Tech Scroll up on the project page. You can review it here:

A fair chunk of the VIP stuff is in there now, so if anyone in the know could take a look at it and let me know what you think, that'd be swell.

Quote:

DaVince wrote:I'll try to spread the word around as well. :)

Excellent, and thanks! This is gonna be the key to the project's ongoing success.

Quote:

Yeti_dude wrote:How many iterations of the graphics code have you managed in the past? You know it always takes a few whacks at it.

That'd be approximately zero. However, compared to CPU operations, the VIP is soooooo simple. Just configure some structs in memory and draw a picture with them. It'll take a fair amount of planning to do it right, but I don't see spending more than maybe a day on that.

Quote:

Yeti_dude wrote:As you're rewriting the VIP portion of the tech scroll, make sure to switch over to KR155E and community's terminology.

Once again, I really want to stress that this isn't "the community's" terminology, but Nintendo's, and that's the only reason I'm using it. I don't like certain things about it (use of the word "world" makes no sense, something named DPSTTS surely isn't called "Display Control Read Register", etc.), but it all needs to be as official as possible to be done correctly.

Quote:

Yeti_dude wrote:[Regarding the VIP debugger window] Guy, you can do it! This would be a huge boon to VBDE and it's sprite engine.

Could you elaborate on why you feel this would be so helpful? I'm interested to know the thought processes of other developers. I've generally been able to visualize my graphics when doing my own software, but I'm not the best case study.

Quote:

Yeti_dude wrote: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?

For the sake of accuracy I'd like to implement it eventually, but it's a rare case a game system being able to modify not just pixel colors, but pixel dimensions as well. I'm not especially worried about it right now, since I don't know of any software that ever changes the column widths.

Quote:

Yeti_dude wrote: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?

The software I'm using to research the VIP is extremely basic and not worthy of release. It's literally just this:

Enough to get the information I need, but not fancy by any stretch of the imagination. The only reason VSU Workshop and CPU Workshop came into being was because I needed comprehensive control over those subsystems and it made sense to make them presentable. So I'm sorry to say, no VIP Workshop this time. (-:

The memory bus was the first thing I implemented, since the CPU requires it for fetching instructions and loads/stores. The source file vue/JavaVUE.java contains generic implementations for read and write methods, which the CPU module uses during its internal operations. Those methods are responsible for routing accesses to the appropriate hardware components, and adding, for instance, VIP support is a simple matter of just putting a line in there to tell it where to forward the access request.

Next step is probably going to be the game pad. I'd like to see things operating sooner than later. (-:

Quote:

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

I've considered a "Save ROM" command since the debugger window will eventually have assembler functionality, but beyond that it's a tricky matter to automatically re-pack things like graphics data back into a ROM image. But don't let the dream die here! Keep the ideas coming, because this is a community effort after all!

Aaaaand there goes a week, entirely to documentation. The CPU stuff, despite being like two and a half times as long, came together more quickly because the available literature was complete and accurate. The VIP stuff, not so much. I had to do a lot of testing on the hardware, and cross-referenced three different sources through it all, but I made due.

New content has been added to the work-in-progress draft of Sacred Tech Scroll v1.0:

 System memory map with details on various address ranges and the nature of the pseudostatic WRAM ROM Format, including Nintendo's game header and V810's exception handlers. Game Pak, which is the official name for those cartridges we all know and love. Updated System Reset section to account for new document content. Redlinks to ghosts of the sections yet to come!

Did I forget anything? I think that's it--OH WAIT, there's this:

 The VIP stuff. All the VIP stuff!

I painstakingly tested every scenario I could think of in order to determine the proper format and behavior of every little thing in that video unit. I ran across many inaccuracies in the emulator I was using, which made testing a bit tricky, but there was a will and therefore a way.

At long last, now I can begin work on video stuff in the emulator. This is going to be the part in the project where it all looks like it's coming together, and I can't wait.

Time for some vidja GUI stuff. This week's task is already outlined in yonder post intended for last week, but the research and documentation effort went all the way up until Friday so I didn't get a start on it yet. But now I shall.