Home
JAQForum Ver 24.01
Log In or Join  
Active Topics
Local Time 04:37 26 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 : 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 Kingdom
Posts: 9114
Posted: 10:12am 06 Feb 2024
Copy link to clipboard 
Print this post

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 Kingdom
Posts: 4037
Posted: 10:23am 06 Feb 2024
Copy link to clipboard 
Print this post

<Brain melts> .
Game*Mite, CMM2 Welcome Tape, Creaky old text adventures
 
Mixtel90

Guru

Joined: 05/10/2019
Location: United Kingdom
Posts: 6786
Posted: 12:20pm 06 Feb 2024
Copy link to clipboard 
Print this post

  thwill said  <Brain melts> .


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: Finland
Posts: 357
Posted: 02:01pm 06 Feb 2024
Copy link to clipboard 
Print this post

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 Kingdom
Posts: 509
Posted: 02:21pm 06 Feb 2024
Copy link to clipboard 
Print this post

No guarantees for anything above 133Mhz.
 
Volhout
Guru

Joined: 05/03/2018
Location: Netherlands
Posts: 4228
Posted: 02:33pm 06 Feb 2024
Copy link to clipboard 
Print this post

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: Netherlands
Posts: 4228
Posted: 02:35pm 06 Feb 2024
Copy link to clipboard 
Print this post

  Bleep said  No guarantees for anything above 133Mhz.


I expect "no guarantees for anything else than 126/133 and 252".

Volhout
PicomiteVGA PETSCII ROBOTS
 
matherp
Guru

Joined: 11/12/2012
Location: United Kingdom
Posts: 9114
Posted: 02:47pm 06 Feb 2024
Copy link to clipboard 
Print this post

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 Kingdom
Posts: 6786
Posted: 02:54pm 06 Feb 2024
Copy link to clipboard 
Print this post

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 States
Posts: 3150
Posted: 03:48pm 06 Feb 2024
Copy link to clipboard 
Print this post

  matherp said  I attach a simple demo program showing a standard PicoMite (or PicoMiteVGA) using all 64 sprites with full collision detection


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: Finland
Posts: 357
Posted: 04:02pm 06 Feb 2024
Copy link to clipboard 
Print this post

  Quote  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.


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 Kingdom
Posts: 2127
Posted: 04:19pm 06 Feb 2024
Copy link to clipboard 
Print this post

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: Finland
Posts: 357
Posted: 04:32pm 06 Feb 2024
Copy link to clipboard 
Print this post

"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 Kingdom
Posts: 4037
Posted: 04:33pm 06 Feb 2024
Copy link to clipboard 
Print this post

  stanleyella said  Using PicoMite MMBasic Version 5.08.00 with ili9341 and using frame and sprite no problem??


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 Kingdom
Posts: 6786
Posted: 04:56pm 06 Feb 2024
Copy link to clipboard 
Print this post

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 Kingdom
Posts: 2127
Posted: 05:04pm 06 Feb 2024
Copy link to clipboard 
Print this post

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 Kingdom
Posts: 6786
Posted: 05:07pm 06 Feb 2024
Copy link to clipboard 
Print this post

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 Kingdom
Posts: 9114
Posted: 05:35pm 06 Feb 2024
Copy link to clipboard 
Print this post

  Quote  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.


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 Kingdom
Posts: 2127
Posted: 06:03pm 06 Feb 2024
Copy link to clipboard 
Print this post

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: Ukraine
Posts: 213
Posted: 06:05pm 06 Feb 2024
Copy link to clipboard 
Print this post

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
© JAQ Software 2024