oPossum 1,083 Posted July 11, 2011 Share Posted July 11, 2011 A frame buffer for 256x192 pixels requires 6k. That is more than will fit in RAM, so the frame buffer is in the FRAM memory. NTSC video generated using TimerA0 for sync, and SPI with DMA for video. Graphics library functions: [*:hf56qo2f]Pixel[*:hf56qo2f]Line[*:hf56qo2f]Box[*:hf56qo2f]Circle[*:hf56qo2f]Ellipse[*:hf56qo2f]Quadratic and cubic bezier curve[*:hf56qo2f]BitBlt up to 24 pixels wide[*:hf56qo2f]OR, AND, and XOR drawing modes[*:hf56qo2f]Text with 8 x 12 font jsolarski, RobG, NatureTM and 12 others 15 Quote Link to post Share on other sites
EngIP 31 Posted July 11, 2011 Share Posted July 11, 2011 Stunning! Quote Link to post Share on other sites
RobG 1,892 Posted July 11, 2011 Share Posted July 11, 2011 Now add Z80 emulator and I can have my favorite computer from the 80's right on my FP. Awesome. Quote Link to post Share on other sites
Mac 67 Posted July 11, 2011 Share Posted July 11, 2011 Now add Z80 emulator and I can have my favorite computer from the 80's right on my FP. Awesome. Slightly off topic but I agree... a Z80 emulator, or others, would be cool... Quote Link to post Share on other sites
gwdeveloper 275 Posted July 11, 2011 Share Posted July 11, 2011 This is great! Every time I see a post like this it makes me feel like I know even less than I thought I did. Good job! Quote Link to post Share on other sites
zborgerd 62 Posted July 11, 2011 Share Posted July 11, 2011 This is great! Every time I see a post like this it makes me feel like I know even less than I thought I did. Good job! Yeah. oPossum is a uC prodigy. Quote Link to post Share on other sites
dubnet 238 Posted July 11, 2011 Share Posted July 11, 2011 This is great! Every time I see a post like this it makes me feel like I know even less than I thought I did. Good job! My seniments exactly. I feel like a first grader in a PhD program. Quote Link to post Share on other sites
RobG 1,892 Posted July 11, 2011 Share Posted July 11, 2011 Slightly off topic but I agree... a Z80 emulator, or others, would be cool... If you think about it, circa 1982 ZX Spectrum for example was Z80 based and could produce very impressive (for 80s) graphics. ZX was 8bit 3.5MHz, FR5739 is 16bit 24MHz; ZX had 16k of ROM and 16k of RAM, FR has 16k + 1k; ZX had ULA, FR has DMA, Timers and UART. I think you can create a very impressive home computer using MSP430FR5739. Quote Link to post Share on other sites
SugarAddict 227 Posted July 11, 2011 Share Posted July 11, 2011 Slightly off topic but I agree... a Z80 emulator, or others, would be cool... If you think about it, circa 1982 ZX Spectrum for example was Z80 based and could produce very impressive (for 80s) graphics. ZX was 8bit 3.5MHz, FR5739 is 16bit 24MHz; ZX had 16k of ROM and 16k of RAM, FR has 16k + 1k; ZX had ULA, FR has DMA, Timers and UART. I think you can create a very impressive home computer using MSP430FR5739. Do eeeettt!! Quote Link to post Share on other sites
nexusone1984 32 Posted July 12, 2011 Share Posted July 12, 2011 First like to say great work.... I loved the old Z-80 and the Motorola 6809 (Color Computer). This reminds of stuff that I used to write on Color computer. Now just add a routine to let you play Space Invaders, one Analog input for a pot and a switch for fire.. Quote Link to post Share on other sites
oPossum 1,083 Posted July 23, 2011 Author Share Posted July 23, 2011 The first font that I used with this was from the MC6847 used by the CoCo 1/2. I had that font in the form of a C array. Many years ago I wrote an emulator for all of the Tandy/Radio Shack home computers. I think it was the first emulator to do MC-10, Model 100 and Tandy 200. The others had been done before. It may be possible to emulate some of the old home computers with an MSP430, but I think it would be very slow. My M80 (Multiple eMulator of TRS-80) emulator running all supported systems concurrently... Quote Link to post Share on other sites
oPossum 1,083 Posted July 23, 2011 Author Share Posted July 23, 2011 Using FRAM for a frame buffer seems to have some problems. There are video artifacts that I assumed where due to instruction cache misses causing clock jitter, but running at 8 MHz clock did not fix that problem. I also may have damaged some of the FRAM - there are some bits that are no longer programmable. So, I am going to switch to a MSP430F5418A and use part of the 16K SRAM as frame buffer. That should fix the video artifact problem and also be a little faster. I added some primitive 3D functions, so here is the obligatory 3D cube (with very noticeable artifacts)... All three axis are rotated concurrently. This is done entirely with 16.16 bit fixed point math. Here is some of the code... void rotate_3d(T3DP const *s, T3DP *d, unsigned n, int rx, int ry, int rz) { long sx, cx, sy, cy, sz, cz; long yx, zx, xy; register long x, y, z; const unsigned long focal_length = 200; unsigned long scale_factor; sx = sin(rx); cx = cos(rx); // Get sin/cos of rotations sy = sin(ry); cy = cos(ry); sz = sin(rz); cz = cos(rz); while(n--) { x = s->x; y = s->y; z = s->z; // Get source point zx = ( y * sx + z * cx) >> 16; // Rotation around x axis yx = ( y * cx - z * sx) >> 16; xy = (zx * sy + x * cy) >> 16; // Rotation around y axis z = (zx * cy - x * sy) >> 16; y = (xy * sz + yx * cz) >> 16; // Rotation around z axis x = (xy * cz - yx * sz) >> 16; // Perspective scale_factor = (focal_length << 16) / (focal_length - z); d->x = (x * scale_factor) >> 16; d->y = (y * scale_factor) >> 16; d->z = z; ++s; ++d; // Inc source and dest pointers } } static const unsigned st[90] = { // sine table 0 to 89 degrees 16 bit fraction 0, 1144, 2287, 3430, 4572, 5712, 6850, 7987, 9121, 10252, 11380, 12505, 13626, 14742, 15855, 16962, 18064, 19161, 20252, 21336, 22415, 23486, 24550, 25607, 26656, 27697, 28729, 29753, 30767, 31772, 32768, 33754, 34729, 35693, 36647, 37590, 38521, 39441, 40348, 41243, 42126, 42995, 43852, 44695, 45525, 46341, 47143, 47930, 48703, 49461, 50203, 50931, 51643, 52339, 53020, 53684, 54332, 54963, 55578, 56175, 56756, 57319, 57865, 58393, 58903, 59396, 59870, 60326, 60764, 61183, 61584, 61966, 62328, 62672, 62997, 63303, 63589, 63856, 64104, 64332, 64540, 64729, 64898, 65048, 65177, 65287, 65376, 65446, 65496, 65526 }; long sin(int d) { while(d < 0) d +=360; while(d > 359) d -= 360; if(d < 180) { if(d < 90) // 0 -> 89 return st[d]; else if(d > 90) // 91 -> 179 return st[180 - d]; else return 65536L; // 90 } else { if(d < 270) // 180 -> 269 return -(long)st[d - 180]; else if(d > 270) // 271 -> 359 return -(long)st[360 - d]; else return -65536L; // 270 } } long cos(int d) { return sin(d + 90); } RobG, jsolarski and bluehash 3 Quote Link to post Share on other sites
bluehash 1,581 Posted July 23, 2011 Share Posted July 23, 2011 Jeez.. awesome. Using FRAM for a frame buffer seems to have some problems. There are video artifacts that I assumed where due to instruction cache misses causing clock jitter, but running at 8 MHz clock did not fix that problem. I also may have damaged some of the FRAM - there are some bits that are no longer programmable. If you are bent on using the Fraunchpad for display... I can arrange one for you, since you are doing some good work here. Quote Link to post Share on other sites
nobody 47 Posted July 23, 2011 Share Posted July 23, 2011 If anyone is looking for good fonts in "C" format - try here. Quote Link to post Share on other sites
RobG 1,892 Posted July 26, 2011 Share Posted July 26, 2011 ...I also may have damaged some of the FRAM - there are some bits that are no longer programmable... How did you manage to do that? You didn't exceed the number of write cycles, did you? Quote Link to post Share on other sites
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.