A 16 x 16 pixel tile consumes one page of RAM. 256 bytes at full color.
On a VGA, that's 64 colors. On a TV, that's more like 80-120 or so, depending on how brave you are, and your display tolerance. 90 colors for sure.
You can get 64 of those tiles into 8K of RAM, for example. At 320 pixels, that's a nice set of colorful tiles. 320 pixels can absolutely happen. Edit: 32 of these. Somewhere, my math broke down.
Is that useful? Would you guys actually build GUI type stuff with that kind of driver? Nobody asked before. I can do it for TV, easy. With some creative tile management in the VBLANK, a mouse can move over it too. Just need 4 tiles to buffer the mouse, and combine it with the other on-screen tiles.
That's a 20 x 12 tile display, BTW. Enough to do something?
re "Would you guys actually build GUI type stuff with that kind of driver?"
Yes, and I think it would look really cool.
I think the secret to this might be to use Catalina with external memory, and hence free up pretty much all the hub ram (all but the top 2k, which is used for a stack and intercog comms).
So say you had some simple C code that grabbed a little bitmap, put it in a tile and put the tile on the screen. Have maybe ten tiles on the screen, and the rest of the screen is black. You could move through a menu of choices very quickly. Menus might run other programs, eg KyeDOS can load binaries so you could start off with the pretty GUI, but run boring old text wordstar from that. Or keep it purely GUI. Many choices.
Attached - lorikeet shrunk down to 64x64 pixels and 64 colors. On a black screen, this is 8k of data so you could fit a few of these into hub ram at any one time.
Is that useful? Would you guys actually build GUI type stuff with that kind of driver?
Well sure! Just having Ok and Cancel buttons with 3D look/feel would be great. Couldn't stop there though. What about a 3D border and corners for window frames? I imagine much more is possible.
I can do it for TV, easy. With some creative tile management in the VBLANK, a mouse can move over it too. Just need 4 tiles to buffer the mouse, and combine it with the other on-screen tiles.
That would be like a big cream filled doughnut. Hard to resist.
Even 4 of those 256 byte 64 color tiles rendered all at once would be great for buttons.
How would a user provide pointers and x/y offsets for "button buffers" ?
How many longs would be left in the TV and/or VGA COG?
*just booted into XP. All my Prop dev stuff is there. Can't make my killer video capture work on Windows 7 yet, and it's annoying as all get out.
I'll see where I get to. Bottom line is some older potatotext code, that is still single COG would work great for this.
Memory map would have to be:
screen = 20x12 bytes, used as indexes to the tile map
tile map = 1 page / tile, for as many as the user chooses to fit, or end of HUB RAM is reached. ($FF / tile)
1 other page to deal with parameters and such.
The rest is up to the user. If the mouse is needed, 4 tiles would have to be reserved as the "redraw buffer", and some code space for the tile swap logic needed. In full color, it's possible to just copy the tiles, draw the mouse over them, then assign those screen coordinates to the buffer tiles. That would happen anytime the mouse moves. I've seen that done on older character display computers. Never done it myself, but that can't be hard.
I'm going to see about just getting the tile display working on TV, and see what you guys do with it. If it's worth it, then ports can be done. Can't promise any more than that right now.
About half the screen, max, could be filled with unique tiles, if the RAM isn't doing much else.
Ok, lets put it on another thread. 64 color tiles in vga or tv or both.
And yes potatohead you are right, 64x64 is 4096 bytes. I was looking at the filesize on paintshop. Use catalina with 30k of space, and we could put 8 of those on a screen. More if you use less colors or do clever things like a tile that is a corner and a tile that is a line.
This would make a cool demo, especially if it came with a skeleton code to step through menus and do things.
Well, I'll start a thread as soon as the basic driver is done. Got a nice start on modding potatotext to do tiles this evening.
320 pixels @ 80Mhz, full color = no problem. Target is 16x8 pixel tiles, on a 20x24 grid, BTW. That appeared to be the best balance for all elements in this case. Good screen coverage, moderate density, resolution.
TV cog is done, tile cog in progress, other cogs possible, and I'll comment stuff so that can be done.
(got my Smile kicked on PAL, and life got in the way too If this sees use, maybe I can get some hints, or help from somebody here to try that again, so it's NTSC for now, sorry)
The attached image will fit into hub ram because most of it is black. 64 colors. If each button brought up sub menus you could do some clever things. I'm thinking of something like kyedos behind the scenes that can load binary files when you click an icon.
With the palatte loaded into paint shop, it is easy to create icons. You could save them as binary files, or text files with numbers 0-63. And it ought to be possible to load them from an sd card as needed.
Second icon is a true 64x64 icon.
If your tiles are 16x8 then maybe make icons 64x64?
But the number contained in variable gets decoded from the internal ROM.
Do i need to make some kinda code to look up the number inside my variable in the internal ROM, and return that?
Theres gotta be a simpler way. I have been out of coding in spin-ning for a while now.
You are passing variable incorrectly. The string function thinks that variable is an ASCII code and is printing out the character that most approximates it.
You need to use the ToStr method of the Numbers object. Numbers is included with the Prop development tool. Once you have it turned into a string, you can display it as a number on the screen.
You are passing variable incorrectly. The string function thinks that variable is an ASCII code and is printing out the character that most approximates it.
You need to use the ToStr method of the Numbers object. Numbers is included with the Prop development tool. Once you have it turned into a string, you can display it as a number on the screen.
Then then the number does need to be converted. Thanks for the numbers object suggestion. I have used the numbers object before, but its been a while I have done anything in spin.
Comments
On a VGA, that's 64 colors. On a TV, that's more like 80-120 or so, depending on how brave you are, and your display tolerance. 90 colors for sure.
You can get 64 of those tiles into 8K of RAM, for example. At 320 pixels, that's a nice set of colorful tiles. 320 pixels can absolutely happen. Edit: 32 of these. Somewhere, my math broke down.
Is that useful? Would you guys actually build GUI type stuff with that kind of driver? Nobody asked before. I can do it for TV, easy. With some creative tile management in the VBLANK, a mouse can move over it too. Just need 4 tiles to buffer the mouse, and combine it with the other on-screen tiles.
That's a 20 x 12 tile display, BTW. Enough to do something?
re "Would you guys actually build GUI type stuff with that kind of driver?"
Yes, and I think it would look really cool.
I think the secret to this might be to use Catalina with external memory, and hence free up pretty much all the hub ram (all but the top 2k, which is used for a stack and intercog comms).
So say you had some simple C code that grabbed a little bitmap, put it in a tile and put the tile on the screen. Have maybe ten tiles on the screen, and the rest of the screen is black. You could move through a menu of choices very quickly. Menus might run other programs, eg KyeDOS can load binaries so you could start off with the pretty GUI, but run boring old text wordstar from that. Or keep it purely GUI. Many choices.
Attached - lorikeet shrunk down to 64x64 pixels and 64 colors. On a black screen, this is 8k of data so you could fit a few of these into hub ram at any one time.
That would be like a big cream filled doughnut. Hard to resist.
Even 4 of those 256 byte 64 color tiles rendered all at once would be great for buttons.
How would a user provide pointers and x/y offsets for "button buffers" ?
How many longs would be left in the TV and/or VGA COG?
I'll see where I get to. Bottom line is some older potatotext code, that is still single COG would work great for this.
Memory map would have to be:
screen = 20x12 bytes, used as indexes to the tile map
tile map = 1 page / tile, for as many as the user chooses to fit, or end of HUB RAM is reached. ($FF / tile)
1 other page to deal with parameters and such.
The rest is up to the user. If the mouse is needed, 4 tiles would have to be reserved as the "redraw buffer", and some code space for the tile swap logic needed. In full color, it's possible to just copy the tiles, draw the mouse over them, then assign those screen coordinates to the buffer tiles. That would happen anytime the mouse moves. I've seen that done on older character display computers. Never done it myself, but that can't be hard.
I'm going to see about just getting the tile display working on TV, and see what you guys do with it. If it's worth it, then ports can be done. Can't promise any more than that right now.
About half the screen, max, could be filled with unique tiles, if the RAM isn't doing much else.
And yes potatohead you are right, 64x64 is 4096 bytes. I was looking at the filesize on paintshop. Use catalina with 30k of space, and we could put 8 of those on a screen. More if you use less colors or do clever things like a tile that is a corner and a tile that is a line.
This would make a cool demo, especially if it came with a skeleton code to step through menus and do things.
320 pixels @ 80Mhz, full color = no problem. Target is 16x8 pixel tiles, on a 20x24 grid, BTW. That appeared to be the best balance for all elements in this case. Good screen coverage, moderate density, resolution.
TV cog is done, tile cog in progress, other cogs possible, and I'll comment stuff so that can be done.
(got my Smile kicked on PAL, and life got in the way too If this sees use, maybe I can get some hints, or help from somebody here to try that again, so it's NTSC for now, sorry)
The attached image will fit into hub ram because most of it is black. 64 colors. If each button brought up sub menus you could do some clever things. I'm thinking of something like kyedos behind the scenes that can load binary files when you click an icon.
With the palatte loaded into paint shop, it is easy to create icons. You could save them as binary files, or text files with numbers 0-63. And it ought to be possible to load them from an sd card as needed.
Second icon is a true 64x64 icon.
If your tiles are 16x8 then maybe make icons 64x64?
i tried
tmp.displayString(string("Value:", variable), tmp#red, tmp#black, 2, 2)But the number contained in variable gets decoded from the internal ROM.Do i need to make some kinda code to look up the number inside my variable in the internal ROM, and return that?
Theres gotta be a simpler way. I have been out of coding in spin-ning for a while now.
You are passing variable incorrectly. The string function thinks that variable is an ASCII code and is printing out the character that most approximates it.
You need to use the ToStr method of the Numbers object. Numbers is included with the Prop development tool. Once you have it turned into a string, you can display it as a number on the screen.
Then then the number does need to be converted. Thanks for the numbers object suggestion. I have used the numbers object before, but its been a while I have done anything in spin.
Speaking of zombies...