In field programming of SUBOR carts?
kevin
I noticed on the PlayPower wiki. I looked at a photo of a SUBOR
cartridge that described having the Flash chips write enable line
wired to VCC. I also didn't see any factory flash programming
connector, so what they might have done is used one of the VCC pins on
the cartridge edge connector as a write enable line, and the other VCC
as the real +5v while programming. The Famicom connector has two VCC
pins that while in a Famicom would both be connected to VCC but at the
factory they could just slap the Flash cartridge into a special
programming device and flash the cart from there. If this is how they
did it, you would be able to flash new carts in the field without
having to take them apart.
I don't have access to the SUBOR carts or I would verify the
connections myself.
Just a thought. :)
-Kevin.
Derek Lomas
I recently reached out to former MECC employees, which is the organization that produced 8-bit educational games for the Apple // (and a number of different early home computers). They made classics like "Oregon Trail", "Number Munchers" and "Lemonade Stand."
Kevin worked at MECC, back in the day. He also worked at EA, where he was on a team to reverse engineer the NES. That's... awesome.
Kevin's got some specific ideas/suggestions around the hardware development kit-- Dave, maybe you could share what you've been working on?
Derek
--
You received this message because you are subscribed to the Google Groups "Playpower Tech" group.
To post to this group, send email to playpo...@googlegroups.com.
To unsubscribe from this group, send email to playpowertec...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/playpowertech?hl=en.
techt
Welcome aboard!
> I noticed on the PlayPower wiki. I looked at a photo of a SUBOR
> cartridge that described having the Flash chips write enable line
> wired to VCC. I also didn't see any factory flash programming
> connector, so what they might have done is used one of the VCC pins on
> the cartridge edge connector as a write enable line, and the other VCC
> as the real +5v while programming. The Famicom connector has two VCC
My SUBOR supplied flash cart is currently packed away so I don't have
it in front of me to check, but I believe the two VCC lines were
connected together and the write on low enable line of the flash chip
was tied high by a VCC trace connecting underneath the flash. I had
cut a VCC trace near the flash to verify and if I remember correctly
all VCC ties to the chip were found to be interconnected. Of course,
it is possible I had made a mistake in my probing so it would be nice
if someone else with a SUBOR supplied flash could repeat and verify.
But, be careful since I managed to accidentally fry my flash chip this
way.
Derek mentioned you have some ideas for a dev kit. Cool. So far I
have a flash cartridge and a programmer in various states of design.
I put together a flash cart based on the design of the SUBOR flash
cart which is geared towards the one-bus mode of the VT02 and family
chipsets. It consists of a flash chip (I'm currently using a SST
39SF040 in PLCC package) and a 128k SRAM chip (ISSI IS61C1024AL).
These specific two aren't critical as there are many that will work in
this design, but these were chosen for their low cost and ease of
purchase. Together, they're very similar to the SUBOR flash in that
the programs from the SUBOR flash have been verified to run on the
homebrew cart without modification. This flash cartridge is writeable
from the SUBOR which opens up the possibility of a SUBOR hosted
development system.
There is also a general purpose programmer design based on the ATMEL
AT90USB162 microcontroller and Microchip MCP23S17 GPIO expanders.
These parts were again chosen based mostly on low price and ease of
purchase. The AT90USB162 mcu was chosen from the experience of trying
to use a ATmega128 as the heart of the programmer and finding serial
port transmission speeds to be just too slow; it took aprox 15 minutes
to transfer and program an entire 512k flash via serial. The
AT90USB162 is connected via full speed USB which gives much greater
transfer speed and flexibility in interfacing, at the price of being
much harder to write driver firmware for. At this time I can
communicate to the mcu using serial over USB via the LUFA library.
I'd really like to get USB mass storage working soon so the flash cart
could be used as if it were a USB thumb-drive. That's the plan,
anyway.
Because the programmer is a general purpose design, it should be able
to accommodate other flash cartridge hardware designs with only an
update to the driver firmware.
One nice thing about using the VT02 one-bus mode is that in that mode
we have some GPIO lines which gives us the possibility to add a SD/MMC
cart interface to the cartridge for nearly free.
Dave
kevin
program the flash in circuit. There must be some way to isolate that
WE* line to be able to program the flash. I highly doubt they
programmed the flash and then soldered it onto the cartridge, but who
knows! :)
It's a very good idea to have the SUBOR run its own debugger / SRAM
upload code, otherwise you end up having to isolate the SRAM from the
SUBOR buss which adds several more chips to the design (aka cost).
This is how we did it for a SEGA Genesis development system my partner
and I designed at a small game company I started after I left EA. We
had a couple EPROMs, a parallel interface chip, a few PLDs and a large
chunk of pseudo static RAM. The PLDs did address decoding and made
sure the pseudo static RAM was continually refreshed (that was the
major issue). We used pseudo static RAMs because the amount of memory
we wanted to emulate would have been cost prohibitive as static RAMs.
At the time Genesis development systems were selling for $5K - $15K,
which is a lot of money to shell out when you need one for every
programmer and every artist.
Anyway, the advantage we had by letting the 68000 in the Genesis run
the debugger code was that we could access everything the 68000 had
access to, including internal registers that you wouldn't have access
to if you just isolated the cartridge emulation memory. We used a
parallel port because at the time it was the fastest way to transfer
data, it's painful to wait for your code change to upload (especially
when it's 32MB). So I totally agree with you about the need for
speed. :)
At EA we used an in-house developed monster sized ROM emulation board
for NES development. The same technique was used with the NES running
a debugger monitor program that would be banked in when the programmer
needed to upload some code or debug. A big challenge was the 6502
stack size, since it only resides in page 1 and is only 256 bytes an
interrupt could potentially overflow the stack and cause all sorts of
grief. So the board would swap out the stack when it presented an IRQ
to the NES. I had a nightmarish time trying to figure out why my IRQ
handler for the debug monitor was crashing only find that the hardware
engineer neglected to swap the page 1 stack *back* when the IRQ was
complete! So here I was, a software guy, cutting traces and adding
jumpers to fix the problem. I have to admit that afterwards it was a
lot of fun, but trying to figure out that problem was very
frustrating.
So as I see it for the SUBOR you could go a couple of ways. You could
make a pretty simple cart with a decent amount of RAM that acts as ROM
(unless you enable it for writing of course), have one EPROM that gets
banked in upon a debugger sent IRQ, and some kind of PLD to address
decode the whole works and perhaps act as the communications interface
to whatever you want to connect it to (serial to USB or parallel or
whatever). The PLD could also let you write to the emulated character
ROM (another static RAM perhaps). That's assuming you want to go the
two bus route. Another way you could make this whole thing work would
be to mux the address and data bus between the NES and an MCU, and
have the MCU communicate with the host system. You would still need
to bank in some sort of debug monitor, but that could be uploaded into
the static RAM by the MCU when the system starts. The mux would let
you cut off access to the emulation RAM and be able to write directly
to the bus from the MCU, plus I believe there are some muxs that also
are dual power, converting the signals from 5v to 3v to use more
modern SRAMs or even a magnetoresistive RAM (which would be awesome
since it would retain the stored application without any power, and
thus you could use your development cart between machines without
worrying about data loss).
One major bummer is that while the IRQ is exposed to the cartridge,
there's no reset. :( This means either the programmer must
physically press the reset button when the system hard crashes (or to
boot another uploaded program), or force them to jerry-rig a
connection to the reset line coming from the NAOC. Either way is a
bummer. If I remember correctly, the NES lockout chip on the
cartridge had a direct connection to the reset line, so I think you
could just pull that bad boy low and reset the system. But if you're
dealing with the Famicom bus you don't have a lockout chip. :(
OK, now for a couple more questions:
1) Are you trying to make a development system dedicated just to the
VT02 / SUBOR? If so, do you know what the market penetration for that
system is?
2) Do you want it to be a general purpose dev kit for all NES like
systems? If so you should probably design something for the dual bus
(program + data / video) Famicom system and use NES adapter boards if
you're using an NES.
3) The most serious issue I see with using these NAOC systems isn't
the tiny amount of RAM or limited video subsystems, it's the complete
lack of any kind of non-volatile data storage. How do you save the
progress that a kid is making in a typing tutor, for example? What
about BASIC programs that they write? Not being able to retain
progress is a serious bummer.
Well I've really rambled on far too long again. It's an interesting
project, I like the idea of being able to just distribute free
educational software to the worlds masses.
-Kevin.