Well, I have a bushel of questions all in concern of the Hydra's capabilities
Bob the Builder on a C64
Posts: 112
I've been wondering quite a bit on what the Hydra could do, here are some things that are boggling me.
1.) Is it possible to have·12 bit color? If so, please tell me ways this could be done
2.) What would it take to make a 3D model on the Hydra?
3.) Do you think you could interface a motorolla 68000 with the Hydra somehow?
4.) Is there any projects in the works to make the Hydra use other languages?
5.) How could I increase the number of sprites possible on the Hydra?
6.) Anybody here know how to interface a floppy drive or CD-ROM drive with the Hydra?
Thank you.·
·
1.) Is it possible to have·12 bit color? If so, please tell me ways this could be done
2.) What would it take to make a 3D model on the Hydra?
3.) Do you think you could interface a motorolla 68000 with the Hydra somehow?
4.) Is there any projects in the works to make the Hydra use other languages?
5.) How could I increase the number of sprites possible on the Hydra?
6.) Anybody here know how to interface a floppy drive or CD-ROM drive with the Hydra?
Thank you.·
·
Comments
1.) Nope. (Without hardware mods or better DAC)
2.) Yes!
3.) Yup, Has been done before with the propeller chip. [noparse]:)[/noparse]
4.) Yes! Logo, Forth and a few versions of basic.
5.) Yes! Set the rendering cogs to the max level allowed! or write your own graphics driver that allows for more sprites.
6.) It can be done, but I havn't heard of anyone doing so yet.
Your welcome.
2) There are some existing 3D wire-model graphics and some multi-layer 2D graphics to give the appearance of 3D, but there hasn't yet been any 3D graphics, mostly because of memory constraints. With the 512K High Speed RAM Card almost here, I'm sure we'll see some experimentation with this.
3) Someone has tried this already. I don't have the link to the discussion thread. The Hydra is mostly just another Propeller board (along with major documentation) and someone made a board with a 68000. I think the 68000 had its own memory and the Propeller acted as an I/O controller.
4) FemtoBasic runs on the Hydra. There are two implementations of FORTH well along (not complete). There is a planned 3rd party C compiler/linker due out around the end of the year.
5) This will probably happen when some new display routines are available using the 512K RAM Card. It's primarily a memory availability issue.
6) You can attach a USB host interface (from Vinculum or GHI Electronics). There are USB floppy and CD-ROM drives that should work as a generic USB mass storage device with these interfaces. You may prefer to use one of these interfaces with a USB flash memory drive since these drives are very cheap now in sizes up to 1-2GB.
Thank you.
The 2D layering stuff is part of the Hydra documentation and is discussed in the Hydra manual.
There's an index "sticky thread" at the beginning of the Propeller chip forum that links to a lot of specific thread topics. Have a look
Thank you.
Post Edited (Bob the Builder on a C64) : 5/22/2007 9:34:48 PM GMT
Post Edited (Bob the Builder on a C64) : 5/22/2007 10:49:29 PM GMT
Andre'
Thank you.
Post Edited (Bob the Builder on a C64) : 5/22/2007 11:05:38 PM GMT
It's possible to add levels to the "D/A" converter, and with them you can add more "luminance levels", and also, because of the added analog levels, it's theoretically possible to modulate the amplitude of the color burst, thereby adding different "color saturation levels".
However, the hardware (phase shift generator) cannot generate more than the current number of unique phase shifts, and therefore "chrominance" levels.
So you cannot add more "basic colors", but you can add more "brightness levels", and more "color saturation levels".
All this is true for NTSC/PAL
For a VGA display (or for other types of RGB signals, such as S-video) the story is completely different. In principle it's possible to add more colors simply by adding more output pins and resistors to each of the three D/A converters. Although you probably need a second COG, and it's possibly tricky to synchronise multiple COG's.
A solution to generate more colors with NTSC/PAL is to add a hardware RGB to NTSC/PAL chip, but thats probably outside of the scope of what you want to do.
Mahjongg
P.S.
For some information about the technical backgrounds see;
en.wikipedia.org/wiki/S-video
·
andre'
Check out this thread: http://forums.parallax.com/forums/default.aspx?f=33&m=185675
As for more colors, there are some approaches, some done, some not. There is some small discussion on my AtariAge blog (same username) about this. The scheme being discussed there would take different video output circut, would use a lookup table, and have very high color / intensity capability. It's just past the concept stage, with another interested forum contributor having cooked up the scheme and some sprite code to go with it. Pure speculation, backed with some thought code, at this point. I'm gonna work with it a bit to learn, then probably revert to method #1 below for anything further.
Some ideas that have been done:
1. Run the video generator in a mode where it's set to output 4 pixels, with each pixel being a color defined in the waitvid instruction. This method yields about 90 pretty decent colors, with six intensities. This requires no modification of the output circut, no syncing of cogs, etc... This is the method found by the HYDRA demo coders. It's solid and a great overall balance of complexity and capability. In particular, it's well suited to methods where multiple COGs will be working together to build an image. Having the video generator able to do it's own thing, while the COG is doing work as well really hits the sweet spot on the Propeller.
The disadvantage of this method is that it consumes a lot of memory. A 160x192 bitmap, at one byte per pixel, is ~30K or so. Not much room for anything else. I've got a quickie demo of this in action, running at 80x192 in the Simple NTSC thread. One could do better at packing pixels into RAM, generating a 16 color display (4 bits per pixel), using a look up table in the video COG, and going from there. Memory use in that scenario would allow for some game logic to happen. You then would get any 16 colors out of the ~90 or so possible. Not bad.
If you build your image on the fly, or via contrived addressing schemes (like character mode on older computers, etc...), you can get all the colors on screen doing stuff, with sprites, etc... However you will be writing what is essentially a video kernel for your game display. This is what is currently happening with the Donkey Kong game here. Running this method as a full on bitmap consumes a lot of ram... If the game is simple, with few assets, well, it could work!
2. Run the video generator at a fairly high resolution (320 - 640) pixels per line, and use artifacting to generate additional colors. Doing this with the Parallax driver results in difficult sprite maps, as the artifacts are offset each line. It requires a tweak to the number of lines to make any sense. Search on my user name for an example of this. The driver CardboardGuru wrote (simple NTSC) could be used this way, with better results because it's color clock synced on each line. (Vertical artifacts line up)
This would give some additional colors, but does require memory the same as the method above. I don't see a real advantage to this, but it would not require a tweak to make happen. This method would deliver some different colors than the method above, however. I think this only would work well on NTSC televisions...
3. Vary the tile size. Smaller tiles does not remove the 2 or 4 color limitation, but does make for a higher overall density. 8 pixel tiles is 8 bit computer like. Both the C64 and Spectrum did this and the results were very decent. I believe this is what Baggers is doing for his great Manic Miner work in progress.
Stuff that's not yet been coded.
3. Run more than one COG, in sync, to output colors that would mix together at the video output. Video outputs are or'ed together, so additional intensity levels, beyond the six provided for, would be possible, but problematic from an addressing standpoint. Laying out the screen ram, building line buffers for the COG's, etc... are gonna consume a lot of cycles.
Syncing the COGs color bursts is an issue. Given method number 1 above, and the nice driver CardboardGuru wrote, this is too much of a hassle to bother with, IMHO.
4. Over clock the video generator, so that more than one pixel is output during an NTSC color clock. This will result in sub-pixel control, which will result in more colors / intensities, as everything kind of adds together, once you output signals that are sharper than the TV can display. Of course, this will consume RAM, and make the COG work pretty hard, making sprites, etc... difficult. Most likely would require bitmapped display, or most of the COG's to get anything working. The RAM expansion might make these kinds of things viable... all depends on how quickly the COG's can retrieve data from the expansion RAM. A few COGs working together can probably yield enough free cycles to make this doable. It would work like this:
Each COG outputs one line of video, then spends however many additional lines it takes to fill it's line buffer again. If it takes 3 scanlines of time to get this all done, then you would need three COG's minimum, working in round robin fashion, to build a complete display. This is the idea being worked through on the AA thread.
If you set the color issues aside, this idea has some merit where sprites are concerned. Having the COG's all take turns outputting single scan lines (they all have a video generator afterall), means more time to process the sprites, look up their colors, address transparency, etc... I believe this will be capable of more sprites per line than simply having one COG do video, and others feeding it.
IMHO, without there being a lot of on-chip RAM, I'm not sure the higher color and intensity schemes make any real sense. The colors output with method #1 are pretty good for gaming in general. There is a case for having a high color and intensity space, keyed to a lookup table. This done with a 32 or 64 color display would look really good on a lot of different games. However, it's gonna take RAM and a lot of cycles, or a different video output circut to make any sense. Sticking with the standard output means others are likely to play your creation. That carries some significant weight, IMHO.
Take a hard look at method #1 and see if that does not meet your color needs. If it does, you can build your video display scheme however you want, then have the use of ~90 or so colors for output, with good results. Like I mentioned above, it's a really good balance for the chip, all things considered.
http://forums.parallax.com/forums/default.aspx?f=25&m=144641
Thank you.
The 320 mode, interlaced, using method #1 for color mapping, is gonna look really good! (When I say interlaced, I mean horixontally interlaced for color, not vertical interlace, which is bad for games and movement in general. Tearing is an issue.) Horizontal interlace, doubles the color resolution, eliminates artifacting for higher resolutions and does not impact animation or movement to a significant degree. Used on all modern consoles. It will have more square pixels too, meaning more coin-op games will translate better.
Having the double buffered screen means being able to build software sprite engines that are more simple and that can provide more functionality without having to manage video at the same time.
Does anyone have a code snippet of how to access the lower 64Kb of SRAM?
(goes off to look for some docs)
Never mind, found the docs.
Post Edited (potatohead) : 5/23/2007 6:00:10 PM GMT
Thank you!
I suggest some experiments with 4-bit color 259x192 bitmap modes, these fit perfectly and allow multiple buffers. But, then add the features where you have a palette table, so each line or each tile has its own palette, this way you can do bitmap graphics, BUT have the flexibility of different colors on a scanline or tile basis, so it allows more color in regions in the screen, but locally only 16 colors. That's what I would do, then you can do full lines, 3D, etc. BUT at the same time make really nice tile looking graphics.
Another thing I would do is a 4-bit bitmap mode, so you have 4 colors in your bitmap plane with 8-bit tile color, and then mix that together so you have tiles, bitmap, and sprites all overlaid, that would be sweet and all fit easily as well in the 64K. Then you can do cool things like generate procedural animations etc. in the upper memory and then use block copies to move them into the frame buffers etc.
Andre'