Ninja

[Radek]

I can get some 70MHz Arm7 chips and Xilinx Spartant XC3S500E rather easily and CHEAPLY. I can make (via some other company) dual sided PCBs plus soldering these chips at acceptable price even for single digit unit production.

So I could afford to make prototypes and low scale production.
(at least I could afford to take risks to try with such project as it'd be within my capabilities)

That's cool, even 70mhz seems like enough, because as long as developers are willing to program for it, power is not that essential...case and point: the gameboy advance - 16mhz and (i believe 256kb ram :huh: ),
yet it has a lot of great emus. You seem to be good with this hardware engineering stuff. I think(again, i'm not forcing anybody)you should try to make this work. Good luck if you decide to though!

The "70Mhz" chip what I was talking about is an Arm7 based µC from Philips. It costs 3$ in a detail. It's far less capable than Arm what we have in GP2x. In my idea it'd only acts as some kind "master controller" for the rest of a system and most of the work would be done by FPGA chip.

The Xilinx XC3S200 costs less than 20$ in detail and it has 12 multiply units, over 200Kb built in sram memory, capability to contain hardwired designs with up to 200000 logic gates.
(let me say it can do SNES like transparencies at fraction of GP2x's clockrate - I don't know exact SNES's gate count but it's possible to mirror such machine in a FPGA for sure)

If a HDL code would be made for any given console (and FPGA could contain it) then it could mirror it in exact precision at the same clockrate as the base system has.

But it's unrealistic because of paramount coding in HDL needed. It'd be be far easier if companies like Nintendo would cooperate providing documentatnon/code (preferably in the Verilog) but it's not realistic.



But the point is to show you than there other ways to do things than just faster CPU with higher clockrate. And there some tasks what are hard for a normal CPU but they are very easy for a FPGA. It's this "hybrid" solution what I have in a mind.

We have a silent revolution going now made by companies like Altera and Xilinx what are producing programmable chips at very low level. If it will be progressing as it's now further then eventually we... say goodbye to...

Anyway it will be great!!!

 

[OMars]

The "70Mhz" chip what I was talking about is an Arm7 based µC from Philips. It costs 3$ in a detail. It's far less capable than Arm what we have in GP2x. In my idea it'd only acts as some kind "master controller" for the rest of a system and most of the work would be done by FPGA chip.

The Xilinx XC3S200 costs less than 20$ in detail and it has 12 multiply units, over 200Kb built in sram memory, capability to contain hardwired designs with up to 200000 logic gates.
(let me say it can do SNES like transparencies at fraction of GP2x's clockrate - I don't know exact SNES's gate count but it's possible to mirror such machine in a FPGA for sure)

If a HDL code would be made for any given console (and FPGA could contain it) then it could mirror it in exact precision at the same clockrate as the base system has.

But it's unrealistic because of paramount coding in HDL needed. It'd be be far easier if companies like Nintendo would cooperate providing documentatnon/code (preferably in the Verilog) but it's not realistic.



But the point is to show you than there other ways to do things than just faster CPU with higher clockrate. And there some tasks what are hard for a normal CPU but they are very easy for a FPGA. It's this "hybrid" solution what I have in a mind.

We have a silent revolution going now made by companies like Altera and Xilinx what are producing programmable chips at very low level. If it will be progressing as it's now further then eventually we... say goodbye to...

Anyway it will be great!!!

So you aren't planning on making this...oh well atleast now people have new ideas to play with. It would be cheap to make and sell too and it has some good feature but lacks others. Can I see the specs on this "70 mhz chip"? :huh:

 

[Radek]

So you aren't planning on making this...oh well atleast now people have new ideas to play with. It would be cheap to make and sell too and it has some good feature but lacks others. Can I see the specs on this "70 mhz chip"? :huh:

I don't know how to answer this well...
(but I will try)

That "70MHz" chips is Arm based microcontroller LPC21xx from Philips. It wouldn't be major chip of a machine. It'd act just like some kind master controller and nothing more!

The actual processing would be made by FPGA type chip:
http://en.wikipedia.org/wiki/Fpga

Basically such machine would be like a mirror - it could mirror (literally) machines like SNES, PC Engine, NeoGeo (whatever) at hardware level. It wouldn't have have to work at any higher clockrate than mirrored system as it'd be that system effectively.
(or any other if its HDL description would fit into FPGA)

I understand that it's so different from "normal" CPU so very hard to comprehend but it's possible.

Thing about it like an mirror (doh - but it's a best description).
But problem is... to do so there is need of exact target machine documentation. Preferably in HDL type language.

Nintendo has such, Sony too, other companies as well. But good luck to get something from them...
Otherwise a "normal" CPU will be more practical in that sense there is lots of C code of emulators. So such system (FPGA based) is an idealistic one. But it's nothing wrong to discuss about it (at least).

 

[OMars]

I don't know how to answer this well...
(but I will try)

That "70MHz" chips is Arm based microcontroller LPC21xx from Philips. It wouldn't be major chip of a machine. It'd act just like some kind master controller and nothing more!

The actual processing would be made by FPGA type chip:
http://en.wikipedia.org/wiki/Fpga

Basically such machine would be like a mirror - it could mirror (literally) machines like SNES, PC Engine, NeoGeo (whatever) at hardware level. It wouldn't have have to work at any higher clockrate than mirrored system as it'd be that system effectively.
(or any other if its HDL description would fit into FPGA)

I understand that it's so different from "normal" CPU so very hard to comprehend but it's possible.

Thing about it like an mirror (doh - but it's a best description).
But problem is... to do so there is need of exact target machine documentation. Preferably in HDL type language.

Nintendo has such, Sony too, other companies as well. But good luck to get something from them...
Otherwise a "normal" CPU will be more practical in that sense there is lots of C code of emulators. So such system (FPGA based) is an idealistic one. But it's nothing wrong to discuss about it (at least).

Oh I see, well I've made an idiot of myself, so thank you for answering nicely!

 

[MWeston]

Can I see the specs on this "70 mhz chip"? :huh:

Radek is probably referring to one of these:
http://www.semiconductors.philips.com/prod...2bit/index.html

They are very limited in capability. I think some don't even have an external memory bus (but many applications don't need it and it's a cheaper part which fits best).

I'd love to see your case designs if you want to send them to me: mjweston3 'at' hotmail.com

Maybe someday you will hold a poll to let everyone decide which one they like best. It might help you come up with the most stylish portable casing ever. I mean, the DS lite is cool, but it's just a white box

Oh, and I'm still planning on developing my idea, don't worry. I can get the parts is smaller quantites (single trays which is better than thousands) and there is an assembly house 15 miles away from my place that will place any BGA package part for about $5 a pop! That makes placing the processor and DDR memory (and FPGA is there was one) very easy and saves me lots of soldering if it was possible to choose 1mm spaced, leaded parts.

 

[OmarNawaz]

http://www.bytecellar.com/archives/000063.php

thought this might be useful

 

[MWeston]

You know probably about my little project of stick replacement, don't you?
Simple as it's looking but there were many considerations. It ended using an µC chip and some parts from some cell phone.
(and it taken lots of time so find suitable µC because of needed voltage tolerance, power consumption and cost of getting a programmer for it plus time needed to learning to program it)

All that because of parts availability and size constrains.

Actually, I haven't read anything about that project. If you posted it here I must have missed it. Are you talking about a memory stick or joystick?

To be really able to make something what could have a chance of success (or even a showing a prototype) there is no place for a dreaming. No, no that dreaming is bad but to be able materialize something anyone has to use things what are realistic to get.

Look at the Ninja - Samsung wasn't willing to provide chips in smaller quantity. Is Samsung bad or there was a design mistake to use a chip what couldn't be bought in such limited numbers?

You decide.

Imho to get results should be a major priority. If Samsung couldn't provide a needed element then it's time to adapt to somethng else.

I can get some 70MHz Arm7 chips and Xilinx Spartant XC3S500E rather easily and CHEAPLY. I can make (via some other company) dual sided PCBs plus soldering these chips at acceptable price even for single digit unit production.

So I could afford to make prototypes and low scale production.
(at least I could afford to take risks to try with such project as it'd be within my capabilities)
...
...
Better think using parts what are available and not in big numbers for an individual consumers.
(and the ones you could make a PCB for)

Oh, I understand what you are saying and I am only focusing on parts that are currently available. Sometimes I like to poke my head in the clouds and think about what could be available some day.

Well... Squidge is more interesting in making his own machine than an emulating some other. Anyway try ask him him for details.

And don't be afraid of FPGA or even much simpler CPLD chips.
They can simplify a design drastically!
(even used only for rerouting signals - you DON'T want to resort to multilayer PCB as the costs will kill you unless you have lots of money to spend). So even 2$ CPLD chip can be very handy.

Maybe he will visit this topic and add his own comments and stories. All are welcome

No if it's FPGA/CPLD would work at low clockrates. These are basically like a hardwired chips and they have perfomance advantage over 10times (if not more) againsts the same task performed via normal CPU at the same clockrate. If balanced well it shouldn't be power hog.

The CPU emulation is many times faster than what is needed for the little systems and so they could be clocked very slowly if I felt like trying them in VHDL, but I was thinking about the higher end machines for the FPGA. The FPGA might be useful in 3D calculations and SH-4 or MIPS instruction decoding of faster gaming machines.

 

[Radek]

You know probably about my little project of stick replacement, don't you?
Simple as it's looking but there were many considerations. It ended using an µC chip and some parts from some cell phone.
(and it taken lots of time so find suitable µC because of needed voltage tolerance, power consumption and cost of getting a programmer for it plus time needed to learning to program it)

All that because of parts availability and size constrains.

Actually, I haven't read anything about that project. If you posted it here I must have missed it. Are you talking about a memory stick or joystick?

I didn't - sorry. Here you have a link (from almost the beginning):
http://www.gp32x.de/board/index.php?showtopic=26613
(it's a long topic so be patient or jump to the latest pages)

It isn't that complicated but it shows very well some obstacles.

To be really able to make something what could have a chance of success (or even a showing a prototype) there is no place for a dreaming. No, no that dreaming is bad but to be able materialize something anyone has to use things what are realistic to get.

Look at the Ninja - Samsung wasn't willing to provide chips in smaller quantity. Is Samsung bad or there was a design mistake to use a chip what couldn't be bought in such limited numbers?

You decide.

Imho to get results should be a major priority. If Samsung couldn't provide a needed element then it's time to adapt to somethng else.

I can get some 70MHz Arm7 chips and Xilinx Spartant XC3S500E rather easily and CHEAPLY. I can make (via some other company) dual sided PCBs plus soldering these chips at acceptable price even for single digit unit production.

So I could afford to make prototypes and low scale production.
(at least I could afford to take risks to try with such project as it'd be within my capabilities)
...
...
Better think using parts what are available and not in big numbers for an individual consumers.
(and the ones you could make a PCB for)

Oh, I understand what you are saying and I am only focusing on parts that are currently available. Sometimes I like to poke my head in the clouds and think about what could be available some day.

That's good but... be realistic.

Well... Squidge is more interesting in making his own machine than an emulating some other. Anyway try ask him him for details.

And don't be afraid of FPGA or even much simpler CPLD chips.
They can simplify a design drastically!
(even used only for rerouting signals - you DON'T want to resort to multilayer PCB as the costs will kill you unless you have lots of money to spend). So even 2$ CPLD chip can be very handy.

Maybe he will visit this topic and add his own comments and stories. All are welcome

I'd like to hear from him about it too!

No if it's FPGA/CPLD would work at low clockrates. These are basically like a hardwired chips and they have perfomance advantage over 10times (if not more) againsts the same task performed via normal CPU at the same clockrate. If balanced well it shouldn't be power hog.

The CPU emulation is many times faster than what is needed for the little systems and so they could be clocked very slowly if I felt like trying them in VHDL, but I was thinking about the higher end machines for the FPGA. The FPGA might be useful in 3D calculations and SH-4 or MIPS instruction decoding of faster gaming machines.

CPUs in the those "higher level consoles" are crippled by one way or another. Except the Dreamcast - it's very reasonably made machine - it has 100mpix of depth complexity free fillrate. Not possible on the GP2x. Not possible on the PSP either.

A FPGA would be most usefull to make existing emus perfect at relatively low cost.
(but problem is to connect it and interface it with GP2x)

 

[cbox]

The FPGA idea sounds like what they did with the Commodore 64 (look up the C One computer), basically it's a computer with a slot where you can stick in any other classic computer CPU and it becomes that computer. And it's built with modern PC interfaces for the monitor/keyboard/mouse.

 

[MWeston]

I didn't - sorry. Here you have a link (from almost the beginning):
http://www.gp32x.de/board/index.php?showtopic=26613
(it's a long topic so be patient or jump to the latest pages)

It isn't that complicated but it shows very well some obstacles.

I had a look at that link, very cool! I see a lot of board revisions and a lot of time put into getting a proper D-pad (or similar) into the GP2X. Truthfully, it makes me want to try the original switch that comes in this thing. I can't imagine such a horrible control stick, but I read so many negative posts that I don't doubt it sucks!
Anyway, great job in getting something better in there and I am happy for you that the GP2X has enough room in there to fit the extra board and a DIP part inside!!!

CPUs in the those "higher level consoles" are crippled by one way or another. Except the Dreamcast - it's very reasonably made machine - it has 100mpix of depth complexity free fillrate. Not possible on the GP2x. Not possible on the PSP either.

A FPGA would be most usefull to make existing emus perfect at relatively low cost.
(but problem is to connect it and interface it with GP2x)

I'm not sure what you mean by crippled?

Well, technically, the PSP has a "theoretical" fill rate of 664Mpixels/s which is mind boggling if it is anywhere near true! The NVIDIA GoForce 5500 has 200Mp/s and my design has 100Mp/s so maybe there is hope for an emulator yet (not on the 2X though). The Dreamcast has a higher triangle per second capacity than my design, but again, the PSP's magical specs (33M triangles/sec) are better that the Dreamcast's (6-12M?). The FPGA design shows itself as very useful in an application like this as you have mentioned. I think my biggest problem is that I would like to make my hardware a contribution to the dev community and I think most people are software programmers, not hardware programmers. I'm not interested in coming up with all of these new emulators myself. I would like to generate a new platform for another big team effort.

Hooking an FPGA to the GP2X processor would be difficult since the SDRAM chips use separate data lines from the generic I/F and I'm not sure if there are other chips on board that use this so there may not be any place to piggy back onto. I doubt that unused solder balls are brought to the other side through vias either. No matter, that just inspires me to continue with my design

 

[OMars]

I'd love to see your case designs if you want to send them to me: mjweston3 'at' hotmail.com

Maybe someday you will hold a poll to let everyone decide which one they like best. It might help you come up with the most stylish portable casing ever. I mean, the DS lite is cool, but it's just a white box

Oh, and I'm still planning on developing my idea, don't worry. I can get the parts is smaller quantites (single trays which is better than thousands) and there is an assembly house 15 miles away from my place that will place any BGA package part for about $5 a pop! That makes placing the processor and DDR memory (and FPGA is there was one) very easy and saves me lots of soldering if it was possible to choose 1mm spaced, leaded parts.

Awesome, I'll scan them today if I have more time. You know I'm not to bad at design these things. Also I try to put as few buttons as possible but make it usefull for emulators - it saves money and time...hopefully. So If a team of hardware engineers and designers were to make this how long do you figure it would take to make a successfull prototype?
:huh:
P.S. I know of a few hardware component sites if you want them........

 

[MWeston]

Awesome, I'll scan them today if I have more time. You know I'm not to bad at design these things. Also I try to put as few buttons as possible but make it usefull for emulators - it saves money and time...hopefully. So If a team of hardware engineers and designers were to make this how long do you figure it would take to make a successfull prototype?
:huh:
P.S. I know of a few hardware component sites if you want them........

Sounds good. I'm interested in seeing them. I don't know about the reduced number of buttons. I was actually thinking of putting six buttons on the right side to accomodate emulators such as the Sega Genesis/Megadrive.

Oh, don't worry about providing me with component sites (unless they are obscure ones I probably haven't heard of or are really cheap!). I am an engineer and I have distributors, board manufacturers and assembly facilities at my disposal. About the only service I am not involved with is plastic housing design, but I guess I could ask someone at work where we get that done.

If I were working on this full time, I could imagine having a prototype done by September (just the hardware, no case or code). Unfortunately this is just a fun side project and so working on it depends on how busy my personal and professional life is. Realistically, I was aiming for spring of next year as a time when I could show pictures and have a modified version of the Linux kernel working on my board. It isn't easy to get realistic price quotes unless you have a full bill of materials, exact gerbers and physical specs for the unit itself and so it would need to get to that point before seeing if I would make more.

 

[Shaun]

It would be sweet to see an N64 emulator for the 2X, if it were utilising both of the CPUs, but that's unlikely, or maybe impossible. Not that I'd know...

 

[Draco]

It would be sweet to see an N64 emulator for the 2X, if it were utilising both of the CPUs, but that's unlikely, or maybe impossible. Not that I'd know...

First off, this is the wrong thread for this and this has been discussed many times already, the conclusion was: It won't happen.

 

[Radek]

I didn't - sorry. Here you have a link (from almost the beginning):
http://www.gp32x.de/board/index.php?showtopic=26613
(it's a long topic so be patient or jump to the latest pages)

It isn't that complicated but it shows very well some obstacles.

I had a look at that link, very cool! I see a lot of board revisions and a lot of time put into getting a proper D-pad (or similar) into the GP2X. Truthfully, it makes me want to try the original switch that comes in this thing. I can't imagine such a horrible control stick, but I read so many negative posts that I don't doubt it sucks!
Anyway, great job in getting something better in there and I am happy for you that the GP2X has enough room in there to fit the extra board and a DIP part inside!!!

CPUs in the those "higher level consoles" are crippled by one way or another. Except the Dreamcast - it's very reasonably made machine - it has 100mpix of depth complexity free fillrate. Not possible on the GP2x. Not possible on the PSP either.

A FPGA would be most usefull to make existing emus perfect at relatively low cost.
(but problem is to connect it and interface it with GP2x)

I'm not sure what you mean by crippled?

Most consoles CPUs are far less powefull then comparing to theirs data sheets. The N64 for an example - it has 64 bit MIPS4300 derivate at 93.75MHz however it's permonance is seriously compromised. It was so because the CPU had to talk to memory vie the RCP chip and a massive rdram latency.

Then we the Jaguar with two pretty decent RISC cores plus usual 68000. But its risc cores can only read instruction codes from theirs "caches". Such flaw imposed need of constant reloading them as they were too small to contain a whole code.

Other machine also have such "features". It was this "crippling" what I had in a mind.

Well, technically, the PSP has a "theoretical" fill rate of 664Mpixels/s which is mind boggling if it is anywhere near true! The NVIDIA GoForce 5500 has 200Mp/s and my design has 100Mp/s so maybe there is hope for an

It's not realistic thought. My Radeon 9550 as stock speed shows similar figures in actual tests. Yet it slays PSP badly therefore the
664Mpix/s" figure it just a theoretical maxim.

emulator yet (not on the 2X though). The Dreamcast has a higher triangle per second capacity than my design, but again, the PSP's magical specs (33M triangles/sec) are better that the Dreamcast's (6-12M?).

The Dreamcast is a very different kind of a machine. It's GPU (a deffered, tiled based renderer) is immune to overdraw factor (mostly) and should not be loosing efficiency with higher number at triangles so fast as in normal "GPU".

PSP GPU would have a very hard time with it.

The FPGA design shows itself as very useful in an application like this as you have mentioned. I think my biggest problem is that I would like to make my hardware a contribution to the dev community and I think most people are software programmers, not hardware programmers. I'm not interested in coming up with all of these new emulators myself. I would like to generate a new platform for another big team effort.

I'm now learning Verilog and got a reasonably grip on it.
Actually it proved very usefull thought I'm yet to have try a FPGA.
(was experimenting on cheaper and simpler CPLD)

Not that really harder than C except the concept of wires and conccurent statements execution can be very weird at first.

Hooking an FPGA to the GP2X processor would be difficult since the SDRAM chips use separate data lines from the generic I/F and I'm not sure if there are other chips on board that use this so there may not be any place to piggy back onto. I doubt that unused solder balls are brought to the other side through vias either. No matter, that just inspires me to continue with my design

There is one trick - remove existing SDRAM chips and connected those signals pads to a FPGA. Then implement SDRAM protocol into a FPGA so MMSP2 would be fooled and we could be able to do everything in MMSP2 memory space at will in a FPGA.

Sure - still there will be need of some extra memory to connect to a FPGA. But it should be workable.

Another (easier?) idea is to intercept LCD signals, and add some overlays into it and output it back to the LCD screen. It'd be easier to connect but less flexible.

Yet another it'd be connecting a FPGA via USB internally in GP2x. But... it'd be very bandwith limited so no practical for all tasks. However 320x240x16bpp at 30fps will need only 4500KB/s...
(how big transfers can built in GP2x's USB2 controller sustain?)

 

[MWeston]

Most consoles CPUs are far less powefull then comparing to theirs data sheets. The N64 for an example - it has 64 bit MIPS4300 derivate at 93.75MHz however it's permonance is seriously compromised. It was so because the CPU had to talk to memory vie the RCP chip and a massive rdram latency.

Then we the Jaguar with two pretty decent RISC cores plus usual 68000. But its risc cores can only read instruction codes from theirs "caches". Such flaw imposed need of constant reloading them as they were too small to contain a whole code.

Other machine also have such "features". It was this "crippling" what I had in a mind.

I understand what you mean now. I think the N64 only used 8-bit wide memory too. That's pretty crappy when instructions could be 32 or 64 bits wide!!!

There is one trick - remove existing SDRAM chips and connected those signals pads to a FPGA. Then implement SDRAM protocol into a FPGA so MMSP2 would be fooled and we could be able to do everything in MMSP2 memory space at will in a FPGA.

Sure - still there will be need of some extra memory to connect to a FPGA. But it should be workable.

Another (easier?) idea is to intercept LCD signals, and add some overlays into it and output it back to the LCD screen. It'd be easier to connect but less flexible.

Yet another it'd be connecting a FPGA via USB internally in GP2x. But... it'd be very bandwith limited so no practical for all tasks. However 320x240x16bpp at 30fps will need only 4500KB/s...
(how big transfers can built in GP2x's USB2 controller sustain?)

Interesting ideas but not too many people would be willing to do that to their GP2X's so it would be for your pleasure only

 

[OMars]

Hey, MWeston and Radek, check this site out..... h34r:

 

[Dzz]

Hey, MWeston and Radek, check this site out..... h34r:

That's not even funny.

 

[Ravnos]

Hey, MWeston and Radek, check this site out..... h34r:

That's not even funny.

???

I'm confused. Is there something about that link that's offensive?

 

[Dzz]

Ok, me and Skyone have been talking for a while and we've scrapped all the current plans. We have now decided to use the Propeller chip as the main processor. Even the power supply has to be redesigned because the Propeller runs at 3.3v! Well, whatever. A 90Mhz 32-bit chip is going to be way better then whatever I was thinking of before. Wink

A cool feature of the Propeller is its programming langauge. It is programmed in a langauge called "Spin" which is a variation of BASIC and Pascal. If wanted, the chip can also be programmed in assembly.