New Features Incubator

[ladyada]

I like the USB->Serial approach since it could avoid/solve a few problems for users. (ie-- no need for an ISP adapter, no need for a serial port on new PC's/Macs, no need for a separate USB->Serial dongle on the computer) We'd need a little serial bootloader, but that could be pretty simple. I like SD though too. Just wish FAT wasn't such a porker... Would love to be able to drag and drop files and pop the card in.

I'm planning to, basically, port the STK500 bootloader to the chip and then provide a 1x6 header for plugging in a USB-ttl cable ($20). whats nice is that then you can use the cable for debugging (serial output) as well as programming (albeit a bit slower than with a 'real programmer') I use them a lot and they are rather 'foolproof'
http://www.adafruit.com/index.php?main_ ... ucts_id=70
they're also sold at mouser.
You can see the header in my board layout, in the bottom left

[havok1919]

I'm planning to, basically, port the STK500 bootloader to the chip and then provide a 1x6 header for plugging in a USB-ttl cable ($20). whats nice is that then you can use the cable for debugging (serial output) as well as programming (albeit a bit slower than with a 'real programmer') I use them a lot and they are rather 'foolproof' http://www.adafruit.com/index.php?main_ ... ucts_id=70 they're also sold at mouser.
You can see the header in my board layout, in the bottom left

That's a neat little cable. I think I'll probably just go with a regular USB connector/cable and FTDI chip on board. I figure that even including a standard USB A-B cable that the discrete solution can't run more than $6-7 depending on which chip is used. I still can't believe that Maxim or Analog Devices haven't cloned the FTDI stuff and integrated 232 level shifters. There's just so much margin in the price of those FTDI chips...

Serial program/debug is handy. I guess the wait time could be a little annoying with a 64K MCU-- the last one I did was just on a Mega48/88 and it was totally acceptable. I suppose a full 64K rewrite could be a little bothersome. It's an easily enough solution though. If people don't like the speed, just use the ISP port instead.

-Clay

[cjoudrey]

The SD Card reader is really a must especially since FuzeBox kits have been made available.

Opening the case each time to change game is frustrating.

My 2 cents.

[uze6666]

It should be coming soon, I had made a working bootloader prototype lately that can read games from the SD card and flash them successfully. It's not fragmentation aware and was a done in C so it's somewhat bloated, but it a proof of concept. I've been working with Pragma on this in the past weeks, he has rewritten & updated the FAT/SD code is assembler. Just need to make his libs C callable and we should be able to present some beta for you guys to play with.

-Uze

[DaveyPocket]

we should be able to present some beta for you guys to play with.

x10

[cjoudrey]

Sounds awesome Uze !

Can't wait ! )

[Vertig0zone]

Change Video Modes on the fly.
Interlaced double buffered bitmap mode.
have options in leplatz to generate and render povray tiles.

Add support to map a sprite and then switch the sprite tile table. i'm got very good with assembly or i'de do it myself, but a general outline of how it would work is to when move sprite is called , store the sprite data into ram, then add a function to concatenate the vram(collision detection) before the user calls waitvsync(). That way developers could have tons, and tons, and tons of animations, because you would store one character on a sheet of 256 tiles, map it, move it, then use another 256 tile sheet to do another character. If i could sqeeze 64 frame per character instead of 8 or 9, i could probably pull of street fighter 3 quality animation(although i don't know how many character i could fit). In the mean time, i'll be doing research on the Mode3 code to see if i can figure it out, because i already drew tons of sprites, and can easily make the animation better.
It would probbly be more effecient if MoveSprite() did the collision tests.

[D3thAdd3r]

Very modest feature request here. Working on my first hopefully successful hardware contribution for Uzebox, and not owning an oscilloscope or much and an electronics lab, I have found something as simple as:

Code: Select all

void LEDon(){PORTD|=(1<<PD4);}
void LEDoff(){PORTD&=~(1<<PD4);}

to be simple and effective for testing things out and is video mode independent. More than that, it makes code look cleaner and doesn't require me to be hooked up to a television for indication when I have ISP,laptop,wires,and a chicken all over my work bench already. Probably not much discussion required besides better name but I wanted to mention it before I forget.

[uze6666]

Very modest feature request here. Working on my first hopefully successful hardware contribution for Uzebox, and not owning an oscilloscope or much and an electronics lab, I have found something as simple as:

Code: Select all

void LEDon(){PORTD|=(1<<PD4);}
void LEDoff(){PORTD&=~(1<<PD4);}

to be simple and effective for testing things out and is video mode independent. More than that, it makes code look cleaner and doesn't require me to be hooked up to a television for indication when I have ISP,laptop,wires,and a chicken all over my work bench already. Probably not much discussion required besides better name but I wanted to mention it before I forget.

Good idea, I can't believe it's not been added before! I've created 3 functions with names in line with the remaining API:

Code: Select all

	extern void SetLedOn();
	extern void SetLedOff();
	extern void ToggleLed();

It's commited to the trunk and ready to use.

[D3thAdd3r]

Trivial feature request here. I have a game where the title screen plays a song right away and I don't want it to loop. Currently there is no way that I can see to make sure that u16 currDeltaTime doesn't rollover, and you would have to extern it to access it from user code to do a manual StopSong() before a rollover. It would be nice if we could trigger one shot songs and not have to worry about it looping later unexpectedly without adding code in a wait loop to call StopSong() after some period of time(there are situations where that would be kind of silly code).

Code: Select all

//ProcessMusic()...
//....
//...
		}//end while
		
		if(++currDeltaTime == 65535)//this is currently just: currDeltaTime++
			playSong = false;//just need a little check for a rollover loop, now one shot songs we just set -e65535 in midiconv and it will never loop
	
	}//end if(playSong)

I haven't seen any games that rely on the current behavior, and I don't believe there is any way to handle this in the midiconv conversion regardless of what -e setting you use?