 Notice. New forum software under development. It's going to miss a few functions and look a bit ugly for a while, but I'm working on it full time now as the old forum was too unstable. Couple days, all good. If you notice any issues, please contact me. |
Forum Index : Microcontroller and PC projects : PicoMite VGA TILE
Page 1 of 2   |
|||||
| Author | Message | ||||
| Mark Regular Member  Joined: 26/11/2022 Location: United StatesPosts: 85 |
I am playing PicoMite VGA from using the PiPicoMite03 board from land-boards. I just discovered the TILE command to give colors in the monochrome mode (mode 1). It lets you set the foreground and background color in a series of 16 by 16 pixels rectangles 40 across and 30 down. That size aligns with font 3. Would it be possible to have the TILE size adjustable? If the tile size could be set to the size of font1 (8 x 12), we could have colored text at 640 by 480. Thanks, Mark |
||||
Mixtel90 Guru  Joined: 05/10/2019 Location: United KingdomPosts: 7937 |
I can't see that happening, to be quite honest. The tile size limit is probably set by the maximum space available in the frame buffer. Mick Zilog Inside! nascom.info for Nascom & Gemini Preliminary MMBasic docs & my PCB designs |
||||
| Mark Regular Member Joined: 26/11/2022 Location: United StatesPosts: 85 |
Thanks, Granted, I don’t know how the TILE mechanism works, assuming… Assuming the TILE Stores 1 byte for each TILE, (4 bits each for foreground and background colors) 40 by 30 is 1200 bytes. If the tile count were increased to 80 by 40, that would only increase the memory requirement by 1200 bytes to 2400. I think PicoMite (and PicoMite VGA) is pretty amazing - kudos to all involved in creating it. Mark |
||||
| Volhout Guru Joined: 05/03/2018 Location: NetherlandsPosts: 5089 |
Tiles are currently 16x16 pixels, hence 40x30 on a 640x480 VGA screen. There is 1 font that aligns. But it is 16x16, large characters. Volhout PicomiteVGA PETSCII ROBOTS |
||||
| JohnS Guru Joined: 18/11/2011 Location: United KingdomPosts: 4044 |
I think that's beyond what the (VGA-related) hardware can do and bigger than the RAM buffer(s). Someone who knows more please correct me if I'm wrong :) John |
||||
| Mixtel90 Guru Joined: 05/10/2019 Location: United KingdomPosts: 7937 |
The frame buffer is always 38.4k You have to think of the VGA display as a graphic display, even though it may be displaying text. You can't PRINT to it, you draw the text with the TEXT command. In that respect the number of characters is irrelevant, it's the number of pixels that counts. The frame buffer can be split in two ways: Mode 1 is 640x480. Each pixel is on or off, so 38.4k Mode 2 is 320x240x4 colour bits = 38.4k again. I think tile mode probably uses pixel doubling horizontally. That would use 19.2k of the frame buffer for the pixels and anything up to 19.2k to store the colour info, but it would also prevent the possibility of variable size tiles. Pixel doubling would be fast and relatively easy to accomplish - there's not a lot of processing overhead involved. For 8x12 tiles you can't use horizontal pixel doubling (unless you reduce the number of horizontal tiles to 40 and use half the screen width) so you can't gain frame buffer space to put any colour info into. Mick Zilog Inside! nascom.info for Nascom & Gemini Preliminary MMBasic docs & my PCB designs |
||||
| matherp Guru Joined: 11/12/2012 Location: United KingdomPosts: 10310 |
Wrong again  int ytile=(line>>4)*40; uint16_t *q=&fbuff[nextbuf][0]; //point to the data to be dma'd next unsigned char *p=&DisplayBuf[line * 80]; //point to the line in the framebuffer for(i=0;i<40;i++){ // 40 tiles across the line with 16 pixels each register int pos=ytile+i; register int low= *p & 0xF; // get four single bit pixels register int high=*p++ >>4; // and the next 4 // map 4 pixels at a time to the required tile colour and load a 16bit value with the answer *q++=(M_Foreground[low] & tilefcols[pos]) | (M_Background[low] & tilebcols[pos]) ; *q++=(M_Foreground[high]& tilefcols[pos]) | (M_Background[high] & tilebcols[pos]) ; // process the other 8 pixels in the tile low= *p & 0xF; high=*p++ >>4; *q++=(M_Foreground[low] & tilefcols[pos]) | (M_Background[low] & tilebcols[pos]) ; *q++=(M_Foreground[high]& tilefcols[pos]) | (M_Background[high] & tilebcols[pos]) ; Edited 2023-02-14 23:00 by matherp |
||||
| Mark Regular Member Joined: 26/11/2022 Location: United StatesPosts: 85 |
Thanks for the reply. I’m going to dig into the source code and see if I can figure out how TILEs work, but I suspect that they don’t use a full 38.4K frame buffer. Mark |
||||
| Mixtel90 Guru Joined: 05/10/2019 Location: United KingdomPosts: 7937 |
But I'm *always* wrong, Peter. At least I get you out of the woodwork with the correct answers. :) (Even if it's written in an obscure dialect of Sanskrit. My head hurts.) ;) That's a lot more processing than I had assumed, even though I hardly understand most of what's going on. lol Mick Zilog Inside! nascom.info for Nascom & Gemini Preliminary MMBasic docs & my PCB designs |
||||
| robert.rozee Guru Joined: 31/12/2012 Location: New ZealandPosts: 2442 |
ADDENDUM: i was writing the below while Peter made his above posting, so did not see it before sending this. i believe not. the VGA implementation is/was based upon the code from here: http://www.breatharian.eu/hw/pico16vga/index_en.html and here: https://www.breatharian.eu/hw/picovga/index_en.html as i recall from looking at it a while back, in the 640x480 mode any two colours may be used, and to do tiling the two colours selected are swapped on-the-fly ever 16 pixels. this effectively uses TWO frame buffers, one for pixel (on/off), the other (colour) at a much lower resolution. Peter should be able to better fill in the details. i've asked before why the swapping could not be done on character boundaries (ie, ever 8 pixels) to give 80-column colour text, but never got any answer. the library from breatharian.eu does support this mode: this is essentially the same the same character/attribute system introduced with the IBM CGA and MDA displays back in the 1980's. i believe that Peter only ever intended that tiling be used for games, hence why the fixed 16x16 tile size. i have always wanted to see things opened up to wider application. cheers, rob :-) Edited 2023-02-14 23:41 by robert.rozee |
||||
| Mark Regular Member Joined: 26/11/2022 Location: United StatesPosts: 85 |
I found the same code that matherp quoted above in the source. It wasn't quite what I proposed, but I found the tile info is stored in two arrays: tilefcols and tilebcols declared in PicoMite.c. Each is an array of 40 * 30 uint16_t's which together take 4800 bytes. To add 8 by 12 tile support (80 by 40 tiles) would take 12800 bytes. It should be doable. Here's what to me appears to be the relative code in Draw.c (around line 1163), which matherp quoted above if(DISPLAY_TYPE==MONOVGA){ int ytile=(line>>4)*40; uint16_t *q=&fbuff[nextbuf][0]; unsigned char *p=&DisplayBuf[line * 80]; for(i=0;i<40;i++){ register int pos=ytile+i; register int low= *p & 0xF; register int high=*p++ >>4; *q++=(M_Foreground[low] & tilefcols[pos]) | (M_Background[low] & tilebcols[pos]) ; *q++=(M_Foreground[high]& tilefcols[pos]) | (M_Background[high] & tilebcols[pos]) ; low= *p & 0xF; high=*p++ >>4; *q++=(M_Foreground[low] & tilefcols[pos]) | (M_Background[low] & tilebcols[pos]) ; *q++=(M_Foreground[high]& tilefcols[pos]) | (M_Background[high] & tilebcols[pos]) ; } } else { I have a question, the same code is repeated around line 1268. They are in two separate functions void __not_in_flash_func(QVgaLine0)() (near line 1112) void __not_in_flash_func(QVgaLine1)() (near line 1215) I'm not sure I understand the function header or why there are two. Thanks, Mark |
||||
| matherp Guru Joined: 11/12/2012 Location: United KingdomPosts: 10310 |
I didn't quote it, I wrote it. And the code had to be iteratively tweaked to run in the part of line blanking available Oh yes where from? Are you going to reduce program and variable space by 8000 bytes for a fringe requirement? Ram is completely full |
||||
| Mark Regular Member Joined: 26/11/2022 Location: United StatesPosts: 85 |
Thanks for your work on this. I didn't realize that RAM was full. Again, I'm not complaining, what PicoMite and PicoMiteVGA do is simply amazing to me, I'm just exploring if something can be easily done. In my use case, I am not concerned with displaying pixel graphics, but I would like to display 80 columns of color characters. Thanks again, Mark |
||||
| robert.rozee Guru Joined: 31/12/2012 Location: New ZealandPosts: 2442 |
one could always push out some of the routines loaded into RAM (void __not_in_flash_func) and accept a slight hit on the speed of the interpreter cheers, rob :-) Edited 2023-02-15 00:42 by robert.rozee |
||||
| matherp Guru Joined: 11/12/2012 Location: United KingdomPosts: 10310 |
and accept a MASSIVE hit on the speed of the interpreter |
||||
| robert.rozee Guru Joined: 31/12/2012 Location: New ZealandPosts: 2442 |
10% speed reduction? 50%? 90%? please quantify. cheers, rob :-) |
||||
| matherp Guru Joined: 11/12/2012 Location: United KingdomPosts: 10310 |
> 50 but irrelevant anyway because I'm not doing it |
||||
| Mixtel90 Guru Joined: 05/10/2019 Location: United KingdomPosts: 7937 |
80 column colour text *would* be of use to some people, yes, but how many? I don't think many users would be too happy about slowing the system down. It would spoil it as a games system. If you use an 8x(up to)16 font you can double up characters into a single tile. Ok, those two characters have to share the same colours, but with some imagination it may be possible to get some interesting results that look like 80-column coloured text. Mick Zilog Inside! nascom.info for Nascom & Gemini Preliminary MMBasic docs & my PCB designs |
||||
thwill Guru Joined: 16/09/2019 Location: United KingdomPosts: 4311 |
FWIW I've taken a look and think Peter is right (not that I doubted him) ... ... I was going to say it would be nice if fun_ternary() could be squeezed into RAM ... but it looks like it is ... that's good ;-) Possibly the code could be made slightly tighter to free up a little RAM, but that is a dangerous game with no guarantee of success, so I'm out too. EDIT: Hopefully if we all sit around for a couple of years we will get a successor to the RP2040 with a smidgin more RAM. Best wishes, Tom Edited 2023-02-15 02:06 by thwill MMBasic for Linux, Game*Mite, CMM2 Welcome Tape, Creaky old text adventures |
||||
| Mark Regular Member Joined: 26/11/2022 Location: United StatesPosts: 85 |
That’s what I plan on doing if I can’t come up with a solution that allows me to color individual characters. On the subject of “what would you get rid of?” Has there ever been any thought to allowing features being included or excluded at compile time? Perhaps via a series of compiler switches. A couple of years ago, I wrote some Arduino code (to support the uBItx radio transceiver). When I added all the features I wanted, the code exceeded the available flash memory. I used #ifdef statements to enable and disable features, all controlled by #define’s in an include file so the code could be compiled with a user selected subset of features to fit. Again, not a complaint, just a suggestion. Mark |
||||
| Page 1 of 2 |
|||||
 Print this page |
 |
The Back Shed's forum code is written, and hosted, in Australia. | © JAQ Software 2025 |
