|
Forum Index : Microcontroller and PC projects : tables
| Author | Message | ||||
| stanleyella Guru Joined: 25/06/2022 Location: United KingdomPosts: 2681 |
I looked through the mmbasic manual for rpi pico and can't see a read table/data function. So does that mean I got to dim var(256) as array and then a list of var(x)= val. I'm new to mmbasic. Is there a table function? |
||||
palcal![]() Guru Joined: 12/10/2011 Location: AustraliaPosts: 2006 |
From the Manual... is this what you need. "It is better to be ignorant and ask a stupid question than to be plain Stupid and not ask at all" |
||||
| Mixtel90 Guru Joined: 05/10/2019 Location: United KingdomPosts: 8304 |
You could DIM an array then fill it from DATA / READ statements or input it from a SD card file on program start. There's no TABLE statement as such. You can also do interesting things peeking and poking values in strings. :) Edited 2022-07-24 06:57 by Mixtel90 Mick Zilog Inside! nascom.info for Nascom & Gemini Preliminary MMBasic docs & my PCB designs |
||||
| stanleyella Guru Joined: 25/06/2022 Location: United KingdomPosts: 2681 |
Ah yes.. page 112 in the manual. Thanks and sorry to bother you. also data on page 85. Any examples of use please? |
||||
| disco4now Guru Joined: 18/12/2014 Location: AustraliaPosts: 1055 |
You can also add the values as you DIM the array. (0 numbered) So DIM x(12) needs 13 entries. Edited 2022-07-24 09:42 by disco4now F4 H7FotSF4xGT |
||||
| stanleyella Guru Joined: 25/06/2022 Location: United KingdomPosts: 2681 |
If I use Data to store 256 colour values, does that use program memory or ram? cheers. |
||||
| Mixtel90 Guru Joined: 05/10/2019 Location: United KingdomPosts: 8304 |
DATA statements are completely in program memory, I think. When you use READ only the variable read is in variables space. If you read all the DATA statements into an array then the whole array is in variable memory. If you use DIM a(5)=(0,1,2,3,4,5) then they exist in program memory (as they are stored as part of the program) AND the whole array is in variable memory. Incidentally, I'm not sure what your application is, but you can't get 256 colour values out of a PicoMite. The hardware only has 4-bit colour (i.e. 16 colours including black). It's not a software limitation. Mick Zilog Inside! nascom.info for Nascom & Gemini Preliminary MMBasic docs & my PCB designs |
||||
| phil99 Guru Joined: 11/02/2018 Location: AustraliaPosts: 2832 |
Although the VGA PicoMite has 4 bit colour most LCDs support 16 bits. |
||||
| pwillard Guru Joined: 07/06/2022 Location: United StatesPosts: 324 |
Is it just a matter of saving on pins and resistors? |
||||
| Mixtel90 Guru Joined: 05/10/2019 Location: United KingdomPosts: 8304 |
No. It's to do with how much RAM is needed for a frame buffer. The RAM in the PicoMite is *very* tight and the space has to be shared with other stuff. The existing PicoMite VGA FRAME BUFFER is 38,400 bytes That works with 640*480*1-bitcolour or 320*240*4-bitcolours If you want 8-bit colour at 320x240 you need 320x240x8=614,400 bytes - well over twice what the Pico has in total. Edited 2022-07-25 22:53 by Mixtel90 Mick Zilog Inside! nascom.info for Nascom & Gemini Preliminary MMBasic docs & my PCB designs |
||||
| phil99 Guru Joined: 11/02/2018 Location: AustraliaPosts: 2832 |
I should have been more specific, LCD panels rather than LCD monitors. The interface is digital (usually SPI or parallel) so no resistor network but you can still create a 256 colour palate (8 bit) to feed to the 16 bit LCD panel if that suits your application. In the case of the VGA PicoMite 8 pins wouldn't leave many for anything else, but the main issue is the amount of memory needed. An LCD panel has its own memory but a VGA monitor doesn't, a full screen of pixels must be kept in the Pico's limited memory at all times. In order to get 4 bits per pixel for mode 2 the number of pixels had to be reduced to a quarter of mode 1 (1 bit per pixel). . Edited 2022-07-25 23:12 by phil99 |
||||
| stanleyella Guru Joined: 25/06/2022 Location: United KingdomPosts: 2681 |
My idea was a video game on ILI934 lcd. I think mmbasic uses 16 colours so need 16 x 16 sprites and data for each pixel. It will be read a pixel at a time and "plot" it but may be able to get the ili9341 send word to work with mmbasic. |
||||
| Mixtel90 Guru Joined: 05/10/2019 Location: United KingdomPosts: 8304 |
Colours aren't a problem on that display - it supports 64k colours in 565 format (5 red bits, 6 green bits, 5 blue bits). I suspect your main problem might be with speed as it's a SPI display. You can move areas of the screen around using BLIT commands. You can also move areas to and from up to 8 memory buffers. There's some info in the manual on how to do this. Mick Zilog Inside! nascom.info for Nascom & Gemini Preliminary MMBasic docs & my PCB designs |
||||
| stanleyella Guru Joined: 25/06/2022 Location: United KingdomPosts: 2681 |
Mmbasic on rpipico seems faster than compiled gcbasic on mega328p uno/nano with the ili9341. I think some rpinano pins are hardware spi and mmbasic uses them not software spi. I think 16 "colours" are predefined rgb values. |
||||
| Mixtel90 Guru Joined: 05/10/2019 Location: United KingdomPosts: 8304 |
As far as I know, SPI displays on the PicoMite all use hardware SPI, but SD cards only use bitbanged SPI as it turned out to be more reliable. The CMM2 has 16 "real" recognised colours: Black, Blue, Green, Cyan, Red, Magenta, Yellow, Brown Gray, Lightgray, White, Orange, Pink, Gold, Salmon, Beige It also has Notblack I *think* that these names only apply to the CMM2 but I may be wrong. It may be that some but not all of them work on LCD displays. You can define whatever you like, of course: CONST BLOOD=RGB(31,0,0) CONST GRASS=RGB(0,63,0) Mick Zilog Inside! nascom.info for Nascom & Gemini Preliminary MMBasic docs & my PCB designs |
||||
| stanleyella Guru Joined: 25/06/2022 Location: United KingdomPosts: 2681 |
The Blit command seems ideal, I'll try it. Think of pacman and the ghosts don't erase the dots but taking a screen area then plot a defined shape then restore screen area then take screen area in next defined shape's xy position then plot and repeat may be slow. |
||||
| Mixtel90 Guru Joined: 05/10/2019 Location: United KingdomPosts: 8304 |
You'd have to try it, I think. The speed will be limited by how fast you can blit the data. That will depend on what size your "sprites" are and you may find that powers of two are faster than other sizes. I've not used it, personally, so I'm not a good one to ask about this. Mick Zilog Inside! nascom.info for Nascom & Gemini Preliminary MMBasic docs & my PCB designs |
||||
| stanleyella Guru Joined: 25/06/2022 Location: United KingdomPosts: 2681 |
The drawing filled circles in the lcd test is very fast. It's a compiled function called from basic so should be fast. They're not real circles but a mid point, 1 quadrant repeated and inverted not sin,cos but fast. I'll see how fast things go but lots of new stuff like mmedit to learn. It replaced all ; in my code to ' as ; is not a comment marker :( For a few £ the rpipico and mmbasic work great. Cheaper than an arduino. faster,more memory and ram. |
||||
| JohnS Guru Joined: 18/11/2011 Location: United KingdomPosts: 4147 |
If using SPI then that may well set the limit for drawing speed. John |
||||
| stanleyella Guru Joined: 25/06/2022 Location: United KingdomPosts: 2681 |
It is fine with mega328p and another basic so should be as fast or faster with rpi-pico and mmbasic.. IMHO. ILI9341 seems very fast with mmbasic. Well implemented! Cheers. |
||||
| The Back Shed's forum code is written, and hosted, in Australia. | © JAQ Software 2025 |