Uzebox FAQ wiki page updated

Topics on software tools like TileStudio, comments on documentation and tutorials (or the lack of) should go here.
User avatar
danboid
Posts: 1881
Joined: Sun Jun 14, 2020 12:14 am

Uzebox FAQ wiki page updated

Post by danboid »

I have added a few new questions with answer to the FAQ over the last few days. These three were copy/pasted onto the TODO page so I moved them onto the actual FAQ after tidying them up:

11 Is there an official Uzebox IRC channel or Discord server?
12 Does the Uzebox support MIDI IN?
13 Can I use hex files built for the atmega644 on the 644p?

and today I added:
1. My power button isn't working?

It's OK, its probably not your switch that has broke. The Uzebox power button doesn't do anything by default, the Uzebox powers on as soon as a power adapter is connected.
https://uzebox.org/wiki/FAQ
User avatar
danboid
Posts: 1881
Joined: Sun Jun 14, 2020 12:14 am

Re: Uzebox FAQ wiki page updated

Post by danboid »

I updated the FAQ again today to answer the question "What is the recommended way to format a SD card for use with the Uzebox?".

I have really only answered it from a Linux users perspective which means using mkfs.vfat and FAT16. I suspect Artcfox may wish to extend the answer to cover the best way to format SD cards for Windows (and Mac?) users which would seem to be using the sdcard.org tool, which I presume you format them using FAT32 when using the secret sauce format tool or do you use FAT16 when using that too?
User avatar
uze6666
Site Admin
Posts: 4778
Joined: Tue Aug 12, 2008 9:13 pm
Location: Montreal, Canada
Contact:

Re: Uzebox FAQ wiki page updated

Post by uze6666 »

danboid wrote: Tue Mar 28, 2023 1:54 pm users which would seem to be using the sdcard.org tool, which I presume you format them using FAT32 when using the secret sauce format tool or do you use FAT16 when using that too?
I downloaded the sdcard.org tool and it does not give you the choice of the file system. My 2G card (Regular SD) was formatted as FAT16 and a 32GB card as FAT32. So I it seems to choose the best for the card and that's it. Btw, I made a couple test and didn't find a noticeable performance difference (at least for the Uzebox) for a card formatted by Windows and the sdcard.org tool. I added some basic verbiage for the sd card formatting on windows on the faq.
User avatar
danboid
Posts: 1881
Joined: Sun Jun 14, 2020 12:14 am

Re: Uzebox FAQ wiki page updated

Post by danboid »

Under Linux, using a Uzebox compat 4 GB SDHC card, if I format the card with FAT32 it shows your beta project in the Uzebox bootmenu when the card is inserted but it doesn't load it successfully, unlike the same card formatted with FAT16 which boots it fine.

You can right click format disks from the both GNOME and MATE desktop's file managers if you have gnome-disk-utility installed but its FAT option gives you a FAT32 formatted disk.
User avatar
Artcfox
Posts: 1382
Joined: Thu Jun 04, 2015 5:35 pm
Contact:

Re: Uzebox FAQ wiki page updated

Post by Artcfox »

Formatting SD cards is really the only thing that I would borrow a Windows machine to do, in order to use the sdcard.org tool.

Otherwise on Linux, the best way that I have found to get back to the same optimal format that the sdcard.org tool gives is to take an image of the SD card (it compresses REALLY REALLY well) and if you need to format it later, just write enough of that image back to the device to bring it back to the original. (If you only wrote to the first 100 MB of the card, you can tell DD to only write the first 100 MB of the image back to it.)
User avatar
danboid
Posts: 1881
Joined: Sun Jun 14, 2020 12:14 am

Re: Uzebox FAQ wiki page updated

Post by danboid »

Stuff I'd like to or plan to add to the FAQ:

How much RAM does the Uzebox have free after loading the (essential bits of) the kernel?

How many sprites can the Uzebox handle? Should address at least modes 3 and 74.

I'll update it with how the ATMega compares to the CPU of the MD and SNES when we've done that benchmark.
User avatar
D3thAdd3r
Posts: 3170
Joined: Wed Apr 29, 2009 10:00 am
Location: Minneapolis, United States

Re: Uzebox FAQ wiki page updated

Post by D3thAdd3r »

Problem is it's extremely variable to use case, even more so perhaps than NES and similar. It's hard to get an accurate assessment without listing lots of details and caveats. I guess listing maximum could be good, though even that can't provide a 1:1 comparison between modes, and definitely not to another system. For instance, one could create situations where NES would smoke Uzebox on sprites(most realistic scenarios are this), but there would be some where NES couldn't match Uzebox horizontally.

IMO "32-40" sprites is max....except M74 can easily do 30Hz and hit 64...then in theory at reduced color depth and resolution, SPI overlays can do "128+". M74 could hit 64 sprites in perfect scenarios, or as low as 16. Mode 3 likes...maybe 32...or as little as 8. On average scenarios, maybe it's half with proper design considerations.

At max(shortest reasonable screen of 204) I think Uzebox has at most 28 scanlines to process game, graphics, input, and logic. Those lines are interrupted by HSYNC, let's say 1600 cycles on average, so 44800 cycles per frame but probably less. Let's say everything but game logic(which would be handled mostly in hardware on other machines) takes 8 scanlines, so effectively 32000 cycles per frame max. To further distort things if we just look at Mhz, 1-2 Uzebox cycles usually accomplishes what takes 2-6 in some other architectures...highly dependent on the task/operations. Let's bump this up to say 48000 6502 cycles equivalent. Well old games were all hand optimized assembly...let's say 40000...

Then to me, just to display a static BG with max sprites unchanging, the video Max is comparable to some degree. Then the Uzebox CPU could extremely roughly be compared against 40000*60=~~2.4Mhz 6502..basically NES. But Uzebox is completely flexible, take bitmap mode with lots of free scanlines, and basically no vsync tasks(a test which yields no benefit from parallel tile/sprite/audio processors)...that changes the comparison drastically, then I would imagine the equivalent starts pushing against even the mighty 68K at 7-8Mhz?! Those systems might even need to devote significant CPU to converting their tile hardware to operate like a bitmap, where Uzebox flexibility already paid that price and it's no extra cost in the equation.

Probably totally wrong, that's my feel off the top of the head though. IMO game examples are the most accurate comparison, though I agree there could be more specifications added.
User avatar
danboid
Posts: 1881
Joined: Sun Jun 14, 2020 12:14 am

Re: Uzebox FAQ wiki page updated

Post by danboid »

Thanks DA, I may copy/paste some of your response onto the FAQ as I think that's about as good a response anyone could give re: max sprites.

How many minutes do you think it would take you to port/rewrite that asm addition benchmark? Do you think it is a valid way for us to compare the ATMega to the SNES and MD CPUs? Addition is an important operation I suppose, can't deny that.
User avatar
danboid
Posts: 1881
Joined: Sun Jun 14, 2020 12:14 am

Re: Uzebox FAQ wiki page updated

Post by danboid »

I have added a "How many sprites can the Uzebox handle?" question to the FAQ.
User avatar
danboid
Posts: 1881
Joined: Sun Jun 14, 2020 12:14 am

Re: Uzebox FAQ wiki page updated

Post by danboid »

I have added this perfect ending QA to the Uzebox FAQ:

Q. How does the Uzebox processor speed compare to other 8 bit platforms?

Very favorably, as far as MCU/CPU speed is concerned. See The Retro Desk's 8-bit fractal drawing benchmark thread. The fastest 8 bit computer that Matt from YT channel The Retro Desk benchmarked using his assembly mandelbrot drawing test was the Z80-based Agon Light 2 SBC, which managed to compute and draw the fractal in 1.5 seconds.

Uze recreated this same test (but in C) for the Uzebox and it computed the same size fractal in almost dead on one second and thats with the Uzebox graphics output enabled. With graphics output disabled the Uzebox computes it in 0.08 seconds. The Commander X16 took 3.2 seconds, the NES 16.2 seconds and the C64 took 26.4 seconds to compute the same fractal using assembly code.
Last edited by danboid on Sun Sep 17, 2023 12:23 pm, edited 2 times in total.
Post Reply