I found this article about using the I/O protection diodes in a microcontroller for a similar purpose. Not really relevant, I just thought it was kinda cool… 😉

Regarding the variable charging current: a good, current-controlled bench supply would solve that problem. I’ve even heard of (but have never tried; because I don’t have one 😛 ) charging Li-ion cells with such a current-controlled supply. This is usually just to trickle-charge them up to a point where they can be safely charged at normal speed with a dedicated charger.

@DogP:

I forgot about your battery pack mod, and that it could be charged while running the VB off of it.

I also had no idea you could just hook up an unregulated DC source with a current-limiting resistor to a bunch of (I’m assuming) NiCd batteries…

There isn’t anything special about the AC adapter included with the GG packs, is there? Wouldn’t it just keep charging them, even if they’re full, and overheat/destroy them?

@Vaughan:

Best Buy has one for < $40, which is pretty reasonable. You could also find a free one on craigslist or something and replace the (likely dead) batteries. As far as overkill, you could also use it for other stuff (WiFi AP, cordless phone, other game systems, etc.) so it wouldn't be a total waste... just not a hack 😉

I think an internal modification would be cool (and that’s a very good circuit/description by Vaughanabe13) but you could also just go with a commercial UPS unit. Even the smallest one should be able to supply power to a VB for days–maybe even weeks… Just make sure the switch-over is “instantaneous”.

As an addendum to Vaughanabe13’s circuit, adding one or more large value capacitors in parallel with the battery and AC adapter (with a voltage rating of at least double your AC adapter output) would give you a little added insurance during the switch-over. And if you use electrolytics, mind the polarity.

http://www.vr32.de/modules/newbb/viewtopic.php?viewmode=flat&type=&topic_id=3432&forum=2

It won’t do much good to revise the “compiling the compiler” tutorial, because the compiler won’t compile under Cygwin (read: GCC 3.4) anymore…

Parasyte has been working on compiling a newer version, but it wasn’t ready last I heard. If you’re on Windows, you can still use the older one that comes as a set of binaries, and you really don’t have to mess with the path if you use a batch script to run it. It’s not ideal, but it’s a way to get started, at least.

There are a couple of home-made assemblers in the Tech section. I’m not sure how well they work, though.

[RunnerPack]

DogP wrote:
There could be a file name length issue… IIRC, the files are referenced by a 255 byte string, so if you’ve got a really long path, it may hit the limit.

Actually, in my version of the front-end at least, the file paths (emu and ROM) are stored in 2048-byte strings. But, I kinda goofed because the command-line options (minus the emu executable path) is stored in a 512-byte string… :doh:

Microsoft’s docs for ShellExecute don’t say if there is a limit to the lengths of strings passed to it, so I’m going to increase it to 4K or so and test it out with a really long path.

EDIT: I increased the path variable size and also now use _snprintf() so there shouldn’t be anymore buffer overruns even if the size is exceeded (it’ll just cut off the last few options). I tested it on:

“C:\Documents and Settings\\My Documents\Really Big, Long, and also Huge Test Path\Which is also nested quite deeply\And is used to store only a single Virtual Boy ROM Image\Space Invaders Virtual Collection (J) [!].vb” and it worked a treat 😀

Attached you should find a new executable to test.

• This reply was modified 16 years, 5 months ago by RunnerPack.

[RunnerPack]

DaVince wrote:
Well! Seems like the emulator would run just fine when run from the commandline. The frontend’s just a frontend, what could be so wrong in the way it calls the emulator? Perhaps some arguments the emu can’t handle properly, like (as suggested) the color correction flags?

Maybe there are some side-effects of ShellExecute()? The only thing I found with a quick search was related to multi-threading, which the FE doesn’t use.

Looks like the FE needs a new maintainer with access to a Vista/7 machine… (and removing the MFC dependency wouldn’t hurt, but I hope it doesn’t succumb to “.NET’s disease” :-P)

Another option would be to change the front-end into a “command-line maker” that just generates a command-line that can be used in a file association or Shortcut.

• This reply was modified 16 years, 5 months ago by RunnerPack.
• This reply was modified 16 years, 5 months ago by RunnerPack.

Did you try setting the command-line parameters manually? Make sure to look at the actual “usage” output of the emulator, to see what it’s actually expecting (although this text can get out of sync with the parameter parser, depending on what DogP has been experimenting with).

It could be either the front-end or the emulator (or both?) causing the problem, so it’s important to figure out which needs to be fixed.

EDIT: Actually, I just tried this and there is no usage information anymore… But, I did look at the strings in the exe, and it’s at least looking for the “brite” and “balance” switches (which are what all versions of the front-end are using) so I guess the problem is in the emu.

RunnerPack wrote:
I looked in the executable and it’s still using the same command-line options. Also, my front-end version is not using the same ones (I changed them in the front-end and in my copy of the RB source). I’m having compiler trouble in relation to a registry corruption, but I’ll build a new binary soon, if I can.

I’ve built a new binary, but I had to install VC6 to do it, so it probably won’t work for most people. Here it is anyway, just in case.

I suggest doing what Dan did, or associating VB files in the registry, like I mentioned before.

Welcome back, Para!

I like RB for what it is, but I’m glad to see you’re back to working on a new emulator based on modern technology. (Allegro is nice, but it is getting a bit long in the tooth…) Hopefully, with SoftVue using SDL, it’ll even be playable on my crusty old PC 😀

It probably won’t help, but Dan reminded me that I was (and am still) working on this font for Bitmap Font Writer.

I want to eventually add punctuation, digits, and maybe lower-case, as well as making a TTF out of it. Also, as you can see, there are some kerning problems due to the nature of the BFW software…

(PS: KR155E, you might want to think about using CSS sprites for those titles…)

Attachments:

1. 

   sample.png
   

1. a-vb-logo-font.zip

Hedgetrimmer wrote:
I am hoping i can maybe get one machined up in clear acrylic, the machining marks can be ‘flame’ polished out, a blow torch gently melts the machined surface and returns it to smooth & clear, thats the theory and in the very small trial i did it worked about 75-80%, just got to be carefull with the flame distance and time held.

I was also hoping to try acrylic (if I can find a piece with the right dimensions) but I was going to use my heavy-duty heat gun to “flame-polish” it. If you have or can get one of those, it might be easier to control. Also, I’ve heard that, to prevent warping, you can cool the back of the piece you’re polishing, so only the surface to be polished gets heated.

DanB wrote:
I second e5frog. The anaglyph red/cyan mode doesn’t work anymore (“-dspmode affine -pallet rc”) It’s greenish/yellow/red inverted sort of. Did you change the command line parameters?

On mine, with the same parameters, I just get a monochrome, monoscopic image. 😕

I looked in the executable and it’s still using the same command-line options. Also, my front-end version is not using the same ones (I changed them in the front-end and in my copy of the RB source). I’m having compiler trouble in relation to a registry corruption, but I’ll build a new binary soon, if I can.

Is Java enabled? Do you have the Java run-time installed? Is it up-to-date?

KR155E wrote:
Dan: Since a while ago, edits are only possible within 30 minutes after posting. This is because the edit function should only be used to fix errors or append to posts right after they’ve been posted. There should not be a possibility to alter posts anymore after a little while, since that could lead to confusion, the deleting of inportant posts or such things.

While I understand the philosophy behind disallowing edits, perhaps a nice compromise would be, after the full-edit time period expires, to only allow adding to the bottom of a post. Also, a post edited in such a way should have its “read” status reset. Anyway, that’s what I would do…

(We now return you to your regularly scheduled thread ;-))

EDIT: It is UPX’ed.

Works fine for me, too (3.0.4 “Optimized” version).

Did you check to see if the DLL is UPX packed? (I’m testing out GNUstep right now, or I would do it myself.) Also, the DLL is probably newer than the static lib DT linked with, so it could just be more efficiently coded, or have certain code disabled, or something.

About the problems: by “pick” do you mean from the front-end? If so, are you using my modified front-end, or one from a specific version of RB, or… The front-end may not be using the same command-line syntax the emulator is expecting.

The workaround is to run RB from a shortcut with manually chosen options, or associate .VB files with it in the registry.

RunnerPack likes very much indeed! 😀

Thanks! :blush:

I really need to get busy putting the rest up, but I didn’t want to just plagiarize the manual–if for no other reason than the typos and slightly “engrish” grammar choices! 😛 Plus, I think the organization could be better.

I could, however, provide my OCR’d version so you could make a new (smaller) PDF, but you’d have to reverse some changes I’ve already made and restore the page headers/footers. PM/email me if you want it… I’ve also got the NVC and VIP sections OCR’d, though the latter hasn’t been completely proofread yet.