I find it difficult to access glcd code routines. I want to move the ssd1306 hardware cursor ie where on display,not buffer,to write a byte. This sends a byte to 0,0 next to "|test" not px,row co-ords.
The move page/column codes did work but not with GCB.
I tried using sub Cursor_Position_SSD1306( in LocX as byte, in LocY as byte ) but I get asm errors, wrong var type value.
I want to write sprites to the display and have the code nearly done for rotating sprite bytes across byte rows.
This should be decimal sorry, HI2CSend 0x64
The GCB glcd includes are a great feature. I just want to move defined chars say 8x8 or 16x16 pixels around faster than using pset or line. On a ili9341 maybe multi coloured chars which maybe simpler than ssd1306. I'll percy vere,it's interesting.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
To access the buffer simply use yourbytevariable = SSD1306_BufferAlias(n) where n is in the range of 1 to 1024 for a 128 * 64 pixels display.
Then you want to send 6 bytes?
Simply use: Cursor_Position_SSD1306 ( GLCDX, GLCDY ) 'where GLCDX and GLCDY are valid locations for the sprite Write_Data_SSD1306 ( yourbytevariable ) 'where yourbytevariable is a byte value from your 6 byte sprite array.
As this will overwrite the display buffer you should consider saving the existing 6 bytes and restoring usingPixelStatus_SSD1306 ( GLCDX, GLCDY ) 'where GLCDX and GLCDY are valid locations for the target location of the sprite.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Thanks sir. It could have waited until you were back. I am reinventing the wheel, it's my way of understanding these displays,from the ground up, in GCB. Some of the init I don't understand yet,chargepump vcc etc.
Time of posting this is NEARLY working. You can see were I'm going with the idea, then use the glcd buffer and routines instead.
I don't know if the rotate from hi_byte to low_byte is ok. On the display 16 bytes but sprite seems rotated wrong.
EDIT This works,yippee! I got top and bottom of sprites wrong way round.
I'll try 16x16 next if developers interested in the project fo sprites. This is just first working code.
edit2 Not quite right though. rotating byte left into byte 2 now. I'm confused again,doh
I used SSD1306MEMORYMODE 0x00 ; Horiz mode. 0x0 act like ks0108
which is not recomended in ssd1306_glcd.h
@Stan. If you have some time. Can you help with some developement? I have an open request for Elipse and Triangle support across all the GLCDs. Should be relatively simple. Got time to do this?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Elipse: I have a program as a good starter. This has a prototype Elipse method. You should be able to port to any GLCD device. The ADC simply lets you change to the elipse parameters on the GLCD device rather than having to change the source program.
I have not looked at FilledElipse.
Triangle: There are many example of triangle on the internet. I do have a C++ example but I have not ported to Great Cow BASIC.
I have not looked at FilledTriangle.
OK. Complete one method at a time. You should keep the method in the program and do not do what I have done.... use silly variable names such as xx, yy and xx. Rename to something very specific or use temp variables that are already used by other GLCD methods.
Good luck.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Here is a sprite program. It looks like a little pacman running across the screen!
As I have not write a sprite routine before this took about 15mins. I took an existing method, used your table, added extendability to the tables and it truly worked first time.
I probably have the wrong solution but it should be a good start.
You can.
1. Create many sprites
2. Place sprites at any screen location
3. Place any of the sprites at any location.
A version for an UNO... pretty fast. The little sprite runs back and forth across the screen with some pace. If you were playing ping-pong with this sprite... you would lose every time.
I am sure the method is not 100% correct but I am not totally sure what to expect as an outcome.
To define a sprint you need to define in the 8 tables. This makes the system extensible.
A sprite is pulled from each element of the 8 tables.
Sprite 1 is at element 1 of all the tables. This is 8 * 8 of 0’s. So, you can blank things out.
Sprite 2 is at element 2 of all the tables. This is 8 * 8 of an eye… looks like an eye to me.
Sprite 3 is at element 3 of all the tables. This is 8 * 8 of 1’s. So, all pixels are set.
This is the way to make extensible sprites else all the tables will have hard coded names.
To draw a sprite. GLCDDrawSprite_SSD1306 xx, 8 , 2, GLCDBackground
Xpos, Ypos, Sprite Number, Color (so you can invert sprites).
A small video of the GLCD Sprite in operation and the hex for an UNO. Power, 0V and I2C are the standard device connections.
The video does not do the OLED display or the library justice - looks ok when using the 'mark one eyeball'. :-)
This uses the very very latest GLCD libraries for the SH1106 and SH1306. These do support faster operations and the Sprite library is not include in the standard build.
I worked for ZX Africa for a while - we reproduced and distributed the ZX
software for Psion and Sinclair throughout Sub Saharan Africa.
I think I still have a full set of cassettes for each package released for
the ZX81, probably no longer readable.
I do remember that Forth Interpreter, I wrote some good code with it and I
still have a copy of "Starting Forth" next to my bed of all places :)
I knew of the Jupiter but the the FORTH I used was for the ZX81.
I cant recall the makers but I remember two versions, Tape based and ROM
based.
Not sure if the JUPITER FORTH was ever used on the ZX81 but FORTH in
general was a technically brilliant but I guess doomed to obscurity :)
EDIT:
What I used probably was the same one afterall.
Last edit: Chris Roper 2017-08-20
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Same thing without using pset. Flickery video. Same method as zx81.The first people to do it on sinclair spectrum cleaned up. https://youtu.be/LUzWlghjH1Q
Your sprite002a gives error 118 Variable CURRCHARVAL not explicitly declared..but it's dim'ed.
I always get errors trying to use vars in includes.
I'm using latest gcb with ssd1306 that came with it and latest ssd1306 you posted here for another user.
Last edit: stan cartwright 2017-08-19
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I got sprite002a to work by commenting option explicit because CurrCharVal was not declared.
It works fine. When I 1st used GCB I drew and erased a small shape from x,y by a list of pset x+1,y+1. pset x+2,y+2...etc but seemed to remember it was slow and flickered. Your sprite runs smoothly.
I didn't work out the timing by looking at my code but thought the more pixels in the sprite the slower it would be but you plot 64 fast even non lit.
You made the display faster by checking if the pixel had changed in the buffer and not write if the same.
I'm going to try using pset for multicoloured ili9341 sprites but maybe writng bytes would be faster as it's not bit mapped. Is a pixel a byte or 3, one each for R,G,B? The data sheet was jibberish to me.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I find it difficult to access glcd code routines. I want to move the ssd1306 hardware cursor ie where on display,not buffer,to write a byte. This sends a byte to 0,0 next to "|test" not px,row co-ords.
The move page/column codes did work but not with GCB.
I tried using sub Cursor_Position_SSD1306( in LocX as byte, in LocY as byte ) but I get asm errors, wrong var type value.
I want to write sprites to the display and have the code nearly done for rotating sprite bytes across byte rows.
This is related to https://sourceforge.net/p/gcbasic/discussion/579126/thread/b37f24d0/#89fb
And, https://sourceforge.net/p/gcbasic/discussion/579126/thread/c83e9684/#24a2
I will look at the root cause when my vacation is over. I have already said this before.
Last edit: Anobium 2017-08-13
I will close the other posts and link to this post when I get some time.
This should be decimal sorry, HI2CSend 0x64
The GCB glcd includes are a great feature. I just want to move defined chars say 8x8 or 16x16 pixels around faster than using pset or line. On a ili9341 maybe multi coloured chars which maybe simpler than ssd1306. I'll percy vere,it's interesting.
This code works and sends a byte to px,row but I've reinvented the wheel. It would be nice to access glcd include to do it.
Yes. You are reinventing the wheel.
Here goes..
To access the buffer simply use
yourbytevariable = SSD1306_BufferAlias(n)
where n is in the range of 1 to 1024 for a 128 * 64 pixels display.Then you want to send 6 bytes?
Simply use:
Cursor_Position_SSD1306 ( GLCDX, GLCDY )
'where GLCDX and GLCDY are valid locations for the spriteWrite_Data_SSD1306 ( yourbytevariable )
'where yourbytevariable is a byte value from your 6 byte sprite array.As this will overwrite the display buffer you should consider saving the existing 6 bytes and restoring using
PixelStatus_SSD1306 ( GLCDX, GLCDY )
'where GLCDX and GLCDY are valid locations for the target location of the sprite.Thanks sir. It could have waited until you were back. I am reinventing the wheel, it's my way of understanding these displays,from the ground up, in GCB. Some of the init I don't understand yet,chargepump vcc etc.
Time of posting this is NEARLY working. You can see were I'm going with the idea, then use the glcd buffer and routines instead.
I don't know if the rotate from hi_byte to low_byte is ok. On the display 16 bytes but sprite seems rotated wrong.
EDIT This works,yippee! I got top and bottom of sprites wrong way round.
I'll try 16x16 next if developers interested in the project fo sprites. This is just first working code.
edit2 Not quite right though. rotating byte left into byte 2 now. I'm confused again,doh
I used SSD1306MEMORYMODE 0x00 ; Horiz mode. 0x0 act like ks0108
which is not recomended in ssd1306_glcd.h
Last edit: stan cartwright 2017-08-14
@Stan. If you have some time. Can you help with some developement? I have an open request for Elipse and Triangle support across all the GLCDs. Should be relatively simple. Got time to do this?
@Stan.
Elipse: I have a program as a good starter. This has a prototype Elipse method. You should be able to port to any GLCD device. The ADC simply lets you change to the elipse parameters on the GLCD device rather than having to change the source program.
I have not looked at FilledElipse.
Triangle: There are many example of triangle on the internet. I do have a C++ example but I have not ported to Great Cow BASIC.
I have not looked at FilledTriangle.
See attached for the current working prototype.
Last edit: Anobium 2017-08-15
I'll have a go. A general flood fill for polygons would be handy but might need test pixel status.
OK. Complete one method at a time. You should keep the method in the program and do not do what I have done.... use silly variable names such as xx, yy and xx. Rename to something very specific or use temp variables that are already used by other GLCD methods.
Good luck.
Here is a sprite program. It looks like a little pacman running across the screen!
As I have not write a sprite routine before this took about 15mins. I took an existing method, used your table, added extendability to the tables and it truly worked first time.
I probably have the wrong solution but it should be a good start.
You can.
1. Create many sprites
2. Place sprites at any screen location
3. Place any of the sprites at any location.
Attached is the code and a link to the GIF of the animation. https://1drv.ms/i/s!Ase-PX_n_4cvgqMV5QlYa7eB_A71OA
Enjoy.
Last edit: Anobium 2017-08-17
A version for an UNO... pretty fast. The little sprite runs back and forth across the screen with some pace. If you were playing ping-pong with this sprite... you would lose every time.
I am sure the method is not 100% correct but I am not totally sure what to expect as an outcome.
To define a sprint you need to define in the 8 tables. This makes the system extensible.
A sprite is pulled from each element of the 8 tables.
Sprite 1 is at element 1 of all the tables. This is 8 * 8 of 0’s. So, you can blank things out.
Sprite 2 is at element 2 of all the tables. This is 8 * 8 of an eye… looks like an eye to me.
Sprite 3 is at element 3 of all the tables. This is 8 * 8 of 1’s. So, all pixels are set.
This is the way to make extensible sprites else all the tables will have hard coded names.
To draw a sprite. GLCDDrawSprite_SSD1306 xx, 8 , 2, GLCDBackground
Xpos, Ypos, Sprite Number, Color (so you can invert sprites).
Enjoy
Last edit: Anobium 2017-08-18
A small video of the GLCD Sprite in operation and the hex for an UNO. Power, 0V and I2C are the standard device connections.
The video does not do the OLED display or the library justice - looks ok when using the 'mark one eyeball'. :-)
This uses the very very latest GLCD libraries for the SH1106 and SH1306. These do support faster operations and the Sprite library is not include in the standard build.
https://1drv.ms/v/s!Ase-PX_n_4cvgqMWE3QF56WeHoGDZw
Last edit: Anobium 2017-08-19
Bouncing ball routine... boucing in a box... wow... it is like the 1980's.
UNO. Power, 0V and I2C are the standard device connections for a SD1306 OLED.
This is screen shot only. No video.
Last edit: Anobium 2017-08-19
My first actual Computer.
Befor that it was HP calculators and a Motorola MEK6800D2
In the day. I was part of the Acorn Dev team and the Jupiter.... a Forth interpreter in a ZX81plastic chassis.
Those were not the days.
I worked for ZX Africa for a while - we reproduced and distributed the ZX
software for Psion and Sinclair throughout Sub Saharan Africa.
I think I still have a full set of cassettes for each package released for
the ZX81, probably no longer readable.
I do remember that Forth Interpreter, I wrote some good code with it and I
still have a copy of "Starting Forth" next to my bed of all places :)
On 19 August 2017 at 22:37, Anobium evanvennn@users.sf.net wrote:
Amazing someone who knows about the Jupiter Ace. It is not dead... https://en.m.wikipedia.org/wiki/Jupiter_Cantab
I knew of the Jupiter but the the FORTH I used was for the ZX81.
I cant recall the makers but I remember two versions, Tape based and ROM
based.
Not sure if the JUPITER FORTH was ever used on the ZX81 but FORTH in
general was a technically brilliant but I guess doomed to obscurity :)
EDIT:

What I used probably was the same one afterall.
Last edit: Chris Roper 2017-08-20
Same thing without using pset. Flickery video. Same method as zx81.The first people to do it on sinclair spectrum cleaned up. https://youtu.be/LUzWlghjH1Q
Your sprite002a gives error 118 Variable CURRCHARVAL not explicitly declared..but it's dim'ed.
I always get errors trying to use vars in includes.
I'm using latest gcb with ssd1306 that came with it and latest ssd1306 you posted here for another user.
Last edit: stan cartwright 2017-08-19
I got it working using the glcd include and using the buffer ssd1306 buffer_alias. Paste and try.
I did try. I hooked up my scope and after each sprite draw I toggle a port.
Optimised existing method 19-24 ms. A delay is needed to see the box bouncing.
Your method 32-40 ms
We have revised the library extensively and with your changes I think we can get it faster.
Last edit: Anobium 2017-08-20
I got sprite002a to work by commenting option explicit because CurrCharVal was not declared.
It works fine. When I 1st used GCB I drew and erased a small shape from x,y by a list of pset x+1,y+1. pset x+2,y+2...etc but seemed to remember it was slow and flickered. Your sprite runs smoothly.
I didn't work out the timing by looking at my code but thought the more pixels in the sprite the slower it would be but you plot 64 fast even non lit.
You made the display faster by checking if the pixel had changed in the buffer and not write if the same.
I'm going to try using pset for multicoloured ili9341 sprites but maybe writng bytes would be faster as it's not bit mapped. Is a pixel a byte or 3, one each for R,G,B? The data sheet was jibberish to me.