UzeboxUI - a GUI demo for Uzebox

Use this forum to share and discuss Uzebox games and demos.
User avatar
danboid
Posts: 1937
Joined: Sun Jun 14, 2020 12:14 am

Re: UzeboxUI - a GUI demo for Uzebox

Post by danboid »

Artcfox wrote: Sun Feb 19, 2023 8:25 am
danboid wrote: Sun Feb 19, 2023 8:19 am * A minimal file manager, if only for deleting files off SD but copy and move would be cool too.
Just a FYI, deleting files off the SD card can cause fragmentation, which would break a bunch of games that require their level data to be contiguous (for speed purposes) if any of those games were copied to the SD card after the fragmentation took place.

Edit: The best way to restore full speed of a fragmented SD card is to format it with this proprietary tool: https://www.sdcard.org/downloads/formatter/ which only has a Windows and Mac version, because it does some behind the scenes magic to make sure the filesystem parameters match up with the underlying hardware implementation for that specific card. I guess on Linux, one could create a compressed image of the card before copying any files to it, and then use dd to restore the formatted image back.
I thought I'd read on the wiki that v5 of the bootloader handles fragmentation better?

It seems that the majority of Uzebox games can run entirely from flash without and any data stored on SD card. It seems its only really T2K and playing audio files with Uzeamp that might require a defragged SD card. I've been deleting and adding stuff onto my SD card without issue so far. T2K still seems to play after all my messing without any defrags so maybe its only really Uzeamp that is hyper sensitive to fragmentation?

I would imagine that simply copying all of the files off your SD card, then doing a full mkfs.vfat format or dd'ing the disk and then doing a quick vfat format should both fix fragmentation but there is also at least one tool to defrag FAT32 (and NTFS) disks from Linux:

https://github.com/749/UltraDefrag4Linux

There is at least one more but I'm struggling to find it or remember what it was called.
User avatar
D3thAdd3r
Posts: 3222
Joined: Wed Apr 29, 2009 10:00 am
Location: Minneapolis, United States

Re: UzeboxUI - a GUI demo for Uzebox

Post by D3thAdd3r »

You had this going a couple years ago you mention, can I ask if you still have plans on developing this? I don't want to start dropping all kinds of "helpful suggestions" if you are already working on other projects, but I think there is enough possible where some key apps could be made.

Specifically with some more host side offloading(block copies, VM IRQs, VM messages/input, etc), there could be things like music players, file browsers, and most importantly, a way to push state to an SD card, flash another ROM, have the GUI flashed back, pop the SD state, and continue. Then this would just be the default ROM for a lot of users :ugeek:
User avatar
ry755
Posts: 226
Joined: Mon May 22, 2017 6:01 am

Re: UzeboxUI - a GUI demo for Uzebox

Post by ry755 »

Yeah I plan on continuing to work on this, I just haven't touched it in 3 years. Another thing is stability on real hardware, iirc it would lock up/reset after a little while and the Apps menu would show garbage characters.
User avatar
uze6666
Site Admin
Posts: 4801
Joined: Tue Aug 12, 2008 9:13 pm
Location: Montreal, Canada
Contact:

Re: UzeboxUI - a GUI demo for Uzebox

Post by uze6666 »

The first GUI on the Uzebox, pretty cool stuff! And I reckon it's decently fast as it is considering it's a VM. Using SPI RAM would slow things down appreciably (2 cycles vs 64 for ramdom access) so I would probably would not use it for main memory.
Couldn't resist it :geek: Pretty fun set of restrictions, I recommend people take a try at making a simple game(hangman?, battleship?).
I would have bet Lee would do something...but the sound effects was the cherry on the top! :mrgreen:
User avatar
ry755
Posts: 226
Joined: Mon May 22, 2017 6:01 am

Re: UzeboxUI - a GUI demo for Uzebox

Post by ry755 »

uze6666 wrote: Tue Feb 21, 2023 6:34 am Using SPI RAM would slow things down appreciably (2 cycles vs 64 for ramdom access) so I would probably would not use it for main memory.
Oh it already does use the SPI RAM as the VM's memory. Each VM is allowed to use up to 3KB. With up to 10 VMs allowed to exist at once, that means 30KB of the SPI RAM is reserved for VM memory.
User avatar
ry755
Posts: 226
Joined: Mon May 22, 2017 6:01 am

Re: UzeboxUI - a GUI demo for Uzebox

Post by ry755 »

ry755 wrote: Tue Feb 21, 2023 5:08 am Yeah I plan on continuing to work on this, I just haven't touched it in 3 years.
Honestly I kinda want to just start from scratch. I've learned a lot over those 3 years and I think I would do things differently now.

I was thinking about D3thAdd3r's comments from a long time ago about making a GUI for the Uzebox, and iirc his plan was to create a monochrome bitmap video mode. What are everyone's thoughts on making something like that? Could a monochrome bitmap be streamed from the SPI RAM? I would need some help with the video mode part as AVR assembly isn't one of my strong points, but I feel like I could comfortably take it from there and remake UzeboxUI to be bitmap-based rather than tile-based like it currently is.

Looking at the details for video mode 6 (the monochrome 1bpp ramtile-only video mode) I see it says up to 288x224 resolution using 36x28 ramtiles, but then under that it says up to 256 ramtiles? Is that a mistake/typo or does that mean only part of the screen can contain unique ramtiles?

Ideally I'd like something like video mode 8 (the 2bpp bitmap mode), but with some sacrifices (i.e. no color, 1bpp) to hopefully squeeze out a bit higher resolution.
User avatar
danboid
Posts: 1937
Joined: Sun Jun 14, 2020 12:14 am

Re: UzeboxUI - a GUI demo for Uzebox

Post by danboid »

ry755 wrote: Tue Feb 21, 2023 8:36 am
uze6666 wrote: Tue Feb 21, 2023 6:34 am Using SPI RAM would slow things down appreciably (2 cycles vs 64 for ramdom access) so I would probably would not use it for main memory.
Oh it already does use the SPI RAM as the VM's memory. Each VM is allowed to use up to 3KB. With up to 10 VMs allowed to exist at once, that means 30KB of the SPI RAM is reserved for VM memory.
That's why it fails to load on my Uzebox then as I don't have the Uzenet adapter installed yet.
User avatar
ry755
Posts: 226
Joined: Mon May 22, 2017 6:01 am

Re: UzeboxUI - a GUI demo for Uzebox

Post by ry755 »

danboid wrote: Tue Feb 21, 2023 9:12 am That's why it fails to load on my Uzebox then as I don't have the Uzenet adapter installed yet.
Oh you mean it doesn't show an error message about not having the SPI RAM installed? It's supposed to, I guess maybe that got broken at some point without me realizing it :P
User avatar
danboid
Posts: 1937
Joined: Sun Jun 14, 2020 12:14 am

Re: UzeboxUI - a GUI demo for Uzebox

Post by danboid »

ry755 wrote: Tue Feb 21, 2023 9:18 am
danboid wrote: Tue Feb 21, 2023 9:12 am That's why it fails to load on my Uzebox then as I don't have the Uzenet adapter installed yet.
Oh you mean it doesn't show an error message about not having the SPI RAM installed? It's supposed to, I guess maybe that got broken at some point without me realizing it :P
It does not show that error.
CunningFellow
Posts: 1445
Joined: Mon Feb 11, 2013 8:08 am
Location: Brisbane, Australia

Re: UzeboxUI - a GUI demo for Uzebox

Post by CunningFellow »

ry755,

Doing a VM was actually one of the two things I had in mind to enable a new bootloader. The other was to move all the FONT to RAM apart from a frowning face.

On any error before the FONT was loaded it would just show a series of frowning faces depending on the error. Kind of like a PC BIOS error beeps. You would have to look up a table to work out the fault.

The things that would need to be in ROM would be the video mode, basic SD Card routines the FLASH programming and the VM.

This means you could have a nicer 8x8 font with 128 chars, the video mode could show full colour RAM tiles (for things like game icons).

I think there should be enough space left for a VM with the space saved from dropping the font and GUI code.

Obviously not embedVM which is written in C to be easy to understand, but a simple ASM speed/size optimized VM should be totally doable.


OH - and to answer your question - mode6 is 256 ramtiles. Only part of the screen can be unique ramtiles. Vectorgame/Asteroids was done in a variant of mode6.


ry755 wrote: Tue Feb 21, 2023 9:02 am
ry755 wrote: Tue Feb 21, 2023 5:08 am Yeah I plan on continuing to work on this, I just haven't touched it in 3 years.
Honestly I kinda want to just start from scratch. I've learned a lot over those 3 years and I think I would do things differently now.

I was thinking about D3thAdd3r's comments from a long time ago about making a GUI for the Uzebox, and iirc his plan was to create a monochrome bitmap video mode. What are everyone's thoughts on making something like that? Could a monochrome bitmap be streamed from the SPI RAM? I would need some help with the video mode part as AVR assembly isn't one of my strong points, but I feel like I could comfortably take it from there and remake UzeboxUI to be bitmap-based rather than tile-based like it currently is.

Looking at the details for video mode 6 (the monochrome 1bpp ramtile-only video mode) I see it says up to 288x224 resolution using 36x28 ramtiles, but then under that it says up to 256 ramtiles? Is that a mistake/typo or does that mean only part of the screen can contain unique ramtiles?

Ideally I'd like something like video mode 8 (the 2bpp bitmap mode), but with some sacrifices (i.e. no color, 1bpp) to hopefully squeeze out a bit higher resolution.
Post Reply