I know you don’t do what you do for recognition, but you truly deserve this thread, man. We are blessed, as a community, to count you among our number.
A communications protocol is a system of digital message formats and rules for exchanging those messages in or between computing systems and in telecommunications.
If we take the binary data sent by the various controllers as the “message format” and the “latch, then shift while reading” process as the “rules”, then what you call an “encoding” seems to fit Wikipedia’s definition of a protocol. And there’s more:
A protocol definition defines the syntax, semantics, and synchronization of communication; the specified behavior is typically independent of how it is to be implemented.
Syntax is the particular arrangement of symbols (in this case logic bits) and the semantics is the information carried by them (in this case, button states). The synchronization part is self-explanitory… Now, notice that part about being independent of implementation.
(This space intentionally left blank to keep from sounding smug and patronizing. ;-))
Though the encoding on the wire may be the same or similar (I’m not sure if both use low/high cycles) on NES and Virtual Boy, the protocol by which the software communicates with the controller is different.
Actually, they are precisely the same, evidenced by the fact that NES (and SNES) pads (and even mice) have been connected to the VB using only wire and connectors (link). Also, as stated above, the syntax and semantics of the data are even compatible (i.e. the equivalent button states between the three pads are represented by the same bits in the data).
RunnerPack wrote:
Obviously these are going to be different, since the VB doesn’t use a 6502-derivative.
I’d just like to point out that the behavior of the input hardware is independent from the CPU being used. (-:
Actually, since the hardware relies on being attached to said CPU via an I/O port, and these are implemented differently on each CPU (given things like size of address space, bus architecture, and endianness), I beg to differ. However, since the protocol is defined independently of the CPU, this is moot.
Now, having said all that, I’m willing to concede that the “Did you Know…” could be written less ambiguously. I propose this:
“…that NES and SNES controllers can be connected to the VB?”
I think that gets the point across without getting bogged down in the details.
And with that, I offer my (metaphorical) hand in a sign of friendship. I hope that you will (metaphorically) shake it and we can be friends 😀
Actually, that’s quite true; you just have the wrong end of the stick, so to speak.
Notice that it says “protocol” not “subroutine”. It’s referring to the way the data physically flows from the controller to the machine, which is precisely the same on the NES, SNES, and VB (except for the length of the “packets” and the number of actually used bits). It has nothing to do with which registers are used to control the hardware or access the data once it’s inside the CPU. Obviously these are going to be different, since the VB doesn’t use a 6502-derivative.
Wow, MineStorm, those look great! What make/model/tech is your printer? If that’s FDM, it’s got an impressive resolution.
roelvdm3 beat me to it… I was going to post that WEEKS ago and forgot 😛 There are many more videos covering the whole process in detail. I’ve been wanting to do a similar process; I would use a CNC router to make a mold, rather than duplicating an existing object, but it would be more-or-less the same materials and steps.
However, upon seeing MineStorm’s results from printing, I think I might just continue my plan to convert my CNC mill to an FDM printer…
Also, yes, the official cart shells are made of ABS, as are most consumer product casings. As roelvdm3’s link shows, there are now quite a few castable resins that can approximate the properties of ABS. Many 3D printing technologies can make something suitable, too. In fact, ABS itself can be printed using FDM printers (although PLA—Polylactic Acid—would probably be just as good for cart shells).
Having already attempted this exact thing a few years back (with much less promising results…), I’m eagerly awaiting a look at that code.
I think my main problem was trying to get fancy with the line drawing algorithm. I found what the author purported to be “the fastest line algorithm in the world” and attempted to port it to VB. While I’ve never profiled or anything, I’m pretty sure that’s the bottleneck in my code.
Like thunderstruck, I also plan on making tools for model creation, but my platform of choice is Trimble’s (formerly Google’s) SketchUp. It’s a breeze to pick up and use, and the Ruby-based plugin API is a joy to work with.
Irony [AHY-ruh-nee, AHY-er-] n. – Getting killed by the fish named after you.
Great work on the game, t.s.! It’s easily one of the top five homemade VB titles. The presentation is outstanding and the game-play, while a tad simple, is actually not bad. The public domain music was a nice touch 😉
It’s most likely just something done to help with the manufacturing process.
I’m assuming it’s a way to track which machine/die/die-section was used to punch out the blank. If there is an error on some of the blanks, they know where to look to find the problem. That’s just a guess, but I’m sure it’s something like that.
You can’t just replace the plastic, because the displays only produce red light. Replacing the LED arrays will likely be cost-prohibitive for many years to come. Feel free to dream, but don’t get your hopes up.
This reply was modified 13 years, 8 months ago by RunnerPack.
HorvatM wrote:
I understand that the lowest bit is always zero, but if you look at GP’s SRAM, you will see that, for example, the player names are stored as consecutive ASCII characters, and it uses all 8K of the SRAM. So how does it access the odd bytes? Does the SRAM support 16-bit I/O or what?
I assume you mean a file generated by an emulator, since a dump of the actual chip would be pointless. However, you should specify which emulator.
I just looked at a GP RAM file made by (I think) Reality Boy. It’s 8K in length. That explains the lack of “garbage” bytes: they’re not written to the file (otherwise, it would be 16K in size).
I also looked at Mednafen’s (0.9.17.1) save folder. None of the VB save files I have are larger than a few hundred bytes, which means some kind of compression is being used (possibly just a means of skipping the unused areas, given that most games don’t use the entire 8K).
e5frog wrote:
Seems a bit odd to me.
Isn’t the SRAM hooked to the same bus as the rom but only half of the data lines hooked up?
Is it the data lines that are used every second one and not just the upper or lower half?
I’m 99% sure that the lower (“even”) byte of the VB’s bus is hooked up to the SRAM. It doesn’t matter which of the SRAM’s data lines are hooked up to said bus lines, though, as long as the same ones are used for both reading and writing. The same goes for the ROM, as well as the address lines on either chip. The lines are almost always used in numerical order, however. This simplifies preparation of the file to be written to the ROM.
@thunderstruck: Thanks for sharing your code and running the tests.
HorvatM wrote:
But the VB is big endian …
Actually, the VB is little-endian.
As thunderstruck states, the save RAM is an 8-bit device, but the VB has a 16-bit bus. In other words, there is no “0th” address line. No matter what address you access, it becomes “even” at the cart connector (i.e. the address is, in effect, boolean ANDed with 0xFFFF_FFFE). Since the SRAM’s A0 is connected to the VB’s A1 (and so on) each byte in the chip is read/written as a 16-bit word on the VB (thus, incrementing the address by one results in every address being used twice).
The only explanation I can see for what you observed with GP is that the (pragmatic) author(s) didn’t see the need to waste time clearing the upper (unwritten) byte before writing a word to SRAM, but the emulator author decided (correctly, IMO) that such writes should be preserved (although it may have been pragmatism in this case, too ;-)). This effect could be used by a VB program to detect whether it is running in an emulator or on hardware, but the emulator could just as easily be patched to prevent said detection…
I’ve always been a fan of the books (I have quite a few of them) and I wouldn’t mind reading each of the comics once (don’t feel a need to collect them) so that’s my vote: literature = coolest 😉
That is a lot of cards, though… are they CCG, or just “baseball” cards, or a mixture?
VirtualMan! wrote:
Hi. I’m new to this forum, and I have a virtual boy with the horizontal line glitch in both sides of the eyepiece. I’ve tried opening up my virtual boy but when I do, there seems to be a part connected to the black plastic casing. I’ve taken out all the 6 required screws so that is not the issue. I was wondering if this happens to all virtual boys or if I just really messed mine up. If it’s messed up, then I was wondering if anyone knew how to fix it? Oh, and the part the seems to be connected to the black plastic is at about the same spot as the cartridge slot. I don’t know if that helps.
There are actually 12 screws holding the VB together. The case is divided into three parts:
1. The top half (red plastic)
2. The bottom half (black plastic)
3. The stand clamp/cartridge slot cover (black plastic)
Part three is attached to part two with six screws, and part two is attached to part one with six more screws (two of which are in very deep wells). Part three also holds the serial number sticker.
If this doesn’t help you figure out how to disassemble your VB, and you’ve followed DogP’s Disassembly Tutorial, you’ll have to post photos to show us what you’re talking about.
This is almost certainly a speck on the mirror. It doesn’t seem like it, but there are actually quite a few of ways dust can enter the VB.
Another possibility is an age-induced defect in the lens. Not a scratch in the surface, but a hairline crack in the lens itself. This affects clear polystyrene items as they age. It can be seen in old CD “Jewel” cases, for example. It essentially makes a “facet” inside the plastic, perpendicular to the front and back surfaces, that acts as a mirror. Maybe there’s some way of restoring the integrity of the plastic, perhaps by heating it.
If you took out the “cross piece” in each ring, maybe you could make it a kind of 3-D Mancala derivative. Also, you could show the layers from a purely top-down view, and make them concentric (i.e. upper layer on the outside).
