Arduino Graphics Card

Until I move away from the propeller chip entirely for my graphics, I will want to make my code run faster.  I want more RAM free to store sprites and 3d lines, and I want better framerates.

I have always used spin for programming the Propeller chip, however I have recently discovered that Propeller C is now faster than spin.  To be exact, for some programs it can be twice or even 5x as fast!!!

I got this data from here.

I think my program could have a decent increase in speed using propeller C.  There are two caveats however:

1. Most of the CPU time is spent in assembly routines, not spin code
2. The communication bottleneck is (mostly) in the 115200 bps serial, not the spin code

To speed up the assembly routines I could overclock the propeller chip.  This has been done.  The propeller reaches about 100 Mhz on most chips if I remember correctly.

The communication bottleneck could be fixed by adding a SPI communication option.  I must keep serial however to keep a certain level of backwards compatibility with my older versions.

Assembly code (and almost everything) working.

I still need to do a little more optimization to speed up the rendering, but other than that the thing works!  :-D

Doing trig in assembly

The sine function actually works!  But cosine doesn't.

I suspect it is a problem with signed multiplication/division.  It *should* work... But ya never know.

I have tried other angles and different multipliers (instead of 16384)

I think after this my 3d rendering might actually work in assembly!

EDIT : im posting latest code on GitHub if you are interrested. Check project page for the link.

Thanks @oshpark for the beautiful boards :-)

Now I need to finish the software...

I fixed some bugs in the Arduino libraries today, but I still need to finish the 3D graphics.  I have decided that my original model for the rendering will not work.

Why not?

Too many cogs are competing for graphics rendering at the same time.  One cog must do all rendering for the entire NGT30. I have noticed rendering issues.

Also, my assembly code is not going to be able to render the graphics even if it were the only cog using the Graphics object.

Additionally, the original rendering model wastes a ton of processing power and slows everything down.

What is the new idea?

Have a cog running assembly code to calculate the screen coordinates of 3d coordinates.  The Arduino will send a command to the NGT30 when the 3D objects must be rendered. The main cog will actually send the commands to the Graphics object, while the assembly "calculator cog" will do all the necessary trigonometry.

This should be better AND easier! :D

My OSH Park boards arrived!  I had most of the parts but I realized I was missing two important components for the PCB:  arduino shield headers and ic sockets.

Well, the board seems cool so far!  I just won't be able to test it.

I decided not to solder the resistors without the rest of the parts.  

3d rendering in the parallax propeller's spin just isn't fast enough.  In case you don't know, the parallax propeller actually INTERPRETS SPIN CODE.  Although spin is still reasonably fast, I can get it much faster if I got the rendering going in assembly.

This is what I have been working on lately, and it seems that it *somewhat* works in the simulator.  But nothing ever renders. The simulator says that the graphics command register is always occupied, and, for some reason, never empties itself (as it shoud and usually does).

So I dug in the hex files to find ...numbers... : 

I don't want to go into details, but basically this proves that the entire command chain is being ruined by my assembly code.  I think that if I fix that my assembly will render 3d graphics!

ALSO. I am making a commit to my github so that anyone who wants to take a peek at my code can.

I got these nice boards from OSH park Thursday:

I only made one mistake (so far as I know):  the communication pins for the arduino are FLIPPED.  So these boards cannot be made backwards-compatible with NGT20 anything.  Other than that, this board seems to work great!

I will be porting #Arduino Desktop to this soon.  I just need to make sure the keyboard pins are right and I need to hack the Arduino library for communicating with the NGT20 for compatibility with the error on the PCBs.

The cube I had been rendering did not calculate for camera pitch/yaw, so if it was a 3d game you would only be able to look in the +X direction.  I added some math to fix that, but then I got another problem.

I wasn't using floating point numbers, and I was using a homemade arctan table which, sadly, may have been less than accurate.  The cube jumped around the screen and was recognisable only most of the time.

I was using propeller spin language, and used fixed-point arithmatic.  I think its time I used c++.  We shall see how it goes!

I wasn't sure if the propeller could handle 3D graphics, but I gave it a shot this weekend.  I did it, I got a rectangular prism up and made it move!

The NGT30, which I am going to be building when I get the boards back from OSH :D, will be 3d-graphics capable.

I have ordered the prototype NGT30s from OSH.  I decided not to modify the board (like make any Through-hole components SMD or anything) because I am terrible at SMD resistor sizes and couldn't figure it out.  Should get the boards in a few weeks :D

The new firmware will be pretty much the same as NGT20 firmware.  The board is just improved for flexibility and an added PS2 port, shrunken down and made more affordable.  I want to add something fun to the firmware but I have no idea what.  The current NGT30s have no NTSC/PAL port, so much of the RAM is not used and many cogs of the Propeller could be used.  If you have any thoughts let me know!