During this winter break I decided to revisit an old project that I attempted to build when I first started working with microcontrollers. This particular project was a TI graphing calculator memory expander called PIXPander that was created by a man named Sami Khawam. PIXPander was a device that consisted of a PIC16F84 microcontroller, a Playstation memory card, and various discrete components to provide 128KB of external memory to TI graphing calculators. Unfortunately, I was never able to get this device to work, even now. What follows is my research into this device and my attempts to get it to work, as well as suggestions for anyone who may decide to pick up this project themselves.



Was this design tested before being published?
 Has anyone ever gotten this to work?
  Doniguan on ticalc.org apparently got it to work, but his comments seem suspect to me
   entire TI-83+ games library, plus calc vids all on a 128KB memory card?
  zecoj got it to work?
  ftp83plus tried building PIXPander and was unsuccessful
  I myself have tried and have not gotten it to work (even after modifying the schematic to include level shifters and a proper 3.4V supply)
   I believe there to be a communications problem between the PIC and the calculator
    I only get the LEDs to sweep after sending a variable to PIXPander fails

Hardware issues
 Mem. card runs @ 3.4V, however there are no level shifters being used between the PIC and the memory card
  No pull-up resistor for ACK? (need to check firmware about this one)
   Why use 18KΩ pull-up resistors?
   
Firmware issues
 Supplied hex file is faulty (there's an instruction "bsf 0x75, 04", which is invalid)
 new files at next frame after an end frame, but still within same 32K segment?
  how would you read a file in the middle of a 32K segment that's not in a group?
 speed of calc vs. speed of memory card?
 
This project is over 10 years old.
 Firmware was written using SPASM -> have to convert to MPASM format to work with current-gen tools (my converted MPASM source is available in the files portion of this post)
  Can compile with SPASM and program hex to a 16F84 with ICProg
 Firmware source code is incredibly buggy and unfriendly to modify, even for beta (alpha?) code (why on Earth would you release source code as a pdf?!)
  May be better off to start from scratch?
 PIC16F84 is now waaaaaaay obsolete (thankfully Microchip still produces their old parts, unlike *cough*Atmel*cough*)
  Could re-compile MPASM source to use PIC16F84A very easily
   Port to 16F628?
 
Assuming PIXPander did work,
 From what I can tell you can only store to 4 locations (need to check firmware)
  Does this mean you can have at most 4 files on the memory card? (which would make this device rather restrictive)
   Corroborated by AuroraBoriales? http://webcache.googleusercontent.com/search?q=cache:ANp7KEuU_HUJ:www.ticalc.org/community/surveys/57.html%3Fp%3D3+pixpander+site:ticalc.org&cd=25&hl=en&ct=clnk&gl=us
   Or does it mean you can only store at most 4 transfers worth of data (<=32KB) at a time? (would complicate transferring individual files back to a calc)
 Automatic overwrite is dangerous
 Very bare-bones feature set
 W32Tran8x and PIXPander?
  Had to install Windows 95 to get it to run :P
  All "XPander" references are greyed-out
 Not practical (even back then, you could get EEPROMs far cheaper than PSX memory cards, though PSX memory cards were fairly common)
  only extends memory by 128KB (unless you have one of those "expanded" memory cards like this)
  Much cheaper to just buy a used TI-83+ SE or TI-84+ SE, not to mention 1.5MB ROM > 288KB (160KB FLASH of TI-83+ + 128KB Playstation memory card) 8x increase in ROM vs. .8x increase (SE will increase mem. 10x more than playstation memory card)
  Would be better to adapt another expander (Expander II, TICFRW, etc.) for the TI-83+ if one is serious about having external memory for the TI-83+
  Is a TI-83+ memory expander in demand anymore, considering the TI-84+ with msd8x?

Some history of PIXPander and related projects:
 PIXPander was originally based on (Smart Media then) Samsung FLASH chips? http://web.archive.org/web/19991022231959/sami.ticalc.org/e_pxpand.htm
  He never tested his first design using FLASH chips (doesn't really seem like he devoted enough time PIXPander)
  Why go from 4Mb FLASH to a 1Mb Playstation memory card?
 
 Cemetech 
  http://www.cemetech.net/forum/viewtopic.php?t=1779&start=0&postdays=0&postorder=asc&highlight=
 ftp83plus
  http://bx.yaronet.com/posts.php?s=2005
  http://www.google.com/search?sourceid=chrome&ie=UTF-8&q=pixpander+site:yaronet.com
 Expander II
  http://web.archive.org/web/20010801225401/horizon.pair.com/e2/
  http://web.archive.org/web/20041206004450/http://staidm.org/old/horizon/e2/
  http://www.ticalc.org/archives/news/articles/11/112/112314.html
 Mel Tsai?
  http://web.archive.org/web/19970612220726/http://www.egr.msu.edu/~tsaimelv/expander.htm
  http://www.mtsai.net/documents/appnote/appnote.html

Files
Here are the files that I have been using while working on PIXPander (includes a new schematic, source code, and hex files): http://www.ultdev.com/files/pixpand.zip

TL;DR
If you want more memory on your calc, buy a TI-84+ and a USB mini-A plug to USB A receptacle adapter cable so you can use a USB mass storage device as an external memory expander.
If you *really* want to make PIXPander work, build the circuit from the schematic posted here and write your own firmware for the 16F84 (better yet, move to a newer microcontroller platform.)

Wow, this sounds like an entremely, extremely comprehensive review, Ultimate Dev'r! Congratulations for your persistence and thoroughness; a lot of people could learn from your superb example. As far as the project goes, now that you've explained the details of this project that I previously had only heard vague details about in such depth, it sounds very suspect. Indeed, I tend to think that either the project never worked, or that the author released some earlier, nonworking version and never released his functional code. I'd be happy to assist with the linking protocol if possible, since you mentioned that as one of the areas that seems to be a bottleneck, and I certainly consider that silly games library claim downright laughable. Hell, I know single projects that are around 128KB, notably some of TIFreak8x's and DJ Omnimaga's.

One problem with the Expander II: the plans don't exist. The guy's site is gone, and the schematics are not in the zip you can download.

An SD card reader would be awesome

I can only assume that Ultimate Dev'r somehow either found them or figured them out; perhaps he would share his secrets?

Certainly agreed. Bitbanging the protocol would be impressive...

Perhaps he already did and somebody didn't read his post carefully (hint: look under the heading "Some history of PIXPander and related projects:")



...but impossible over a two-wire linkport Maybe use a USB SD card reader on a TI-84+ with msd8x?

Ultimate Dev'r, certainly not impossible with a simple pair of shift registers and some sundry coordinating logic, I think. In fact, if you take a look at SPI mode, I think that two wires actually would suffice:

http://www.planetmobile.it/jumpjack/adattatore/pinout-eng.html

After looking further into this, you might be able to use a universal shift register (one that's bidirectional, serial-in-parallel-out and vice versa, and has data hold capabilities), but this may not be fast enough for SDHC and above cards (do speed classes apply for SPI comms?), in which case you'd need to use a microcontroller.

As for using SPI over only 2 wires by themselves, you'd lose some functionality by tying CS low (i.e. auto-detection, some helpful things for debugging), and you need to use two separate data lines (can't use SISO; see pg.99 of the SD Card manual), so you'd need a minimum of 3 wires for SD card SPI comms.

Meh, that's a bit of a pain; thanks for researching it. I guess a uC intermediary would be necessary regardless.

Umm, SDHC and SD have no minimum speed, as far as I understand it. You can go as slow as you want, just that they are classified according to max speed i.e. a class 6 card is much faster than class 2, but a class 6 card can be read as slow as a class 2, if the reader can't handle it.

Edited for clarification and error fixing.

They are actually classified by least sustained write speed, i.e. class 2 cards have a minimum sustained write speed of 2MBps, class 4 cards 4MBps, etc. The question I had was whether or not these classes prevent a card from operating below their rated minimum speeds (though on IRC last night I found that class 0 cards & regular SD cards don't have a minimum SPI speed (documentation I used is here and here), but I can't find any info on minimum SPI speed for sdhc cards.)

Do you know of any resources where you might be able to find more information? It's terrible that the non-SPI SD spec is guarded with such secrecy and licensing; it sounds like even the SPI stuff is poorly-documented.

The full specs are under lock and key by Sandisk, but I'm sure someone on edaboard or sonsivri would know.

Ah, that's about what I figured. I too need to venture outside Cemetech at some point, to ask if there's a way to distribute Arduino programs as objects/binaries rather than source code.

Presumably so, as avrdude lists "arduino" as a valid programmer type.

I managed to extract my gcnbridge2.hex file and figure out the command line to use avrdude to load the .hex file, and even made it work, but for the sake of Linux users (and to avoid having to include 1.8MB / 500KB compressed of the avrdude binary, I think I'll just hand out the source and hex file and let Arduino and AVR users figure it out on their own. I have a very stern admonition at the top of the source code about what not to do with it.