VRJZ wrote:
I’ve recently been seeing a vertical set of lines … that seem to come and go frequently…

I’ve also experienced this. I believe it may be caused when the select line is still mostly connected, yet randomly failing for short periods (on the order of microseconds) the length of which is probably related to harmonics in the vibrating mirrors.

The select line usually keeps one display off while the other is being used (they both share the same set of signals, except for the alternating select line). If the connection “stutters” while, e.g. the left display is being drawn, a tiny fragment of the left display will appear, mirrored, on the right display.

It’s just another symptom of the same problem causing the horizontal lines: intermittent contact between the display and the VB due to failing adhesive. Soldering the cable should fix it.

Wow! If that was in black, it would look 1st party! Gotta love the VB silhouette.

Thanks for all the kind words, everyone. I’m sure he’ll appreciate it when he’s able to get back to the site.

I’ve learned that it’s just a relatively minor issue with side-effects of some medications he’s taking, combined with stress. They’re changing some of his meds and keeping him under observation for a few days.

HP Lovethrash wrote:
Fascinating…well maybe I will experiment with that idea- personally I feel like using the right D-pad for A/B in a game like Mega Man on NES may lead to epic thumb fatigue, but maybe not. And the “guts box” idea is clever, I may give that a shot first so I can customize and use A/B as intended. Or, experiment using L/R triggers for A/B??

You may be right about the thumb damage. I’ve got fairly large thumbs, and I’ve never really cared for the VB d-pads’ sharp ends. For a while now, I’ve been wanting to try to swap them out for GBA ones. I think they’re about the right size, but they’re flat like those on all of N’s other systems.

BTW, that’s a good point about the customization options.

Now, how much of a pain would a VB>N64 conversion be? I always found the N64 controller to be cumbersome.

Again, it’s pretty much up to you how much work you want to put into it.

Maybe the left D-pad on the VB could be swapped for the joystick, the right D-pad becomes the C-buttons, select becomes Z, triggers and A/B are the same…I forget if I had mentioned this one before in a previous post :p

I would suggest using L for Z and select for L; more N64 games use Z than L, after all. You could use a 4PDT toggle switch to select between the d-pad being the joystick or the d-pad.

First things first, do you know off-hand what wires I swap/connect when doing VB>NES? Hopefully they’re color-coded somehow.

Thanks \m/

I plan on making a wiki entry about the controller port, but in the mean time, David Tucker (reality_boy) has a pinout diagram on his site, and you can pretty easily find the pinouts for (S)NES pads, online. Just match up the +5V, GND, clock (clk, shift, etc.), latch (load, P/S, etc.), and data (D0, etc.) lines.

Have phun! 😉

HP Lovethrash wrote:
Assume that I know nothing about this controller mod project and that I’m already in way over my head…do I need to do some kind of adjustment to coding or data protocols or whatever? I figured it wasn’t as simple as affixing VB wires to NES controller cables, but I read some of the stuff on the links you posted and it’s daunting to a beginner like me.

Actually, it is that simple; if you want to use the VB pad on an NES or SNES. The three systems share a nearly identical controller interface, and a simple passive adapter works fine. The NES will, of course, not support the L/R triggers or B/A (B and A on the NES pad correspond to R-Down and R-Right, respectively). On the SNES, A, B, X, and Y map to the right d-pad as you’d expect, and the only unsupported buttons are B/A (unless you write your own game).

As for the other systems, if you don’t want to deal with microcontrollers to translate between protocols, the easiest thing to do is just gut the VB pad and wire up the buttons to the guts of the target system’s pad. Since the latter probably won’t fit inside the VB pad, you could send the button wires out via a custom cable and make a box for the controller guts, connecting the two with a DB25 or other suitable connector. Then you could bring it full-circle by putting the VB pad guts in a similar box for use with a VB.

Tauwasser wrote:

RunnerPack wrote:
What does #LWR mean? I assume you mean the ROM/EXP write strobe, pin 5. What is the purpose of doing this?

It’s the write strobe for the least-significant 8 bits on the data bus. The meaning is the same as for the WRAM chips. You could also use #UWR if you so wished (only half-word/word access then). Look at this Wiki page where I updated the signal names and corrected the pinout.

It’s /WE0 and /WE1 respectively. I doubt the table is correct, because the write strobes don’t really depend on memory ranges but on bus configuration and width of write/read access. Which is why I stick to #LWR and #UWR.

Actually, while that may be true on a standard V810 bus, are you sure its applicable to the VB? The address masking alone shows how much Nintendo messed with the V810 when they made the NVC. I don’t think there is a way to access individual byte addresses on the cart, since there is no A0 line (which is why the upper bytes read from cart RAM have to be masked off). I do believe the pinout on the Wiki is correct, though, according to information gathered by David Tucker and DogP while testing the actual hardware (and, obviously, the Flashboy+ works ;-)).

RunnerPack wrote:
IMO, switching between the ROM and the SRAM shouldn’t be based on a pre-determined number of read cycles. For maximum versatility, it should be totally under the control of the software running on the VB.

It is totally under control of the software. You write to anywhere in the ROM region, either byte-wide or half-word-wide (so we have one bus access cycle). Then you jump to the reset vector of whatever you just wrote into SRAM.

You will have to bridge the delay
– from writing to our register,
– reading the JMP instruction — one bus accesses in instruction format I,
– executing the JMP instruction

Instruction cache will have to be off for that, but I image it will have to be off either way or you risk data from your bootstrap being used in place of program instructions?

Oh, I think I get it, now. I was assuming the SRAM and ROM would both be in the ROM address space, with writes going to the SRAM and reads coming from either the ROM or the SRAM under the control of your circuit. Now it seems like you want to use the cart SRAM (i.e. save-game RAM) space for the SRAM, which would require modifying the ROM or retargeting the compiler. Am I close?

An ugly eagle drawing will suffice:

(This is the first time I used Eagle – and I hope it’s the last time…)

As an aside, what do you normally use instead of Eagle, and why didn’t you use it this time? I use Eagle quite a bit. It was a little weird at first, but once you understand how it does things, it’s not that bad. The limitations of the “hobbyist” version are frustrating, sometimes, but not a deal-breaker.

Gating logic could be for instance 74LVC1G57 + Transistor + Pullup Resistor. Take 74HC161 for the 4-bit synchronous counter with asynchronous clear and we’re looking at part costs of about 1.50 USD with no special programming equipment and no concern for high-voltages needed for PALs/GALs that would kill our other parts.

I just did a quick check, and your parts list comes to quite a bit more than the cost of many of the ATtiny chips (only checked Mouser, though). Other than the cost of a programmer, that might be a better solution (and a parallel port could be used as a bootstrap, in a pinch). Just something to ponder, anyway. Of course, your actual circuit function looks good, even if it’s implemented in code instead of silicon.

bigmak wrote:
What would this be used for ? increasing the memory size/saving games…? just curious.

-Eric

The proposed cartridge would allow developers to test code on hardware more quickly, since there would be no need to remove the cart from the VB to program, and the SRAM can be written to much faster than flash.

The downside for general gaming use is the need to battery-back the SRAM for it to retain its contents with the VB off (hence the use of flash in the flashboy).

[RunnerPack]

***Deleted by author***

• This reply was modified 12 years, 9 months ago by RunnerPack.

There is a lot of stuff in your post I don’t get, Tauwasser.

Tauwasser wrote:
Dude, a 4-bit register would suffice for this. Just

Do you have an actual part number for this? It sounds like you’re talking about a quad D flip-flop.

– configure it as a shift register,

What is this configurable part that isn’t an FPGA/CPLD(/PAL/GAL)? Do you just mean strapping inputs to outputs in a chain? Why not just use a purpose-built, serial-in, parallel-out shift register?

– have asynchronous reset connected to the #RESET line,
– clock connected to #ROM_CE, and
– parallel load connected to #LWR.

What does #LWR mean? I assume you mean the ROM/EXP write strobe, pin 5. What is the purpose of doing this?

Then either make the input A a static ‘1’ or D0 or something. The output Q_A goes to the boot ROM.

Where on the boot ROM does Q_A connect? #CE?

You should then use a little logic gate to invert this enable signal for the SRAM chip: tie the SRAM CE to deasserted state when #RESET is asserted to protect SRAM from spurious writes during powerup.

This part I get, although the point of this whole excercise is to make a circuit that keeps the SRAM disabled until it’s time to switch.

Now, let me see if I get how your proposed circuit would work:
1) Upon boot, the “register” would be reset, thus containing four ‘0’ bits.
2) Output Q_A, being low, would enable the ROM (and disable the SRAM).
3) Every time the ROM chip-enable line is asserted, the contents of the register are shifted.
4) Since input “A” is tied high, ones would always be shifted into the register. (Unless it’s tied to D0, then I’m not even sure how to determine what gets shifted in…)
5) After one read from the ROM, a ‘1’ gets clocked in, switching from ROM to SRAM.
6) The VB appears to freeze as it starts executing the (still empty) SRAM. 😕

I don’t think you can fit a link port-based SRAM programming routine in one instruction… 😉

I probably don’t fully understand what your circuit does. It’s pretty much moot, though since, IMO, switching between the ROM and the SRAM shouldn’t be based on a pre-determined number of read cycles. For maximum versatility, it should be totally under the control of the software running on the VB. Hence my proposal for triggering it based on a read from the reset vector. Would you care to apply your 1337 logic haxx0ring skillz to that problem? 😀

Overall though, I think slapping an FPGA on a cart with some modern memory is the way to go. If I had time to finish projects, I’d just build a real cart like I prototyped up a few years back

An FPGA would be an excellent expansion lol. However, I do think an FPGA/CPLD for this kind of project would be overkill 😐

I agree that an FPGA or other large programmable device would be overkill for the cart I described. I was thinking more along the lines of a PAL/GAL like the (once ubiquitous) PALCE16V8 (or whatever similar device can still be found/programmed in sufficient quantity).

While I have no direct experience, I believe DogP has written to flashROMs located at 0x07xxxxxx while the cart was in a VB. I believe the “write enable” line used for the expansion area (0x04xxxxxx) is also active during writes to the ROM area.

When I was pondering the problem of an SRAM cart, here is what I came up with:
1) The SRAM would be mapped to ROM space, as usual.
2) A bootloader, stored in a small (mask/OTP/EP/EEP/flash)ROM, would also be mapped in the ROM area.
3) There would be no conflict, because the /CE lines of the two (sets of) chips would not be enabled at the same time.
4) Upon booting, the ROM’s /CE would be connected to the VB.
5) After optionally loading a ROM over the link, the VB would jump to the reset vector (0xFFFF_FFF0).
6) Logic in the cart would detect this jump and simultaneously disconnect the ROM’s /CE while connecting the SRAM’s /CE.
7) When power is removed from the cart and reapplied, the /CE switching circuit would be reset, ensuring that the ROM will boot next time the system is started.

It could be done with discrete logic, but a more compact (and likely cheaper) method would use some kind of programmable logic chip. If I were familiar enough with these to decide on the best one(s) to use, I would have already designed the circuit for this. (I have a lot of 5V SRAM chips salvaged from the cache of old PC motherboards). I would gladly help do some research on this, though.

That’s pretty cool, Chris! Why not whip up a full-blown editor while you’re at it? 😉

The Caanoo is probably a bit too slow for anything but a highly-optimized VB emu, but getting Mednafen on the Zero should be as easy as recompiling (given that the requisite libraries are available). The screen on the Zero is too small, but it has an HDMI output. The input situation is also a bit wrong, but since it’s Linux and has USB-OTG, you could even use a real VB pad with USB adapter. A cool mod (unless you’re a die-hard collector ;-)) would be to convert a VB pad into a cradle for the Zero.

Greg Stevens wrote:
I should probably study the syntax at some point.

I found a pretty good introduction:

http://www.schacherer.de/frank/technology/tools/make.html

Greg Stevens wrote:
I believe your change is what is needed but to the $OFILES variable instead of the $CFILES variable.

Well, that’s essentially what I did, since the order of the .o files in the OFILES variable is derived from that of the .c files in the CFILES variable. COBJS consists of the filenames in CFILES with “.o” stuck on the end of each, and OFILES contains COBJS, verbatim.

I knew about getting an assembly listing from the ELF, I just forgot the syntax and didn’t feel like looking it up before posting 😛 so thanks for mentioning it! 🙂 I used my customized version of David Tucker’s disassembler, instead.

Anyway, does using the right link order fix all of the known issues, or is gcc still doing other, unrelated weird stuff?

Based on Greg’s idea, I did some tests by changing the makefile in blitter’s music demo (BTW, great music/conversion blitter!) in two ways:

First, I made it put main.c first. I thought this produced a change, but it must have been caused by a difference in compilers (I’m using one I built myself from blitter and Jorge’s patches which, apparently, only runs on my system :-P). When I built a ROM using the unchanged makefile, they were identical.

Next, I changed it to put isr.c after the other files. This did produce a difference. I’ve attached the three ROMs and their disassembler listings for those more experienced with v810 assembly to look at 😉

The makefile changes were pretty simple. I just changed the definition of the “CFILES” variable as follows:

# Original
CFILES = $(wildcard *.c) $(foreach dir,,$(wildcard $(dir)/*.c))
# main.c first
CFILES = main.c $(filter-out main.c,$(wildcard *.c) $(foreach dir,,$(wildcard $(dir)/*.c)))
# isr.c last
CFILES = $(filter-out isr.c,$(wildcard *.c) $(foreach dir,,$(wildcard $(dir)/*.c))) isr.c

Attachments:

1. before_n_after.zip

Excellent news! I especially like the part about getting loose shells/pins to hack with 😉 I’m sure those of us who truly appreciate your effort in this will make sure you at least recoup your losses very soon after release.

Re: other colors — If you’re getting them made in ABS, there is always vinyl dye for those who want other colors. People have been using it for years to mod consoles and controllers. Unlike paint, it actually becomes part of the plastic itself, so it won’t rub or flake off. I don’t know how well it works on black, though, so maybe “natural” or white abs would be better (if it ends up being cheap enough to do two colors).

You should skip those obsolete (i.e. deprecated) macros and do it the new way:

WA[n].gx = foo; WA[n].gy = bar; WA[n].gp = baz;

And so on. I’m sure there are many better ways to load World attributes, but for quick’n’dirty projects, this will do the trick.

MineStorm wrote:

since the serial protocol is essentially SPI…

SEEPROM memory card for game saves ?

Good one! I had the similar idea of using old PS1 memory cards on the port, since they (as well as PS1/2 controllers) use a similar “SPI-like” protocol.

Thanks again, DogP; I’ll get this info into the wiki, at some point. I’m not sure whether it falls under VSU or cartridge, so I’ll probably stick it in both places 😀

That’s good enough for me. If it works, I’ll just update the existing file, so the above link will still work.