Retroblox

[kevtris]

...and if they can deliver once they've collected crowd funding. I think that's the biggest issue with this kind of project, honestly.

That's the problem I have with it too- they supposedly have all the parts (including the cart adapter, front end, emulators, enclosure, system, etc) so why do they all of a sudden need money to get it working? I think the pieces are already done- just make it work as a proof of concept, THEN ask for the money once you can show it works.

[Flojomojo]

That's the problem I have with it too- they supposedly have all the parts (including the cart adapter, front end, emulators, enclosure, system, etc) so why do they all of a sudden need money to get it working? I think the pieces are already done- just make it work as a proof of concept, THEN ask for the money once you can show it works.

Yes. Product first, paying customers second. That's the way most people sell things of value.

[enoofu]

 

That would be my definition of "hybrid emulation"

 

Pop in starfox, the console side SNESy bits are handled by software emulation whilst coordinating with the cart's SuperFX chip for superfxy bits.

 

Based on kevtris' statement, this is bollocks.

 

Kevtris and Elmer are both industry professionals and believe their main issue was that it would be very hard to program since the hardware on the carts are very limited in speed and Chips like the FX are Co Processors (Think CPU) and would need to be syched with at least one CPU core 100% of the time at extremely slow speeds

 

Even more so since ARM SoC's don't have much of a good reputation in terms of memory and other resources to offload some of this work

 

They are not discounting the ability for someone to program, but it doesn't make business sense to add since it would add a lot of programming hours best used elsewhere, especially since this ability will probably slow down the emulation from running at real time with no real benefits for consumers

[Hyperboy]

New Info: (grain of salt not included).

http://www.nintendolife.com/news/2017/02/exclusive_getting_under_the_hood_of_retroblox_the_clone_console_to_rule_them_all

 

 

Sent from my non beer holding hand.

[xiaNaix]

Another puff piece with no real specifics. I hope these guys plan on getting serious about the technical details before launching their crowdfunding campaign.

[Flojomojo]

Another puff piece with no real specifics. I hope these guys plan on getting serious about the technical details before launching their crowdfunding campaign.

[elmer]

New Info: (grain of salt not included).

http://www.nintendolife.com/news/2017/02/exclusive_getting_under_the_hood_of_retroblox_the_clone_console_to_rule_them_all

OMFG ... I'm really starting to dislike that guy.

 

So much name-dropping and appeals to Authority Figures to show that they know what they're doing.

 

Jeez ... their team created SpaceX's Dragon Module, they really *are* a bunch of Rocket Scientists!!!

 

 

And then ...

 

Could you explain what makes "Hybrid emulation" so special?

 

Without going into an extreme technical explanation (you can read that here), Hybrid Emulation allows emulators to read cartridges and controllers electrically so that they function like the real consoles did when they're connected to a modern system on a chip (SOC) style processor.

Errr ... no I can't read an "extreme technical explanation" on your website, it's vague and full of holes.

 

That "extreme technical explanation" is *exactly* what I do want to read.

 

FFS ... these guys have already filed their Patent Application, they're in-the-queue with a datestamp on the tech ... there shouldn't be any reason to avoid talking bragging about it.

 

 

And then ...

 

Some of the retro game systems that use optical media require special ways of reading data off of discs so that original games can be used. HLDS have been working with us to improve the firmware and reading of this data on the optical disc drive that ships with RetroBlox. That's all we can say about that, for now.

Really?

 

You need 8-10 months after the Kickstarter to finish building the console, and you need crowdfunding money to do it, but Hitachi are already dedicating expensive engineering time to write custom firmware for the optical drive just for you?

 

 

Sure, it could be true.

 

Sure, this could all be true.

 

But it really *smells* of the same kind of exaggeration that Mike Kennedy was throwing around about when he said that he was having discussions with Konami about them developing for the RetroVGS.

 

 

They've got about 2 months left to really show stuff working.

[godslabrat]

OMFG ... I'm really starting to dislike that guy.

 

So much name-dropping and appeals to Authority Figures to show that they know what they're doing.

 

Jeez ... their team created SpaceX's Dragon Module, they really *are* a bunch of Rocket Scientists!!!

 

 

 

The "industry veterans" card is very overplayed. Lots of high profile projects led by "industry veterans" have fallen completely on their faces. Once someone, even someone very talented, leaves their organization, they often leave behind the pool of talent that made the rest of the project possible. It's very possible that if you took Miyamoto out of Nintendo, he might never be able to make another Zelda-caliber game again, because although he'd still have his vision, he'd lack the pool of hundreds of other people who knew how to work with him to make it a reality.

 

Breaking up the Beatles doesn't usually end well.

 

 

 

FFS ... these guys have already filed their Patent Application, they're in-the-queue with a datestamp on the tech ... there shouldn't be any reason to avoid talking bragging about it.

 

Agreed. If they have what they say they have, then it can only help them to show it off. The alleged technology behind this project is the real appeal, not the fancy cases or cool blog. They have to realize that. If they're avoiding the topic, that says to me either the tech isn't what they're implying it is, or they're plain clueless on who their market is.

 

 

 

You need 8-10 months after the Kickstarter to finish building the console, and you need crowdfunding money to do it, but Hitachi are already dedicating expensive engineering time to write custom firmware for the optical drive just for you?

 

Sure, it could be true.

 

Sure, this could all be true.

 

But it really *smells* of the same kind of exaggeration that Mike Kennedy was throwing around about when he said that he was having discussions with Konami about them developing for the RetroVGS.

 

Exactly like Mike. Every time these jokers release some sort of info, the comparisons between this and the CC get closer, not further away. Like I said, I do believe they've gotten as far as cobbling together a unit out of off-the-shelf parts and writing a front end for it (more than Mike ever did) but that still doesn't answer the claims they're making in the press materials.

Edited February 13, 2017 by godslabrat

[Keatah]

I'm an "industry veteran" when it comes to emulators. Been working with them since the late 1980's. But I can't program them worth the shit. Well not in any significant depth anyways..

Edited February 13, 2017 by Keatah

[+Atari_Warlord]

I'm intrigued enough to see what they're doing, but not enough to give them money yet. To meet their manufacturing deadline they would need the hardware spec complete and a factory lined up when they go for crowd funding. Otherwise it will end like most hardware projects, long delays and under deliver on promises.

[godslabrat]

I'm intrigued enough to see what they're doing, but not enough to give them money yet. To meet their manufacturing deadline they would need the hardware spec complete and a factory lined up when they go for crowd funding. Otherwise it will end like most hardware projects, long delays and under deliver on promises.

Indeed, there's a HUGE disconnect here. Retroblox is talking about shipping in as soon as 8 months after the kickstarter. The only way that's going to happen is if they literally have every step finalized and just have to call up China and tell them to push the "Start" button. Were that the case, they wouldn't be fussing around with incomplete prototypes or slow-dancing around questions about supported systems.

 

So either we've got a team who thinks they can bluff and spend their way into a turnkey product (ie, stupid) or we've got a team who think they can lie about anything just to get the money (ie, dishonest).

[Keatah]

Mmm.. they probably don't know what they're getting into. Asking for funds while they figure it out.

[keepdreamin]

Hybrid Emulation allows emulators to read cartridges and controllers electrically so that they function like the real consoles did when they're connected to a modern system on a chip (SOC) style processor. So, instead of dumping the ROM file from the cartridge and holding it in resident memory as other consoles do, we read the data that is input and output from the connectors on the Element Module directly to the CPU at a "bare metal" level like the real systems. This means we never have to guess what's happening inside the cartridge, significantly increasing compatibility with homebrew cartridges and other special types of games that aren't likely to work well on a 100 percent emulation system.

 

What a terrible explanation.

 

I'll give my best guess... They've found* someway to actively access data from a cart on the fly, vs from a Rom dump in memory. So homebrew games that typically have problems with dumping (Pier Solar for example) on systems that go that route (Retron 5) will have increased compatibility. I'm seriously doubting carts that use on board processors (star fox, virtua racing) will actively be using those chips. Most likely handled by the emulator like normal.

 

*yeah, maybe

[Keatah]

There's no magic secret secret to accessing a cart on the the fly. It's a simple matter of clocking in the address and reading the data lines.

 

Dumping is the same thing, just that you go sequentially from 0 to 2048, for a 2K VCS cartridge, till you've gone through the whole cartridge. When running a cartridge, the emulator or console will simply be addressing memory as the "Game Program" needs it.

 

Cartridges with CPUs and auxiliary processors in them are much more complex. Setting an address and toggling data lines might set a whole new dynamic pattern of data output with no further addressing. Much different than the fixed output of "traditional" ROM. It be like sending a command to draw a polygon here at x,y.. and the cartridge's CPU will spit it out without further intervention from the console. The console can go about its way running the "Game Program" without further worry.

 

Software emulators like BSNES/HIGAN emulate that co-processor too. It's nothing new.

 

---

 

You can think of the "cartridge with cpu" as the mother of a fat-ass spoiled 30-year old who won't get out of the basement.

 

The console is the kid, and the kid doesn't write videogames, doesn't earn money, doesn't leave the house.. Instead he makes mommy go out buy them from the store. 1 command, and a whole new set of games arrives as if by magic.

Edited February 14, 2017 by Keatah

[Andromeda Stardust]

New Info: (grain of salt not included).

http://www.nintendolife.com/news/2017/02/exclusive_getting_under_the_hood_of_retroblox_the_clone_console_to_rule_them_all

 

 

Sent from my non beer holding hand.

 

 

I'm still cautiously optimistic about this thing, as it seems these guys have really done their homework, but also heed what Kevtris said about using GPIO pins for the cartridge interface. I imagine some amount of FPGA resources will be necessary to offload the bus interface.

 

One option would be to have the console CPU in FPGA and offload the realtime video/audio bits from the FPGA to the ARM/GPU for upscaling. If done properly, the delay might be less than 16ms.

 

Such a hybrid approach would allow for the FPGA to be much smaller since it doesn't need to interface the HDMI controller directly.

 

 

After getting my setup dialed and enjoying it for a while (without being totally satisfied), I started talking to some friends from the gaming industry about an idea to create a nice FPGA PC-Engine / TurboGrafx-16 (the system I wanted to play most on my HD monitor), and I got in contact with Rob Wyatt, who is one of the top minds around when it comes to video game tech. He was into the idea, so we started working on it. After a few months of research, we discovered the emulation method (which we now informally call "Hybrid Emulation") that would have the potential to benefit quite a lot of different retro gaming fans who were struggling with the same issues we were.

Seeing its potential, we decided to modify the industrial and mechanical design of our yet-to-be named system to be modular, with the intent of supporting a broad range of classic consoles (not just the 3-5 most popular ones). By doing so, it gave rise to the idea of RetroBlox and what you see today.

[cybercylon]

Correct me if I am wrong as I am not very familiar with business world, but don't project managers basically oversee the project and make sure the various people involved in the different aspects stay on task and resolve any issues among the different departments? I am sure a software PM probably has some degree in IT or computer science, but how much are they involved in the nuts and bolts, battling in the trenches?

 

The question is not meant as a critique... just curious.

[MagnaRyuu]

Good lord the more I read on this the more it just seems so damn stupid. The design is just stupid as shit frankly.

[Keatah]

FPGA is no holy grail of any kind. No ticket to error-free emulation. And that's what FPGA is, emulation. And it's even more spotty when you're limiting its size. Believe me you always want to have some headroom for performance improvements and bug fixes and the like. This goes for ALL FPGA projects.

Edited February 14, 2017 by Keatah

[Keatah]

Good lord the more I read on this the more it just seems so damn stupid. The design is just stupid as shit frankly.

 

Just wondering exactly what you think is stupid about it?

[elmer]

I am sure a software PM probably has some degree in IT or computer science, but how much are they involved in the nuts and bolts, battling in the trenches?

Hahaha ... nope no degree required.

 

In my *personal* experience, it's an Administrative and People-Skills job.

 

At a videogame company the size of Insomniac, they're probably there to make sure that schedule is being kept, that the tasks are being done, that the Programming/Art/Sound/Design/etc Directors (the ones that do the real technical stuff) actually have what they need, that the client's Producer is happy, and that the client's concerns are all being met.

 

They spend a lot of time on the phone, or making sure that the coffee supply doesn't run out and that the fridge is stocked with soda (maybe beer, too), and that there's a decent-enough rotation on the free-dinner menu that the grunts don't complain too much at the mandatory-overtime.

 

They are there to grease the wheels. It's an important job ... it needs to be done. But it's not a "technical" job.

 

They often have "ideas", and some of those "ideas" might be good ... but, like everyone else, not all.

 

In the case of an existing Sony-owned franchise like Ratchet & Clank, I'd be very surprised if Brian would have had much, if any, creative control.

 

It's not like film-production where the Producer might be the guy that ropes in the financing and keeps a tight lid on things.

 

Then again, perhaps Insomniac was different to the companies that I saw.

 

Doesn't sound too much like it, though.

 

I've seen many, many other guys that went from QA-Tester to Producer/Project Manager.

Edited February 14, 2017 by elmer

[Newsdee]

I read their page explaining Hybrid emulation. They seem to be claiming that because they wrote some software stack on a low level OS, their system can integrate directly with the cartridge.

 

That seems very dubious to me, because if true it means that emulators would also meed a big rewrite to work on such OS (granted a few older ones are in C, so it's doable but a lot of work).

 

Also they don't seem to know that a very decent and open-source FPGA inplementation of the PC Engine already exists, ported to several boards. Why try to reinvent the wheel when polishing that up would give you a very good PCE clone? (like the AVS).

 

I suppose they want to be able to patent their "hybrid" tech but I wonder if they have an inplementation of it, or it's just a proof of concept / idea for a software patent.

[philyso]

That seems very dubious to me, because if true it means that emulators would also meed a big rewrite to work on such OS (granted a few older ones are in C, so it's doable but a lot of work).

 

 

Not necessarily, emulated cartridge access are usually segregated and localized in emulated CPU memory handlers (read_byte, read_word, write_byte, etc), it's just a matter of replacing existing functions with 'read_cartridge' or 'write_cartridge' functions that make access to their low-level API. The hardest part is actually not to modify existing emulators but to write that API, and, as already explained by others, to actually interface with the real cartridge bus (at signal levels) and deal with its limitations in real-time while the CPU emulation loop is running.

 

At this point, it would be more interesting to have interview of these Eric Christensen & Rob Wyatt guys to get REAL technical information and a better insight to figure if this is really more than just a conceptual idea.

Edited February 14, 2017 by philyso

[kevtris]

 

Not necessarily, emulated cartridge access are usually segregated and localized in emulated CPU memory handlers (read_byte, read_word, write_byte, etc), it's just a matter of replacing existing functions with 'read_cartridge' or 'write_cartridge' functions that make access to their low-level API. The hardest part is actually not to modify existing emulators but to write that API, and, as already explained by others, to actually interface with the real cartridge bus (at signal levels) and deal with its limitations in real-time while the CPU emulation loop is running.

 

At this point, it would be more interesting to have interview of these Eric Christensen & Rob Wyatt guys to get REAL technical information and a better insight to figure if this is really more than just a conceptual idea.

It isn't that easy though. Emulators typically operate in "Batches"- i.e. rendering a scanline worth of CPU, saving a list of writes to the video/audio chips, render a scanline worth of video, render X samples of audio, and so on. This will not work trying to read cartridges. They do not like to be read faster than the original console would read it, and many NES games will not tolerate any variation in access rates at all- so the game will crash if it isn't monotonous (i.e. one access after another, with the same timing, over and over).

 

Sure it'd be possible to use a multi core CPU to emulate various parts at the same time (i.e. video, audio, other stuff) but synchronizing all the threads would be extremely difficult. You'd need them all to run in lock-step somehow, either via interrupts (not too likely due to the overhead of the interrupt handler) or some kind of semaphore (i.e. a variable the core polls, waiting for some kind of signal to run).

 

I don't see much easy way to do this stuff without at a minimum totally rewriting your emulator core- this definitely is not going to be happening here if they are hoping to run more than a few systems in any reasonable time period. This is IF the idea will work, and honestly I think it is all a pipe dream.

[philyso]

Yes, I know that, the access time for those old cartridge interface is way slower than modern system RAM access time (I think I addressed it in an earlier post) but my point is that there isn't much things that can be 'rewrote from scratch' because software emulation always fundamentally work the same way and this cannot be changed so, unless I'm missing something, I don't see any other ways than naively patching cartridge access functions in emulator code.

 

Indeed, the first thing that ANY emulator does is to emulate the native CPU, which will continuously fetch instructions from cartridge ROM to decode them, then eventually do more access (read/write) to cartridge area. You cannot change that, it already syncs to cartridge every single instructions, it's just that since ROM is copied in system RAM, this is quite fast but this will however result in a huge bottleneck if you start being locked to external hardware access timings for every instructions, and a lot of potentially wasted host CPU cycles that are needed for emulating the rest of the console hardware.

 

I agree with you that this also goes even madder when it comes to on-board co-processors or DSPs since they will run at their own speed (i.e the original speed) so the whole emulated hardware will need to keep in sync with that process.

Edited February 14, 2017 by philyso

[Newsdee]

Yes, I know that, the access time for those old cartridge interface is way slower than modern system RAM access time (I think I addressed it in an earlier post) but my point is that there isn't much things that can be 'rewrote from scratch' because software emulation always fundamentally work the same way

There's a fundamental difference in how a CPU works versus a electrical circuit, in that it (a single core) can only do an instruction at a time when in a circuit everything can happen in parallel.

 

FPGA are designed to replicate circuits, and work in parallel. They have their own problems and limitations, but play much better with original hardware for that reason. This guy has a nice simple explanation of the benefits in his introduction to the MiST: http://youtu.be/CVq_jzj_u8U

 

Now, I think there's a very simple way to test these guys' claims: run an Everdrive on the NES core. If it truly interfaces with the hardware without tricks (like dumping the ROM) then it should just work.