Bootloader

Topics related to the API, programming discussions & questions, coding tips, bugs, etc. should go here.
ravyne
Posts: 59
Joined: Thu Sep 25, 2008 7:59 pm

Re: Bootloader

Post by ravyne »

Just for the text mode I mean. Looking at the code you posted above that's how it looks to me, just wanted some confirmation -- or, in the negative, what other clever trickery you've wrangled.
User avatar
uze6666
Site Admin
Posts: 4801
Joined: Tue Aug 12, 2008 9:13 pm
Location: Montreal, Canada
Contact:

Re: Bootloader

Post by uze6666 »

Aaah! I went back to that 1bbp loop after all :D . Not 100% commented yet, but heres' the code:

Code: Select all

;*************************************************
; RENDER TILE LINE
; r22     = Y offset in tiles
; r23 	  = tile width in bytes
; Y       = VRAM adress to draw from (must not be modified)
; Must preserve: r22,r23,Y
;*************************************************
render_tile_line:
	;get shade color for current font line
	clr r16
	ldi ZL,lo8(fontshade)
	ldi ZH,hi8(fontshade)
	add ZL,r22
	adc ZH,r16
	lpm r4,Z

	;copy current VRAM position
	movw XL,YL

	ldi r21,TILE_HEIGHT 

	;Pre-calculate tile table base+tile row offset
	ldi r16,1 ;tile width (in bytes, 8 pix per byte)
	mul r22,r16 
	ldi ZL,lo8(fontram)
	ldi ZH,hi8(fontram)
	add ZL,r0	;add tile row offset
	adc ZH,r1   ;add tile row offset
	
	movw r24,ZL	;save for use in loop

	;load the first tile from vram
	ld	r16,X+	;load next tile # from VRAM	
	mul r16,r21  ;calculate offset in tile table
	add ZL,r0	
	adc ZH,r1   

	ld r2,X+	;load next tile bg color
	ld r16,Z	;load first tile pixels

	;draw 30 tiles wide (8x8), 6 clocks/pixel -->1440
	ldi r17,30

m1_rtl_loop:
	mov r18,r2
	sbrc r16,7
	mov r18,r4
	out _SFR_IO_ADDR(DATA_PORT),r18	
	ld	r20,X+	;load next tile # from VRAM	
	
	mov r18,r2
	sbrc r16,6
	mov r18,r4
	out _SFR_IO_ADDR(DATA_PORT),r18	
	mul r20,r21 ;calculate offset in tile table
	
	mov r18,r2
	sbrc r16,5
	mov r18,r4
	out _SFR_IO_ADDR(DATA_PORT),r18	
	add r0,r24  ;add tile table base + tile row offset 	
	adc r1,r25  ;add tile table base + tile row offset 	
	
	mov r18,r2
	sbrc r16,4
	mov r18,r4
	out _SFR_IO_ADDR(DATA_PORT),r18	
	movw ZL,r0
	mov r15,r16
	
	mov r18,r2
	sbrc r15,3
	mov r18,r4
	out _SFR_IO_ADDR(DATA_PORT),r18	
	ld r16,Z	;load next tile pixels
	
	mov r18,r2
	sbrc r15,2
	mov r18,r4
	out _SFR_IO_ADDR(DATA_PORT),r18	
	ld r3,X+	;load next tile bg color
	
	mov r18,r2
	sbrc r15,1
	mov r18,r4
	out _SFR_IO_ADDR(DATA_PORT),r18		
	mov r18,r2
	sbrc r15,0

	mov r18,r4
	dec r17
	mov r2,r3
	out _SFR_IO_ADDR(DATA_PORT),r18
	brne m1_rtl_loop


	;end set last pix to zero
	lpm ;3 nops
	clr r16	
	out _SFR_IO_ADDR(DATA_PORT),r16
-Alec (aka Uze)
CompMan
Posts: 91
Joined: Mon Aug 25, 2008 3:48 am
Location: Kent, WA

Re: Bootloader

Post by CompMan »

Wow a lot has changed since I was last online. I love the work on the new games and the bootloader. Who's idea was the Bootloader anyway?

Glad to announce I just got a job working as a server administrator. But unfortunately all the money I had going to the Uzebox fund got put into my new car that I just got.

Compman
User avatar
uze6666
Site Admin
Posts: 4801
Joined: Tue Aug 12, 2008 9:13 pm
Location: Montreal, Canada
Contact:

Re: Bootloader

Post by uze6666 »

Hey, welcome back Josh.

Yeah, things are going full speed lately. The bootloader idea is partly, Clay's idea I think. But, if I recall, it was somewhat implied since we started talking about the SD interface.

Glad to hear thing are going well for you now. :)

Cheers,

-Alec
havok1919
Posts: 474
Joined: Thu Aug 28, 2008 9:44 pm
Location: Vancouver, WA
Contact:

Re: Bootloader

Post by havok1919 »

uze6666 wrote:Yeah, things are going full speed lately. The bootloader idea is partly, Clay's idea I think. But, if I recall, it was somewhat implied since we started talking about the SD interface.
Yeah, I dunno if I can claim credit for the idea-- I just kind-of assumed that's how we'd have to do it in order to load stuff from SD into program memory. ;-) I started bugging Alec about how small he could make a display kernel so we could get a feel for if we need 2K or 4K word bootloader size. I'm thinking that we can do it with 2K words (4Kbytes). SD init looks pretty small as does basic self-programming.

I think I read that the 'full' Atmel bootloader protocol (which includes a bunch of interactive crap that we won't need) only took about ~500 bytes under IAR C, so that's encouraging.

-Clay
DavidEtherton
Posts: 252
Joined: Tue Dec 02, 2008 12:38 am
Location: Carlsbad, California (USA)

Re: Bootloader

Post by DavidEtherton »

Any progress on this lately? If somebody can point me at code that reads SD sectors I can try to get FAT16 decode running.

Also, could we cheat a bit and break the bootloader up into two parts? The resident part is burned into permanent memory and just has enough code to fire up the SD card interface and pull BOOT.BIN (or whatever) off the card into main memory, where the bulk of the loader then lives? That in turn can pass a sector list to the resident part to perform the rest of the load?

-Dave
havok1919
Posts: 474
Joined: Thu Aug 28, 2008 9:44 pm
Location: Vancouver, WA
Contact:

Re: Bootloader

Post by havok1919 »

DavidEtherton wrote:Any progress on this lately? If somebody can point me at code that reads SD sectors I can try to get FAT16 decode running.
I haven't tried this code, but it seems reasonable in my 10 second inspection. ;-)

http://www.avrrepository.com/samplecode ... /main.html

Remember to SPI change the chip select to PORTD.6.
Also, could we cheat a bit and break the bootloader up into two parts? The resident part is burned into permanent memory and just has enough code to fire up the SD card interface and pull BOOT.BIN (or whatever) off the card into main memory, where the bulk of the loader then lives? That in turn can pass a sector list to the resident part to perform the rest of the load?
Might be possible technically, but maybe a bit tricky to implement. The SPM instructions will only execute from inside the boot loader area, so we really need read only FAT, SPM (flasher), and a simple GUI to fit in the bootloader if we want an "unbrickable" device. (We can lock the boot blocks once we're stable and even turn off SPM's ability to write to the boot block area to protect the code there.)

While we could bootstrap something (ie, load a "fancy flasher" app from the SD card as the boot sequence and run that for a nicer GUI or whatever-- could use Alec's RAM tiles in that case to show little icons for the games, etc.) we would essentially be doing two erase cycles on the flash every time the menu is called and a game selected. (Since the program flash has limited erase endurance that makes the engineer in me get a little anxious... OTOH, neither Alec or I have 'worn' one out yet during development... and I've never worn out a flash based ARV *ever*, but I do hate building in a failure mechanism with twice the aging rate when one with half would do.) The other upside to a bootloader-only implementation is that one of the menu options could just be "exit" which runs the existing flash code since nothing would need to be overwritten.

(I had always thought of the menu just being called by the user-- either the button on PORTD.3 or some combination on the control pad, but if it was non-destructive and non-wearing on the flash it could also just appear on power-up or reset. We could always reserve a few bytes in EEPROM for a "default" game selection-- either a filename, and/or a CRC of program space to "reload" if it doesn't match up.)

-Clay
exile
Posts: 11
Joined: Wed Dec 17, 2008 7:40 pm

Re: Bootloader

Post by exile »

I have one idea, and is to reuse FAT, video and sound kernel from boatloader in the game.
This idea have some nice size saving, (I think)

Of cores it have done side, if modify the video kernel, you have to sacrifice "game" program space for it.
And if you modify the bootlader video kernel, the "older" games will not run. (so only one video mode)

How ever this can be down only FAT if "uzebox" want....

About FAT has some one have see the Tiny-FatFs it use "only" 2524byte for read only FAT16 and 3634 byte for read only FAT32 and FAT16, it is nice but made lite to big ^^ (it free to use)
DavidEtherton
Posts: 252
Joined: Tue Dec 02, 2008 12:38 am
Location: Carlsbad, California (USA)

Re: Bootloader

Post by DavidEtherton »

havok1919 wrote:
DavidEtherton wrote:Any progress on this lately? If somebody can point me at code that reads SD sectors I can try to get FAT16 decode running.
I haven't tried this code, but it seems reasonable in my 10 second inspection. ;-)

http://www.avrrepository.com/samplecode ... /main.html

Remember to SPI change the chip select to PORTD.6.
It looks like that code is set up to use PORTB, not PORTD? Also, is there a download link to an archive there somewhere I'm too blind to see? All I can find is the documented source code with line numbers in front of it.

Somebody around here must have "int mmc_readsector(uint32_t lba, uint8_t *buffer);" already up and running on Clay's AVCORE?

(I should be able to support this under the emulator too, at least the Win32 version -- I have no idea how to do raw block reads on MacOS)

-Dave
havok1919
Posts: 474
Joined: Thu Aug 28, 2008 9:44 pm
Location: Vancouver, WA
Contact:

Re: Bootloader

Post by havok1919 »

DavidEtherton wrote:It looks like that code is set up to use PORTB, not PORTD?
The SPI pins itself are on PORTB (PB7=SCK, PB6=MISO, PB5=MOSI) and then we have PORTD.6 as the chip select.
Also, is there a download link to an archive there somewhere I'm too blind to see? All I can find is the documented source code with line numbers in front of it.
Damn, you're right, or I'm blind too. That's weird.
Somebody around here must have "int mmc_readsector(uint32_t lba, uint8_t *buffer);" already up and running on Clay's AVCORE?
...

(crickets)

...

I confess that for my testing I just used a commercial library I bought a long while back. ;-) Maybe I'll poke at this for a couple mintes and see what happens...

-Clay
Post Reply