Reading real cartridges (Update - IT LIVES! - video)

[abrugsch]

Here it is, all made up!

IMG_20170216_231657.jpg (2.67 MiB) Viewed 8857 times

IMG_20170216_231704.jpg (2.58 MiB) Viewed 8857 times

IMG_20170216_231735.jpg (2.44 MiB) Viewed 8857 times

IMG_20170216_231719.jpg (2.85 MiB) Viewed 8857 times

I just have some testing but continuity tests so far show there's no stray solder joints!

[abrugsch]

Well good news and bad news...

first the good news.
I plugged it into my testbed Pi and nothing blew up!

connected the power select jumper to 3.3v and did an I2CDetect and only one device showed up. device 0x21 which is the data bus and ancillary signals chip. with only one chip showing up I couldn't do a test run of slurp with a cartridge, so I had to manually poke the registers and see what worked using i2cset.

Code: Select all

Device Write Error

OK, lets try switching over to 5V.
BOOM - Pi immediately resets itself. figured I have a short somewhere related to the 5V line so went back to 3.3v trying various things including a python script to tickle the pins but no luck. the chip detects but doesn't write without getting an error.
Then I remembered these early Pi revisions have pretty crappy power management so I rebooted it with the 5v line connected from the boot. Well it didn't kill the pi, and I2Cdetect shows 0x21 still in the device map, so lets try the python script... BINGO! write worked, so with a little editing I had it walk output values along the pins (and this is why I painstakingly added 27 SMD LED's to the board! worth it.)
However the IC at 0x20 still hasn't detected, so I can't do a full cartridge test til I can get back to the hackerspace and diagnose this properly
So Sudomodders... :

2017-02-17 12.47.56.jpg (2.95 MiB) Viewed 8825 times

here it is in it's partially working glory

[Helder]

Might be the pads on the chip being bridged and you can't see it. I had a similar problem when testing the usb hub chip on my board in the early test stages but some flux and a clean iron tip or better yet hot air gun will usually melt any bridged solder if it's tiny and should fix any soldering issues.

Does your hackspace have solder paste and a hot air rework station? you could just use a stencil and just place the parts on there and heat the board up for nice clean solder job.

[abrugsch]

Might be the pads on the chip being bridged and you can't see it. I had a similar problem when testing the usb hub chip on my board in the early test stages but some flux and a clean iron tip or better yet hot air gun will usually melt any bridged solder if it's tiny and should fix any soldering issues.

Yeah that's my thinking though I already did a thorough flux cleanup.

Does your hackspace have solder paste and a hot air rework station? you could just use a stencil and just place the parts on there and heat the board up for nice clean solder job.

Yes we have hot air but I don't have a stencil. I can laser cut one but tbh I wanted to hand solder this as I need more SMD practice. I have a bunch of spare chips anyway so won't be an issue even if it is a borked chip...

[abrugsch]

Ach it's not that much You'll get into a rhythm

I can safely say, I'll be glad that if I produce any boards for people, that there WON'T be 28 sets of LED/resistor pairs on them unless people want to pay a shit-ton extra or do it themselves The 0805's have easily been the biggest time-sink on this project (so glad I didn't go 0603!) Fortunately they're only for diagnostic purposes during the testing phase, which I can get away with having a breakout board for later on.

[abrugsch]

Might be the pads on the chip being bridged and you can't see it.

Well I had a good look through a loupe and couldn't see anything so gave it a blast with hot air and more flux but no joy. So I hot air'd the chip off, cleaned the pads up and placed a new chip on. And BINGO! works just fine

So here's the promised vid of it working all blinkenlights

(sorry about the crappy music, it was just some cack thing youtube suggested and it was pretty noisy at the space. Also it's straight off my phone with no editing so skip to about 3:00 for the meat)

[abrugsch]

The whole purpose of me making a test PCB was to try and push the speed up from what I was able to achieve with breadboard.
On the breadboard I was able to reliably use the I2C bus speed of 800KHz, above which I'd get garbage back from the cartridge. Probably down to a multitude of reasons in between the I2C signal leaving the pi, going across large jump wires to the chips, then large jump wires carrying the address and bus data to/from the cartridge, not to mention the known crappiness of the breadboard itself for carrying signals with any kind of integrity. there's stray capacitance all over the place, the wires pick up noise like antennas... basically good for demonstrating proof of concept and not much more.

so with the PCB I can eliminate a good chunk of that uncertainly. I can have ground planes, data pairs, short signal lines, decoupling caps... the whole shooting match.

the 23017's can run at an I2C speed of 1.7MHz. more than double I've been able to get so far.

I spent last night going through the bus speeds to see how much effect it had. in the above vid, at 800KHz, tetris dumps in just under 20 seconds. Upping that to 1.2MHz was not only successful (MD5Sum checked out) but came down to 14 seconds. not bad but I think we can do better (it's only 32K after all at ~2KB/s)

So what happens when we go for the full monty of 1.7MHz? Success! MD5 checks out ok, but the dump time was only down to 12 seconds... which sounds like we have a bandwidth between the pi and chips problem. Starting with the easy, I overclocked the pi (it was default 700MHz) and bumping up to TURBO (1.0GHz) helped and brought the dump time down to 9.5 secs. better but still not great (when we have a large cartridge like Perfect Dark, it's still going to be 5 seconds per bank with 128 banks still comes in at over 10 mins )

Optimise, optimise, optimise (Prime)
so now I need to start looking at where there are inefficiencies in my code. I was holding an input buffer of 64 bytes and writing that to SD so figured that operation may have added some slowening. and increasing that to 4096 bytes (4K) improved things a little bit. I took out a load of redundant code from the early days which was doing diagnostic logging, another minor improvement, so now I'm looking at how the bytes get transferred to and from the 23017's.

One of my very first major optimisations that I made in the early days was that the wiring pi library was only working in a pin mode sense. so to change all 8 pins on a port (each chip has 2 8-pin ports) I effectively had to send 8 commands to the chip. but each command carried the whole byte, so my code was slow by a factor of 8 as I only needed one command with all 8 pins updated in one go. So I bypassed the top level pin write function and pulled out the lower level read/write register functions and bit shifted my data in as necessary in memory beforehand and placed whole bytes onto the register.

now for every read operation, I have to:
place the address onto the address bus (chip 1 port A and B) = two write operations
set the read/write pins of the cartridge (chip 2 port B) = one write operation.
read the data bus (chip 2 port A) = one read operation
re-set the read/write pins (chip 2 port B) = one write operation.

now wiring pi has a few layers of abstraction in order to have a consistent interface across lots and lots of devices so I can pare that back (and probably get rid of the wiring pi dependency altogether, which has the added advantage that I can run this on C.H.I.P.) but I think the biggest potential help I just found was by digging through the datasheet of the devices... fast sequential mode.

fast sequential mode lets me write multiple bytes in one hit as long as the registers are sequential, removing some extra overhead. Beyond that I think I'm then done with how far I can go with Pi1 (or zero) and I2C. I haven't yet tried on a Pi2 or 3 mainly because I want to keep it usable on an original or Zero, meaning I may have to bite the bullet and get the SPI version of the chip (MCP23S17). The pins are more or less identical so I should be able to re-use this PCB with minimal modding.

So interesting times ahead!

[moosepr]

awesome work

[abrugsch]

awesome work

hey thanks!

I said above that I'm seeing a bandwidth of ~2KBps... I just looked at the timing diagram of an actual gameboy CPU/Cartridge as I couldn't remember exactly how it looked, a real cartridge is getting an address change on the rising edge of the clock pulse, and data placed on the bus on the falling edge until the next rising edge, so a whole byte is transferred every clock pulse. And the clock speed of a GB? 4.19MHz (8 on a GBC) but in reality it's 1.05MHz so with one byte able to be transferred on every one of those clock pulses you have a bandwidth extraordinarily close to 1MB/s.

that's 3 orders of magnitude faster than we're currently reading! there's clearly scope to be able to at least 10x the read rate...

[Camble]

I am suitably impressed