You can already change the font size in the configuration file. I must be missing something.
But what I would really like is the ability to have a large debugger display without also having to stretch the game display. I have to stretch it 3 times vertically to fit the debugger with a 9×18 font, but then games are almost impossible to play/test. Going full screen solves it, but it’s a little inconvenient.
And pressing Esc shouldn’t quit the emulator when I’m in the debugger!
KR155E wrote:
It’s not that surprising, unfortunately, since this site still uses an ancient, almost 20 year old CMS and I am afraid we’re stuck with it until I get around to finishing the new site I have been working on…
Has XOOPS changed so much that upgrading is no longer possible without breaking things?
As I suspected, there are unused sound effects and even unused music in Virtual Lab.
At 537EC there is an array of 25 words pointing to all(?) sound effects and music tracks. The second one is the intro music, so modifying that one is the most convenient way to hear them all.
I have also considered fixing Virtual Lab. I even asked Benjamin Stevens (the only other person who likes it, heh) for ideas a few years ago. But since the code is such a mess, it might be easier to just remake it from scratch (community project, anyone?).
I would still like to figure out the music format because I actually like the music and there is some data in the ROM that I don’t know the meaning of, so it’s possible that it’s unused music.
As for the review, I laughed at your comment about the price.
Basically (to explain it simply), it’s a combination of two reasons: the first is that each game assumes it is the only game on the cartridge, and the second is that neither the VB nor the FlashBoy have a MMU (memory management unit) that would bypass this problem.
I did make a proof of concept ROM where I joined Game Hero and Fishbone into one ROM (without having access to the games’ source code), but it didn’t work on hardware and I haven’t worked on it since.
Benjamin Stevens wrote:
Out of curiosity, did you look at the game code and save your own level maps to look at / have available while playing the game for the first time?
No, I just approached it as a normal player. I’ll have to play it a few more times to see all the levels.
RunnerPack wrote:
I’m not sure where you got the “officially” part of your above statement, since anything official would have been in Japanese, and whatever wasn’t likely used the actual English spelling “Innsmouth”. (Correct me if I’m wrong, though).
Look at the box. It says “INSMOUSE”. Whoever then first transliterated the game’s full title back to the Latin alphabet was probably not familiar with H. P. Lovecraft’s works and didn’t recognize that it’s a misspelling of Innsmouth. I actually prefer Insmouse, it gives it a unique character. 😉
Awesome! I’ve just played through it for the first time (after not playing any VB games in months) and got ending B. It’s much harder than the original. I died at least once per level. Also, nice use of doors. 😉
cr1901 wrote:
If one wants to play VB games on their flash cart, they need to pad the ROM to some multiple of 2MB IIRC.
The ROM must be padded to the size of the flash memory. No more, no less.
I understand that it’s some sort of address decoding issue from VB CPU’s point of view, but what are the “rules” to ensure that the reset vector and the remaining code ends up in the correct place?
The ROM must decode addresses so that the reset vector (as well as the others if you use interrupts) is at FFFFFFF0. It doesn’t matter from that point on because your code can then jump to any address. The simplest case is if you have a 2^n-byte ROM; it can just decode the lower n bits.
What address does the CPU see and how does it translate to what address is presented on the bus of the ROM? Does the ROM just ignore higher bits of the bus?
Exactly. The CPU always starts execution at FFFFFFF0. The VB only decodes the lower 27 bits, giving 07FFFFF0. This is why the 07xxxxxx range is reserved for cartridge ROM. It’s up to the cartridge to decode the remaining 24 bits. A 2 MB ROM would normally only decode the lower 21 bits, so FFFFFFF0 is at offset 1FFFF0 in such a ROM.
Theoretically, it could also, for example, decode the lower 20 bits and bit 23, but then the two halves would only be contiguous from 077FFFFF to 078FFFFF.
Having the upper bits set is somewhat confusing, in my opinion, so I prefer a ROM to “start” at 07000000, even though it can (in the case of 2 MB) start at FFE00000. Faceball, for example, uses such addresses, but most (if not all) homebrews start at 07000000.
The ROM does not even have to be a power of 2 in size, though at least Mednafen requires it to be. A 3 MB ROM would, for example, be composed of one 2 MB chip and one 1 MB chip, use bit 21 to select between the two chips and the lower 21 bits to select an offset within the chip, with 0 being the 2 MB chip so that all 3 MB would be contiguous in the range from 07000000 to 072FFFFF.
I hope this answers your questions and that I didn’t make a mistake somewhere.
As far as I know, only Mednafen currently has write breakpoints. Press Alt+D to enter the debugger, then Shift+W to set write breakpoints (separated by spaces).
-Can BGMaps be extracted from ROMS? How can I detect the BGMap structure in a file?
It depends on the game. If they’re uncompressed, you can spot them in a hex editor as they are made up of 16-bit values that are usually similar in range. In that case, extracting them would be easy, but the hard part would be finding the charsets.
-BGMaps contain RAM info, not ROM info. So is anyone familiar with how Wario Land loads its tiles, and if so can this info be extracted as well?
If either of these are compressed, the best/easiest way to find them is to use an emulator and place a write breakpoint on addresses where charmaps and BGMaps are usually loaded. For charmaps, most games seem to use 78000, ignoring the uncontiguous areas at lower addresses (but note that any number of characters may be loaded at any address in character memory). BGMaps start at 20000, 22000, etc.; they are usually loaded so they take up the upper left corner of the BGMap segment if they don’t use it completely. Look at the memory map. Once you’ve found the code that loads/decompresses the data, disassemble it so you understand the format. Repeat until exhausted. 😉
Some emulators (at least Red Dragon) can also show you the contents of BGMap memory during execution, though taking screenshots of that and then editing them would also get tedious quickly.
