[HorvatM]

The dev mode of the FlashBoy loader is a great feature, but unfortunately only for developers. Too bad, because it can make flashing much faster.

The ROM footer only contains information about the game (which you really don’t care about once the cartridge is in your VB) and interrupt vectors. Most gccVB games can already use each other’s vectors, as few use interrupts, and gccVB jumps to 0x07000000 on startup by default. So for many homebrew games, you can already safely use the dev mode to speed up loading.

VBDE, however, makes it easy to use interrupts, in particular the timer interrupt. Once link cables become widely available, the link interrupt will probably get used too. However, then it will not always be safe to use dev mode anymore.

So, it might be useful to specify a standard ROM footer that all software would use to make using dev mode possible. The interrupt vectors would point to a jump table at the beginning of the ROM. For compatibility with old, non-conforming homebrew ROMs that don’t use interrupts (the majority of gccVB games), the reset vector would still jump to 0x07000000, and for the other interrupts, the game wouldn’t care. The jump table should simply be an array of 2-byte entries, which is enough for a BR instruction. The vectors at the end of the ROM would jump there, and the game-specific BR instructions would transfer control to the game’s interrupt handlers. This would also require us to agree on which register should be used for the MOVHI/MOVEA/JMP sequence and how it should be saved and restored (on the stack pointed to by register 3, growing downwards?).

There could be a “standardized interrupt vector seal of approval” for games conforming to the specification (and most already do), so players would know whether they can use dev mode for a particular game. It could be present in the form of an extra column in the table of homebrew games, similar to how commercial games have a column indicating SRAM support.

Most homebrew games are 256K or smaller when not padded, so I think players would appreciate shorter flashing times. Remember that the VB allows games to be up to 16 MB in size, so flashing times could get really long with larger cartridges in the future.

Of course, games should still provide their own ROM footer for compatibility with emulators.

And while we’re at it, we could make a specification for sharing SRAM too…

• This topic was modified 10 years, 2 months ago by HorvatM.

IMO, rather than unnecessarily reducing flexibility, and changing the way we work, just to overcome a shortcoming in one tool… why not fix the tool?

I’ve explained to Richard how my padder works, and the code is out there… rather than writing the entire flash, it should be possible to get him to integrate the padder and only write the blocks that need to be written. I imagine that’d work, unless his firmware on the cart side doesn’t support selectively writing a flash block (i.e. always starts at 0 and simply counts up). Not sure if he’s got a bootloader, so it may not be possible to update the firmware on the cart to support that, without a debugger.

DogP

That would be ideal, but I got the impression that it’s not possible.

http://www.planetvb.com/modules/newbb/viewtopic.php?topic_id=3673&post_id=8666#forumpost8666

If it will be, there’s still the question of what to do with old FlashBoys that may not support this.

Ah… yeah, that sucks. Though is the flashing time really that big of a deal (I honestly don’t know… I almost never use the Flashboy)? I assume the time it’d be most annoying would be when you’re constantly reflashing, testing your own code, in which case the “dev mode” should work (because your own vectors shouldn’t be changing).

When you’re just playing games, it seems like you’d most likely be switching betwen commercial games, with the occasional homebrew… in which case, this option would likely only confuse things.

DogP

I almost never use dev mode– most of my development happens against Mednafen, and my game consumes nearly 100% of the 16Mb of the FlashBoy anyway, so dev mode isn’t too effective for me. Why do you need to test against hardware so often? Is there a bug in Mednafen requiring hardware for accurate results?

No, I’m not actually developing anything, just playing/testing more homebrew ROMs recently, and most are well below 2 MB.

blitter wrote:
I almost never use dev mode– most of my development happens against Mednafen, and my game consumes nearly 100% of the 16Mb of the FlashBoy anyway, so dev mode isn’t too effective for me. Why do you need to test against hardware so often? Is there a bug in Mednafen requiring hardware for accurate results?

According to GuyPerfect, Mednafen does not implement the repeat values of the column table properly for shadow or variable-brightness effects.

I’m not sure if all timings of the VB are known with 100% accuracy either (but perhaps it’s close), so there are likely other problems that someone trying to use the system to its full potential will run across.

On a third note, using the keyboard is a PITA :P. I’ll need to create an adapter at some point for the Retrode that lets me use the VB controller in the Genesis port.

There’s plenty that Mednafen doesn’t emulate, and not just trivial things like the behavior of [font=Courier New]MPYHW[/font] when fed out-of-range operands. For instance, the VIP can raise an interrupt when the specified group of 8 rows of pixels is being drawn. Mednafen doesn’t support that; not even in the slightest. And the VSU will refuse any write requests to wave memory while sound is being generated on any channel. Mednafen lets you rewrite wave memory at any time.

More importantly, though, Mednafen’s timing isn’t especially accurate with regards to how much the VIP can draw in any given frame. And that’s understandable, considering the VIP will take different drawing times depending on exactly what it’s configured to draw. It’s not an easy thing to accommodate, and, well, sometimes things that run just fine in the emulator don’t work so well on the hardware.

I’m reminded of the vintage days of internet emulation, where people were developing against NESticle for lack of a way to burn ROMs for use on the NES hardware. But there was a bit of a problem… See, the NES’s “picture processing unit,” or PPU, has a status register that the CPU can query. One of the bits in that value indicates that the PPU is currently in the vertical blanking period, and therefore raising a VBlank interrupt. The way NESticle had this implemented, that bit was set in the register all the time until VBlank ended. But on the hardware, the act of reading from that register is how the very interrupt itself is acknowledged, meaning subsequent reads will show that bit to be clear, even if the PPU is still blanking scanlines.

Consequently, a not-insignificant number of homebrew programs broke when attempting to run them on the hardware, even though they worked in the go-to emulator of the day. In some respects, that’s what we’re facing with Mednafen.

cr1901 wrote:
On a third note, using the keyboard is a PITA :P. I’ll need to create an adapter at some point for the Retrode that lets me use the VB controller in the Genesis port.

On a side note to your third note… 😉 You’ll want to use the SNES port, not the Gen one. The VB controller is almost identical, internally, to the SNES pad. It just uses all 16 bits, instead of only 12.

Unless your project relies on features that Mednafen currently struggles with, I still don’t see why testing against hardware so often is necessary. Mednafen is more than good enough for constant iteration on most projects.

If you encounter a bug in Mednafen that needs fixing, do what I’ve done and write a patch for Ryphecha. That’s the beauty of open source. 😉

Out of curiosity, are you working on a project that uses some of the aforementioned unemulated features? If so I’m very curious what for. (And would love such projects to lead to Mednafen bug fixes)

[cr1901]

Well, I got my FlashBoy today- works like a charm as long as you have a good cable (Surprisingly enough, the USB port on my laptop can power the entire Virtual Boy; this was before I found out that you’re NOT supposed to keep the cartridge in while flashing XD- shame).

I’ve run into my first issue with my (poorly coded) demo which just shows the warning and focus screens; immediately reapplying power after switching the console off is NOT enough time for all RAM contents to go invalid (not sure which regions exactly yet, but at least the BGMaps don’t lose their contents). When I turned the VB on again, I have a superposition of two screens worth of data- the message and the focus screen using the PC BIOS font tiles XD.

It’s amusing to look at (pics if I can find a good camera), but it is a bug that needs to be fixed. To be fair, that’s not really something I’d expect an emulator to emulate, however. Not even higan (cycle accurate SNES emulator), to my knowledge, emulates RAM decay on hard reset (it uses a RNG to fill RAM).

EDIT: Have some photos. Relevant git commit: https://github.com/cr1901/vbdemo/commit/dc36b26c3f999eab4fc6c88160d55e04de475f6d

EDIT 2: Added a reset after the Focus screen fades away. Curiously on soft reset, the VIP may or may not (mostly does) shine all the LEDs (for any non-transparent pixels in a character) at max brightness. Hmmm…

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

Attachments:

1. 

   photo274.jpg
   

2. 

   photo276.jpg