After fixing pin 15 it was clear it wasnt actually hooked up to a contact, and wasn’t met to be. I need my jeweler loupe to see things clearer

So I resoldered all connections on both chips and it still behaving the same way.

I’m not happy.

So either there is a fault in the pic chip or the firmware.

just sent in my 20

this rocks.

Let’s continue this ‘other’ 3d hardware on another thread 😀

I pm’d MineStorm he hasn’t got back with me yet.

So I looked at the board again and it looks like the flash chip does actually have a funky pin that looks like it might be a bad solder.

It’s pin 15 which is the RY/BY ‘ready/busy’ pin. So perhaps thats why I’m having funky timeout periods.

http://pdf1.alldatasheet.com/datasheet-pdf/view/92584/AMD/AM29F160DB75EI.html

I’m gonna heat it up and try to resolder that pin

my quest continues.

DogP, do you maintain the emulator? Whats your involvement there? I’d be interested in checking it out. I still might try to do some of the stuff I mentioned in the following weeks when I get another weekend I can screw off.

And awesome setup! at work we have a 10″ single wall ‘cave’ which is pretty nice I haven’t tinkered with it too much my self other than play quake 3 on it.

[Yackom]

OK now I’m finding the other mem read instructions… let me see what I find

Edit:
for some reason my find all ref’s was acting up anyway.

Ok found various byte,word,hword instructions for reading those arnt interseting but…

This one is. It looks like a fast point to pointer memory copy instruction. With this you can copy from rom to vram

case MOVBSU:
get_bitstr(tmp,src,srcoff,len);
set_bitstr(tmp,dst,dstoff,len);
clocks+=calc_arith_bsu_clk(src,srcoff,dst,dstoff,len);
break;

Anyway regardless of the implementation details on how to detect which graphics to replace, because there are now for sure multiple ways to do it, the concept is still very interesting

• This reply was modified 15 years ago by Yackom.

[Yackom]

so why build another emulator for the three games that might get an incomplete graphics pack one day?

Because it would be awesome! Plus talking about it see’s how much interest there really is in it. Viewing 3d color in anaglyph isn’t that attractive I agree, but in the next few years there will be quite a few new affordable 3d displays, Hell i even have a 3d laptop sharp rd3d from like 5 years ago. I modded the n64 video emu plugin (rice’s 3d I believe) to be compatible with it! Now I can say I am one of the few (maybe only) people who ever played Mario64 in real 3d and it rocked!! The laptop is now dead but whatever you get the point 😀 come to think of it i think might still sell the pannels as monitors 15″ ones for a few hundred.

I would love to play Wario or some of these other titles in color on one of these next generation 3d displays.

Is this just supposed to be an emulator patching?

Yea it would be an emulator patch. I wasn’t intending to make it sound like a hardware mod, and I’m not entirely sure it would be really all that involved. Looking at the source code to reality boy, which is really nice btw, the dsp code is only 1000 lines which would be where most of the heavy lifting would be.

How else would it be transferred?

Thought there would be a instruction to read direct from address to address. Just checked, not the case only instruction to read memory is this one it seems. which leaves me somewhat puzzled because I thought there was a 16bit read access to the cart.

case LD_B:
tmp2 = (sign_16(arg1)+P_REG[arg2])&0x07FFFFFF;
P_REG[arg3] = sign_8(mem_rbyte(tmp2));

oh well.

Could change the read routine to cache sequential reads from the cart, and try to try to check identical sequential bytes to the vram. but that seems unreliable. but I don’t like that idea all that much though it might work and wouldn’t be hard. Worth the experiment probably.

On the other hand not doing any of that but just dealing with vram kinda simplifies the scenario a bit because it doesn’t change the fact that they are static sprites, you could easily map to some other external image file. Selecting these images to dump out would be pretty easy if you changed the the video memory viewing modes with abit of interactive ui.

• This reply was modified 15 years ago by Yackom.

USA Retail

VN1031920[1]

Purchase Date 3/31/97

I’m in for 20.

Sorry to be dense but this is official nintendo samples? any of this in english?

This is totally possible for the sprite based games. Runtime graphics games like red alert are another story.

I just had the same idea today actually, I even went so far as to download the emulator reality boy’s source. I was going to post this idea just now but thankfully I did a search first.

Ok so I’m new to the VB dev scene so grant me a little bit of theory here, but I’m really familiar with DS and GBA development. (see proof: http://dsquake.blogspot.com/ ) I’m sure most of you know this but these “character” based rendering systems arrange sprites/graphics in small tiles 4×4 or 8×8 depending. I made sure this was the same basic concept with the VB when I looked at the source code.

So backgrounds and objects(sprites) are comprised of just a few things which we would have to map to some outside patched/graphics. the characters(tiles) them selfs which for most sprite based games should be a location on the rom. And of course the ‘color palettes’ (in quotes cause its the VB :D) The palette them selfs can come from anywhere ram or rom but they are generally a very small around of memory which its self can be used as a key. So an image can be located by the pair (romsource, color palette).

Getting these will be tricky, but ultimately we will have control over anytime the video ram is wrote to/ read from which is defined here in vb_vbt.cpp V810_MEMORYFETCH V810_DISPLAY_RAM; . I looked for DMA in the emulator and didnt find any cases of it, anyone know if the VB supports this? I think it would be fair to assume that only memory from Rom to VRam would be graphics we could patch. As a developer I can’t really think of many resonable reasons, other than compression which I doubt is used, to copy graphics from ram to rom unless they were generated in real time, because the ram is very limited on these machines. So all vram writes from rom could be cataloged in a table of sorts which we can then reverse for quicklookup for the graphics in rom lookup. This could all be profiled too, % directly from rom vs % from ram/registers. The worst case scenario I think is where this is hard to detect because memory is copied from rom to reg/ram then copied to vram but is still static values. If we suspect that to be the case we can pause the emulator examine the objects in memory. In those cases we could compute a hash of the graphics and swap it for some file on the harddrive. Am I missing anything else guys?

Then there is the mode7ish (assuming the VB does have something similar) kinda processing which would have to be considered, I hoping the emulator they process the colors in 16bit RGB if thats the case then we should already be covered for those algorithms if not, then they will have to be modified otherwise colors will get garbled. Which I think could wait a bit until other more basic tasks are working first.

So how would we implement this..?

I think step 1 would make the emulator dump out the objects/backgrounds from roms as it renders them. We would try to key these images as I mentioned before (romsource, color palette) and ignore other flags in memory such as location/rotation and so on.

that would be useful for two things 1 dump all images, to be patched and establish a link between the roms memory and the filesystem.

in vb_dsp.h, we would need to add a rom source value to these structures and any others that have raw graphics.

struct VB_BGMAP
struct VB_OBJ

There is also something called a world I’m assuming is a slice of graphics in 3d space maybe I’m wrong. this might need tweaking too.

//Structure defining one world from the world table
// there are 32 worlds in the world table
struct VB_WORLD

in vb_dsp.cpp, we would want to dump unique pairs of that information every time this is called: void V810_Dsp_Frame(int dNum)

step 2 would be getting colors on screen, we change the rending routines that follow V810_Dsp_Frame. but I haven’t dug that deep yet.

OK thanks for the tip.

Slightly better results. It flashed it twice, but still errors out a great deal of the time. I’ve tried a few other versions so far, no luck.

Also, the erase command is different this time only one packet of 0xA1,0x0…0x0
then wait for about 10.1 seconds.