Complete Gaming Interface (Open Source)
blittled
Posts: 681
I got involved with the tinyclr's Gameo project, which now appears to be dead. That plus Microcontroller's Graphic Slave got me thinking of doing an open source project where the Propeller does all the video and sound. With many other micro-controller forums some of the hot topics are video and sound so I see a possible need for this. I envisioned it as this:
Phase one:
Development of the video tile engine. This would be NTSC/PAL output and can be set to variable resolution and variable tile sizes. It would also have sprites and page flipping. The sound engine would be a multichannel square wave generator with programmable frequency, attack and decay. The interface to the Propeller would either be SPI or serial.
Phase two:
Create tools to generate pallets, tile bitmaps and mapping layouts so tiles can be visualized as a complete screen. Also there would be a tool to control each of the sound channels. These tools would be cross platform.
Phase three:
Generate libraries for Basic Stamp, PIC, Arduino, and C to use the Propeller.
Everything would be open source. it is my hope if this is posted in some of the other micro-controller forums that it would generate an interest in the Propeller. In making it all open source it makes it more enticing since it wouldn't need a commitment in money. Also it would let the curious and creative to delve into the code and get more involved with the Propeller.
Now before undertaking this ambitious project I wanted to see if others think this is viable and what objects available would help in this endeavor. I don't have alot of Spin and PASM experience but as a programmer by profession I feel I am capable of coding or modifying the objects needed.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Will work for Propeller parts!
Phase one:
Development of the video tile engine. This would be NTSC/PAL output and can be set to variable resolution and variable tile sizes. It would also have sprites and page flipping. The sound engine would be a multichannel square wave generator with programmable frequency, attack and decay. The interface to the Propeller would either be SPI or serial.
Phase two:
Create tools to generate pallets, tile bitmaps and mapping layouts so tiles can be visualized as a complete screen. Also there would be a tool to control each of the sound channels. These tools would be cross platform.
Phase three:
Generate libraries for Basic Stamp, PIC, Arduino, and C to use the Propeller.
Everything would be open source. it is my hope if this is posted in some of the other micro-controller forums that it would generate an interest in the Propeller. In making it all open source it makes it more enticing since it wouldn't need a commitment in money. Also it would let the curious and creative to delve into the code and get more involved with the Propeller.
Now before undertaking this ambitious project I wanted to see if others think this is viable and what objects available would help in this endeavor. I don't have alot of Spin and PASM experience but as a programmer by profession I feel I am capable of coding or modifying the objects needed.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Will work for Propeller parts!
Comments
It would be a good place to start since the Hydra is a Propeller based video game system.
From there, build some render cogs that do tiles and sprites, feeding them to that core TV cog. That's how most of the better drivers are done.
One COG can read from the video memory and do the signal, and even sneak in some simple controller IO, but the trade off is the inability to fold in sprites and such at full color. If the color space is limited, that can be done, but nobody really wants a 4 color / tile / page / scan line limitation.
I've got most of the video signal options modeled in the text driver you will find in my signature. That's the template adapted to draw from a scan line buffer, graphics generated by another COG. That driver is running 4 color, but it doesn't have to. Could run full color, one byte per pixel, and still get most of the resolution.
In general, 4 or two color graphics can be done up to about 640 pixels on 80Mhz boards. The limitation is the waitvid frame loop. A 4 color frame can do 16 pixels at a time, and that's how most of the tile drivers are done. No independent color sprites on that though.
If one runs the waitvid backwards, using the colors as pixels, the frame is 4 pixels, instead of something larger. The loop needs to be tighter and that takes the resolution down some, but it's still possible to exceed 320 pixels that way. The tips are in Andre's book, and in the code from some of the games posted. The trick is "waitvid colors, #%%3210" where the pixels are always the same color value, and the "colors" then become pixels as they are all assignable each frame!
The nice thing about building in good signal options is the resulting graphics driver can be used on a lot of displays for a great signal look. A lot of what makes colors "pop" has to do with how the signal is generated, just FYI.
If the sprite engine is coded to work from a simple 256x96 bitmap, or maybe a 256x64, then existing tools can be used to build up tiles and sprites. It's all about keeping a consistent size, and using simple linear indexes to the data generated. Include this file as a binary in the DAT section of a Propeller program, or feed it to a propeller waiting for it serially, for the best, simplest tool path. A user running paint could do sprites that way.
That's demonstrated in the VCS like projects located in the HYDRA forum.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Propeller Wiki: Share the coolness!
8x8 color 80 Column NTSC Text Object
Wondering how to set tile colors in the graphics_demo.spin?
Safety Tip: Life is as good as YOU think it is!
Gameo may be dead, but PropCade is alive and well [noparse]:)[/noparse]
I am currently finishing debugging the second prototype of PropCade, however I expect to have boards and full kits available for sale by the end of August.
You can find the PropCade feature list and discussion in this thread: http://forums.parallax.com/showthread.php?p=894725
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
www.mikronauts.com E-mail: mikronauts _at_ gmail _dot_ com
My products: Morpheus / Mem+ / PropCade / FlexMem / VMCOG / Propteus / Proteus / SerPlug
and 6.250MHz Crystals to run Propellers at 100MHz & 5.0" OEM TFT VGA LCD modules
Las - Large model assembler Largos - upcoming nano operating system
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Propeller Pages: Propeller JVM
My guess would have been that there are too many projects pulling in different directions at the same time..
... also there's the vaporware factor that has plagued a few projects like Gameo
At this moment (to the best of memory) we have the following gaming platforms...
The Hydra -:- A current product of Parallax which follows a few standards of it's own due to it's being first.
El Jugador -:- A current product of Gadget Gangster which follows most of the "demoboard" standards.
SpinStudio Game Stacker -:- A current project of uController.com which follows most of the "demoboard" standards.
The C3 -:- A yet to be released project by Parallax/Andre which will follow most of the "demoboard" standards and introduce some new memory configurations as well. Thankfully Open Source which will allow others to climb aboard the new ideas with C3 compatible products.
Gameo -:- Now dead?
PropArcade -:- A yet to be released product which will follow some "demoboard" standards as well as introduce some new memory configurations as well.
PropGFX -:- An add-on video system to be released? which will provide some new standards for video output for easy game creation. Currently halted by an inability to protect the code and personal work issues in the lives of it's creators.
We're pulling in 7 or 8 different directions at once.. Nothing will be accomplished largely because of this.
I know it's a little like asking 40 people to agree on what to have for lunch, but unless we find a couple released standards to pull behind, preferably open sourced we are going to continue to spin (no pun intended) our wheels here.
Take a good look at Uzebox project. Everyone is rowing the boat pretty much in the same direction.
It's resulted in traction for the project, and they are pretty much overtaking our accomplishments.
It's time for some standards folks..
[noparse][[/noparse]/rant off]
OBC
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Propeller Feature Projects: PropellerPowered.com
Visit the: PROPELLERPOWERED SIG forum kindly hosted by Savage Circuits.
I've taken a "software" approach to this, currently there are only two of use pulling in this direction.
www.propellerpowered.com/gaming.html
OBC
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Propeller Feature Projects: PropellerPowered.com
Visit the: PROPELLERPOWERED SIG forum kindly hosted by Savage Circuits.
Other than the audio lines, PropCade (not PropArcade) is 100% DemoBoard compatible - that was one of my major design goals.
P30,P31 = Serial programming port / PropPlug compatible header
P28,P29 = I2C EEPROM
P26,P27 = PS/2 keyboard
P24,P25 = PS/2 mouse
P16-P23 = regular Parallax VGA
P12-P15 = S-VID/VID out
The only non-demo board standard part is changing the audio pins, to better allow for memory expansion.
P7-P8 = audio out <-- only change from demo board, needed as
P9-P11 is used to select memory chip, not demo board compatible
P0-P7 is available on the demo board, and is used for the other features of PropCade.
I suggest all gaming efforts allow easy changes of video/kb/audio etc pins.
I know you keep pushing for standards, but it would hold back innovation. The best way to standardize is to have a "pins.spin" object that exports constants for pin definitions, and a hardware abstraction layer - for example "joystick.spin" object with a standardized object interface, "vmcog" for different memory expansion schemes etc.
If I stuck to pure "demo board" standard, I could never have fit in (in an efficient manner) all the extra features of PropCade.
As far as your Open Source comment...
All of the mentioned boards allow anyone to write software that runs on them, and will have fully published hardware programming information - so they are as open as is needed for software; and if hardware abstraction layers are used, software could be built that runs on all of them.
Regarding the C3, I can't wait to see the actual specifications - but note that the price it will apparently be sold at is only possible because Parallax/Andre are making a run of 2500+ boards, thus getting much better pricing for PCB's, Propellers and other components than mere mortals can get - giving a HUGE competitive advantage to Andre/Parallax for the C3.
No one else could offer the C3 at what Parallax will sell it for - and I would be very surprised if they made significant profit per unit.
What we need is standardized interface objects for joysticks, sounds, etc. - NOT cast in stone hardware specs that restrict innovation.
In other news...
I *REALLY* like your standard TV gaming driver with sprites effort - I think that will definitely help advance Prop gaming!
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
www.mikronauts.com E-mail: mikronauts _at_ gmail _dot_ com
My products: Morpheus / Mem+ / PropCade / FlexMem / VMCOG / Propteus / Proteus / SerPlug
and 6.250MHz Crystals to run Propellers at 100MHz & 5.0" OEM TFT VGA LCD modules
Las - Large model assembler Largos - upcoming nano operating system
Post Edited (Bill Henning) : 7/25/2010 10:51:44 PM GMT
None of the games/objects should have any built-in assumptions about the clock frequency either... note 8x10MHz on Hydra, people using different crystals, etc. - all timing should be based on clkfreq, or a constant in "pins.spin" - which should probably be called "hal.spin" [noparse]:)[/noparse]
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
www.mikronauts.com E-mail: mikronauts _at_ gmail _dot_ com
My products: Morpheus / Mem+ / PropCade / FlexMem / VMCOG / Propteus / Proteus / SerPlug
and 6.250MHz Crystals to run Propellers at 100MHz & 5.0" OEM TFT VGA LCD modules
Las - Large model assembler Largos - upcoming nano operating system
Take clockfreq as input to establish a PLLA timing for video, based on the color burst. Every other thing in the driver is based on that. When this is done, the actual clock of the board doesn't really matter much, unless it's just not fast enough. It also means being able to change signal modes, pixel count, etc.. live, just like one would see on a graphics chip.
Allow for simple pin inputs. That's easy, and obvious.
Do calculations during the VBLANK time, process changes, updates for nice, frame locked transitions.
Use a block of memory in the HUB as "registers" to allow for modes, and do calcs in PASM, because that makes the driver:
binary blob loadable off SD card, or out of high eeprom, or any other storage really.
It also means using lots of languages and breaking video functions into loadable parts.
The only thing needed is to load up the registers, cognew, done!
That's where I'm going this next pass. With all the cool options we've got now, simple binary packages make a lot of sense. Say there's a game project that needs a simple title screen, followed by text input, followed by tile / sprite action.
Fetch high-color bitmap driver into HUB buffer, start it, then load title screen.
Kill that high color bitmap, fetch text screen, start it, load SPIN for some game action, ask player questions.
Kill that, fetch and start tile / sprite driver, etc...
Really, if one keeps the SD card software loaded and at the ready, maybe just read only, one cog, the rest can just happen as it needs to, much like it did on older systems using floppy disk and such.
...or, it makes for easier lego pieces, which is a big part of the other project success. Because that one uses a kernel that's complex, everybody is more or less jamming on that, because it's very difficult not to.
my .02
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Propeller Wiki: Share the coolness!
8x8 color 80 Column NTSC Text Object
Wondering how to set tile colors in the graphics_demo.spin?
Safety Tip: Life is as good as YOU think it is!
Post Edited (potatohead) : 7/26/2010 12:17:34 AM GMT
by George you've got it!!!!!!
I can't wait to see your new drivers [noparse]:)[/noparse]
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
www.mikronauts.com E-mail: mikronauts _at_ gmail _dot_ com
My products: Morpheus / Mem+ / PropCade / FlexMem / VMCOG / Propteus / Proteus / SerPlug
and 6.250MHz Crystals to run Propellers at 100MHz & 5.0" OEM TFT VGA LCD modules
Las - Large model assembler Largos - upcoming nano operating system
Blaming lack of standardization is just as good of an excuse as any other though [noparse]:)[/noparse]
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Propeller Pages: Propeller JVM
Yeah Bill, I do too [noparse]:)[/noparse]
Bill, I learned a lot of stuff on Potatotext. The biggie was multi-cog, and signal options [noparse]:)[/noparse] Right now, I'm stuffing the mouse into it, without adding a cog. (it will fit, it will fit, it will fit...)
The way to go forward, instead of weaving together complex things for each case, is to build a flexible TV cog. That's kind of the base cog. It can do VBLANK calcs, color cell lookups, a bitmap, and output from a scan line buffer. It's outputs would be the current state of the display, for graphics cog sync purposes, and that's about it. Maybe, depending, it could also maybe read from something really simple. Don't know. Maybe not.
From there, one either runs the base TV cog, because a bitmap is all that is needed, or runs it, sets it's mode, then runs one of any number of graphics cogs that just read the state of the TV cog, sync up, and do their thing. That's kind of how potatotext is built right now, and it just hit me the other day, how if there was a base TV cog, like the template Eric wrote, that writing graphics cogs to feed it is easier. Enter the SD card functions we've got now, binary loading, and it starts to look cool.
So, that's where I'm headed.
As for building the binary, I think I'm going to just build it with a small SPIN prototype demo program, like what happens now. Then when it works, just write out the binary for the COG as a file from within that same SPIN build program, done!
Another program written in pretty much anything then could just declare a buffer, fetch that binary, cognew, and it's all pretty easy, and works with Prop tool at the basic level. That makes for a nice test, debug environment, a place to modify that doesn't take special tools, and the end product works elsewhere with those special tools, or not, and can therefore exist in the OBEX, useful to anyone.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Propeller Wiki: Share the coolness!
8x8 color 80 Column NTSC Text Object
Wondering how to set tile colors in the graphics_demo.spin?
Safety Tip: Life is as good as YOU think it is!
Post Edited (potatohead) : 7/26/2010 1:06:23 AM GMT
Standards allow folks to move forward in one direction instead of fifteen.
OBC
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Propeller Feature Projects: PropellerPowered.com
Visit the: PROPELLERPOWERED SIG forum kindly hosted by Savage Circuits.
The other project makes use of a rather ordinary CPU. Nothing really special there. It's a good, solid chip, with specs that hit home for gaming. The library in use, that makes the games possible is kind of a forced thing, in that rolling one's own isn't going to be easy. And there are limits with that, one being the core capabilities are kind of cut in stone. On the flip side, libraries, interrupts and such are well trodden paths, meaning layers on layers of standards are in place and operating.
That tends to help solidify and focus the efforts. So the easy stuff will be pretty easy. Bet we won't see WOLF3D rendering on that thing anytime soon, and that's the difference.
A quick look at the last coupla years of stuff done on the Prop makes it very clear that the differences in the chip have really played out. Some standard stuff one would expect works! A lot of stuff doesn't, or if it does, is kind of a kludge, or that under-exploits the chip.
I think the call for some standards to focus development are a good thing, but I also think the "boot strapping" that has gone on with the Propeller is both necessary, and very beneficial. Because of that, it's also safe to say we don't have solid standards in a lot of areas yet, because we don't know the best ways, or there are enough trade-offs to make the best ways of doing things somewhat unclear at this time.
A big part of that is pushing the thing well beyond what a lot of people expected too. Can't forget that.
Edit: Another way to consider this is the other project uses a traditional CPU, traditional libraries, with some good video and sound bits all packaged as a kit. This is cool, and that combined with it all being just C, helps bring the effort along, because there is a freaking ton of C sitting around that's gonna largely work.
Getting there has been generations of CPUs, code, and such too.
We are at gen 1, building some stuff, translating some stuff, figuring a lot of stuff out. Now, take this body of work, roll most of it onto Prop II, and what happens? *BOOM*, lots! There will be a batch of translating that will leverage damn near everything done to date that matters, then a new round of figuring stuff out, and the cycle continues.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Propeller Wiki: Share the coolness!
8x8 color 80 Column NTSC Text Object
Wondering how to set tile colors in the graphics_demo.spin?
Safety Tip: Life is as good as YOU think it is!
Post Edited (potatohead) : 7/26/2010 1:59:29 AM GMT
Also, nothing is wrong with doing what you think is right for your project.
Blame can go both ways and I could have just as easily jokingly said:
Blaming adherence to standardization is just as good of an excuse as any other [noparse]:)[/noparse]
@potatohead as always sums all this up nicely.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Propeller Pages: Propeller JVM
They MUST support also PAL. I can not use most of the Hydra Games, or Potatotext, because they are NTSC only.
And don't make it first for NTSC with the option to port it later to PAL. This never happens...
Andy
As long as we use the clkfreq and some pin definitions we have the flexibility to use various boards for the task.
While essentially OT, this could be a good point in time to raise this problem again...
The pin definitions seem to be the biggest problem to releasing a binary. If you take my minimal eeprom boot code from RamBlade, all it knows about is the SD pins - it needs this to be able to load a binary from SD. The same idea can work if using the eeprom to store a binary(s).
Here is an idea for the SD version...
Now we can read the file and get the pin definitions so that a standard binary could be released which could get it's own pin assignments.
Thoughts??
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Links to other interesting threads:
· Home of the MultiBladeProps: TriBlade,·RamBlade,·SixBlade, website
· Single Board Computer:·3 Propeller ICs·and a·TriBladeProp board (ZiCog Z80 Emulator)
· Prop Tools under Development or Completed (Index)
· Emulators: CPUs Z80 etc; Micros Altair etc;· Terminals·VT100 etc; (Index) ZiCog (Z80) , MoCog (6809)·
· Prop OS: SphinxOS·, PropDos , PropCmd··· Search the Propeller forums·(uses advanced Google search)
My cruising website is: ·www.bluemagic.biz·· MultiBlade Props: www.cluso.bluemagic.biz
Jazzed: I feel OBC is right about the Gameo. I have no affiliation with tinyclr so I have no official news on Gameo. I did contact the leader of the project 3 weeks ago and he said they were taking a 2 week break on it so they could concentrate on getting their products updated to Visual Studio 2010. I went on last week only to find the logo for Gameo and the postings on their forum removed! That indicates to me the project may be at least put on hold. I haven't heard from the team leader but I know he was pushing for it to continue and their Wiki still shows it so it may not be dead yet.
Potatohead: I definitely like the direction your TV driver is going and would like to include it iin the project. I had similar ideas but do not have the video experience you have. I have been trying some of the other drivers and haven't been happy with the limitations of some of them have.
I agree that it should be standardized. Maybe this could be a community effort rather than one person. This may cause some issues since each of us has our own ideas of what would be standardized but a discussion via the forum could iron out some of the issues.
Like I mentioned I have been on other forums where people mention that they wish their micro-processor had video capabilities. In fact the Arduino forum mentioned the Propeller as a solution and that generated mixed comments.
What I would like to see is a project somewhat like the Arduino is structured. Open source, a team of people overseeing the standards and possibly a hardware platform that people could copy. In this age of Iphones video is almost a must in development. The Propeller can fill this niche and it would be a way to get developers and hobbyists of other micro-controller excited about the Propeller.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Will work for Propeller parts!
In my case, I'm looking back at when I first got a Prop. Had the stuff from Parallax to work with, some groovy code and advice from Baggers, and the stuff off the HYDRA CD.
No SD card. No advanced SPIN tricks. No real standards on pins, communication between COGs, not that many objects even.
Those first drivers were woven together by Chip, and some of the HYDRA demo pioneers. They are complex, but in some cases, like the Parallax driver, very useful in a broad range of cases. So many things were not done then. HUB memory was gobbled up with buffers, coginit code laying around in the HUB was not reclaimed, and I could go down the list.
At that time I was trying to get to the basics, breaking stuff, writing some PASM, yelling, you know the drill, having a good time!
Cardboard GURU shows us how it's done with DK, and his SimpleNTSC effort. Baggers shows us another way, customizing the Parallax TV cog, and I jump in with some simple bitmap drivers, the first 8x8 (because I wanted to just dump strings to RAM like on old computers), and some fancy artifacting tricks we ended up never using at all.
Hippy sees my error in slapping the GPL on those early 8x8 and bitmap efforts, and along with OBC cleans up the core of that, mixing in elements of TV_Text, adding the nice font pointer trick, some C64 fonts, and some sane color capability, producing AiGeneric. That was a very nice step forward --nice enough that it's getting used regularly today.
Some fragmented efforts follow. Bamse writes a very compact driver and tutorial to go with it, Kye starts working on some cool VGA drivers, JT_Cook knocks out the screen capture and also does some VGA, I start work on potatotext, and attempt some one cog video that sucks, Baggers starts on PropGFX, and tosses us some various drivers that all build off the core Parallax one, and so it goes.
Kye takes some of the cool stuff seen elsewhere and just works his *** off to produce really great, well commented productions, adding a ton of value. Somewhere in there, we get easy SD card too. Bradc gives us some great, cross platform tools, Cluso wants more pins, gets that itch and scrunches down video and keyboard to one pin versions.
Along in there comes Eric Ball, who sees all the efforts, and shows us software generated composite with more colors, and some great signal qualities. He and I have a conversation or two where he sees I want to do stuff with signal options and writes up a nice template that has been the basis for a lot of things.
BTW: Eric wrote a killer sprite driver that never got any love. Honestly, that one really should see a mod that permits background tiles or something, solving any number of problems, just FYI.
Kye builds again and again, producing fine VGA drivers, fine SD card drivers, we get sound several different ways too. Simple PWM, followed by some excellent FM from Linus, who knocked it out of the park just to remind us how far we could still go. Baggers does it again, just because, well... he's Baggers, and he does that. The SID project hits, OBC goes nuts, combines it with SD card, as do others.
It's said that we can't do a NES. I try a pass at emulation, and realize I suck huge. Eric tosses me a bone with a 6502 core, that ends up being turned into the working NES emulator. (who expected that?)
Then in parallel with that, we've got Heater and friends knocking the Z80 out of the park, developing all sorts of goodness along the way. Don't forget Bill with that first LMM post that made us all realize the game was way more involved than anybody thought, including Chip Gracey. (thanks man) Bill decides to start building big memory stuff, is joined by some, and we get Morpheus. Cluso, Coley, Baggers all do similar things, extending the chip in different ways, triblade, dracblade, Coley's unseen three prop deal (which I want, because I'm a fan), Baggers with high color graphics slave, complete with serial and parallel comms, custom boot eeprom for HYBRID, and it goes on and on.
Hippy more or less pried the lid off the can, freeing the SPIN intrepeter too. That's been invaluable, and the right thing to do, though a batch of us thought it was good and a batch thought it wasn't at the time.
The difference between then and today is staggering!! Back then, a whole lot of us said, "no" only to be shown it's really "yes", if somebody went and worked for it. LOL!! Think about the number of times that's happened, and it's all really just kick ***.
Today we don't say "no" much do we? Well, we do, but by comparison, the scope of "yes" things is huge, and there is still plenty of room to grow.
That's the boot strapping I'm writing about. Early on, I wrote Chip about my experiences on this chip. We shared some interesting observations, one of which was "being a student of multi-processing", and hasn't that been true enough? It is from where I stand, because I see things being done easily, and am doing things easily now that were flat out off the table not very long ago.
And there are so many things I didn't mention. PropDOS, KyeDOS, Pullmoll emulation, Baggers emulation, CP/M not only working, but potent even. (I seriously thought that would be a curio)
One very instructive bit of boot strapping has been the development of language compilers and PropBasic. Truth is, had I the skill early on, that's what I wanted to do. Wanted a compiled BASIC, because I saw and used one on a lowly VCS, wrote a game, and watch people with very little skill do the same nearly every month on a machine that's so old, so limited, and so damn cranky and difficult that it's considered a badge of honor to actually complete a project on. Bean recently got it done, and it's sweet.
Took an awful lot to get there. LMM being the foundation, and the work to bring up a C environment, along with many lessons learned on the CP/M stuff.
The other is C. Imagecraft put forward a solid effort. That was a pioneering bit of work, and the follow on efforts right now are playing off that, advancing things still.
I'm extremely interested in the spin byte code assembler, with it's ability to blend the byte codes, lmm and potentially pasm as binary blobs, or full on pasm. I'm also very interested to watch Zog and Catalina too.
That's where we are today. Still figuring out stuff. I submit the primary reason why we don't have more enduring standards is simply an artifact of how differentiated the propeller really is, and I also submit that we are reaching a state where that can all start to solidify now, because we finally know enough to consider the greater implications of those standards.
Finally, in this "brief history of time" rant, if you were not mentioned, I'm sorry. There is so much. Seriously. We kick ***, and that's just cool. Thanks for it. You all make my week, just about every single week.
Well Smile. I think I probably hammered the thread, but I think it's worth pointing out these things, and the progression of good stuff and what that probably will mean. And just for a bit of advocacy, those guys working on the other cool game oriented designs didn't get any of that, because it's either been proven out, so it's done, or because the hardware doesn't have the attributes needed to bring it all into play.
One other thing I think that goes unappreciated is the sheer effort this group has put into this chip. It's a very impressive, educational, fun, and pioneering effort. We all could very easily be entertaining far worse. And Parallax knows this, we should know this, and maybe that's part of what we could tell others too. Maybe that's bad, I don't know. What I do know is that I learn a ton. Can't be all that bad, can it?
The next level, to me, besides Prop II, is combining prop I with some other CPUs to make it shine in the supporting role. That's started, but we've not really seen anything killer yet. We will. Of that I have no doubt, and doing that will be another boot strapping phase, because it's gonna work just a bit differently than it does on most other CPUs. I see things like the Andre' combo boards, Dennis F's 6502 project (which I need to complete a build of, just because), and some stuff being worked on right now as very capable projects, that will extend Propellers in that direction too.
I mention that to underscore the standards bit. How can they be done, when the means and methods are still pioneering?
So, I'm not anti on it. Just a realist. Why be constrained in that way, unless it's known solid?
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Propeller Wiki: Share the coolness!
8x8 color 80 Column NTSC Text Object
Wondering how to set tile colors in the graphics_demo.spin?
Safety Tip: Life is as good as YOU think it is!
Edit: What got me on PAL was time, and lack of a suitable display. My capture card does it, but that's not always optimal. Kind of need a real display. The other element is just not really knowing PAL like I do NTSC. Honestly, for things like text, it's actually way better [noparse]:)[/noparse]
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Propeller Wiki: Share the coolness!
8x8 color 80 Column NTSC Text Object
Wondering how to set tile colors in the graphics_demo.spin?
Safety Tip: Life is as good as YOU think it is!
Post Edited (potatohead) : 7/26/2010 3:47:53 AM GMT
Ariba is right. Many of the other forums I have gone to have been based in PAL based countries and if it is not taken into account this will not be readily accepted by other micro-controller communities.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Will work for Propeller parts!
Getting a video driver paired up with a big, fast, external memory would be great.
Unfortunately it's hard to do anything else while using a big fast memory.
Gameo was most likely just a "vapor" intended to draw our attention to tinyclr.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Propeller Pages: Propeller JVM
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Propeller Wiki: Share the coolness!
8x8 color 80 Column NTSC Text Object
Wondering how to set tile colors in the graphics_demo.spin?
Safety Tip: Life is as good as YOU think it is!
I would love to help in the optimisation.
BTW The RamBlade's main intention was to be a simple self-contained add-on pcb (i.e. module) to any prop (or other micro), and then to run an OS, be it CPM and ZiCog or Sphinx. The other prop would be the peripherals including TV/VGA, Keyboard, etc. The standalone 1pin versions of TV & Kbd were just so it could work also as a SBC. I guess I need to push it into the Retro markets outside the prop but I have been too busy. Since the prop is fast enough, it makes a great module for all sorts of retro-computing.
Basically, what is being described here is the Intelligent Peripheral PCB to any micro, including the RamBlade.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Links to other interesting threads:
· Home of the MultiBladeProps: TriBlade,·RamBlade,·SixBlade, website
· Single Board Computer:·3 Propeller ICs·and a·TriBladeProp board (ZiCog Z80 Emulator)
· Prop Tools under Development or Completed (Index)
· Emulators: CPUs Z80 etc; Micros Altair etc;· Terminals·VT100 etc; (Index) ZiCog (Z80) , MoCog (6809)·
· Prop OS: SphinxOS·, PropDos , PropCmd··· Search the Propeller forums·(uses advanced Google search)
My cruising website is: ·www.bluemagic.biz·· MultiBlade Props: www.cluso.bluemagic.biz
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
http://www.propgfx.co.uk/forum/·home of the PropGFX Lite
·
While we can get better resolution from PAL there is no real point when we have to also cater for NTSC (never the same color LOL). And it seems that the US TV's don't do PAL whereas us in the PAL countries seem to have the backward step for NTSC now anyways. My oldest TV that has a video in connector is 10 years old. My older TV's only have RF (aerial) connectors) so they won't work anyway - I am not interested in using an RF adapter anymore.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Links to other interesting threads:
· Home of the MultiBladeProps: TriBlade,·RamBlade,·SixBlade, website
· Single Board Computer:·3 Propeller ICs·and a·TriBladeProp board (ZiCog Z80 Emulator)
· Prop Tools under Development or Completed (Index)
· Emulators: CPUs Z80 etc; Micros Altair etc;· Terminals·VT100 etc; (Index) ZiCog (Z80) , MoCog (6809)·
· Prop OS: SphinxOS·, PropDos , PropCmd··· Search the Propeller forums·(uses advanced Google search)
My cruising website is: ·www.bluemagic.biz·· MultiBlade Props: www.cluso.bluemagic.biz
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
www.mikronauts.com E-mail: mikronauts _at_ gmail _dot_ com
My products: Morpheus / Mem+ / PropCade / FlexMem / VMCOG / Propteus / Proteus / SerPlug
and 6.250MHz Crystals to run Propellers at 100MHz & 5.0" OEM TFT VGA LCD modules
Las - Large model assembler Largos - upcoming nano operating system
VERY close, but it needs to be inverted:
is what I had in mind. Every object that needs to know the pins can reference it as:
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
www.mikronauts.com E-mail: mikronauts _at_ gmail _dot_ com
My products: Morpheus / Mem+ / PropCade / FlexMem / VMCOG / Propteus / Proteus / SerPlug
and 6.250MHz Crystals to run Propellers at 100MHz & 5.0" OEM TFT VGA LCD modules
Las - Large model assembler Largos - upcoming nano operating system
(there is some really cool PAL color artifacting possible, and I'm kind of eager to try it, because it's not horizontally resolution limited. It is in the vertical, but an interlaced display can keep 200+ lines on the screen and still do it, I believe. Won't know, until I try it, and I always end up artifacting on every chip and signal I get hold of, just because.)
In US, PAL is simply not here. If one gets lucky, TV firmware can be hacked, or maybe land on a multi-region device found in a thrifty store or something, but that's it.
There are a coupla really nice things about PAL that are going to keep me motivated to do it this time. Last coupla times it was everything I could manage to get the driver done. Chipping away at that took a while, and it seemed easy to just do PAL later, but then I chip away at something else, leaving a lot of PAL users stuck with the core Parallax driver, and or the PAL template Eric did.
Those things are: Significantly improved color resolution, and improved vertical resolution, followed by a longer blanking time, and some interesting artifacts we've not yet explored on the Prop, that are not resolution limited to 160 pixels.
The first two are notable and probably useful for text and line art type displays, which NTSC tends to either mangle, or "shimmer" onto the screen. The second two are game oriented, and could be fun down the road.
If the TV cog, or two TV cogs, which is where I'm leaning, with the PAL one being first, get done, lots of people can and probably will write graphics cogs. That's easier both conceptually, and to debug. Signal cogs are a PITA, without a scope, as one has to really think through what the display is doing, often debugging with nothing. There are a fair number of graphics cogs written to Chip's TV driver, with a few tweaks added to it, mostly to get scan line buffers, and or color depth changes.
Potatotext was done without a scope, and it took forever, advancing it little tiny bits at a time. Once that was done, the graphics cog moved rather quickly, as the product of it could always be seen.
(I've a scope now, which has already helped on some things)
Honestly, the right first step might be to build out the potatotext TV cog in PAL. Eric did do the nice template. (And those are a *BIG* help.) I'm thinking on that right now. Might save some nice dev time, because the TV cog will be built off of that code, because it really works nicely, and it does color cells, which I think might be a good TV cog option. If that can be generalized, it would really boost what we get from graphics cogs, which would be free to ask for the color cells or not.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Propeller Wiki: Share the coolness!
8x8 color 80 Column NTSC Text Object
Wondering how to set tile colors in the graphics_demo.spin?
Safety Tip: Life is as good as YOU think it is!
Post Edited (potatohead) : 7/26/2010 2:19:53 PM GMT