Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.

Messages - zet23t

Pages: 1 2 3
I've "Clone and Edit"ed both games and they both return "Verification Successful!" when clicking the Verify Code button; but, for some reason I get the same response every time when trying to run on the arduino. Even after restarting my computer and unplugging/replugging everything back in, it still wont run. Hmm..

I'm running it on Google Chrome; what browser are you using to compile it?

I use firefox. If the verification is successful, it means that the program was created and that it's merely the upload the fails.

Have you checked the com port settings? I used com1 for my device, maybe it's different for yours?


Stellar Explorer:

Asteroids returns: "Could not connect to your device. Make sure that you have connected it properly, that you have selected the correct settings (device type and port) and try again" even though other programs are being uploaded successfully without this problem. Has anyone had this issue?

Stellar Explorer returns: "There was an error compiling." and I can't seem to figure out where it's going wrong.

Thanks for your help in advance!

Both are games I've uploaded. Interesting that they don't work for you  - both compile and upload for me without problems. Do they also report errors when you "verify code"?

I sometimes also have trouble with the serial connection. Most often it simply works by unplugging the device and plugging it in again.

7.5.3 says that if you are using 8 bit color mode, the 16 bit color is generated into RAM.

In 8.1, it indicates you can read via parallel, but not in serial mode.

I really wonder how true this 'read' condition is. I guess it's worth a shot.

Ah yes, that point looks pretty clear to me. Otherwise the logic for the screen would probably be much more complicated. I've been already thinking about the possibilities - like having an offscreen sprite atlas and copying it onto the front buffer. Then however I realized that this technique would also have severe drawbacks: No transparency support. And since sending the data line by line lacks also transparency, there's no solid way to fix it. Too bad they didn't just pack twice or four times more RAM and included some transparency mode. That would make making games quite easy...

I think I'll stick to scanline rendering as it requires less fiddling.

There are btw. two things I've been thinking in the past about regarding compression: Text compression and image compression. I dropped doing an implementation since I didn't see much use (yet) with the stuff I want to do, but by mentioning full screen images, I've been wondering if you would be interested in that.

The text compression I thought of would be quite simple: A script scans a file with all strings you want to use in your game. It determines the character usage and creates a custom compression table of all used characters. Depending on the number of distinct characters it would pack the strings into 4 bit tuples where certain sequences would tell the decompressor that the character needs another 4 bit tuple for unpacking. I wrote a simple Lua script for compression and it pretty much works... it would save 50-70% of storage space for all strings and the decompressor should be rather simple since the format is quite straight forward. It wouldn't however really matter unless you have ~1k of text.
I could finish that work if you are interested.

Another thing was image compression... I didn't follow that since rendering times would decrease significantly, however again, if you are interested, I could look into that direction as well. I think it wouldn't be too much work. I'm just also not sure how "good" it would look like. The idea is similar to DXT/ETC compression - with some adaptions: I would slice an image into a 4x4 or 8x8 block. Each block would have a color palette associated. An image would have 16 color palettes to pick from, 4 colors each. Each pixel would therefore use 2bits plus 4 bits for each 8x8 or 4x4 block for the palette selection. That would mean using 16.5 bytes for each 8x8 block instead of 64 bytes or 4.5 bytes for each 4x4 block instead of 16 bytes. Depending on the image content, it might look ok (of course it's lossy compression, so quality might be problematic ;)). The decompressor would be still rather simple to implement (read a byte, unpack pixels, load palette colors, translate colors to line pixels). However the compressor would require some more thinking to get "good" quality.

But it's been mostly just ideas. It would be more interesting to make use of that ;)


This is interesting. The RAM is holding either 16bits or 8bits. And the address for read out can be set. So... if I am not mistaken from the short glance I had, double buffering might be possible by using 8bit mode and doing the page flip by setting the address respectively to the left or right half. If that would work, using the hardware commands for drawing rectangles and such becomes interesting again. I hope that this really works... it might be that the driver doesn't allow doing that - which would be a shame because the memory is available for that it appears. Have to invest more time in the evening.

User Projects / Code Examples / Re: TinyDuino Game Kit Case
« on: May 13, 2015, 01:08:56 AM »
Not that I am aware of. I asked a bit around but no one turned out to have one. I would probably need to search in a maker forum or something ...

User Projects / Code Examples / Re: TinyDuino Game Kit Case
« on: May 12, 2015, 06:11:06 PM »
I've uploaded the files to my blog: I have ordered the version with the changes (not sure if they turn out to work) to see if they work. I should have it at the end of next week. It's really annoying without access to a printer.


There is a datasheet for the chip. It has a few other modes which are useful for hardware acceleration of graphics.

One major compliant I have with this display driver is there is no way to read back the frame buffer. This makes it very difficult to efficiently draw graphics on the screen, implement sprites, and use windows. I mitigate this by using SetX() and SetY() and calculating what should be replaced.

Do you have a link to the datasheet?

As I wrote earlier - right now I am solely trusting my scanline renderer with which I can do quite many sprite renderings with reasonable frame rates. It's is quite optimized so I am fine for most games I was thinking of.

User Projects / Code Examples / Re: TinyDuino Game Kit Case
« on: May 12, 2015, 01:35:30 AM »
You mean having the STL files? I am working with Cinema 4d, which isn't a CAD software but an editor for rendering purposes, hence it's a bit clunky from time to time.

I have made changes by now and ordered a new version. It's annoying me that I still have no 3d printer myself since it costs 30€ each time I order it. Of course the delivered quality exceeds private 3d printers in detail by far... therefore I am also unsure how useful the design would be for you.

Hm. Hardware copy sounds neat but without double buffering, the uses are a bit limited. I am most annoyed by the flickering - therefore I just use the scanline rendering for everything. It's fast enough to scroll all sprites/texts that I draw in any direction anyway.

It would be much more useful if the screen had

- Selectable 8bit palettes (currently it's 2-3-3)
- Double buffering
- Uploadable sprites that can be used as textures (32kb or so would suffice)

Essentially the Double buffering would make the difficult-to-use scanline renderer obsolete - which uses also quite a bit of precious ram. And it would make the hardware commands more attractive again - right now I chose not to use them.

Is there an overview what hardware commands are supported?

Looks cool. What do you mean with hardware copy?

I also have implemented a scanline renderer - it's opensource and is available here:

User Projects / Code Examples / TinyDuino Game Kit Case
« on: May 09, 2015, 02:11:32 AM »
Hey there, if you are interested in having a case for the TinyDuino Game Kit - I am working on something, here's the video:

Ah, ok so I am lacking right now the hardware to burn a bootloader as the tiny USB shield is not capable of burning the bootloader? I wasn't even aware of that... it's somewhat difficult to come by information how to approach this entire matter.

I have looked now a bit at USBasp but am blank regarding how to connect it to my TinyDuino. Does Tiny-Circuits offer some kind of hardware elements to approach this? I would be interested in getting something like that then.

Meanwhile I tried the examples for SDcard reading / writing with the sd card shield I got last week. It looks interesting but the sketch size is quite huge right now. It looks really difficult to handle the SD communication reduced to the level that it works but is just enough. My current plan is to try to get something working that loads data from SD but stays below 1k. If I can't get that working, I won't need the hardware I guess and fall back to trying out making an interpreter, though I guess that performance will be bad.

TinyDuino Processors & TinyShields / TinyDuino Bootloader questions
« on: May 05, 2015, 01:20:16 PM »
I intend to modify the bootloader to support loading programs from SD cards. I don't know if this will work, but I want to attempt it in an effort to make an autonomous gaming console that can load different games without being connected via USB.

I am seeking now the source code of the current bootloader that is used in the tinyduino so I can learn what it does and how it works. Furthermore I wonder if I can brick (break) my tinyduino when burning the loader so that I can't program it anymore with my USB shield - maybe someone can tell me?

TinyDuino Processors & TinyShields / Re: Loading programs from SD
« on: April 30, 2015, 06:17:35 PM »
Your thoughts are similar to what I have been pondering about...

The rewrite limit: 10k rewrites are unlikely to be hit within a reasonable time. If you'd play each day 3 different games it would take more than 4-10 years to hit he guaranteed minimum rewrites. Since I think that this is a highly unlikely scenario, I came to the conclusion that this doesn't matter much (to me). Even if a game would consist of multiple programs, it would still take plenty of play time to trash the chip. (If it was so much fun to play, 15$ would be sort of OK to pay once per year I'd think ;))

About the boot loader: I have no idea how to work with it, but I have some ideas. I was thinking to have some code that takes an address of the SD card file and starts loading the content, not taking (much) file system code into the loader. One way to do it would be to have a "Loader" program that has FAT32 code to look through the SD card, showing ROM thumbnails and allowing to load a game.
When a game is selected to be loaded, the game's properties (FAT32 first cluster table entry) as well as the loader program's address is stored on EEPROM. It then loads the code from flash through the bootloader that only needs to handle loading files through the FAT cluster table, which should be reasonably simple to read. So to load the loader program from the game again, very little FAT32 code is required because all required cluster information is stored on the EEPROM. Note: If the ROM format of the files on the SD card has a size limit like 128kb and the cluster size of the FAT32 format is 4k, the 32 cluster addresses of the file entries could be just stored on EEPROM - so loading content would be really simple by just reading the eeprom. Especially if the file structure is aligned with FAT cluster sizes.
I researched a bit the topic of resetting and using the watchdog timeout it's possible. So I would think that the life cycle would be:
:: Loader => user selects a game => store cluster file data in eeprom => flash the ROM => restart. Game.
:: Game => user selects option to quit => load loader cluster from eeprom => flash the ROM => restart. Loader.
I am curious if that could work out this way...

Regarding an interpreter: I've considered this as well for quite some time. It would be great! After all, loading code dynamically from SD and executing it would drop lots of limits. However, I am worried about two things: RAM and performance. The interpreter would need some RAM that would not be available to the program. And interpreting code will take quite some extra cycles. The more since data needs to be loaded from SD continuously. Having played a bit with the tinyduino, I think using an interpreter would be fine for plenty of applications but games that require every CPU cycle to achieve 20fps+ in native code would probably not run at reasonable speed when executed partially via interpreter.

I still think that an interpreter would be cool for various things and I am intrigued of it. But I am afraid that it might turn out to be not usable for most games. With the render API I wrote where you can issue draw commands to draw textures / rectangles or circles, you could certainly make a simple game such as pong and maybe asteroids with interpreted code... but anything more complex would be quite difficult if not impossible.
Another reason why I'd prefer flashing is that loading textures from SD and blitting them to the tinyscreen is probably quite slow as well in itself.

I'd be interested to know if you see any problems with my considerations!

TinyDuino Processors & TinyShields / Loading programs from SD
« on: April 27, 2015, 04:39:51 AM »
I have recently ordered a SD card reader - I have a vague idea of what I want to achieve and I wonder if anyone could contribute expertise or is interested in the result of this project.

The idea is to make the TinyDuino Game kit an actual complete portable gaming console. One on which you can chose and play several games without connecting it with a computer, simply by loading a game from SD.

As far as my knowledge goes, it is possible to define a bootloader function and make it rewrite the flash memory with any content. So I guess it should be possible to load data from SD, store it in memory, write it to flash, repeat until the program is loaded and then reset via software and let it restart.
The loaded program would contain the game as well as the code to load other games to repeat the entire process. I guess that such logic would consume 4-12kb of memory. However, games could consist then of several programs that get loaded when needed, e.g. a program where you play on a world map vs. a jump and run program to play a specific level.  Communication between program parts would happen then via EEPROM stored values. Saving a gamestate would be done by writing to the SD card.

Any thoughts or considerations about all this? Any reason why it would not work? Interest in having such a system?

Pages: 1 2 3
SMF spam blocked by CleanTalk