
NES Dual Port RAM Interface - jboggan
http://www.batslyadams.com/2014/05/nes-dual-port-ram-interface.html
======
duskwuff
I'm reminded of ICU64 - an interactive debugger for C64 - as seen in this 2009
video:

[http://www.youtube.com/watch?v=tjcvR5McmSg](http://www.youtube.com/watch?v=tjcvR5McmSg)

------
T-R
That's fantastic.

I'd been thinking about modifying an emulator to do automatic speedrun splits
based on changes in memory. Many of the people who'd most appreciate that kind
of thing prefer to speedrun on original hardware, though, and a lot of them
would be happy to pay for modifications like this - as many have, e.g., paid
to have their 3DS modded with HDMI output.

~~~
b0b_d0e
I've had a similar project floating around in the back of my mind, except
instead of reading the state off the emulator to determine when to split, the
program watches the video stream and uses visual cues to determine when to
split. As a simplistic example, consider the original mario game. When a
runner would want to split, the game screen would display the text 1-1 with a
black background roughly at the center area of the screen. With this
information, I'm sure it wouldn't be too hard to determine when to split by
scanning in the rough area for a picture similar to the what you would expect
at this spot. I know that in practice this is possible to do since I have
(just for fun) written a similar program for pokemon games when I wanted to EV
train on an emulator. It would scan for the edge block of the tall grass
(since all grass looks the same), and then turn around and scan for the edge
again. When the screen went black, I knew I was entering a battle, so I was
start scanning where the wild pokemon's name was and the program would be able
to decide if I wanted to kill it or if I wanted to run (so I can keep count of
the EVs I've gotten) The main issue with that program is that it couldn't tell
shinies apart, so maybe over night I could have lost a shiny without ever
knowing.

Anyway, long post short, I think it would be possible to monitor the live
video and determine when to split based off information that can be stored in
some kinda downloadable database (or some way to preset all the different
required split information).

~~~
_frog
That's a very cool idea, but its application seems limited to games with clear
'level' screens. Recently I've been watching speedruns of Ocarina of Time as
well as Metroid Prime and neither of those have obvious indicators for most of
the splits.

~~~
b0b_d0e
I agree that it would be more difficult for those kinds of games, but I think
with a little bit of cleverness it can still be managed. Since it doesn't
really matter where you split, but rather that you consistently split at the
same spot, I think it can work by splitting on "You've got item!" text or
other things like that. For instance, the first split of the Ocarina of Time
escape could be split as soon as it displays part of the map for the zora
river. The bottle split could be hit when you hold the bottle over your head,
it could match part of the blue text box displayed over your hand since this
exact spot on the screen would look the same for all N64 versions of the game.
One of the key features of the auto split program would have to be that the
image matching program wouldn't be so strict as to require pixel perfect
matches, but also would be strict enough that it wouldn't pick up any false
positives.

------
daeken
Woah, I was designing a system just like this for the Vectrex a while back.
Great execution on this project -- love to see clever hardware hacks.

------
mcescalante
This is some awesome engineering, and an equally as awesome result. Does
anybody know if the author is going to put these boards on sale or what he
does with his designs?

I'd imagine from the look of the PCB (2 layer with no solder mask or
silkscreen) that they're designed & printed with ExpressPCB - they look
similar to a few I've done with them before.

This really makes me want to start tinkering with older gaming systems.

------
psgbg
I don't know if anybody can confirm this but this site causes that firefox
(firefox 29 arch linux) use up to 300% of cpu (according to top).

Weird. I noticed this when the cooler started to work. Minutes after start the
machine in a cool day.

~~~
binarycrusader
No problems here, but it does have several Adobe Flash embeds.

~~~
psgbg
I have flashblock, and since this incident noscript.

This seems to be a problem related to Mozilla's javascript interpreter, since
Chromium works fine (and worst do not affect other versions and platforms).
It's not flash nor other embedded issue.

The problem do not block the ui just consume an insane amount of resources.

~~~
binarycrusader
I'm using FireFox 29 on Solaris and don't see the CPU usage problem.

------
statik_42
This is some serious hacking, I love projects like these. Kudos for the live
hex editor as well, this is a really cool debugging setup. Thanks for sharing!

------
jevinskie
And I thought I had a cool idea for a custom flash cart for a Game Gear. In
addition to proving the ROM to the Game Gear, it would present some of its own
memory-mapped registers on the bus to use as a debugging channel. This
certainly blows that out of the water!

------
sitkack
Needs a forth in that ram monitor,
[http://pygmy.utoh.org/3ins4th.html](http://pygmy.utoh.org/3ins4th.html) also
composite out from the AVR could make a nice second debug screen.

