Dodo is finally complete!

[pnoyes]

Hey everyone! The Dodo project I have been working on for some time is finally complete.

Basically it is a 1mhz 65C02 handheld game system running off of AAA batteries with swappable came cartridges, monochrome graphics, and a single voice of sound. There is a web IDE where games can be developed in either C or Assembly. Here are ports of Tetris https://play.dodolabs.io/?code=89e9a475 and Space Invaders https://play.dodolabs.io/?code=67cc1a42

I have made it available as a kit on Tindie: https://www.tindie.com/products/pnoyes/ ... ystem-kit/
All of the project logs are available on hackaday.io: https://hackaday.io/project/9325-dodo-6 ... ame-system
Here are the instructions: http://docs.dodolabs.io

Thanks for looking!

[jim30109]

I have the kit and am looking forward to building it. Got sidetracked playing with my FPGA system on my week off, but the Dodo is next on the list!

[pnoyes]

jim30109 wrote:

I have the kit and am looking forward to building it. Got sidetracked playing with my FPGA system on my week off, but the Dodo is next on the list!

Awesome! Thanks for picking one up. Let me know if you have any suggestions for the API. I am starting to queue up some ideas for the next revision of the firmware.

[BigEd]

Excellent news, and a great project.

[Alarm Siren]

Indeed, I have to say this is really cool, and I may well pick one up myself if it can be shipped to the UK. I particularly like the WebIDE - I wouldn't even know where to begin making one of those.

Having had a look through the API documentation, one major suggestion I have is some kind of Save Game feature. Perhaps reserve a small number of bytes - for the sake of argument lets say 128 bytes - somewhere on the FRAM cartridge which the game can read and write using API calls.

[pnoyes]

Alarm Siren wrote:

Indeed, I have to say this is really cool, and I may well pick one up myself if it can be shipped to the UK. I particularly like the WebIDE - I wouldn't even know where to begin making one of those.

Having had a look through the API documentation, one major suggestion I have is some kind of Save Game feature. Perhaps reserve a small number of bytes - for the sake of argument lets say 128 bytes - somewhere on the FRAM cartridge which the game can read and write using API calls.

Thanks! I do intend to provide international shipping. What method would you prefer? I have heard horror stories about using USPS internationally, and the private carriers seem quite expensive.

Also, thanks for the save game suggestion. I already reserved 100 bytes on the FRAM for such a purpose, there is just no API around it yet. I logged it as an issue here: https://github.com/peternoyes/dodo/issues/2

[Alarm Siren]

I've never personally had experience of having had things shipped from america by USPS, at least that I can recall. I think normally when things are posted to me internationally its either FedEx or UPS. In any case, they always hit me with some kind if ridiculous (read, more than £10) duty & handling fee, but other than that I can't recall any problems.

EDIT: I've never actually used them yet, but OSH Park, a US PCB manufacturer, ships internationally using either UPS or USPS. I find it difficult to believe they'd offer an option that doesn't work.

[BigEd]

I think I've had books from the US by ordinary post. I've never had a problem. Of course, there will always be some small proportion of failures in shipping.

[GARTHWILSON]

When we had friends in France whom we wanted to send something, they specifically asked that we not use UPS or FedEx because the cost was ridiculous, but that we only use USPS (United States Post Office).

[pnoyes]

I just enabled international shipping using USPS Priority Mail International which seems to be the best value.

[BigDumbDinosaur]

pnoyes wrote:

Thanks! I do intend to provide international shipping. What method would you prefer? I have heard horror stories about using USPS internationally, and the private carriers seem quite expensive.

I've used the U.S. Postal Service's Priority Mail to send stuff to Canada, Europe and Australia. I've never had a problem with it.

[Alarm Siren]

pnoyes, what kind of current does this thing draw?

My research of what's in there suggests that there shouldn't be enough current (or only just barely) to run this thing.

The main buck boost according to the datasheet is good for 400mA, and the LDO stepping down to 3.3V is good for 250mA. From my research, the screen alone should draw 310mA peak, RAM & ROM ~40mA each....

EDIT: Scratch that, according to your v1.4 schematic from github, the Buckboost you're using is only good to 200mA, which puzzles me even further.

[pnoyes]

Alarm Siren wrote:

pnoyes, what kind of current does this thing draw?

My research of what's in there suggests that there shouldn't be enough current (or only just barely) to run this thing.

The main buck boost according to the datasheet is good for 400mA, and the LDO stepping down to 3.3V is good for 250mA. From my research, the screen alone should draw 310mA peak, RAM & ROM ~40mA each....

EDIT: Scratch that, according to your v1.4 schematic from github, the Buckboost you're using is only good to 200mA, which puzzles me even further.

When measured before the boost converter, Dodo typically pulls around 180mA at 2.5v while a game is being played. The LT1303-5 can produce 200mA at 5V. The output of the converter is 5V and less than 100mA (well under the 200mA limit).

EDIT: Just to follow up:
The Display from the Datasheet pulls a max of 90mA at 3.3v (so 60mA from the 5V perspective) but it is not run at full brightness so it consumes less.
The RAM and ROM pull far less than 40mA each because they are clocked at 1MHz. Current consumption is related linearly to clock speed and those current limits are spec'd for the maximum supported clock speed which is an order of magnitude higher.

[Oneironaut]

Wow, I have only been away from this forum for a little while, and it is great to see how far your project has progressed in that short time.
Nice work!

Brad

[Alarm Siren]

pnoyes wrote:

EDIT: Just to follow up:
The Display from the Datasheet pulls a max of 90mA at 3.3v (so 60mA from the 5V perspective) but it is not run at full brightness so it consumes less.
The RAM and ROM pull far less than 40mA each because they are clocked at 1MHz. Current consumption is related linearly to clock speed and those current limits are spec'd for the maximum supported clock speed which is an order of magnitude higher.

Thanks for that. I had not considered that, of course, the RAM/ROM will draw less current at less than their maximum specified clock speed. I do a lot of not quite thinking things through! As to the screen, the nearest equivalent I could find to what you're using (there's no part numbers so I'm going by physical looks of the screen) says it draws up to 310mA, so I'd be interested to know what screen you're using.

A further note, I believe that the 1N4148 diodes in your debounce circuit are unecessary. The circuit you've used is a direct lift from here, which on the matter of the diode states:

Quote:

The diode is an optional part needed only when the math goes haywire. It's possible, with the wrong sort of gate where the hysteresis voltages assume other values, for the formulas to pop out a value for R1 + R2 which is less than that of R2. In this case the diode forms a short cut that removes R2 from the charging circuit. All of the charge flows through R1. The previous equation still applies, except we have to account for drop across the diode. Change Vfinal to 4.3 volts (5 minus the 0.7 diode drop), turn the crank and R1 pops out.

However, R1 + R2 is obviously greater than R2 in this case. Further the R1/R2 values are those from earlier in the article, and do not take into account the diode (Vfinal = 5V not 4.3V) so it may actually be suboptimal to have the diode in place.