Java Game Console

@monkeyget: Thanks for the support! :slight_smile:

@everyone: I was Christmas shopping for the kids this week and ran across a little console called “V-Smile”. The V-Smile is basically a Super Nintendo equivalent that’s targeted at the educational market. Its price is just outside of the JGC target price, as are the games. More info can be found at:

http://jgcwiki.datadino.com/jgcwiki/index.php?title=Similar_Products

I think this proves that a console with the planned specification and price point is actually quite feasible. :slight_smile:

Well, I just saw an ad on TV for a Barbie-console (yeah, the doll) for £50.

“plugs into the TV or works standalone as sound only, no graphics”.

What you need to do is start watching ©ITV between 15:50 and 16:50 each day :).

/me admits only to watching “My parents are aliens” which is often considerably funnier than most “adult” sitcoms…I recently noticed quite a lot of dodgy jokes that I’m sure fly straight over the heads of anyone under 16.

I wouldn’t go out of my way to watch it, but it’s good to have in the background whilst waiting for stuff to happen (compiler, tea break, etc).

[quote]Well, I just saw an ad on TV for a Barbie-console (yeah, the doll) for £50.

“plugs into the TV or works standalone as sound only, no graphics”.
[/quote]
Hi Blah!

Do you by any chance mean this thing?

http://www.walmart.com/catalog/product.gsp?product_id=2276650&cat=103288&type=5&dept=4171&path=0%3A4171%3A119668%3A103288#long_descr

That’s the closest thing I could find that matches your description. It doesn’t appear to plug into the TV, though…

Nope. It has a magnet-based graphics tablet (by the looks of the tv ad) with drop-in faceplates (each of which is just a piece of cardboard by the looks of things) so you can point and click on different areas.

This is the main unit, and it plugs into a TV to display what looks like a 5-bit or 8-bit vector image on the TV, and do animations etc in response to the pen/tablet actions.

For £50 you’d be looking at at least $50, if not more.

Odd. That sounds a lot like the InteracTV system, but that’s from Fisher-Price instead of Mattel. Next time you see the commercial, you’ll have to take note of the product name. I’d love to find more info on the device. :slight_smile:

My uncle’s very much into hardware (he’s an EE), I’ll show him this thread; he might be able to give suggestions or (unlikely, he’s really busy) help.

Very cool idea. I’m going to have to check out the wiki.

Personally, I’d like to see it do just a bit more, like add a DVD player. How do you get kids in the back seat to stay quiet? Just plug in a video for em, ask any parent.

Add CD music playback too, and DreamCast style 3D graphics. All for around US$75. I think that’d work.

But the basic plan is way cool. I hope something comes of this.

[quote]Personally, I’d like to see it do just a bit more, like add a DVD player. How do you get kids in the back seat to stay quiet? Just plug in a video for em, ask any parent.
[/quote]
As a parent, I can attest to this sort of feature. HOWEVER, that’s a completely different market from what I’m targetting. You can already purchase a Playstation or portable DVD player to do the same thing.

[quote]Add CD music playback too, and DreamCast style 3D graphics. All for around US$75. I think that’d work.
[/quote]
The problem is that the console would stop competing with things like the Jakks controllers and the new Atari console, and start competing with the Playstation, XBOX, and GameCube. That is not a market JGC could win in.

Not to mention that you can’t add a DVD player and expect the complete console to remain at $75 or less. The drive mechanics + MPEG decoder chip + controller chips are pretty expensive. It would also complicate the design considerably. Instead of decompressing the entire datastream into memory, random access support would need to be added. :-/

[quote]Also, while the JOP looks cool, it’s just a Ph.D. project. I’d recomend something like ARM instead. ASICS have bugs just like software, except bugs in hardware are MUCH worse than software bugs. I know, I use to test ASICS. Something like ARM is used widely and is more likely to be debugged than a one man project like JOP. Trust me on this.
[/quote]
I’m pretty close to dropping ASICs for FPGAs in the production design. The reason is that the Spartan 3s have actually gotten cheaper than low volume ASICs. This opens up quite a few possiblilties in the way of reconfiguring the hardware on the fly.

As for using an ARM, I have considered that. However, JOP already has a highly optimized JVM, which makes it a very valuable project. The ARM route would require a JVM from scratch (or expensive licensing of one). Programmers would question why they can’t just program the ARM, and find a way to do exactly that.

[quote]But the basic plan is way cool. I hope something comes of this.
[/quote]
Glad you like it. And keep the suggestions coming. :slight_smile:

• OS: Windows XP Embedded (customized)

Wonder if it runs Java…

[quote]http://www.gamespot.com/news/2004/09/02/news_6106533.html

• OS: Windows XP Embedded (customized)

Wonder if it runs Java…
[/quote]
Doesn’t matter. With a 4.2 GHz CPU, up to 2GB of RAM, a Radeon 9200SE, and other PC goodies, I think it’s just a little out of the price range I’m targetting. I’m thinking more along the lines of a 100MHz processor w/ 8mb of RAM and some custom graphics hardware. That will help keep the console in the $25-50 range. Nice thought, though. :slight_smile:

[quote]I’m pretty close to dropping ASICs for FPGAs in the production design. The reason is that the Spartan 3s have actually gotten cheaper than low volume ASICs. This opens up quite a few possiblilties in the way of reconfiguring the hardware on the fly.
[/quote]
Just curious: what’s the top clock speed for these FPGAs? The one’s I’ve worked with were quite slow. Maybe they’ve sped up?

JOP can run on a Spartan 3 at about 87 MHz, and a Cyclone at ~100MHz. Xilnix claims the Spartan 3 can hit ~400MHz with the right pathways. The Virtex chips are WAY more powerful, but they’re also WAY more expensive. :slight_smile:

EDIT: I looked up some of the standard propoganda for you.

http://www.xilinx.com/products/virtex4/overview/performance.htm
http://www.xilinx.com/xlnx/xil_prodcat_product.jsp?BV_UseBVCookie=yes&ioid=-8265&isoid=-19147&ipoid=120046&itype=2&iLanguageID=1&iCountryID=1&sSecondaryNavPick=Devices&sGlobalNavPick=PRODUCTS

As you probably know, the MHz and actual thoroughput depends on your chip design.

Could we get some kind of blitter in this thing cheaply? I expect that even at 30MHz a Java interpreter would be easily fast enough if it had a bit of help from hardware blitting.

Cas :slight_smile:

[quote]Could we get some kind of blitter in this thing cheaply? I expect that even at 30MHz a Java interpreter would be easily fast enough if it had a bit of help from hardware blitting.
[/quote]
Of course. In fact, the use of a hardware blitter was very much part of my Master Plan. Here’s the evolution of concepts I’ve been going through:

  1. Use hardware overlay for sprites. This is how a lot of Old Skool game machines did it. The background was the primary video signal, then the signal was modified for each sprite that needed to be laid down. That’s why when the older game machines slowed down, the sprites would begin to flicker.

  2. Use a framebuffer with pre-calculated YUV. The framebuffer would be fed through a standard set of accelerated 2D operations. (e.g. line, circle, image transform and blitting) The use of a framebuffer also means that an Alpha Channel could be added. This would allow for many of the effects that you use in PuppyGames.

  3. Extend the 2D operations out to provide acceleration for basic 3D operations. A lot of the work would still have to be done in software, but a good chunk of the more expensive stuff could be moved to hardware. This is very similar to how early 3D cards functioned.

At this point, I’m 80% certain that I’ll dump option 1 and go with option 2 or 3. Option 3 will be highly dependent on exactly how much I can fit into the Spartan 3 FPGA, and how much the functionality reduces the overall speed of the chip.

Hey, I just got an idea for a new contest. Instead of the “4K contest”, we can do the “How much logic can you fit in a Spartan 3 contest?” It would be a real challenge. :wink:

Ok this looks very cool. Even 50-60MHz would be good for a final product.

The hardware blitter is a good idea. I’d ask for a descriptor chain (the ability get the hardware DMA to step through a simple list of sprites, rather than just one at a time) and stretch/scale transform for 2.5D games (think Space Harrier).

Lines and cirlces are ok but normally I don’t think a game uses these.

Oh, and a scrollable background. Very important that one. And maybe some sort of tiles for backgrounds too. (Ie, scrolling bitmaps or tiles, in the same hardware.)

Ok, hehe, enough demands. :wink:

[quote]Ok this looks very cool. Even 50-60MHz would be good for a final product.
[/quote]
Indeed. Once you reduce most expensive operations to one cycle, even a few megahertz starts to sound fast. :slight_smile:

[quote]The hardware blitter is a good idea. I’d ask for a descriptor chain (the ability get the hardware DMA to step through a simple list of sprites, rather than just one at a time)
[/quote]
Actually, I was considering an opcode design like 3D cards use. That way you can build a memory queue between frames, and then use the VSync time to populate the YUV buffer. The “render to screen” clock would run at ~27 MHz, and would be independent of the main CPU clock. Gotta love how you can put parallel processing on the same FPGA. :wink:

[quote]and stretch/scale transform for 2.5D games (think Space Harrier).
[/quote]
Don’t worry. That’s what I meant by “image transformations”. Besides, I want to code a Wing Commander clone one of these days!

[quote]Lines and cirlces are ok but normally I don’t think a game uses these.
[/quote]
Poppycock. Primitives are extremely useful for various special effects. And 3D work is very much about screen primitives. I hope no one minds perspective affine texture mapping? :slight_smile:

[quote]Oh, and a scrollable background. Very important that one. And maybe some sort of tiles for backgrounds too. (Ie, scrolling bitmaps or tiles, in the same hardware.)
[/quote]
Umm… yeah. I’ll let the coder just rebuild the framebuffer every loop through. That should allow him to do whatever he wants. :slight_smile:

[quote]Ok, hehe, enough demands. :wink:
[/quote]
It’s always good to discuss these things. Otherwise I might forget something. :slight_smile:

Any new updates?

Sorry, I’m new and I stumbled upon this with a “JVN Game Console” google search. It’s 2021 now. Should this be idea be revisited? If it already has, could someone point me in the right direction? I haven’t bothered searching forums yet but I noticed this thread is old and I thought it couldn’t hurt to ask.

Something like this? Blu-Play: An introduction to developers

I just stumbled on this somewhat discouraging bit of history. It’s from a discussion on StackOverflow, from 2014, by someone who wanted to stay anonymous: user430788. The writer claims to have been “Sun’s Java Game technical evangelist and lecturing Java performance programming expert.”

Although you could write a Java game and ship it on Windows, OSX and Linux, there was never a console VM. This was due to total ineptitude in Sun middle management. The few of us working on Java in games actually had deals with Sony no less then 3 times to get a VM on a Playstation and all 3 times Sun middle management killed it.

Worth looking at the full reply.

1 Like