HYDRA or XGS PIC or Uzebox...

polbit

I really hope that I can get some input to help me decide which console to get. I'm already familiar with AVR chips via , and I like that the Uzebox has NTSC color generation done in hardware, and that it has S-Video. However there is no denying the power of the Propeller, or PIC24.

I'm an old Commodore 64 and Atari 800-series programmer at heart. My goal is to have fun with something similar, but without the pain of an ancient 8-bit CPU, and with modern interfaces. What scares me away is the complexity of having to deal with video signal generation. From what I understand, there is basically no cycles available to the main program during the screen redraw (except the multi-cog Propeller I'm assuming), with the power of the AVR or PIC being "wasted" on the display. Also, because it is done purely in software, how is the video quality on the Hydra or XGS, especially with composite only?

Any input from current/former users, as to ease of use, quality, speed, etc. of these platforms would be greatly appreciated!

JT Cook

I have both XGS PIC and Hydra and speed has never been an issue on either of them.·One thing you may not realize·is on the original 8-bit systems, those CPUs were usually only processed game logic during vsync too because while the image was being displayed, it had interrupts setup to handle things with the graphics like sprite multiplexing and scrolling effects. So with that said, you still have many times the CPU power of these 8-bit consoles.

Really both systems are good, easy to use, and also come with graphics drivers you can use right out of the box so you don't have to worry about the low level code of rendering a video signal (but of course can always do later on after you have more hands on).

Out of respect to Parallax, I am not going to go on any furth on the XGS PIC, but the Hydra produces an extremely·clean NTSC signal and with the SD card add on, you can load programs from the SD card, as well as store individual programs on the Hydra. The ability to use the original NES controllers on the unit is a big plus too.

polbit

Thanks for a quick reply. Actually, most old 8-bit computers had a lot of free time during screen redraw. For example, on C64 the VIC (graphics chip) co-existed happily without stealing any cycles, except for every 8th line, when it had to load character/sprite data. I am used to programming based on screen position, so I guess programming only during vsync seems a bit odd for me [noparse]:)[/noparse] But I totally understand what you are saying about the power - 6502 at 1MHz is a far cry from a Propeller, or PIC, or even AVR....

Glad to hear about the video quality on the Hydra, I currently use a 24" Gateway LCD for my monitor, with composite/s-video/etc inputs. It has an unfortunate tendency to magnify any flaws in the signal [noparse]:)[/noparse]

polbit

The more I read about Propeller, the more I want to play with it. It is so different than what I'm used to, this whole no interrupt thing has me really intrigued! Needless to say, I'll be placing my Hydra order over the weekend. Can't wait to play with it.

ericball

First, most 8 bit consoles and computers were clocked under 2MHz and often less than 1MHz.

The number of available CPU cycles per frame depended on the particular "GPU" in the console or computer. For the Atari 2600 the GPU is only 1-D, so the CPU had to actively update the GPU registers during the active portion of the screen (and invoke VSYNC at the proper time too!). On the Atari 7800 the GPU runs independently, but shares the bus with the CPU. So during much of the active portion of the screen the CPU is suspended while the GPU fetches graphics data. But the NES has separate CPU and GPU buses, so the CPU can do anything (except update the GPU registers) during the active portion.

8 bit Computers often had frame buffers. Depending on the computer, the GPU might compete with the CPU for bus access or might not block the CPU. (e.g. The GPU on the CoCo accessed RAM on the opposite clock phase from the CPU.) If the CPU could access the frame buffer while it was being displayed, care had to be taken to avoid causing visual problem. Some computers could "double buffer" so the CPU would update one frame buffer while the GPU displayed the other.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Composite NTSC sprite driver: http://forums.parallax.com/showthread.php?p=800114
NTSC color bars (template): http://forums.parallax.com/showthread.php?p=803904