Could this be done with a Picaxe?
- Thread starter skatt
- Start date
Hi,
Quite possibly, but perhaps not the way you think. It's a long time since I wrote graphics to that type of display (directly in asssembler), but....
The screen's character display is probably not changing at all, he's just re-loading the 8 user-definable characters. That potentially needs 7 x 8 = 56 bytes to be updated, perhaps 20 times a second, so around 1 kbytes/second. That could even be done with a serial interface (maybe even the best approach with a PICaxe, using hserout) although he appears to be using a parallel interface.
I don't know if the "image data" is being generated "on the fly", but for a PICaxe you'd pull it all out of an external I2C EEPROM which had been preloaded (either by another PICaxe program, or by other means). So perhaps it can be done with an 08M2 ?
Cheers, Alan.
Quite possibly, but perhaps not the way you think. It's a long time since I wrote graphics to that type of display (directly in asssembler), but....
The screen's character display is probably not changing at all, he's just re-loading the 8 user-definable characters. That potentially needs 7 x 8 = 56 bytes to be updated, perhaps 20 times a second, so around 1 kbytes/second. That could even be done with a serial interface (maybe even the best approach with a PICaxe, using hserout) although he appears to be using a parallel interface.
I don't know if the "image data" is being generated "on the fly", but for a PICaxe you'd pull it all out of an external I2C EEPROM which had been preloaded (either by another PICaxe program, or by other means). So perhaps it can be done with an 08M2 ?
Cheers, Alan.
westaust55
Moderator
As Alan suggests using custom characters.
Trying to watch the video only seems to use a few characters for the "packman".
Add the dots and a couple of custom characters for the end image and it will likely fit in 8 let alone 16 custom characters.
For such a simple displays sped the you-tube clip it would be achieved holding some data in internal EEPROM.
Only need external EEPROM for more complex animations.
Certainly do-able for the simpler displays with the PICAXE.
Trying to watch the video only seems to use a few characters for the "packman".
Add the dots and a couple of custom characters for the end image and it will likely fit in 8 let alone 16 custom characters.
For such a simple displays sped the you-tube clip it would be achieved holding some data in internal EEPROM.
Only need external EEPROM for more complex animations.
Certainly do-able for the simpler displays with the PICAXE.
hippy
Ex-Staff (retired)
I have never completely understood the 'demo scene' but it seems to come down to generating "wow", in that people would never have expected to see something doing whatever it is doing, a display of capabilities beyond what anyone might have expected.
Given a parallel connected LCD I imagine a PICAXE could do the same as 25 fps is quite a lot for each frame, 40ms, and at higher speeds a PICAXE can churn out data quite quickly.
inglewoodpete
Senior Member
My experiments with a Winstar 16x2 OLED display and a PICAXE 20X2 running at 64MHz showed that a row of the display can be written with its ROM-based characters in 9.58mS or 1669 characters per second with a 4-bit parallel interface.
This could be equated to 1669 bytes per second. Is that fast enough to get 20 or 25 frames per second of graphics? I'll leave it to others to ponder.
This could be equated to 1669 bytes per second. Is that fast enough to get 20 or 25 frames per second of graphics? I'll leave it to others to ponder.
hippy
Ex-Staff (retired)
9 bytes per CGRAM x 8 CGRAM characters = 72 bytes to be sent.
25 fps means one frame every 40ms and would require a byte to be written every 40ms/72 = 555us.
1 byte every 555us = 1800 cps.
20 fps means one frame every 50ms and would require a byte to be written every 50ms/72 = 694us.
1 byte every 694us = 1440 cps.
Looks like 20 fps would be achievable and you can probably go slower than that in practice as that's the maximum rate of change. Unlike a TV one doesn't have to regularly refresh everything only when something changes.
25 fps means one frame every 40ms and would require a byte to be written every 40ms/72 = 555us.
1 byte every 555us = 1800 cps.
20 fps means one frame every 50ms and would require a byte to be written every 50ms/72 = 694us.
1 byte every 694us = 1440 cps.
Looks like 20 fps would be achievable and you can probably go slower than that in practice as that's the maximum rate of change. Unlike a TV one doesn't have to regularly refresh everything only when something changes.
The address byte does not need to be sent between each CGRAM character. You can send just the one address byte ($40), then send the 64 bytes required to update the entire CGRAM.