Dr.Crackers wrote:
Has anyone figured out what was causing those faint moving black horizontal lines in the display?

It’s usually something on the clear window over the LED bar. Try removing the LED PCB and carefully wiping the window. A quick way to verify is to swap the left and right PCBs… if it follows it, it’s gotta be dirty windows.

DogP

KJ4860 wrote:
Have any of you purchased/tried one of these out yet?

http://www.ebay.com/itm/Virtual-Boy-Tripod-Mount-Stand-Replacement-/201144740897?ssPageName=ADME:L:OC:US:3160

I just grabbed one so i can give it a shot with a custom flexible tripod setup.

Wow… that looks pretty nice, and the price is very reasonable. That’s kinda funny that someone else had the same idea… I was bored a couple months ago and quickly threw together a design for a 3D printed VB tripod mount as well. I didn’t really like how it turned out though and never got around to improving it. But that one looks way better, if it works as advertised (no screws, springs, etc. needed).

The thing I quickly found was that a full size tripod isn’t really convenient to use for playing, since the legs are kinda in your way (something with a boom would be much more convenient)… and the flexible one isn’t really sturdy enough standing as a tripod. The flexible one may work if you’ve got something to wrap it around, but the VB is kinda heavy for it. The best one would probably be a small tabletop tripod… but by the time you buy the adapter and a small tripod, it’s probably more expensive than a real VB stand.

DogP

Attachments:

1. 

   dsc02655.jpg
   

2. 

   dsc02656.jpg
   

David Tucker has some good information on it here: http://www.goliathindustries.com/vb/VBProg.html . Check out the PDF (“A brief introduction to Affine mode programming”) at the top of the page, and his demos (“Affine Demo’s”) at the bottom.

I did “Mode 7” style on Mario Kart… though I optimized a lot of stuff, so the code is pretty ugly. David Tucker’s demos are clean, and you can directly use his libraries in your program.

DogP

Benjamin Stevens wrote:

DanB wrote:

… What’s interesting though is a sticker on it that sais “BPS”. Could this be a hint as to who originally owned this kit? (A certain Faceball/Tetris developer) 😉

Or does it just mean “Battery Pack Storage”? 😛 …

Well, I believe that there are at least two other owners of VUE Debuggers on this site. Not sure if they have original controllers to go along with their units, though. If they do, and their controllers don’t have the “BPS” on them, then I’d say it would be good evidence that this truly did belong to Bullet Proof Software.

It would certainly make sense, then, as to why the original development team had a link cable, since they were working on 2-player Faceball. It would also make sense as to why this particular Debugger made it out of developer hands and into the wild, just as the original Faceball prototype cart did.

I agree… I’d guess it’s BPS, as in Bullet Proof Software.

DogP

Awesome… glad to see it arrived safely! From the populated pins, it appears that the 5<->6 pin swap is likely confirmed, though if you could verify the pinout, that’d be awesome (to confirm that they didn’t use resistors or do something else goofy).

DogP

MineStorm wrote:

Hope it works, be interested to see results.

OK, apart from the centre of the base. The inner cylinder wasn’t attached to anything.

Cool… looks nice!

vb-fan wrote:
BTW, do they make plastic stock that glows in the dark? That would be cool to have some VB parts glowing brightly! I know, glow-RED would be coolest, but red pigments only glow a few minutes. Green and aqua glow all night!

I’ve got some glow-in-the-dark green PLA… I like the color, but as far as glowing goes, it’s pretty pitiful. You have to charge it with a VERY bright light, and then you can barely see it glowing in a dark room.

DogP

The models look awesome as usual HT. I recently upgraded to a dual extruder printer, but haven’t tried the support material yet… this looks like it’d be a good candidate to experiment with.

I’ll post back with the results when I get a chance to try it.

DogP

Nice! The two-tone looks pretty cool… and I like the stand!

DogP

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

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

FYI, I know Hedgetrimmer posted a model of at least the clip half of that: http://www.planetvb.com/modules/newbb/viewtopic.php?post_id=16876#forumpost16876 . A couple of us have printed them, and they turned out good.

Jay666 posted pics of his print in that thread, and I printed a couple of them for retronintendonerd a couple months ago: http://www.planetvb.com/modules/newbb/viewtopic.php?post_id=28669#forumpost28669 , and they worked perfectly.

I know Hedgetrimmer has done a lot of models… I’m not sure whether he has posted that other part you’re working on, but I see he posted a video from Solidworks of the entire stand assembly here: http://www.planetvb.com/modules/newbb/viewtopic.php?post_id=7502 , so if you PM him, he may send you the STL.

DogP

Oh… just an update. I sent my gerbers over to them, they never replied, and shortly afterwards they went “out of stock”. Then they came back, but more expensive and not allowing panelizing… which totally screws the whole deal. :/

DogP

HorvatM wrote:
Regarding CLI and SEI, do we even know how long the stock V810 methods take?

That’s a good question… I don’t see that listed in the manual. One thing I did notice is that CLI and SEI have the same opcode as EI and DI on the V830 (which is based on the V810 architecture, though not necessarily implemented the same). In the V830 case, they claim to take 4 cycles each. For comparison, LDSR and STSR take 5 cycles on the V830.

DogP

Hmm… some of those results are a bit surprising. It just seems like what’s the point of having custom CPU instructions if they’re not much faster than what you could do with just a few instructions in software (sure… they’re a little bit more convenient, and more compact, but that hardly seems worth a CPU customization).

Guy Perfect wrote:
Curious is the fact that my program didn’t log an extra third of a cycle like it did for all the other instructions I tested. Someone else’s testing would be appreciated to get a clearer view on this count.

Guy Perfect wrote:

ADD     1966    1.0         1 cycle

What about ADD? How about running it on a larger chunk of regular V810 instructions to see if it really is an anomaly, or just that some do and some don’t (you might make a connection between them)?

And just out of curiosity… why 3 instructions in a row? Do you get the same results with just 1? How about 10?

DogP

Guy Perfect wrote:
It’s not an issue of being undocumented, it’s an issue of being undefined. When the destination string starts less than 64 bits after the source string, the output won’t be the same from one execution to the next.

Maybe you could simulate it by tossing a random number generator in there, but no matter how you slice it, you can’t match what the CPU is doing.

Sorry… I’ll admit that I didn’t re-read the entire thread… I just saw:

Guy Perfect wrote:
I must issue an apology to Mednafen. With regards to bit strings, even though its results differed from those on the Virtual Boy hardware, it didn’t implement them wrong.

I also withdraw my praise for RealityBoy. With regards to bit strings, even though its results matched those on the Virtual Boy hardware, it didn’t implement them right.

which made me assume you were saying Mednafen was different than the hardware, yet somehow correct… while RealityBoy matched the hardware, but was somehow incorrect.

But yes… while you say it’s different between executions, resets, etc… I find it hard to believe that it’s truly “random”, unless it’s causing a timing violation or collision on the bus or something. Other than that, the hardware has to be doing fixed operations… just not necessarily the right thing (possibly dependent on some internal state, or previous register value).

It’s been a long time since I’ve messed with bit string stuff (and I was never really THAT interested in it)… but is there somewhere that says this 64 bit limitation exists, or are you claiming that it’s a hardware bug? From looking at Table 5-13 in document # U10082EJ1V0UM00, it looks like any source and any destination is supposed to be possible.

DogP

Guy Perfect wrote:
To play it safe, an emulator should–just as Mednafen does–process bit strings one bit at a time, feeding modified output back as input if the destination overlaps the source.

I disagree. The emulator is supposed to be emulating the CPU, not what makes sense. If an emulator differs from hardware, even if it’s because of an “undocumented feature”, then it’s not properly emulating the hardware. If there’s a bug where 1+1=3, you shouldn’t be like “well… they meant that to be 2, so I’ll fix it for them”. Look at the errata sheet for a CPU… there are usually a LOT of things that aren’t quite right, but there’s no going back and changing it… so it becomoes a “feature” of the CPU.

DogP

HorvatM wrote:
Just a thought. Could this be the mythical “Hong Kong cartridge with all commercial games, including prototypes”?

That was the first thing that came to my mind when I saw that as well… any idea when this adapter came out? That rumor has been around for a long time. And it’s strange that it’s used for a lot of systems, yet somehow the VB gets the “Hong Kong cart” rumor.

DogP

Hmm… that’s kinda interesting. What are the initial values of the registers? Do any of them ever change on their own? It would be interesting to periodically read and randomly change them while running a more complex program to see if anything goofy happens or if they ever change.

If I was to guess, I’d say #31 would be the equivalent of HCCW (Hardware Configuration Control Word) on the V830. In our case, we don’t have internal RAM (unless that’s undocumented too 😉 ), which would mean writing that to a 1 would cause interrupts to fail (would try mapping to 0xFE0000x0, which should go into the battery backed RAM area). It’s possible that the bit is just registered and not connected to anything internally as well.

I’m not sure about the others… you could check some of the other NEC V8xx datasheets to see if 29 or 30 were ever used for anything (since, presumably RFU registers would possibly be used in the future 🙂 ). You could also decap the chip and look at the die with a SEM. 😉

DogP

retronintendonerd wrote:
Looks good! Thanks for sharing the writeup.

Thanks. 🙂

RunnerPack wrote:
Great write-up, DogP! Next you should try laminating another layer (or two) on that one with, e.g. spray-adhesive.

Good idea. I’m not sure that it really needs more layers on the whole visor, though I was thinking if I was to cut another, I may leave more of a tail on the end with the holes and fold it over once to fill the gap a bit, and hopefully add some strength for the holes by going through two layers.

VBmills wrote:
Looks good Dogp. I had the same idea the other week. I was in hobby craft and walked past the foam and couldn’t resist. I used black and red, black for the inside and red for the outside. Looks ok but the red is a different shade to the VB. Ill post a picture when I get chance.

Cool, I’d definitely like to see what you did. Did you use similar foam, or something thicker? I’d imagine a craft store would have a much better selection of this kinda stuff than Wal*Mart.

bigmak wrote:
I always thought someone could make a little money making high quality eyeshades for the community. Wouldn’t be to hard to do….

Yep… I agree. Someone that’s got some nice foam sheets and a machine to cut them could probably make some really nice replacements… though this isn’t bad for a few minutes of time with cheap readily available foam sheets.

DogP

thunderstruck wrote:
Right now I’m recovering from a nail hitting my eye

Ouch! The funny thing is if I’m working in the garage and should be wearing safety glasses, the first thing that comes to mind is “if I lose an eye, the Virtual Boy will be much less interesting”. 😛

DogP