First Quickdev16 PCB is working

Not “out of the box” but with only slightly changes on the software part, the new quickdev16 PCBs are working. Their shape fit the SNES cartslot, the changes in hardware design and parts worked out great and we have a kind of stable firmware and upload tool.

When you turn on the SNES, the microcontroller extracts a small loader-rom into the cartridge RAM that is mapped into the SNES addressspace. This one copies itself to SNES’s WRAM and jumps into it. So the cartridge RAM is unaccessed and we can safely switch back to the AVR mode to push a real payload rom onto the cartridge. We are also working on a shared memory function so that we can use the cartridge RAM to exchange infomation between the AVR and the SNES. This will be used to display a proper Progressbar while uploading a rom.

As usal you can use our patched version of ucon64 – even under windows – to upload a game to the quickdev16. When the upload is done, the SNES reset line is pulled by quickdev16 and the game starts. When you press the reset button, you only reset the game, not the quickdev16 – it acts like a normal cart. When you press the reset button during the upload process or while watching the loaderscreen, you reset the quickdev and can abort uploads or just restart the quickdev16 – thats a really usefull feature. To initiate the upload of a new game, just start the upload process with ucon, the quickdev switches to the loader mode by itself and receives the new ROM.

So the steps are now to improve the loader code, finish the progress bar stuff, figure out how to solder the PCBs faster than now and add some minor features. Stay tuned for updates, it’s not too long to the release.

svgallery=

Quickdev16 Pre-orders

I start taking inoffical pre-orders for the Quickdev16 now. Just send me an email to david at optixx.org with your name and email address. In order of arrival i will put you on the pre-order list. Right now we plan to sell around 35 cartridges.

Why inoffical pre-orders list? A fews points are unclear right now. I don’t know the final price since this will depend on the assembling costs which are not setteld yet. I can’t say if the the new PCB are working 100% since we didn’t test it yet. Also we didn’t figured out if we gonna ship the cartidge with a CIC chip or not. The client software is tested and developed under Linux and OS X. Can’t say much about windows. But if you can compile ucon64 with libusb support in windows you should be fine. I will give this a shot soon.

These points will clear up within the next 2-3 weeks. But expect an sale price around 100 USD or 80 Euros. I gonna use paypal for international shipping and direct debit in Germany and even Europe. Will provide an an IBAN and paypal account later.

I don’t take any money before everything has clear up. So the pre-order is not binding as long as you are not happy with the final outcome of the project. I just started this pre-order list, since a few people start asking for it and they don’t want to miss the opportunity to get one.

Just a quick preview of up coming features.

  • up to 16Mbit Roms supported
  • Ucon64 upload via USB
  • Lo/Hi Rom
  • Serial Debug Console
  • SNES Boot Loader
  • SDcard Daughter Board planed

We call it ‘QuickDev16 USB’

Finally we found a better name for the snesram and renamed it to ‘QuickDev16 USB’. Final PCB layouts are ready and will be send to china soon. So in about 2 weeks we will have our first PCBs.

Confirmed Features:

  • 16 MBit Sram for Rom storage
  • ATmega644 MCU for housekeeping
  • USB connection for ROM upload
  • ucon64 software compatibel
  • PAL/NTSC CICs are supported
  • Lo/Hirom support
  • Reset trigger from cartridge possible
  • AVR USB Bootloader for quick firmware uploads
  • Snes bootloader intro
  • Snes powered, no power source needed

Stay tuned for more features, especially debugging helpers

pov_front_2.6

pov_back_2.6

Features Features Features…

Things are going well. Have added some features to the software side and also got some stuff working hardware wise.

Can confirm that US/JAP roms are working.Only tested EU roms before. Used my japanese Nintendo junior and a japanese CIC to confirm that the snesram is working with that setup too.

Max and i added an bootloader to the AVR software toolchain. Now its possible to flash the AVR firmware via the same USB cable as for the normal bulk transfer. So no extra ISP programmer is needed to change the AVR firmware. This is super fast, can flash the 16kb client side firmware in like 3 secs.

Added a reset line trigger to the snes bus. Now the client software can reset the snes after uploading the software. So its possbile to push a rom via ucon64 from the pc and then reset is done by ucon64 and the firmware. No interaction needed from there.

Max is refactoring the schematics so that we can send them over to the pcb fab soon. Stay tuned.

New Hardware Revision

Max took a quick break from his vacations and was able to work on the new hardware revision of the snesram. Its mainly a bugfix to version 0.1 . We also did some cost reductions. Most obvious is to go for 2 Mbyte of sram instead of 4Mbyte. It just make the PCB smaller and less complex. I guess this should be alright with most peoples needs. We gonna print a small amount of PCB and will take pre-orders as soon as we know they will arrive. Not sure about the final price, depends on the PCB costs and if we get better prices for the sram. Stay tuned.

Changes in Detail:

* Add AVR reset button
* Fix CS bug and add additional gate
* Reduce to 2 Mbytes for 16 Mbits games
* Snes reset line trigger
* No FTDI for the serial line
* Add RX/TX to pin header
* Model Snes connector header
* 1,2 mm PCB for direct plug
* Blacksolder Mask
* White silk screen

Preview:

Front

Front

Back

Back

Ucon64 Support

The software is coming down smoothly. Ported the usb uploader code to ucon64. Also Hirom support ist working now with ucon64 autodedection. So the Snesram board is becoming quite handy for daily dev work.

This hardware revision has 2 bugs which doesn’t make it possible to print pcbs now. There is additional OR gate needed to drive the CS line properly and an AVR reset switch is missing too. I guess when Max is back from his holiday he wants to fix this in the pcb layout. I think it would be smart to only use 4 sram chips and to have 2mb and not 4mb. Just to reduce the cost and get some more space on the pcb. If there is an interest from the community to support this hardware revision we gonna print some pcbs and sell them. Otherwise we gonna start working on a enhanced version soon.

A video showing the hardware with ucon64 in action…

[flash]http://www.youtube.com/watch?v=1mfq6yJA1MQ[/flash]

The eagle has landed!

Yeah, its working. Have been playing Super Mario Word last night. Did a few tests with different roms. Mainly Lorom, type 0 without save game ram. Was able to run games up to 16bmit. Couldn’t find any 32mbit type 0 games to test the complete ram area. Anyways its working finally. What de did? Resolder the cart connector and cleaned the contacts :-)

And some pictures of the OR gate hack:

Now its time to work on the software side. Stay tuned.

The magic of bus sharing

I did some more debugging over the weekend. The thing to investigate was why roms crash or hang when music starts. That was the last suspicion we had on thursday.

So mukunda from #snesdev helped me and made a few test roms to investigate the problem with the SPC. First we started with a simple test to find out that during the SPC boot the system stalls. So it was verified, that music triggers the problem.

I learned that the system needs to read back $2140 and $2141 to get the SPC status. So where software will wait for $AABB in that registers. I suggested to mukunda to add verbose debug printing on the display to see the register status. Also he added color flashing of the background so see if the snes crashes or just idles on the register poll.

So it came out that the register always reads $2121, which is an openbus. Made a video from that tests:

[flash]http://www.youtube.com/watch?v=gTMA8aCmMco[/flash]

So i suspected that there is something wrong with the CART/CS line, because it looks like the rom doesn’t get deselected.

Background to this is that MMIO access of the register $2140/2141 make the address appear on the A bus. RD will go low and CS will go high for deselecting the rom. This should activate the SPC on the A bus. So i made a little logic analyzer session with the prototype board to verify this. The outcome looked quite ok.

READ and MMIO READ

RD and MMIO RD

Next day Max joined me debugging and i explained him that we have a conflict on the A bus during MMIO. Going thru the schematics we figured out that the only weak spot could be the busdriver which forwards the CART IO line and switches the ram address and data bus to the SNES A bus.

So Max added another OR gate to get better control over the CS line. What we needed was this:

CS: Cart ( low active )
EN: SNES enable from avr
G:  Busdriver enable

 CS EN G
 --------
 1  1   1
 0  1   1
 1  0   1 
 0  0   0  

Since i didn’t had anything better than an 74LS00 at home, we did it with 3 AND gates. And this did the trick. Now we were able to boot roms which used the SPC. So we think the problem was that the budsriver was soaking up too much voltage, when the SNES was pulling CS hi the SPC didn’t got triggered.

After running a few games, we found that that now he have random crashes somewhere else :-( Have to investigate this right now…

  • Loose connections
  • SRAM timings
  • Memory corupptions