 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 : PICO PETSCII
  Page 6 of 38   |
|||||
| Author | Message | ||||
thwill Guru  Joined: 16/09/2019 Location: United KingdomPosts: 4042 |
Hi Peter, Hope you had a good break. Ack, but I doubt that is going to stop us (or at least me) trying. I'm not sure the actual gameplay for PETSCII Robots is that processor intensive, it looks like a robot blasing arcade game but is more of a small-scale real time strategy game. EDIT: I've got very few data-points at the moment, but Martin's 3D Maze program running on the Game*Mite, whilst admittedly graphically much simpler, writes each frame of the 320x240 SPI display to F and then copies it to N running as fast as you would want. I would wait to see if @Volhout and friends actually implement the gameplay or whether this has all been just a pleasant diversion playing with graphics. Two items have come up which IMO are worth looking at in the shorter term: a) @vegipete's suggestion that BLIT COMPRESSED is merged with BLIT MEMORY and instead have whether the data is treated as compressed or not be dependent on a bit being set in the header of each individual "sprite": https://www.thebackshed.com/forum/ViewTopic.php?FID=16&TID=16248&LastEntry=Y#210010#209995 b) Whether BLIT COMPRESSED with transparency is possible - this may be MMBasic programmer error, I haven't had a chance to pull things together to try it for myself: https://www.thebackshed.com/forum/ViewTopic.php?FID=16&TID=16235&LastEntry=Y#210011#209990 My opinion is that we should within a program be able to read arbitrary binary data (not tokenized MMBasic) into a flash slot and be able to READ (but not write) that memory (which I assume is just part of the standard address space) with PEEK and BLIT MEMORY. Not only could it be used here for sprites, but it could be used to store the ROM section of Infocom adventure data in it (making a full Z-MIM on PicoMite potentially possible without paging to the file-system) or if I ever get off my arse to revisit it could be used to store FORTH programs. However I also think it can and should wait, nobody needs it "right now", and user requirements may become more concrete as PicoSCII Robots progresses ... or doesn't. YMMV and thanks for your endless efforts, Tom Edited 2023-09-24 22:52 by thwill Game*Mite, CMM2 Welcome Tape, Creaky old text adventures |
||||
| matherp Guru Joined: 11/12/2012 Location: United KingdomPosts: 9122 |
It is, always has been, documented in the beta thread Will look at it |
||||
Martin H. Guru Joined: 04/06/2022 Location: GermanyPosts: 1113 |
I'm still thinking about a stripped-down graphic version with 8x8 pixel tiles, which is what it was originally. The 24x24 tiles would serve as a template, so no visible PETSCII. To do this, I would use a 15x12 byte pseudo text buffer to make all changes to the image and build the screen based on the tile numbers stored there. It would have the advantage that you can process the entire tile handling in the buffer, which is only 180 bytes in size.So you can store it in a second buffer. When transferring the tiles to the N FRame (or LCD), you can now compare the current tiles with those from the last image and only draw those that have been changed. You don't have to worry about scrolling either, because it doesn't take place except in the buffer. .. i will test this  Edited 2023-09-24 23:37 by Martin H. 'no comment |
||||
Lodovik Newbie  Joined: 17/05/2021 Location: CanadaPosts: 40 |
I didn’t read the entire topic but if you need it, I have converted the Commodore 64 character set to a CMM2 font a while ago, when I was toying with my new Color Maximite 2. I can post it here if you wish. |
||||
| Martin H. Guru Joined: 04/06/2022 Location: GermanyPosts: 1113 |
Hi Lodovik, thank you for your participation in the development. We are grateful for any help... I (we) allready got the GFX-, C64- and the PETSCII Font look at this Topic Fonts for Mites there is also a Listing which converts a BMP of a Font to a Font file.Have fun. But as you have a CMM2 you might test, if the Fonts there work on it ... Maybe you have to rename the *.BAS to *.fnt. I would be happy to receive feedback Cheers Mart!n EDIT: This how the Tileset for the Game looks with C64 Font   Edited 2023-09-25 03:01 by Martin H. 'no comment |
||||
| lizby Guru Joined: 17/05/2016 Location: United StatesPosts: 3150 |
I don't know how pertinent it is here, but I was curious about the theoretical maximum scrolling speed for the ILI9341 (it may not be relevant, but CPUSPEED is 378000). Martin's initial screen for PETSCII Robots seemed like a good start. Scrolling one column per iteration, it managed 9.9 frames per second. Dim integer i,j,x,y,xx,yy FRAMEBUFFER create FRAMEBUFFER write F Load image "b:\petscii-intro.bmp" 'Pause 5000 FRAMEBUFFER COPY F,N FRAMEBUFFER WRITE N CLS xx=MM.HRes-1 yy=MM.VRes-1 Timer =0 For i=0 To xx FRAMEBUFFER BLIT F,N,i,0,0,0,xx-i,yy FRAMEBUFFER BLIT F,N,0,0,xx-i,0,i,yy Next i Print Str$((xx+1)/(Timer/1000),0,1)+" Frames per Second" Text 0,MM.VRes-(MM.Info(FONTHEIGHT)*2),Str$((xx+1)/(Timer/1000),0,1)+" Frames per Second"  Youtube video here. PicoMite, Armmite F4, SensorKits, MMBasic Hardware, Games, etc. on fruitoftheshed |
||||
| Martin H. Guru Joined: 04/06/2022 Location: GermanyPosts: 1113 |
your Video is private  Edited 2023-09-25 10:30 by Martin H. 'no comment |
||||
| lizby Guru Joined: 17/05/2016 Location: United StatesPosts: 3150 |
Oops, sorry. Should be public now. PicoMite, Armmite F4, SensorKits, MMBasic Hardware, Games, etc. on fruitoftheshed |
||||
Mixtel90 Guru Joined: 05/10/2019 Location: United KingdomPosts: 6798 |
I don't think the CPU speed will make any difference to the SPI clock speed and the display will only update at whatever speed it does, depending on how fast you fill its RX buffer (I assume it has one), no matter how fast you attempt to drive it. Mick Zilog Inside! nascom.info for Nascom & Gemini Preliminary MMBasic docs & my PCB designs |
||||
| Volhout Guru Joined: 05/03/2018 Location: NetherlandsPosts: 4243 |
With 16MHz clock on SPI, sending 1 pixel (65536 colors = 2 bytes = 16 bits) take 1us (micro second). There are 320x240 = 76800 pixels. To refresh the screen takes 76800*1us = 76.8 miliseconds (13 fps) for SPI bus communication. since pico has not enough memory for a ILI9341 framebuffer, it uses the ILI9341 internal buffer. Through SPI bus. Scolling the screen would require reading each pixel, and re-writing it in another location. This would bring back the refresh rate to 2x76.8ms=154ms (or 6.5fps). It would be better not to scroll , and re-calculate the screen each time. The pico is much faster in re-calculating. But this is theoretical limit of the SPI but. Practice with be slower. Edited 2023-09-25 17:54 by Volhout PicomiteVGA PETSCII ROBOTS |
||||
| thwill Guru Joined: 16/09/2019 Location: United KingdomPosts: 4042 |
Note that you don't have to refresh the whole display on each frame, just the map so probably 60-80% of those 76800 pixels. Martin's idea of only redrawing changed tiles may reduce this further, however it will have additional overhead and I recall Peter posting that at some point it is cheaper just to redraw the whole display rather than multiple sub-rectangles. Note I think there is some suggestion that the ILI9341 SPI can be driven faster than its theoretical maximum but (but I haven't read it properly so may be reading more into it than exists) that seems to require additional trickery (which is probably not compatible with the PicoMite's multiple different display support) and may require a slab of Pico RAM that we don't have: https://www.reddit.com/r/raspberry_pi/comments/ljexcm/ili9341_with_a_pi_pico_using_a_full_display_buffer/ Best wishes, Tom Game*Mite, CMM2 Welcome Tape, Creaky old text adventures |
||||
| matherp Guru Joined: 11/12/2012 Location: United KingdomPosts: 9122 |
I've found one trick by allowing FRAMEBUFFER COPY F/L,N to be processed on the second CPU. The copy routine then returns immediately allowing you to process game logic while the screen is updating. This will be in the next release candidate. NB: there will be no spin-locks or mutex so it will be up to the programmer to ensure things don't get out of step. The copy itself is blocking based on the 15 word FIFO between the cores so if you do 8 copies one after another (two words used per copy), the 8th will wait for the first to complete before queuing. One thing I forgot to mention above. I think using the sound command for music/sound effects is probably the wrong way to go. Takes more offline preparation but PLAY MODFILE and PLAY MODSAMPLE can do it all (effects are coded as mod samples) and will be much less processor intensive |
||||
| thwill Guru Joined: 16/09/2019 Location: United KingdomPosts: 4042 |
Yes, I suspected as much, but outside my skill set. Presumably though you have to halt the music MOD in order to play the fx MOD, which is a bit of a downer ? The SOUND method allows me to use 3 "channels" for the music and save 1 for the fx. One other question, which @Volhout and I are still investigating. He has found a limit of ~70K on an MMBasic program on the PicoMiteVGA ... though I have written and run bigger. It made me wonder (and I suspect I've asked this before), where is the processed form of a CSUB stored (assuming a separate processed copy exists) ? ... and if that CSUB is from the LIBRARY ? I wonder if the answer to both those questions is in the 100K program space ? Best wishes, Tom Game*Mite, CMM2 Welcome Tape, Creaky old text adventures |
||||
| Martin H. Guru Joined: 04/06/2022 Location: GermanyPosts: 1113 |
Proof of the SubTile-concept (For Picomite VGA, for LCD remove the MODE Commands)  far from optimal (it redraws all Tiles every Frame): Patscii_ascii.zip with "GUI BITMAP" it outputs ~5 FPS. Edited 2023-09-25 20:00 by Martin H. 'no comment |
||||
| matherp Guru Joined: 11/12/2012 Location: United KingdomPosts: 9122 |
No. That is the whole point. The sound effect is coded on a specific channel (32 available) but is not included in the music schedule. PLAY MODSAMPLE triggers that channel alongside anything else playing If we ignore the library. CSUBs have two copied in program memory. One ascii and one binary. That is why the library is so useful for fonts and csub. In the library only the binary copy is stored. The ascii is completely removed One more trick if relevant you can horizontal scroll a ili9341 or ST7789) in landscape in H/W (virtually instantaneous) but only horizontal https://www.youtube.com/watch?v=gSl-lkDoqN4 This is easily achieved with POKE display Try this do:for i=0 to MM.HRes-1:poke display &h37,i\256,i mod 256:pause 10:next:loop Edited 2023-09-25 20:32 by matherp |
||||
| thwill Guru Joined: 16/09/2019 Location: United KingdomPosts: 4042 |
Cool, didn't know that. Definitely the way to go if you can get music and fx in .mod format. Thanks, but having looked closer that isn't the issue anyway. @Volhout has a pathological example consisting of ~94K of this: i=0 inc i,1 inc i,1 inc i,1 inc i,1 inc i,1 inc i,1 inc i,1 inc i,1 ... Which if you try and load reports: Error: not enough memory Even if untokenized (and definitely tokenized) it would be < 100K. Now IIRC the plain text is read into variable memory (nominally 128K) before tokenization, but perhaps all that variable memory isn't available for that purpose? Again IIRC you told me that whilst some of it is the heap (for arrays, etc.) the remainder is used for the variable table? Is it actually possible to fill the entire program memory with MMBasic or is the real limitation some fraction of the variable memory? Neat for a side-scroller, but probably not worth exploiting for PicoSCII Robots. Best wishes, Tom Edited 2023-09-25 20:33 by thwill Game*Mite, CMM2 Welcome Tape, Creaky old text adventures |
||||
| lizby Guru Joined: 17/05/2016 Location: United StatesPosts: 3150 |
How is the observed horizontal scrolling rate of 9.9fps for the ILI9341 shown above compatible with a theoretical maximum of 6.5fps? PicoMite, Armmite F4, SensorKits, MMBasic Hardware, Games, etc. on fruitoftheshed |
||||
| matherp Guru Joined: 11/12/2012 Location: United KingdomPosts: 9122 |
Only the heap memory is available for the program load and the usable buffer is smaller than this by 4608 + 3*HRes Heap memory is VGA 100K Pico 124k Web 80K None of this is on the agenda for change. For bigger programs - that's what the library is for. The next RC will allow loading binary data to a flash slot in a program as well as saving/loading the library from disk (command line only) NB: reading from a display is much slower than writing timer=0:blit 0,0,1,0,mm.hres-1,mm.vres:?timer 631.704 Edited 2023-09-25 20:47 by matherp |
||||
| thwill Guru Joined: 16/09/2019 Location: United KingdomPosts: 4042 |
So mystery solved @Volhout there is a 90-95K limit on the maximum size of .bas file that can be processed by the PicoMiteVGA. Ack. Though note (in the future) you could probably load into RAM and process the .bas file in chunks rather than reading the entire thing in one go. Thanks Peter, going above and beyond as always  .Right, you don't want to do that. Best wishes, Tom Game*Mite, CMM2 Welcome Tape, Creaky old text adventures |
||||
| Martin H. Guru Joined: 04/06/2022 Location: GermanyPosts: 1113 |
Wow that would be a big improvement. There would then be no difference between VGA and LCD in terms of program speed.  'no comment |
||||
| Page 6 of 38 |
|||||
 Print this page |
