Home
JAQForum Ver 24.01
Log In or Join  
Active Topics
Local Time 07:23 25 Nov 2024 Privacy Policy
Jump to

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: Australia
Posts: 512
Posted: 07:52am 18 Jan 2012
Copy link to clipboard 
Print this post

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: Bulgaria
Posts: 226
Posted: 08:11am 18 Jan 2012
Copy link to clipboard 
Print this post

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: Australia
Posts: 512
Posted: 08:51am 18 Jan 2012
Copy link to clipboard 
Print this post

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: Australia
Posts: 164
Posted: 11:38am 18 Jan 2012
Copy link to clipboard 
Print this post

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.Edited by crackerjack 2012-01-19
 
brucepython

Regular Member

Joined: 19/06/2011
Location: Australia
Posts: 64
Posted: 07:36pm 18 Jan 2012
Copy link to clipboard 
Print this post

What's needed is a system variable that returns the base address of the video memory.

Bruce
 
iggy
Newbie

Joined: 26/12/2011
Location: Australia
Posts: 15
Posted: 08:47pm 18 Jan 2012
Copy link to clipboard 
Print this post

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 States
Posts: 1425
Posted: 09:26pm 18 Jan 2012
Copy link to clipboard 
Print this post

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: Australia
Posts: 512
Posted: 09:53pm 18 Jan 2012
Copy link to clipboard 
Print this post

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: Australia
Posts: 70
Posted: 03:10am 19 Jan 2012
Copy link to clipboard 
Print this post

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: Bulgaria
Posts: 226
Posted: 05:58am 19 Jan 2012
Copy link to clipboard 
Print this post

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: Australia
Posts: 447
Posted: 06:29am 19 Jan 2012
Copy link to clipboard 
Print this post

  Olimex said   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
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: Australia
Posts: 15
Posted: 07:22am 19 Jan 2012
Copy link to clipboard 
Print this post

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: Australia
Posts: 512
Posted: 09:45am 20 Jan 2012
Copy link to clipboard 
Print this post

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: Australia
Posts: 15
Posted: 11:28am 20 Jan 2012
Copy link to clipboard 
Print this post

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


To reply to this topic, you need to log in.

© JAQ Software 2024