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 : POKE to screen memory
Author | Message | ||||
Nick Guru Joined: 09/06/2011 Location: AustraliaPosts: 512 |
Is it possible to POKE bytes directly to screen memory? If so, what is the screen memory location? |
||||
Olimex Senior Member Joined: 02/10/2011 Location: BulgariaPosts: 226 |
1. yes 2. as it's in the variable definitions it will vary with every firmware compilation, array of integer variables @ absolute address the video memory is more clean way to directly access video ram, something like pre-defined DIM VIDEORAM(25920) AT (video address) |
||||
Nick Guru Joined: 09/06/2011 Location: AustraliaPosts: 512 |
I'm not sure I understand. I want to POKE (and PEEK) graphics data directly onto the screen. I need the area of memory that the MM uses to create the video display. |
||||
crackerjack Senior Member Joined: 11/07/2011 Location: AustraliaPosts: 164 |
Nick, what I think Olimex is saying is that the area of memory you want to POKE to (video display) shifts with each firmware change. So a program POKE'ing to any such address would not be likely to work after any firmware upgrade. So while it can be done (if you happen to find the right address range), it would not be a solution that is very robust. Also, you may have many inadvertent resets or odd Maximite behaviour while you seek that zone of memory. |
||||
brucepython Regular Member Joined: 19/06/2011 Location: AustraliaPosts: 64 |
What's needed is a system variable that returns the base address of the video memory. Bruce |
||||
iggy Newbie Joined: 26/12/2011 Location: AustraliaPosts: 15 |
Nick, Screen memory is organised into 32 bit words which makes a byte wide poke a bit weird until you get used to it. You calculate the 32bit word location and then add 0-3 with the 0 offset being the right most byte in the word. This has the effect of looking like you are filling those 32 pixels from right to left. I wrote a section of code that rights a unique signature into the screen memory, by drawing a particular pattern, and then searching for that pattern. In 2.7b screen memory starts about &hA000,58684 Can't remember if I'm finding the start or end of my patter now and I'm on the way out the door to head to work. Have a play with the following. iggy 10 y=0 15 s=&ha000 20 CLS 30 FOR x=0 TO 7 40 PIXEL(x,y)=1 50 NEXT x 60 PIXEL(8,y)=1 70 PIXEL(9,y)=0 80 PIXEL(10,y)=1 90 PIXEL(11,y)=0 100 PIXEL(12,y)=1 110 PIXEL(13,y)=0 120 PIXEL(14,y)=1 130 PIXEL(15,y)=0 140 PIXEL(16,y)=1 150 PIXEL(17,y)=1 160 PIXEL(18,y)=1 170 FOR m=0 TO &hffff STEP 4 180 LOCATE 0,64 190 IF PEEK(s,m+1)=&he0 AND PEEK(s,m+2)=170 AND PEEK(s,m+3)=255 THEN 200 PRINT "Found:";m;" ";HEX$(m);" " 210 ENDIF |
||||
CircuitGizmos Guru Joined: 08/09/2011 Location: United StatesPosts: 1425 |
Interesting approach, iggy! It wouldn't matter if the memory moves around, as long as you could use a routine to locate it. Nice job! Micromites and Maximites! - Beginning Maximite |
||||
Nick Guru Joined: 09/06/2011 Location: AustraliaPosts: 512 |
Great feedback guys. The reason for my request is that I want a fast way of loading an image to use as a template layout for a program I'm thinkinbg of writing for the MM. Bruce has a good program that I have been using to load BMP files and Crackerjack has the MPV format program to convert the BMP to something that loads faster. I would ideally like something even faster and could do it by reading/writing directly to the video area using POKES's and compressed data. Of course, the best solution was if MM BASIC has a LOADBMP command to supplement its SAVEBMP. It would make a world of difference to the professionalism of programs if we could design nice screen templates (or titles) using an editor on a PC/MAC. It also saves a lot of coding if we have the screen predrawn and loaded. SD storage space and loading speed is not an issue so why not utilize this ability. Once a screen template is loaded, the software can just write to the spaces provided. No code required to setup the screen presentation. |
||||
Gadget Regular Member Joined: 22/06/2011 Location: AustraliaPosts: 70 |
hi, looking at the map file generated for 3.0A source, i think there is a pointer at 0xA00015B4 (4 bytes) to to location of the video memory. try peeking those four locations and you should be able to construct the address of the video array so i think you would then use the first two locations to generate the high workd and then the last two to generate the lo word (unless the endianness of the pic 32 is different) hope this helps (or totally confuses things) Terry |
||||
Olimex Senior Member Joined: 02/10/2011 Location: BulgariaPosts: 226 |
Iggy approach is adaptive, i.e. with new revisions of the firmware it will locate the correct one, unless system constan MM.VIDEO is add to the BASIC which show where the Video starts |
||||
djuqa Guru Joined: 23/11/2011 Location: AustraliaPosts: 447 |
Sounds good Even better is Commands seen on some old versions of Basic VPoke and VPeek Virtual Video Screen Memory Virtual Memory Locations that were Mapped to the REAL Memory Locations. i.e So VPOKE 0,127 would ALWAYS poke the First Screen Memory Byte Regardless of the ACTUAL mapping. That way programs can be VERSION/Hardware/Revision/Variant independent But still work with the ACTUAL memory locations. Come on guys, it is a computer let it work out the difficult stuff. VK4MU MicroController Units |
||||
iggy Newbie Joined: 26/12/2011 Location: AustraliaPosts: 15 |
and.... as Don pointed out there is a line missing in my rush this morning... 220 next m thanks Don. iggy |
||||
Nick Guru Joined: 09/06/2011 Location: AustraliaPosts: 512 |
I found some time to try iggy's sneaky program to find the video display memory. Under MM Basic 3.0a, it starts an &HA000,&HE398. Each horizontal scanline occupies 60 bytes and there are 432 scanlines. The mapping is a bit strange in that this location is not actually the top-left screen position. It's actually the 4th byte from the top-left. The next byte is the 3rd byte from the top-left, the next is the 2nd from the top left and finally, the next is actually the top-left byte. This pattern repeats with the next byte being the 8th byte from the top left, the next is the 7th byte, the next 6th and finally the 5th which butts up against the first byte written (4th byte from top-left). A non-sequential layout. Nick |
||||
iggy Newbie Joined: 26/12/2011 Location: AustraliaPosts: 15 |
Yes that comes from it being an array of 32bit numbers so when you use an 8bit poke from basic it addresses the 32bit address +0 then the 32 bit address + 1 (next 8 pixels to the left) etc. |
||||
Print this page |