Max Array Size?

[richard]

here is an example using linear memory access to make a large array , note how the memory is reserved in pbp


http://www.picbasic.co.uk/forum/atta...5&d=1508279203

[Art]

My current project is for dspic33FJ128GP802, and has an 8000 byte, a 1024 byte, and 2048 byte arrays, but that’s not PBP.
(I say current, but I think it’s finished now).

I was wandereng if PBP needs a 2D graphics library. To port mine easily would need a single linear, easily accessed 1024 byte array.

I do remember one being posted years ago, and think that included lines and shapes, etc.
But then there have been consistent questions about getting mono graphics displays working over the years also,
such as a recent one, but granted, that was only about the interface.

It isn’t for any project of mine, but might be fairly easy to port for others. It’s contingent on some PBP supporting a 1024 byte array, because unlike most gfx libs,
The frame buffer is already in the format of the display when it’s sent to the display.
It’s the pixel functions that write into the frame buffer in a manner that accommodates the vertically stacked byte arrangement for some LCDs (and possible OLEDs).

[richard]

pic18's in pbp can handle large arrays no problem. although bit offset indexing is limited to 256 [byte size] dimensions .
for pic16 user command and a bit of asm can overcome array size limitations

its just easier in C
I published this

http://www.picbasic.co.uk/forum/showthread.php?t=21235

but it attracted little interest

[Art]

Oh my. The fact that yours hasn’t gotten a single reply puts me off. It’s not like I’d benefit at all porting one to PBP.
I looked at it enough, that it looks tidy, and in the end it does look like a KS0108 128x64 pix GLCD,
that you have just simplified the hardware interface for.

I used the LCD pins as is for mine, but used a shift register for the 8 bit data interface, so it ends up just trimming 8 pins,
and adding 2 pins for the shift register... remaining balance = -5 pins.
It doesn’t need to be a latching SR because the LCD enable pin is the latch that the LCD listens to.

[richard]

Oh my. The fact that yours hasn’t gotten a single reply puts me off. It’s not like I’d benefit at all porting one to PBP.

I have made a ks0108 lib for xc8 that uses a frame buffer it works on any pic16/18 with enough
sram . alas pbp is just so far behind the times its just not on my list of thingstodo to port it there even if there was any interest.

i'd like to find a friendly forum for pic projects with at least a few active members. [ regardless of compiler used ]
there's heaps of features to explore using the newer 8bit chips and the mcc . I have found the mcc framework has
inspired me to new discipline for standard easily configured libraries for all sorts of things,this was just never possible using pbp
I don't want to be robinson crusoe it would be lovely to have a forum to bounce ideas off .


I got a explorer16 board on ebay not long back for peanuts and expect some pim modules from Portugal to arrive soon
along with some pigtail expanders from element14 arriving this week . so pic24/dspic are next on the agenda.
frame buffering is high on the list of experiments and i'm hoping mcc will help me build cross platform libs too.
dream on

[Art]

This has the potential to become that forum. PBP won’t be practical forever.

I’m looking at your setpixel routine. I assume you set X & Y somewhere else, and then just call that to write to the frame.
Not quite pretending to understand it yet, but I have every 2D function under the Sun that might possibly be added to it (in PBP very easily).
Forrest Fire Floodfill with 3 patterns, drawline, drawlinedotted, printtext, printsinetext, printlargetextvarwidth, drawtextvarwidthcentered, drawcircle, drawfilledcircle, drawrectroundedcorners,
drawrect, drawrectfilled, readtextfromdisplay, printmonobitmap, and a bunch of other stuff I wrote from scratch, and could do whatever I want with.

A bunch of them need FP support, such as drawtextrotated.

[richard]

I assume you set X & Y somewhere else

yes they are essentially global vars

[Ioannis]

I published this

http://www.picbasic.co.uk/forum/showthread.php?t=21235

but it attracted little interest

Missed that... I 've moved the thread to Code Examples in hope it has more attention as it was buried.

Regarding the size of arrays, for the 18F series, the manual says that size is limited by the amount of available memory. So, bigger PIC, bigger array.

Ioannis