Oh yikes, I just made a little video mode 8 test program and the RAM consumption is higher than I expected, at 3581 bytes (~87% full) for just a little program that draws a filled rectangle on the screen. I guess 120x96 at 2 bpp takes up a bit more space than I initially realized Is it feasible to use the SPI RAM as a bitmap framebuffer? I know it's much slower but *maybe* it's possible?
UzeboxUI - a GUI demo for Uzebox
Re: UzeboxUI - a GUI demo for Uzebox
Oh yikes, I just made a little video mode 8 test program and the RAM consumption is higher than I expected, at 3581 bytes (~87% full) for just a little program that draws a filled rectangle on the screen. I guess 120x96 at 2 bpp takes up a bit more space than I initially realized Is it feasible to use the SPI RAM as a bitmap framebuffer? I know it's much slower but *maybe* it's possible?
-
- Posts: 1445
- Joined: Mon Feb 11, 2013 8:08 am
- Location: Brisbane, Australia
Re: UzeboxUI - a GUI demo for Uzebox
I dont have the SPI RAM expansion so have never used it, but I think it should be possible to do a 1BPP bitmap mode at 256/288 pixels.
T2K does a 1BPP background straight of the SD card which is on the SPI port.
You could possibly even do 2BPP as that would be within the capability of the AVR SPI port. I am just not 100% sure if the RAM can keep up.
I just tried searching the googles just then and I could not even find the part number of the chip to look at a datasheet.
On problem with using the SPI RAM this way is that updating the screen is going to be crazy slow compared to internal RAM.
T2K does a 1BPP background straight of the SD card which is on the SPI port.
You could possibly even do 2BPP as that would be within the capability of the AVR SPI port. I am just not 100% sure if the RAM can keep up.
I just tried searching the googles just then and I could not even find the part number of the chip to look at a datasheet.
On problem with using the SPI RAM this way is that updating the screen is going to be crazy slow compared to internal RAM.
Re: UzeboxUI - a GUI demo for Uzebox
Hmm yeah.. maybe I should just stick with using the internal RAM and then modify video mode 8 to be 1 bpp, which would half the amount of RAM it takes up.CunningFellow wrote: ↑Wed Feb 22, 2023 11:13 am On problem with using the SPI RAM this way is that updating the screen is going to be crazy slow compared to internal RAM.
-
- Posts: 1445
- Joined: Mon Feb 11, 2013 8:08 am
- Location: Brisbane, Australia
Re: UzeboxUI - a GUI demo for Uzebox
So what is the issue you have with only 255 RAMTiles and having to have duplicate tiles on the screen?
Text, Window borders, blank real-estate will all reuse tiles.
Text, Window borders, blank real-estate will all reuse tiles.
Re: UzeboxUI - a GUI demo for Uzebox
I was mostly thinking about going the bitmap route because it offers more flexibility. Windows could be drawn at any location, not just at 8x8 pixel boundaries. No need to worry about staying under the 256 tile limit, just draw pixels straight to the screen and forget about it.
My current thought is to make this utilize compositing. Each window will have its own framebuffer stored in the SPI RAM, then for each visible part of each window, the contents of those framebuffers will be drawn into the main framebuffer whenever the contents of one of those framebuffers becomes "dirty".
My current thought is to make this utilize compositing. Each window will have its own framebuffer stored in the SPI RAM, then for each visible part of each window, the contents of those framebuffers will be drawn into the main framebuffer whenever the contents of one of those framebuffers becomes "dirty".
Re: UzeboxUI - a GUI demo for Uzebox
I doubt the current VM is any order of magnitude slower than other possibilities*. Given that...I doubt you could do much visually in a real time app, if it had to actually store and churn out arbitrary pixels for everything in app code. I guess I'm trying to say this tile based version seems a better balance than I imagined, and M3 RAM tiles might not be too far off the amount of bitmap realistic to fill anyway.
Now I always want to rewrite everything I ever code, so I understand the feeling haha. But as is, this works and is clever; amusing even! Downsides to a fully bitmapped mode: it's too slow to procedurally generate data, and the size limit is too small for much precalculated bitmap graphics and game code. If blitting and graphics/storage can offload to the host/SD...totally different scenario.
To be feasible for bitmap graphics that take advantage of a bitmapped OS, for even a simple Sokoban, IMO the host would need to implement offloaded commands like:
sdFile(APPGRAFXBIN);
sdOffset(512);
sdFillRamTiles(rt_off,256);//load graphics
sdOffset(512+(lvl*lvlSize));
SdFillVram(0,0,playfieldW,playfieldH);
Sorry I hyped Sokoban Land like it's released, then stall out..but I am aiming at a trick to increase it's production value which needs more level compression to fit(hidden one time RAM tiles loading on intro/title). I think it will give at least a 75% demonstrable reality of what max effort games could do without offloading(space limit). IMO offloading would let you run simplified Donkey Kong, PacMan, etc. which are probably both time and space limited right now(besides input..).
*This is the part where I antagonize CunningFellow on the impossibility of him writing some miracle VM
Now I always want to rewrite everything I ever code, so I understand the feeling haha. But as is, this works and is clever; amusing even! Downsides to a fully bitmapped mode: it's too slow to procedurally generate data, and the size limit is too small for much precalculated bitmap graphics and game code. If blitting and graphics/storage can offload to the host/SD...totally different scenario.
To be feasible for bitmap graphics that take advantage of a bitmapped OS, for even a simple Sokoban, IMO the host would need to implement offloaded commands like:
sdFile(APPGRAFXBIN);
sdOffset(512);
sdFillRamTiles(rt_off,256);//load graphics
sdOffset(512+(lvl*lvlSize));
SdFillVram(0,0,playfieldW,playfieldH);
Sorry I hyped Sokoban Land like it's released, then stall out..but I am aiming at a trick to increase it's production value which needs more level compression to fit(hidden one time RAM tiles loading on intro/title). I think it will give at least a 75% demonstrable reality of what max effort games could do without offloading(space limit). IMO offloading would let you run simplified Donkey Kong, PacMan, etc. which are probably both time and space limited right now(besides input..).
*This is the part where I antagonize CunningFellow on the impossibility of him writing some miracle VM
-
- Posts: 1445
- Joined: Mon Feb 11, 2013 8:08 am
- Location: Brisbane, Australia
Re: UzeboxUI - a GUI demo for Uzebox
You're not going to trick me that easily.
I really do want to do a super optimized VM. I started laying out ideas on a spreadsheet quite a long time ago.
I think I can make it quite fast and capable. Easily be able to perform as the bootloader UI and even do things like play snakes or tetris or a simple text adventure.
Right now though my priorities are finishing up a video about T2K for youtube plus a couple of others things to hopefully get me in slightly less dire financial circumstances.
Re: UzeboxUI - a GUI demo for Uzebox
That's actually a really good point, hmm. I was already going to have "offloaded" routines for drawing text, but I see now that I would have to do the same for drawing graphics as well. VM applications will be able to access files on the SD card, so I could have another offloaded routine which draws graphics directly from a file given a file offset, size, and coords.D3thAdd3r wrote: ↑Thu Feb 23, 2023 6:25 pm Given that...I doubt you could do much visually in a real time app, if it had to actually store and churn out arbitrary pixels for everything in app code. I guess I'm trying to say this tile based version seems a better balance than I imagined, and M3 RAM tiles might not be too far off the amount of bitmap realistic to fill anyway.
I should mention that all of this is just me imagining cool ideas right now, I haven't actually started on a rewrite yet . If anything, rewriting UzeboxUI to use bitmaps will be a fun project even if it doesn't work out usability-wise.
Currently the active window's VM only executes 25 instructions per frame. I'm really hoping that with some optimization I can squeeze a bit more cycles out of it to get even just a minor speedup.
Re: UzeboxUI - a GUI demo for Uzebox
Actually, I do get a "NO SPI RAM!" error when I try to load UzeboxUI on my Uzebox but I didn't see it because the top half of the text isn't visible on my HDMI display and I don't think I could see the error at all on my old TV with svideo input. I get a bunch of random nonsense tiles displayed after it.
Is UzeboxUI the first app released to require SPI RAM to run at all?
Is UzeboxUI the first app released to require SPI RAM to run at all?
Re: UzeboxUI - a GUI demo for Uzebox
Depends what we call an app. Alec's scrolling monochrome Akuma image demo was the first Uzebox program to present something using SPI RAM I think(custom video mode and all). SPI RAM Music/PCM demos require it, pretty sure Bubble Bobble and/or another(RPG?) Nicksen project required it for streaming music and/or tiles? And UzeboxUI was made years back now too...so I have no idea but multiple are out there