Uzebox & SRAM
-
- Posts: 23
- Joined: Wed Jan 09, 2013 5:16 pm
Re: Uzebox & SRAM
You just enter the desired FRQ in your order notes, and it comes ready to use...
http://www.digikey.ca/scripts/dksearch/ ... PV183=6106
If you get into needing many, these can be programmed via SPI or IC2 as well.
Brad
http://www.digikey.ca/scripts/dksearch/ ... PV183=6106
If you get into needing many, these can be programmed via SPI or IC2 as well.
Brad
Re: Uzebox & SRAM
Nice to hear that something might be feasible
Look forward to any updates on this front.
Wish i knew more on the hardware side of things like you guys / gals, I'm an average skilled software only man myself and greatly admire what you have all achieved
If I ever win the Lotto I'm gonna throw a big wedge of $$$ your way to design and build my dream 8-bit retro themed computer
Cheers
Roukan / Jim
Look forward to any updates on this front.
Wish i knew more on the hardware side of things like you guys / gals, I'm an average skilled software only man myself and greatly admire what you have all achieved
If I ever win the Lotto I'm gonna throw a big wedge of $$$ your way to design and build my dream 8-bit retro themed computer
Cheers
Roukan / Jim
-
- Posts: 23
- Joined: Wed Jan 09, 2013 5:16 pm
Re: Uzebox & SRAM
Thanks, it's all about late nights and being stubborn!Roukan wrote:Nice to hear that something might be feasible
Look forward to any updates on this front.
Wish i knew more on the hardware side of things like you guys / gals, I'm an average skilled software only man myself and greatly admire what you have all achieved
If I ever win the Lotto I'm gonna throw a big wedge of $$$ your way to design and build my dream 8-bit retro themed computer
Cheers
Roukan / Jim
Once you dig in, it doesn't take long to get into the hardware end of things.
Your UZEBox is a great learning platform, since you get to talk with the hardware. I found this to be the opposite with the recent Arduino fad though, it seems to be isolating people from the hardware, which in some cases may be ok.
Ah yes...$$$ that's pretty much all it would take to develop just about anything! No doubt Alec has a dozen interesting video projects on the bench as well, but the time and $$$ to get them out there is huge. I did a super powered AVR retro system using an FPGA that would be fairly inexpensive and very easy to program, but alas... that initial 100 boards is a huge inventory to cover when you are just starting out. I hope to release my XMega Vixen project as well soon, but even that simple board is going to cost me $45 each to make 100. If it takes 6 months to sell them, that is a lot to carry. And the support... I would be into every thread answering every question, just like Alec, so this takes time away from work.
Being in Canada makes things even worse. I sell parts for my recumbent bike plans as well, and on some parts I have to take a loss, as shipping to the US (largest client base) is crazy expensive from here.
There are so many things to consider after making a new product, that most of my ideas remain on the bench.
But if you do win that jackpot, I graciously accept your funding offer, and will name my next system "The Roukan Station"!
Brad
- DaveyPocket
- Posts: 378
- Joined: Sun Sep 14, 2008 8:33 pm
- Contact:
Re: Uzebox & SRAM
Maybe with that 16k RAM there would be room for a....
FRAME BUFFER
Or something like that... haha
FRAME BUFFER
Or something like that... haha
Re: Uzebox & SRAM
Dare to discuss the specs or what you had in mind? Interestingly, the uzebox is in fact a fork of an earlier retro computer I started back 10 years ago!If I ever win the Lotto I'm gonna throw a big wedge of $$$ your way to design and build my dream 8-bit retro themed computer
Re: Uzebox & SRAM
Hope your asking because you have a crystal ball/time machine and have foreseen my Lotto winuze6666 wrote:Dare to discuss the specs or what you had in mind? Interestingly, the uzebox is in fact a fork of an earlier retro computer I started back 10 years ago!If I ever win the Lotto I'm gonna throw a big wedge of $$$ your way to design and build my dream 8-bit retro themed computer
On a more serious note where do I begin:
Perhaps best to list what I would really like to see ignoring any thought I might have that it may not be feasible and leave you to push/laugh it off the table.
I will list minimums - eg: 16 colours (obviously more the merrier).
Video:
a) 256 x 192 screen resolution (4:3)
b) 16 colours - separate palette for sprites would be nice.
c) Custom colour palette from RGB pool.
d) Tile mode 8x8 / 16x16 (maybe other variations) - H/V mirror flag
e) Bit mapped mode.
f) Text mode with Attributes similar to ZX Spectrum.
g) Sprites 8x8 /16x16 - H/V Mirror flag - magnify flag - background priority flag (can pass in-front or behind background)
h) Screen scrolling
Audio:
Not much to add here ATM - the Uzebox sound is great - so i shall move on.
Storage:
Again not much to say here as SD card support seems fine.
Memory: (All mentioned here is with an Atmel AVR MCU in mind - as I know nothing of other MCU/CPU and very little about Atmel AVR.)
a) 32k SRAM - I have put this as a minimum it would take 24k to do a 256 x 192 16 colour mode @ 2 pixels per byte - Usaage ala Uzebox.
b) 128k Flash - Not sure what options are available - Usage ala Uzebox - would be nice to have it split between Flashed Kernel / Interpreter / Game - choice at boot
c) 4k EEPROM - as above - Usage ala Uzebox - though maybe game saves could also be stored on SD card.
d) 32k Ext RAM - This would be utilized to store source code to be executed a by Flashed Language interpreter like Forth / Basic.
I/O Support:
a) SNES game pads like Uzebox
b) USB keyboard
c) USB Mouse
d) MIDI Interface
e) Video Out - At end of day whatever would give the best picture quality.
f) Ethernet / LAN port
Programming the beast - Two possible scenario's here spring to mind:
a) As one does now for Uzebox - cross dev on PC/Mac/Linux with GCC writing games / new language interpreters etc.
b) On the Uzebox computer with Flashed language interpreter running - allowing edit - save/load - execution of source code.
Something for you to digest as a starting point
Cheers
Roukan / Jim
-
- Posts: 23
- Joined: Wed Jan 09, 2013 5:16 pm
Re: Uzebox & SRAM
I think you will like what I have sitting beside me right now!...
3 Chip game system (Xmega, 512K SRAM, 1 Logic Gate).
256x200 resolution with 256 colors. Composite output.
384K program memory with 32K internal SRAM!
Auto back buffer, with 8 extra pages of video memory.
4 channel stereo sound much like the Amiga.
Unrestricted sprites of any size with colors of 256 or 16.
Easy to program in GCC, no need to worry about timing or interrupts.
Insane 60 MIPs operations.
Can adapt to any joystick.
Can easily play Wolfenstein 3D!
If you don't mind dropping down a 64 pin IC, I will be detailing this as a complete DIY soon.
Not sure if I can afford to make boards, but will see where it goes.
Here is a video of my initial version running, and it has only a single IC... one XMega384...
http://avrcade.com
Due to the limits of the internal SRAM (only 32K), I managed a dual buffer od 150x100 resolution, but this was just a test for the ability of XMega to generate full NTSC on the fly.
Source code and full tutorials will be coming soon, and I hope that it spawns an XMega UZEBox!
I think XMega is the magic bullet for keeping to the original UZEBox theme... minimalist, 8 bit, inexpensive, powerful, and most of all... FUN!
SO perhaps you can keep your lottery winnings and expect something really cool to come from all of these new developments. There must be 10 or more people working on XMega AV systems now, so the blending of new ideas will no doubt create something special.
Brad
3 Chip game system (Xmega, 512K SRAM, 1 Logic Gate).
256x200 resolution with 256 colors. Composite output.
384K program memory with 32K internal SRAM!
Auto back buffer, with 8 extra pages of video memory.
4 channel stereo sound much like the Amiga.
Unrestricted sprites of any size with colors of 256 or 16.
Easy to program in GCC, no need to worry about timing or interrupts.
Insane 60 MIPs operations.
Can adapt to any joystick.
Can easily play Wolfenstein 3D!
If you don't mind dropping down a 64 pin IC, I will be detailing this as a complete DIY soon.
Not sure if I can afford to make boards, but will see where it goes.
Here is a video of my initial version running, and it has only a single IC... one XMega384...
http://avrcade.com
Due to the limits of the internal SRAM (only 32K), I managed a dual buffer od 150x100 resolution, but this was just a test for the ability of XMega to generate full NTSC on the fly.
Source code and full tutorials will be coming soon, and I hope that it spawns an XMega UZEBox!
I think XMega is the magic bullet for keeping to the original UZEBox theme... minimalist, 8 bit, inexpensive, powerful, and most of all... FUN!
SO perhaps you can keep your lottery winnings and expect something really cool to come from all of these new developments. There must be 10 or more people working on XMega AV systems now, so the blending of new ideas will no doubt create something special.
Brad
Re: Uzebox & SRAM
Hi Brad
Thanks for the reply.
While I was at it I ended reading/watching your Lazarus-64 project diary - again excellent stuff - a great read.
You mention 512k SRAM - I take it this must be external and is fast enough to be utilized as part of the VRAM process in some way?
Keep up the great work you have going here - looking forward to see where this project goes/pans out
Cheers
Roukan / Jim
Thanks for the reply.
I watched the video and it blew me away, especially the big balls with the fire effect background - mightily impressive.AtomicZombie wrote:I think you will like what I have sitting beside me right now!...
Here is a video of my initial version running, and it has only a single IC... one XMega384...
http://avrcade.com
While I was at it I ended reading/watching your Lazarus-64 project diary - again excellent stuff - a great read.
AtomicZombie wrote:3 Chip game system (Xmega, 512K SRAM, 1 Logic Gate)
The performance of these Atmel AVR's is amazing for an 8-bit MCU.AtomicZombie wrote:Auto back buffer, with 8 extra pages of video memory
You mention 512k SRAM - I take it this must be external and is fast enough to be utilized as part of the VRAM process in some way?
Lovely stuff - Will this work/display on European PAL TV's?AtomicZombie wrote:256x200 resolution with 256 colors. Composite output.
That's a wonderful amount of storage for code.AtomicZombie wrote:384K program memory with 32K internal SRAM!Brad
Talking Amiga - do you plan to support MOD/Tracker on this side of things?AtomicZombie wrote:4 channel stereo sound much like the Amiga.
Tony Montana would of been very impressed by the balls in your demo - What (if any) additional attributes might the sprites support?AtomicZombie wrote:Unrestricted sprites of any size with colors of 256 or 16.
That's what I like to hear - As I only started programming with GCC a couple month or so ago - so i'm still a novice.AtomicZombie wrote:Easy to program in GCC, no need to worry about timing or interrupts.
Again - the performance of these MCU's is crazy stuff to me.AtomicZombie wrote:Insane 60 MIPs operations.Brad
Any plans for Keyboard / Mouse?AtomicZombie wrote:Can adapt to any joystick.Brad
Can't beat that feeling of being knee deep in the deadAtomicZombie wrote:Can easily play Wolfenstein 3D!
I can't solder to save my life - there's a story in a thread somewhere here on the forums as to why - Harty kindly supplied me with a ready built Uzebox - but like you say "will see where it goes".AtomicZombie wrote:If you don't mind dropping down a 64 pin IC, I will be detailing this as a complete DIY soon.
Not sure if I can afford to make boards, but will see where it goes.
Well I'd have to win it first to keep em.AtomicZombie wrote:Source code and full tutorials will be coming soon, and I hope that it spawns an XMega UZEBox!
I think XMega is the magic bullet for keeping to the original UZEBox theme... minimalist, 8 bit, inexpensive, powerful, and most of all... FUN!
Do you intend to support SD as a storage medium like the Uzebox?
AtomicZombie wrote:SO perhaps you can keep your lottery winnings and expect something really cool to come from all of these new developments. There must be 10 or more people working on XMega AV systems now, so the blending of new ideas will no doubt create something special.
Keep up the great work you have going here - looking forward to see where this project goes/pans out
Cheers
Roukan / Jim
-
- Posts: 23
- Joined: Wed Jan 09, 2013 5:16 pm
Re: Uzebox & SRAM
Hey thanks, I hate watching TV, so I build video stuff instead!Roukan wrote: While I was at it I ended reading/watching your Lazarus-64 project diary - again excellent stuff - a great read.
Yes this is an external 512K single IC SRAM, and it is fully used as the video memory. There are 2 "video pages", and they are swapped when you are done issuing drawing and graphics commands. One pages is always being displayed while the other is free to use. This is called double buffering and provides seamless, glitch free scrolling and frame rate. There are 8 other "scratch pages" that can be used to decompress or draw really complex images in code that are then blasted out out to the back buffer. I made all of my routines do this automatically so they are very simple to use. DrawSprite(x,y,"BigBall"); for instance.Roukan wrote: You mention 512k SRAM - I take it this must be external and is fast enough to be utilized as part of the VRAM process in some way?
Unfortunately, no. I don't have a PAL set to mess with, and there is no way I will ever be able to afford shipping parts out of North America. Of course, if someone with the know-how wants to build a system based on my design and modify the code, then that will be great, and I will put up the PAL core as well.Roukan wrote: Lovely stuff - Will this work/display on European PAL TV's?
Oh yeah, you can have full screen images, long samples, tons of sprites, and almost endless program code!Roukan wrote: That's a wonderful amount of storage for code.
I wrote a converter (PC Windows) that takes bitmaps and Wave files, then saves them as paste ready GCC files, but I have not considered any MOD stuff. MasterBug has done some work there and by looking at his demos, he seems to have done an amazing job. I bet our sound file format is exactly the same as well, so his .inc files will probably work in my system directly. 8 bit unsigned data sent to PWM.Roukan wrote: Talking Amiga - do you plan to support MOD/Tracker on this side of things?
I know what choo mean mang! My sprites have auto transparency as pixel value 0, and the 16 color versions can be shifted to any of the other 16 hues. So a 16 color shaded ball can be 16 other shaded colors. Sprites can also be 256 colors. These are not "sprites" in the sense of the UzeBox though, they are mainly chunks of image data. So they are any size and in any number. The ones you draw first are on the topmost layer. There are no limits to layers. Actually, think if it as being Photoshop layers with an alpha channel!Roukan wrote: Tony Montana would of been very impressed by the balls in your demo - What (if any) additional attributes might the sprites support?
Me too. I dug into GCC around March2012, and before that I was pure assembly. I like being bale to write optimized assembly, but then call routines in C to take care of the hairy 16 or 32 bit math. It's a great fusion!Roukan wrote: That's what I like to hear - As I only started programming with GCC a couple month or so ago - so i'm still a novice.
My system will have a built in joystick with 2 fire buttons only. I like to keep it simple. I have been trying to find a way to purchase SNES controllers and then retro fit my board inside, but this requires a retooling of the base and a bulk order. I don't have enough spare dabloons to warrant such a thing at this time.Roukan wrote: Any plans for Keyboard / Mouse?
"Come git some!"Roukan wrote: Can't beat that feeling of being knee deep in the dead
Ahh... not yet anyhow, but after a few hundred more solder bridges, you will get there!Roukan wrote: I can't solder to save my life - there's a story in a thread somewhere here on the forums as to why - Harty kindly supplied me with a ready built Uzebox - but like you say "will see where it goes".
I am using 44 pins on the XMega, but left the SPI pins open just in case. I am not sure on this one really. It's would be coold to be able to yank images from SD, but then you have to shut down your video engine to run the FAT/SD code (I think). I would need some help making the SD/FAT stuff work, but perhaps it would be a cool addition. I can see it being used to "change" game screens and load all new sound and graphics or something like that. I tried to get my mellon around the Chan FFS code, but I ended up all night with nothing to show. Still a lot to learn with C being a new language to me.Roukan wrote: Do you intend to support SD as a storage medium like the Uzebox?
Thanks again, it's an obsession, but I am going to get this thing done and put it out there. If it even sparks one new project, I will be happy.Roukan wrote: Keep up the great work you have going here - looking forward to see where this project goes/pans out
Brad
Re: Uzebox & SRAM
My .MOD play routine read the .MOD directly. So all sounds are inside the .MOD. I have made a VB software that get the .MOD file and export it as a big ARRAY[ ]. That it. My player support only a few function, but enough to do all that you want. It support instrument LOOP and volume for each channel. You can also start sounds events on the channel of your choice for in game sound effect. The sounds must be in the .MOD too.Roukan wrote: Talking Amiga - do you plan to support MOD/Tracker on this side of things?
I wrote a converter (PC Windows) that takes bitmaps and Wave files, then saves them as paste ready GCC files, but I have not considered any MOD stuff. MasterBug has done some work there and by looking at his demos, he seems to have done an amazing job. I bet our sound file format is exactly the same as well, so his .inc files will probably work in my system directly. 8 bit unsigned data sent to PWM.
If you want to include it in your console, I think it can be done. Let me know if you are interested.
I compose music with the free tracker, milkytracker.
Mine too. I use internal RAM to backup Zone and restore. I use malloc for that purpore. Are you using malloc() too?Roukan wrote: Tony Montana would of been very impressed by the balls in your demo - What (if any) additional attributes might the sprites support?
I know what choo mean mang! My sprites have auto transparency as pixel value 0, and the 16 color versions can be shifted to any of the other 16 hues. So a 16 color shaded ball can be 16 other shaded colors. Sprites can also be 256 colors. These are not "sprites" in the sense of the UzeBox though, they are mainly chunks of image data. So they are any size and in any number. The ones you draw first are on the topmost layer. There are no limits to layers. Actually, think if it as being Photoshop layers with an alpha channel!
Same for me. I learnt C programming at school, programmed a little on PC but not since the last 6-7 years. I started to code C on Atmega 4 month ago only. Before that, I was a pure ASM coder too.Roukan wrote: That's what I like to hear - As I only started programming with GCC a couple month or so ago - so i'm still a novice.
Me too. I dug into GCC around March2012, and before that I was pure assembly. I like being bale to write optimized assembly, but then call routines in C to take care of the hairy 16 or 32 bit math. It's a great fusion!
You don't need to stop the interrupt to read the SD card. you can even read it in the main code, no need to be in the video interrupt. UZE have made a short video playback on the UZEBOX, playing a movie with sound in realtime. Nice to see (you can see it on youtube).Roukan wrote: Do you intend to support SD as a storage medium like the Uzebox?
I am using 44 pins on the XMega, but left the SPI pins open just in case. I am not sure on this one really. It's would be coold to be able to yank images from SD, but then you have to shut down your video engine to run the FAT/SD code (I think). I would need some help making the SD/FAT stuff work, but perhaps it would be a cool addition. I can see it being used to "change" game screens and load all new sound and graphics or something like that. I tried to get my mellon around the Chan FFS code, but I ended up all night with nothing to show. Still a lot to learn with C being a new language to me.
I have a working code in ASM (that I written from scratch with the FAT documentation), for a complete FAT16 system that respect the Sector steps and the true rules of FAT system (I.E. no need to have the file stored sequentially, it will step to the right cluster). I think this can be integrated as an include file C Callable in only a few hours of works.
You also mentioned 3D stuff, I already have a 3D routine written in ASM highly optimized and compatible with 3D studio max meches file.(But the backface culling is not working) It works really fine. I never tried it on a video console, only on my virtual clock: Link here:
Mast3rbug