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 V5.09.00 betas: Sorting out SPRITE and BLIT + USB variants
Page 1 of 9 | |||||
Author | Message | ||||
matherp Guru Joined: 11/12/2012 Location: United KingdomPosts: 9114 |
Version 5.09.00b0 https://geoffg.net/Downloads/picomite/PicoMite_Beta.zip Contains: PicoMite PicoMiteVGA WebMite PicoMiteUSB PicoMiteVGAUSB See the PicoUSB thread for more details of the USB variants All code and build files on https://github.com/UKTailwind/ including USB variants Changes to BLIT and SPRITE Background The PicoMite is normally used with SPI displays and these are too slow to use the full sprite fuctionality that was originally developed for the CMM2. Because of this I left sprite functionality out of the PicoMite and only included it in the PicMiteVGA. However, since that early decision, I have included the framebuffer and layerbuffer functionality into the PicoMite. Like the PicoMiteVGA, these are based in RAM and pixels are stored as 4-bits each - 1 nibble per pixel. This is efficient in terms of memory and allows very fast read-modify-write transactions which are the basis of the sprite functionality. According, I have decided to incorporate true sprites into the PicoMite and WebMite variants (and the PicoMiteUSB) to work on the framebuffer or layerbuffer. At the same time, it is clear that the use of the commands SPRITE and BLIT which were interchangeable has resulted in confusion so I am now including both in all variants with the relevant functionality limited to the appropriate command. In order to free-up the extra command slot the, little used, REFRESH and FLUSH commands have been combined (FLUSH without a parameter = REFRESH). In addition to free up a function slot for the SPRITE functions MM.HPOS and MM.VPOS are removed and replaced by MM.INFO(HPOS) and MM.INFO(VPOS). Existing code does not need to change as the firmware will make the changes automatically. SPRITE command and function changes The sprite command and function function as per the VGA manual with the exception that its use for a BLIT operations (SPRITE x, y, newx, newy, width, height; SPRITE memory) is removed. SPRITES are ALWAYS 4-bits per pixel and therefore for the non-VGA variants can only be used on a FRAMEBUFFER or LAYERBUFFER. Because of this storage of sprites is very memory efficient New command SPRITE SET TRANSPARENT RGB121colour 'sets the colour(1-15) that will be used as transparent when displaying sprites - defaults to zero In addition the maximum number of available sprites is increased to 64 as per the CMM2 Full List: SHOW SAFE, SHOW, HIDE ALL, RESTORE, HIDE SAFE, HIDE, SWAP, READ, COPY, LOADARRAY, LOAD, INTERRUPT, NOINTERRUPT, CLOSE ALL, CLOSE, NEXT, WRITE, LOADBMP, MOVE, SCROLL, SET TRANSPARENT BLIT command The BLIT command can work on both framebuffers and physical displays. Blit buffers, as used in READ/LOAD and WRITE are RGB888 and therefore take 3 bytes per pixel The maximum number of available BLIT bufferss is increased to 64 Full List: MEMORY, COMPRESSED, FRAMEBUFFER, LOADBMP/LOAD, MERGE, READ, WRITE, CLOSE, normal BLIT This change may break existing programs but the modification needed should be trivial - i.e. swapping BLIT for SPRITE commands or visa-versa I attach a simple demo program showing a standard PicoMite (or PicoMiteVGA) using all 64 sprites with full collision detection Option explicit Option default none If MM.Device$="PicoMiteVGA" Then MODE 2 FRAMEBUFFER create FRAMEBUFFER write f CLS Sprite set transparent 0 'brownian motion demo using sprites Dim integer x(64),y(64),c(64) Dim float direction(64) Dim integer i,j,k, collision=0 Dim string q$ Drive "b:" For i=1 To 64 direction(i)=Rnd*360 'establish the starting direction for each atom c(i)=RGB(Rnd*255,Rnd*255,Rnd*255) 'give each atom a colour Circle 10,10,4,1,,RGB(white),c(i) 'draw the atom Sprite read i,6,6,9,9 'read it in as a sprite Next i CLS RGB(myrtle) Box 0,0,MM.HRes,MM.VRes k=1 For i=MM.HRes\9 To MM.HRes\9*8 Step MM.HRes\9 For j=MM.VRes\9 To MM.VRes\9*8 Step MM.VRes\9 Sprite show k,i,j,1 x(k)=i y(k)=j vector k,direction(k), 0, x(k), y(k) 'load up the vector move k=k+1 Next j Next i ' Do For i=1 To 64 vector i, direction(i), 1, x(i), y(i) Sprite show i,x(i),y(i),1 If sprite(S,i)<>-1 Then break_collision i EndIf Next i FRAMEBUFFER copy f,n Loop ' Sub vector(myobj As integer, angle As float, distance As float, x_new As intege r, y_new As integer) Static float y_move(64), x_move(64) Static float x_last(69), y_last(64) Static float last_angle(64) If distance=0 Then x_last(myobj)=x_new y_last(myobj)=y_new EndIf If angle<>last_angle(myobj) Then y_move(myobj)=-Cos(Rad(angle)) x_move(myobj)=Sin(Rad(angle)) last_angle(myobj)=angle EndIf x_last(myobj) = x_last(myobj) + distance * x_move(myobj) y_last(myobj) = y_last(myobj) + distance * y_move(myobj) x_new=Cint(x_last(myobj)) y_new=Cint(y_last(myobj)) Return ' keep doing stuff until we break the collisions Sub break_collision(atom As integer) Local integer j=1 Local float current_angle=direction(atom) 'start by a simple bounce to break the collision If sprite(e,atom)=1 Then 'collision with left of screen current_angle=360-current_angle ElseIf sprite(e,atom)=2 Then 'collision with top of screen current_angle=((540-current_angle) Mod 360) ElseIf sprite(e,atom)=4 Then 'collision with right of screen current_angle=360-current_angle ElseIf sprite(e,atom)=8 Then 'collision with bottom of screen current_angle=((540-current_angle) Mod 360) Else 'collision with another sprite or with a corner current_angle = current_angle+180 EndIf direction(atom)=current_angle vector atom,direction(atom),j,x(atom),y(atom) 'break the collision Sprite show atom,x(atom),y(atom),1 'if the simple bounce didn't work try a random bounce Do While (sprite(t,atom) Or sprite(e,atom)) And j<10 Do direction(atom)= Rnd*360 vector atom,direction(atom),j,x(atom),y(atom) 'break the collision j=j+1 Loop Until x(atom)>=0 And x(atom)<=MM.HRes-sprite(w,atom) And y(atom)>=0 And y(atom)<=MM.VRes-sprite(h,atom) Sprite show atom,x(atom),y(atom),1 Loop ' if that didn't work then place the atom randomly Do While (sprite(t,atom) Or sprite(e,atom)) direction(atom)= Rnd*360 x(atom)=Rnd*(MM.HRes-sprite(w,atom)) y(atom)=Rnd*(MM.VRes-sprite(h,atom)) vector atom,direction(atom),0,x(atom),y(atom) 'break the collision Sprite show atom,x(atom),y(atom),1 Loop End Sub |
||||
thwill Guru Joined: 16/09/2019 Location: United KingdomPosts: 4037 |
<Brain melts> . Game*Mite, CMM2 Welcome Tape, Creaky old text adventures |
||||
Mixtel90 Guru Joined: 05/10/2019 Location: United KingdomPosts: 6786 |
I'm in excellent company then. What I do understand looks cool, even if I've never used it. :) Mick Zilog Inside! nascom.info for Nascom & Gemini Preliminary MMBasic docs & my PCB designs |
||||
Pluto Guru Joined: 09/06/2017 Location: FinlandPosts: 357 |
Melting for me also. ...but I hope that my PicoMite will not melt...it stopped responding anyway. Loaded the newest firmware and all seemmed ok at 133MHz and 252MHz, but at 378MHz my Pico tilts. Repeated two times. Needed Clear_flash.uf2 to re-establish operation. Thought that "Standard" PicoMite should be ok with 378MHz? option list PicoMite MMBasic Version 5.09.00b0 OPTION SYSTEM SPI GP18,GP19,GP16 OPTION FLASH SIZE 16777216 OPTION LCDPANEL ILI9341, RLANDSCAPE,GP15,GP14,GP13 > OPTION TOUCH GP12, GP11 Pluto NB: Testing on a YD-RP2040. |
||||
Bleep Guru Joined: 09/01/2022 Location: United KingdomPosts: 509 |
No guarantees for anything above 133Mhz. |
||||
Volhout Guru Joined: 05/03/2018 Location: NetherlandsPosts: 4228 |
Hi Peter, I absolutely embrace the harmonization of the VGA/Mite/Web versions. At this moment I try to understand what the impact for the VGA version is. Especially for PETSCII since it is a web of conditional execution for the LCD and VGA platforms. - The VGA version does not have a command "REFRESH" according the manual. - I cannot find (in the manual) any reference to MM.HPOS and MM.VPOS, or did you refer to MM.HRES and MM.VRES. Anyway, never used these functions. Does the VGA version have BLIT and SPRITE separate now, or is it still modifying one into the other ? Thanks you for your response Volhout PicomiteVGA PETSCII ROBOTS |
||||
Volhout Guru Joined: 05/03/2018 Location: NetherlandsPosts: 4228 |
I expect "no guarantees for anything else than 126/133 and 252". Volhout PicomiteVGA PETSCII ROBOTS |
||||
matherp Guru Joined: 11/12/2012 Location: United KingdomPosts: 9114 |
All versions have BLIT and SPRITE separate. Of course merge of L and N is automatic on the VGA versions but you still need to do it for the PIcoMite. The big change is really just access to true sprites for the non-vga versions. Afaik petsii doesn't use sprites so the only change should be to make sure the source uses BLIT |
||||
Mixtel90 Guru Joined: 05/10/2019 Location: United KingdomPosts: 6786 |
The YD-RP2040 appears to have relatively slow flash. I've never managed to run one any faster than 252MHz at all, even with the standard firmware. They've been reliable at that though. I use one for VGA. 378MHz has been guaranteed to lock them up, requiring wiping the flash. Mick Zilog Inside! nascom.info for Nascom & Gemini Preliminary MMBasic docs & my PCB designs |
||||
lizby Guru Joined: 17/05/2016 Location: United StatesPosts: 3150 |
Neat, though I'm not sure why the image I saved with "SAVE IMAGE" after exiting has a green background rather than the black one on the ILI9341. Is it "CLS RGB(myrtle)"? Nearly black, so not transparent? ?hex$(pixel(1,1),6) yields 006000 cls rgb(myrtle) actually looks light green on the screen. ~ Edited 2024-02-07 02:09 by lizby PicoMite, Armmite F4, SensorKits, MMBasic Hardware, Games, etc. on fruitoftheshed |
||||
Pluto Guru Joined: 09/06/2017 Location: FinlandPosts: 357 |
I must have been very lucky. I have several YD-RP2040 and I have successfully run them on 378MHz. I was always up to now a bit sceptic about the comments earlier about their problems. Today was the first time I run into problems. On this specific one the memory has a "Z" logo. On some others it looks like the ID is sanded off the cips. Some have "winbond" Pluto |
||||
stanleyella Guru Joined: 25/06/2022 Location: United KingdomPosts: 2127 |
Using PicoMite MMBasic Version 5.08.00 with ili9341 and using frame and sprite no problem?? FRAMEBUFFER CREATE F FRAMEBUFFER LAYER L FRAMEBUFFER WRITE L cls RGB(black) FRAMEBUFFER WRITE f do 'demo moving sprite FRAMEBUFFER COPY l,f for temp=0 to 15 ' if sprite_status(temp)=1 then 'is sprite active if spx(temp)> 300 then 'check right edge dx(temp)= 0-dx(temp) elseif spx(temp)<8 then 'check left edge dx(temp)= 0-dx(temp) end if if spy(temp)>220 then 'check bottom edge dy(temp)= 0-dy(temp) elseif spy(temp)<8 then 'check top edge dy(temp)= 0-dy(temp) end if ' spx(temp)=spx(temp)+dx(temp):spy(temp)=spy(temp)+dy(temp) 'get new position for draw ' if frame=0 then'which sprite to draw sprite WRITE 1,spx(temp),spy(temp) 'draw sprite1 at new position else sprite WRITE 2,spx(temp),spy(temp) 'draw sprite2 at new position end if next temp FRAMEBUFFER COPY f,N ' frame_count=frame_count+1 'when to change sprite if frame_count=10 then frame=not frame frame_count=0 end if loop |
||||
Pluto Guru Joined: 09/06/2017 Location: FinlandPosts: 357 |
"sanded": OPTION FLASH SIZE 4194304 (OK @378MHz) "winbond 25Q32": OPTION FLASH SIZE 4194304 (OK @378MHz) "Z 25VQ128": OPTION FLASH SIZE 16777216 (The module with this one tilted @378MHz) The "winbond" and "sanded" modules accepts 378MHz: option list PicoMite MMBasic Version 5.09.00b0 OPTION FLASH SIZE 4194304 OPTION CPUSPEED 378000 'KHz (Just loaded the firmware and set CPUSPEED to 378000kHz.) Pluto |
||||
thwill Guru Joined: 16/09/2019 Location: United KingdomPosts: 4037 |
If I understand correctly those are not sprites, they are for want of a better description blit/image buffers and on the PicoMite (5.08) SPRITE was a synonym for BLIT. On PicoMite 5.09 SPRITE and BLIT are no longer synonyms they are independent concepts and now SPRITE is used to manipulate software sprites (as were previously only available on the PicoMiteVGA and CMM2). I'm not sure what all the difference between blit/image buffers and sprites are, though I know the latter have some collision detection support. Best wishes, Tom Edited 2024-02-07 02:34 by thwill Game*Mite, CMM2 Welcome Tape, Creaky old text adventures |
||||
Mixtel90 Guru Joined: 05/10/2019 Location: United KingdomPosts: 6786 |
Mine all have Z logo flash. 16MB. Looks like I should have got the 4MB ones. lol. Stan: The RP2040 doesn't support "true" hardware sprites like you used to get on a lot of the old machines. They are always produced by fast RAM copying. Consequently BLIT and SPRITE use the same mechanism underneath. The framebuffer is merely an area of RAM. The user CPU writes to it and the second CPU reads from it and sends it to the PIO for VGA or it is sent to the SPI port for an LCD. . Edited 2024-02-07 03:05 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: 2127 |
I've tried to keep up with what started as "connect usb keyboard" to picomite and thought it needed 2 picomites. Do the usb betas need just 1 picomite? sorry I'm confused. I only want to use a mini wireless keyboard and usb dongle. cheers, stan |
||||
Mixtel90 Guru Joined: 05/10/2019 Location: United KingdomPosts: 6786 |
Yes, the host USB port is the one on the Pico. A second USB is connected via a USB-TTL converter (to GP8/GP9) to get the console connection as that will no longer work on the Pico's USB port. Mick Zilog Inside! nascom.info for Nascom & Gemini Preliminary MMBasic docs & my PCB designs |
||||
matherp Guru Joined: 11/12/2012 Location: United KingdomPosts: 9114 |
The concept of BLIT is simply that you move one area of memory to another replacing what was there and of course those areas of memory are going to be related to some sort of image data or a physical screen SPRITES are different. You can create a sprite in various ways but essentially you are just storing an image in a buffer. The difference comes when you SHOW the sprite. In this case, first time in, the firmware stores the area of memory (or display real-estate) that will be replaced by the sprite and then draws the sprite in its place. Subsequent SHOW commands replace the sprite with the stored background, store the background for the new location and finally draw the sprite. In this way you can move the sprite over the background without any extra code. Collision detection then sits on top of this and looks for the rectangular boundaries of sprites touching to create an interrupt or a sprite touching the edge of the frame. Finally sprites are ordered so the drawing order is held in a lifo. suppose you have sprite 1 overlapped by sprite 2 and then by sprite 3. If you simply moved sprite 1 then its background would overwrite bits of 2 and 3 - not what we want. SPRITE SHOW SAFE unwinds the LIFO by removing each sprite in reverse order, moves sprite 1 and then restores first 2 and then 3 on top of it. Finally and just to complicate things more there is the concept of layers (this is the 4th parameter in SPRITE SHOW). As per the Appendix in the manual Sprites collide with sprites on the same layer, layer 0, or the screen edge. Layer 0 is a special case and sprites on all other layers will collide with it. The SCROLL commands leave sprites on all layers except layer 0 unmoved. Layer 0 sprites scroll with the background and this can cause collisions. Hopefully you can see from the above why it is unrealistic to implement true sprites on an SPI display the replace,save, draw sequence results in artifacts and things like scroll where all sprites have to be removed before the background scrolls and then replace after is just a non-starter Edited 2024-02-07 03:42 by matherp |
||||
stanleyella Guru Joined: 25/06/2022 Location: United KingdomPosts: 2127 |
Tom I thought they were sprites.plotted from data and sprite read from screen. I'll load the new version. cls restore sprite1 udg1 'draws sprite1 on screen at 10,10 sprite READ 1,10,10,16,16 'reads sprite1 from screen to blit buffer1 restore sprite2 udg1 'draws sprite2 on screen at 10,10 sprite read 2,10,10,16,16 'reads sprite2 from screen to blit buffer2 ' sub udg1 'draws 16x16 data for blit to copy for spht=0 to 15 for spw=0 to 15 read sp1 pixel spw+10,spht+10,sp1 next spw next spht end sub |
||||
javavi Senior Member Joined: 01/10/2023 Location: UkrainePosts: 213 |
Hi Peter, Compiled from sources PicoMiteVGA 5.09.00b0 The PicoMan game that ran on PicoMiteVGA 5.08.00 stopped working and gives an error message: [448] Sub DrawBoard Error : Not enough memory |
||||
Page 1 of 9 |
Print this page |