HorvatM suggested that I disable interrupts from reaching the CPU, which I did with an asm intrinsic:

asm("SEI;")

But sei enables interrupts. cli disables them.

Maybe you should go a bit more into detail what actually happens. Could it be that the VB doesn’t freeze, but you get stuck in the exception handler or something along those lines?

cYa,

Tauwasser

Dear aleis80,

we aren’t that kind of friends you mistake us for.
Please find your ROMs elsewhere.

cYa,

Tauwasser

Guy Perfect wrote:

Tauwasser wrote:
However, what you’re proposing is essentially butchering the ROMs respectively adding an iNES-type of header.

That’s exactly correct and exactly the intention.

You are aware of the fact that everybody loathes iNES headers?

Guy Perfect wrote:
Doing it that way pairs the ROM with its respective metadata, and avoids the issue of attempting to keep a comprehensive database of Virtual Boy software somewhere. The meta data simply must be included with the ROM data in order to be useful.

Keeping a database is not what my approach is about. While feasible for VUE, most Nintendo game systems have the necessary data encoded somewhere in their header. When this is wrong, too bad => user has to decide what’s right.

If you’re keen on distributing everything on one file, then create your preferred file format(s) and zip them together with the ROM. Problem solved. No need to distribute sullied ROM images.

Guy Perfect wrote:
Even what Higan does with its games database doesn’t solve the problem I see when someone distributes or receives a Virtual Boy program, but the emulator doesn’t necessarily know what kind of hardware it was intended to work with. That’s why I strongly feel that the metadata needs to be in the same file with the ROM.

The need to know what hardware a game is supposed to run on does not implicate the need to have one file. Guess what, the VUE doesn’t know anything about the game that is inserted into it either.
Instead, the information is there implicitly by the PCB design of the game. You need to make that data explicit, i.e. by writing it down in a markup format, and distribute it.

Guy Perfect wrote:
I do a lot of experimenting, we’ve got a fair amount of homebrew, and someday we might even do some manufacturing. It’s simply not practical to try to keep a running bank of everything all the time.

Well, you’re a developer then. I see two primary use-cases here.

[list][*]casual gamer: a database of VUE game hashes will suffice, games will work
[*]developer: you know your stuff anyway and get the benefit of telling the emulator about the board you’re actually experimenting on[/list]

One case doesn’t need special knowledge and “it will just work”, the other has so much knowledge that choosing the right board file should be easy and a one-time job.

Guy Perfect wrote:
My proposal fully supports arbitrary representations and affords the additions of new features at a later date without breaking compatibility. I understand the dangers of making assumptions.

Your first assumption is that your format would work… Again, look at the iNES mess when all the mapper numbers were used up or used to mean different things at different times :-/

Basically, you should think about why you would want to do this if you end up touching the original ROM images. Because it’s 2014 and there just is no excuse for not generating metadata that can be distributed alongside whatever homebrew you cook up.

cYa,

Tauwasser

Hi, I like your idea to allow for as-of-yet un-emulated stuff.

However, what you’re proposing is essentially butchering the ROMs respectively adding an iNES-type of header.

Representations change, knowledge changes, requirements change etc.

IMHO, one should go the way byuu went about Higan, i.e. add metadata. It takes a little preparation:
[list]
[*]have XML files of all PCBs you want to support at a reasonable level of abstraction
[*]have XML files that describe an actual game cartridge, i.e. bind “cartridge” to PCB and all its relevant data.
[/list]

What PCB descriptions might look like:

	
		VDD
		
A20..A0
		#ROM_CE
		#OE
	


	
		VDD
		
A20..A0
		#ROM_CE
		#OE
	
	
		battery.v
		
A12..A0
		#RAM_CS
		mm1245.cs
		#OE
		#WE
	
	
		VDD
		battery.v
		150nF
	
	
	
		#RAM_CS
	

What a game description might look like:

	
		VUE-VMTJ-0.vb
	

Basically, have an abstraction in whatever detail you want of the PCB. Then have a game file that maps files, can turn options on or off.
For instance, battery might not be fitted or not. Some game might have VUE-AA3A’s resistor fitted and mm1245 not fitted, so they would write

	
		VUE-VMTJ-0_hacked.vb
		ram.bin
		
		<
	

As you saw earlier, instances have a fixed set of signals they provide. GEC is implicitly on all PCBs. It provides A0..A22, D0..D15, #OE etc.
MM1245 provides cs, csb, and tr.b. It wants a capacitor value in tc and it wants to know which voltages go into it.
Battery provides its voltage v.

A custom mapper could provide ROM addresses:

	
		VDD
		
mapper.ra22..mapper.ra21 A20..A0
		#ROM_CE
		#OE
	
	
		
 A22..A15 A7..A0
		#OE
		#RAM_CS
		#UWR
	

So now my ROM has two address bits more, RA22 and RA21, which are provided by mapper. Mapper itself needs some address lines to determined if it’s turned on or not etc.

Orient yourself by what’s actually physically possible and then find a level of abstraction you’re comfortable with. For instance, you could just nix the whole SRAM backup IC and just always have SRAM work. Then you couldn’t emulate the SRAM battery running dry or a brown-out of the Virtual Boy supply voltage (batteries in controller).
You would then have to determine if you’d be comfortable with not emulating this behavior or not.

But please, don’t invent some custom ROM header format that will get spread for no good reason and become out-dated once the first real-world mapper application is developed and being emulated.

cYa,

Tauwasser

With the upload of VB Guide II, it becomes apparent, that the girls is apparently supposed to be counting…

cYa,

Tauwasser

HoMenace wrote:
Well I’m actually multilingual. Just not in Japanese. I do expect someone who is listing something for sale on a English dominant auction site to be able to communicate with a potential buyer. The listing is even in pretty good English.

There’s English and then there’s Yo bud wazzup? Dis offer gots the shades’ box or wut lol?? English.

Oh and in a lot of countries, English is a VERY common second, third, or even fourth language that children learn.

Oh really? And I thought those poor bastards in Europe had to get by using their cavespeak, seeing as they lack so many modern commodities such as electricity, central heating and refrigeration :-/
Guess it’s up to ‘Merica to teach them proper speech and decent values.

cYa,

Tauwasser

I’m always amazed at how English-speaking people assume their counterparts know enough colloquial English and idioms to keep track of what is being said.
The seller’s translation sucks, true. But your attempt at communication isn’t golden either.

Hello, so I’m assuming you mean that it is only the eye shade and no box? I mainly just want to know if the box is included. Thanks.

Yes, let’s start off with a complex sentence. Use the KISS principle. Split that up into multiple sentences which all follow SPO word order resp. PSO for questions.
Don’t use colloquial speech either. Say “without X” instead of “no X”. Much better chance being understood. Keep the adverbs and subjunctive clauses in check, too.

You mainly just want to possibly if it you oh-so-pleases maybe like to know?

Hello X!
Is auction only for eye shades? Is the box included?

That might not yield eggplant in your answer.

cYa,

Tauwasser

Take a look at http://flashboy.vr32.de.

Bottom right corner has downloads as well as the manual. Download everything, read the manual, use the padder to pad your ROMs to the correct size, use the loader to load your padded ROMs onto your Flashboy Plus.

cYa,

Tauwasser

BigFred wrote:
Innsmouth actually was a plain bad dump with some bytes different here and there – not overdumped. There appears to be some confusion here. I’m glad we got a match here from both sides.

Ah, yes. I remembered the Japanese page with the overdump and just assumed the serial I obsoleted for DoM was the same. My bad on that part. Still should have been caught, though!

DogP wrote:
my point was just that by checking the CRC32 of my cart again (quick and easy to do), I could tell with very high confidence that the cart still matched the dump I had previously made […].

Sorry, I somehow did not get that part when I originally read your post. Thanks for the pics! I guess now we know that they also did the weird (K) code for VUE-AA-01(K). Do you have any idea what that means? It’s there for one Game Boy PCB, too. However, the PCBs definitely match, so I wonder if that’s an indicator for… anything, really

cYa,

Tauwasser

DogP wrote:
Attached is a screenshot of my test app… it outputs the CRC32 of all the common sizes […], and you have to decide which is correct […].

[…]

I’m not quite sure I understand what you’re saying about the old Innsmouth CRC32 though… are you saying the old “good” ROM was correct, but simply over-dumped? That should have been easily caught by a quick check in a hex editor.

It should have been easily caught, but apparently, it wasn’t caught. After all, some people test by dumping and running an emulator. That would of course work for an overdump, since the vectors are correct.

DogP wrote:
IMO, looking at the size and CRC32 from the no-intro database and comparing that CRC32 with the one of the corresponding size in my test app is a pretty reassuring check that they match.

Well, it doesn’t totally preclude a situation where the publicized size and CRC32 are for a bad dump. Over-dumps will work in emulators, which most figure is good enough, under-dumps at least won’t run — except for the slim chance developers put the vector table at the right spot in the half-size ROM.

I agree it’s somewhat farfetched, but so far, the track record has shown that even for widely dumped, hashed systems, e.g. Game Boy, bad dumps — including bad metadata such as bad ROM size, bad RAM size — do occur.
So it’s preferable to have someone knowledgeable check the dumps out.

DogP wrote:
Yep, I can… it was getting late last night and I didn’t feel like pulling apart a bunch of carts, but I wanted to post pics at least as “proof” of ownership.

Thanks, that’s wonderful!

cYa,

Tauwasser

Whoa, I see BigFred is doing some advertising here

BigFred wrote:
I’d like to bump this old thread because Tauwasser has built a reliable dumper on his own and he already redumped 2/3 of the Virtual Boy library.

Well, it’s not like it’s magic. A reader using the GEC is just more reliable than wiring up the ROM IC by hand using wire-wrap.

One of these days I’m going to upload my final hardware/software resources — once I’m not too ashamed of my code anymore.

SirGuntz wrote:
If USA (or JPN etc) is followed by a -1, then it’s probably revision 1.1. -2 is 1.2 and so on.

Well, that is correct. If the label has the product code followed by a -N, then it’s revision N of the label — not the game.

Game revisions are still marked using stamp codes, NN[A], where NN is the factory and A is a letter of the alphabet and only present for revisions.

DogP wrote:
I just re-ran those carts […] through a CRC32 calculator program I had written, which runs on the VB and calculates the CRC32 of the cartridge in the system. The CRC32s all matched.

Well, not to rain on your parade, but that statement doesn’t alleviate our fears in the slightest.

The problem with the Virtual Boy is that Nintendo decided not to encode ROM/RAM size etc. in the game header like they did for every other system — at least up to that point (I’m not too up-to-date on NDS stuff).

So, I imagine that you either input the ROM size manually within your software, or check if the header exists at 0x7FFDE0 & 0x7FFFFF, 0x3FFFFF, 0x1FFFFF etc. programmatically.
The latter is still not too definitive as a game could easily have the same bytes in multiple places, but should be enough.

For instance, I can also confirm the old Innsmouth CRC32, simply by over-dumping and not checking whether or not the first half of the dump is actually identical to the second half.

DogP wrote:
I attached a pic of the carts

Would it be possible for you to take a picture of the cart PCBs? I’m kind of a stickler for accuracy in that regard.

So far, only VUE-AA-01, VUE-AA3A-01 and VUE-(E)BA3A have surfaced, so it would be “easy” to assign the right PCB for each game. But having actual proof would be far preferable IMO.

cYa,

Tauwasser

Stop pushing stuff into the slot. You probably accidentally bent one of the contacts and now it’s under the carriage that is supposed to keep foreign materials out.

Disassemble the bottom of your Virtual Boy and look at the GEC receptacle to see what’s going on and whether or not you can fix it.

cYa,

Tauwasser

WiFi might not be an option, but there are several Bluetooth chips out there that are much nicer power-wise. They take 20-80 mA peak current — depending on chip model –, while most of the time taking less than 3 mA.

They’re not big either, don’t need an external antenna, are relatively easy to communicate with and provide a transparent serial interface, so with a bit of surrounding tech and initial programming of the chip, they can be a drop-in replacement for a cable.

cYa,

Tauwasser

jorgeche wrote:
I’m trying to make sense of the interrupt vectors, first I’m trying to use the key_hnd to fire a key pressed event upon receiving the interrupt, since I want my engine to support the event driven paradigm:

1) As far as I understand, as long as the corresponding register is set as follows: HW_REGS[SCR] &= ~S_HWDIS;
the interruptions for the key pad are active, so does it means that at any moment that the user presses any key a the key_hnd should be called? that should be ideal, but I’m no receiving such call.

You also need to set S_HW. Follow the procedure described in the Development Manual:

HW_REGS[SCR] &= ~S_HWDIS;
HW_REGS[SCR] |= S_HW;

However, hardware reading should be on after reset. Maybe you forgot to enable interrupts at all? See the sei and cli commands.

cYa,

Tauwasser

Dude, YouTube scratched response videos last fall, because nobody ever used them!

cYa,

Tauwasser

You can always make your own board and just transplant the edge connector

cYa,

Tauwasser

It has to be noted that cartridge RAM accesses are as fast as WRAM accesses: 1 wait state.
ROM and EXT areas can be configured to 1 wait state from their default 2 wait state configuration.

So ROM accesses needn’t be slower than RAM accesses at all.

Of course, for a physical cartridge, you would have to have fast memory chips as well

cYa,

Tauwasser

The linker script is the right place for that.
You will have to know how your compiler names these variables, then you can simply put them where you want them using the linker script.

You could also use gcc-specific extension to determine the section your variables end up in, instead of the usual data, bss etc.

my_file.c:
int my_variable __attribute__((section(".bss_special.my_variable")));

vb.ld:
MEMORY
{
    rom : org = 0x07000000, len = 16M
    sram : org = 0x06000000, len = 8M /* lower 16M */
    sram_wram : org = 0x06800000, len = 8M /* upper 16M */
    wram : org = 0x05000000, len = 64k
}

...

.bss_special :
{
	. = ALIGN(4);
	PROVIDE(_bss_special_start = .);
	*(.bss_special)
	. = ALIGN(4);
	*(.bss_special.*)
	. = ALIGN(4);
	PROVIDE(_bss_special_end = .);
} > sram_wram

Then you can abuse the upper 8MB of SRAM as WRAM. Ideally, you would have a cartridge that actually has 16MB SRAM, and where the upper 8MB may or may not be battery-backed.

Edit the startup *.S files to initialize this segment to zero if you really want to using _bss_special_start, _bss_special_end.

cYa,

Tauwasser

Do the paperwork. Get a letter from FedEx with confirmation that the package was not delivered. Claim buyer protection while you still can with that.

I don’t know about you, but whenever something remotely like this happens to me, I just go into “fuck over everybody else” mode and stop caring about everybody else.

A crippled orphan kid that needs the money to support their HIV medicine bill sent you the stuff that never arrived? Tough luck, get that money anyway.

I have the feeling you try to play nice here and you being understanding at the phone with FedEx just makes them tick the “can be fucked with” check mark in their database for your account.

Who are they to tell you who to do dealings with in the first place? If FedEx is too incompetent to actually deliver items safe and sound and cannot be bothered to offer actual compensation for lost items, maybe you shouldn’t have shipped with them in the first place — that’s what you should have told that crook on the phone. Don’t let them bullshit you any more!

cYa,

Tauwasser

I don’t get why their investigation requires you to talk to people. They should have the recipients signature on file, see that it is not yours — or when in doubt have you sign a legally binding statement to that effect — and move on with life.

Basically, they’re having you investigate for them, at no cost to them and no benefit to you, just to later claim that you are somehow responsible for this. You should have told the lady at the phone to go fuck herself, seriously!

IMHO, you should just say that you talked to everybody available, item could not be found, they’re at fault and make no concessions whatsoever.

cYa,

Tauwasser