Bootloader

[uze6666]

Hi Clay,

Hope you don't mind, I'm moving our discussion here about the SD bootloader. From some initial tests, I may be able to fit my part (a minimalist kernel) into around 2.3Kbytes or less by cutting on the sound. The only issue I have is the graphics. A Monochrome font is great but you ideally need to have 8 pixels wide tiles for that (though we could "waste" the two last bits on each line). I tried rewrite a new mode for that, but it got quite big, so sort of loosing the gain made on the font. One possible approach is to unpack 6x8 or 8x8 fonts in RAM and work from there. That will eat a lot of RAM and I was wondering how much you will need for the SD/Fat loader? For sure at least a 512 block of memory to hold a sector, but how much more?

About the font going with RAM will mean a very reduced character set, here's what I propose:

Code: Select all

 0123456789!'$/@?&ABCDEFGHIJKLMNOPQRSTUVWXYZ

That would take around 2k in RAM for 6x8 tiles.

If we could have everything fit into a 2K words bootloader that would be awesome, but that file system stuff seem quite FAT to me.

Regards,

Uze

[ravyne]

Why do you need full 256 colors on each pixel of every character for just a simple UI?

I would simply use a bit-mask with 1 representing a foreground color, and 0 representing a background color or transparency. Mask off the low-order bit and use it as an index into a register containing the desired background/foreground colors. You can shift the original pattern to select successive pixels. If you want to get a little fancy, you can use 2 bit patterns with 3 foreground colors + background/transparency, which is enough for base color, highlight and low-light, or other effects, hell, maybe even go crazy with 4bits per pixel, though you'll quickly begin to eat more ram. You could change the color palette during hblank for different sections of the UI, heck, with just 1 or two bits, you could almost certainly find the cycles to change the colors in the palette during the raster stream, remember, you've only got to load a byte or two of image data per 8 pixels with this approach, so loading another byte or three per 8 pixels ought to be doable.

for 1 Bpp its only 344 bytes for those 43 characters you laid out, for 8x8 glyphs even.

[uze6666]

Why do you need full 256 colors on each pixel of every character for just a simple UI?

Ok, let me precise. I'm also looking for 1bbp fonts, not 256 colors. It already fits into 344 bytes and it's 8x8. But you have to realize that it takes cycles to index things a you mentioned. Personally, I came up with a 5 cycle/pixel loop using 1bbp fonts unpacked in RAM, otherwise it's six cycles/pix.

Right now, I'm just trying various things to get the best quality for a minimum size. Note that unpacking in RAM has the added benefit that you can you can apply some gradient on the font, making it look nicer.

Uze

[ravyne]

Could you post the code for the 5 cycle/pixel routine? What's the format you're un-packing to?

[uze6666]

Could you post the code for the 5 cycle/pixel routine? What's the format you're un-packing to?

The bits are simply expanded to one byte per pixel. Here's the loop:

Code: Select all

m1_rtl_loop:
	ld r16,Z+	;load tile pixel 0
	out _SFR_IO_ADDR(DATA_PORT),r16
	ld	r20,X+	;load next tile No
	
	ld r16,Z+	;load tile pixel 1
	out _SFR_IO_ADDR(DATA_PORT),r16
	rjmp .
	
	ld r16,Z+	;load tile pixel 2	
	out _SFR_IO_ADDR(DATA_PORT),r16
	rjmp .
	
	ld r16,Z+	;load tile pixel 3	
	out _SFR_IO_ADDR(DATA_PORT),r16
	rjmp .

	ld r16,Z+	;load tile pixel 4	
	out _SFR_IO_ADDR(DATA_PORT),r16
	mul r20,r21	;tile No*width*height

	ld r16,Z+	;load tile pixel 5	
	out _SFR_IO_ADDR(DATA_PORT),r16
	add r0,r18	;add tile table base + tile row offset 	
	adc r1,r19	;add tile table base + tile row offset 	

	ld r16,Z+	;load tile pixel 6	
	out _SFR_IO_ADDR(DATA_PORT),r16
	ld r16,Z+	;load tile pixel 7
	
	movw ZL,r0	;copy next tile adress 
	dec r17		;decrement tile counter	
	out _SFR_IO_ADDR(DATA_PORT),r16
	brne m1_rtl_loop

That give about 288x224 resolution with 8x8 tiles. Looks good but eats a lot of RAM. And I guess we will need some for the rest of the bootloader, so perhaps not the ideal. In the mean time I came up with another loop that's 6 cycles/pix with 8x8 tiles. This one will read 1bbp packed pixel from RAM, so its usage is greatly reduced, only 352 bytes instead of 2K+. Also, there was room left to allow setting the background color of each tiles independently. With that, I made a flashing cursors "bar" for selecting games in the menu. Plus was also able to add a nice gradient in the font.

Cheers,

Uze

[uze6666]

Clay,

Ok, so it's seems I was able to bring down the size of the kernel to 1880 bytes. That includes:
-bare minimum sound
-30x28 tiles, 8x8 pixels each
-64 characters font
-Background color can be defined per tile.

If required to fit in the 2K limit, there still ways to cut another 256-300 bytes or so.


You can't see it, but the red bar is actually glowing slowly. Neat .

Uze

[havok1919]

Ok, so it's seems I was able to bring down the size of the kernel to 1880 bytes.

Nice! That's tiny! Very cool. Good job.

You can't see it, but the red bar is actually glowing slowly. Neat .

That's one of the reasons I like your work so much, you always have an eye for detail! I'll try to take a look at bootloader (flash programming) stuff tonight. It'll largely depend on what we're talking for SD access as to overall size requirements, but a 4K(byte) bootloader from SD might be possible. That's be pretty sweet.

-Clay

[uze6666]

That's one of the reasons I like your work so much, you always have an eye for detail!

Happy you appreciate, for me details are everything!

Here's the HEX file if you want to see how it looks.

Bootloader.hex

(7.6 KiB) Downloaded 423 times

Cheers,

Uze

[ravyne]

Very nice, don't need more than that really. For some reason I could have sworn the AVR had a single-cycle instruction indexed access into register space, but apparently I was dreaming... I guess that's what happens when you're neck deep in 20 different little things at work and trying to absorb a new ISA during sporadic moments of down-time.

So, are you decoding a whole scan-line into ram then, Uze?

[uze6666]

So, are you decoding a whole scan-line into ram then, Uze?

For which engine?

Uze