Retroblox

[godslabrat]

Blast processing and fisticuffs.

[dj_convoy]

300.00 plus a nebulous add on fee for each module is disastrous (assuming that's where they end up). I preordered my Retron from Amazon, so I paid like 80 or 90 bucks for it and I think the actual retail was like 120 or 130. Retro Freak I think was around 200.00 and also had a couple of add ons you need to buy... just skirting the edge of unacceptability. It's just too much.

 

"our team discovered a new method of emulation that provides the advantages of an emulation-based system with the broad compatibility of an FPGA-based system." still tells us nothing. It's just double speak.

 

"[The emulators are] built from the ground up in Linux, fully optimized for our system so that we can access the architecture from the bus-level and I/O from cartridge interfaces and controllers directly via high level emulation on the heart of the system, the Rockchip RK3288. This means we don’t have to rely on software emulation of memory mappers and/or co-processors that may not be fully optimized, which in turn frees up valuable resources to ensure other aspects of the machine run smoothly." Well, it's better be built from the ground up because, when we inevitably find out that isn't the case...

 

"It just works." Not remotely good enough and you'd better not use anything remotely resembling that language in the KS campaign.

[Andromeda Stardust]

EVERYTHING YOU NEED TO KNOW

 

WHAT’S HYBRID EMULATION?

 

Hybrid emulation is a completely new way of tackling emulation, providing the cost-effective and future-friendly advantages of high level emulation as well as the accuracy and compatibility advantages of using clone hardware or FPGAs (Field-Programmable Gate Arrays) to model the original consoles.

Hybrid Emulation is unique in that it requires software emulators to function at a much lower level than the ones you can simply download for your PC, Phone or RetroPie / RetroArch / LibRetro box. RetroBlox’s proprietary RBXOS and Richter UI environment are built from the ground up in Linux, fully optimized for our system so that we can access the architecture from the bus-level and I/O from cartridge interfaces and controllers directly via high level emulation on the heart of the system, the Rockchip RK3288. This means we don’t have to rely on software emulation of memory mappers and/or co-processors that may not be fully optimized, which in turn frees up valuable resources to ensure other aspects of the machine run smoothly. This is especially important to the homebrew community where many developers have created their own bank-switching and mapping mechanisms to extend the abilities of the original platform far beyond the manufacturers original intent. With Hybrid Emulation, we do not need to be privy to the intimate details of how the cartridge expansions function to have their software run on RetroBlox. It just works.

While this may sound like a magical, do everything under the sun console – some discerning folks recently asked what it WON’T do. Right off the bat, you won’t be able to play games that purely rely on light gun controller input. The limitations of light gun technology vs. HDTVs have been a constant struggle for those that enjoy the genre (including us!). However, we would like to address this issue sometime down the line after RetroBlox launches. For the moment, we are 100% focused on delivering what we have committed to above. Please note that light-gun type games that support controller D-Pad input will work fine on RetroBlox.

If true, this will be amazing if they can pull it off.

[Flojomojo]

Blast processing and fisticuffs.

Do the math!

[enoofu]

hybrid emulation can mean a lot of things. We still do not know what it means when talking about retroblox.

Hybrid emulation has been well defined especially since the below companies use the term

But its sounds like he is using the term incorrectly

 

Synopsys, Cadence and Aldec

[Keatah]

..aaaannndd what is hybrid emulation again?

 

So.. With a RockChip SoC, no recreation in FPGA.. That leaves you with software emulation or a mix-match of the original hardware built into the module (not likely). Where the software emulator gets its data from, a cartridge, disc, iso file, binary file from SD card, doesn't matter.

 

The question no one is asking is where does the emulation processing take place? What part of system is doing it?

[enoofu]

Basically just software emulating some hardware components like a FPGA, also it will not have 100% cycle accuracy

 

Also these process would happen in the SoC like any other piece of software

Edited February 9, 2017 by enoofu

[xiaNaix]

The Retro Freak can run some multicarts and "homebrew" carts too. So far I don't hear anything in the double talk that these guys are posting that sounds like it's anything new, other than their "proprietary RBXOS and Richter UI environment." They are clearly going out of their way to not get into technical details on how the hardware functions. I would hope those answers will be forthcoming before they start taking people's money for a lot of smoke and mirrors but I doubt it.

[elmer]

The question no one is asking is where does the emulation processing take place? What part of system is doing it?

Errr ... it is taking place in software on multiple cores in the RK3288 ARM SoC.

 

I thought that was quite obvious from their many postings.

 

It's just that while normal emuators concentrate exclusively on *what* the emulated VirtualCPU instruction does to memory, and registers and flags, they're going down a step below that and also concerning themselves with timings of the bus-access patterns so that they can emulate the signals on the cartridge-bus, and so access real physical data from a real cartridge, and not do it too fast, or too slow.

 

It's the kind of thing that Kevtris must have to think about when he writes his code that programs the FPGA.

 

They're probably just skipping some of the more-annoying steps and letting ARM instructions handle those.

 

I can see how it *could* work in practice ... and how it *could* provide some benefits to balance the costs.

 

Most obviously ... they wouldn't have to care about what expansion chips are on a SNES cartridge., or try to emulate them or figure out what "mapper" is used.

 

They'd just pretend to be the emulated-console's main CPU, and access the cartridge hardware in just the way that it would, with just the same electrical signals on the cartridge bus.

 

So to the coprocessor on the cartridge ... it would just look like it was plugged into a real machine.

 

It's a nice theory, but how well they've got it to work in *practice* is anyone's guess, and that's even if they're doing that, and not something else entirely.

 

There's also the huge question of what benefits would this scheme actually provide, except to run real hardware cartridges in a world where nobody under 30 cares, and would just prefer 100% digital.

 

All-in-all, even if these guys are legit (as they still may well be), their vision of a "fun" machine isn't one that I share, with its lockdown and HomeBrew Store, and expensive add-ons, and all of the other stuff that goes beyond making a cool product, and instead, into following Mike Kennedy's RetroVGS business plan to create an EMPIRE!

[Keatah]

Basically just software emulating some hardware components like a FPGA, also it will not have 100% cycle accuracy

 

Also these process would happen in the SoC like any other piece of software

Did I read that right? Software emulating an FPGA? Edited February 9, 2017 by Keatah

[elmer]

Did I read that right? Software emulating an FPGA?

Personally, I'd suggest that you read that as ...

 

"Basically just software emulating some hardware components, with the same results as an FPGA (emulating other hardware), except that it will not have 100% cycle accuracy.

 

Also these process would happen in the SoC, like any other piece of software."

 

 

I'm of the *opinion* that they're dedicating one or more cores to this emulation, at least to the VirtualCPU, because I don't see how they could get the tight roughly-cycle-accurate timings needed to access the cartridge bus, in any other way. But I could easily be wrong.

[Keatah]

So it's software emulation running on a traditional cpu.

 

It also doesn't make sense they'd go through the trouble to access the cartridge interface with accurate timing, and then blow it in the software emulator portion.

Edited February 9, 2017 by Keatah

[StopDrop&Retro]

I've come up with a hypothesis.

 

I think the guy writing all the PR and the Kickstarter pitch have employed someone much like elmer working behind the scenes. I'll refer to this unknown man as 'Evilmer' from now on.

 

Fig. 1, Evilmer

 

 

Evilmer has some level of expertise, maybe a nice puffy resume and is confident that he can do this, but he will need time, which is perfect because the backers will have to wait for delivery anyways. In the meantime we can make the money right now. So Evilmer instructs the PR guys to just fake the hardware at the show for now and worry about sorting the real stuff and licensing issues after a big Kickstarter success. The fact that they were playing Mega Man X2 without a cart and loading up whatever rom and image files they had on hand is hugely telling.

 

In other words, fake it till you make it. Money will solve all their problems. Your money more specifically, not theirs. Sounds a lot like Mike... did anyone else get a chill down their spine as they heard the rough $300 estimate?

 

These YouTubers, especially Gamester81, really need to reevaluate what they're getting into. Yes, this could all be real. Tomorrow they could go full disclosure and we on this forum will end up with egg on our faces, big whoop. But if someone with an audience like him ends up getting roped into yet another scampaign, that'll be a hard stigma to shake.

[elmer]

It also doesn't make sense they'd go through the trouble to access the cartridge interface with accurate timing, and then blow it in the software emulator portion.

Because (IMHO) ... if they *chose* to spend the development time to do so, they *could* get probably-accurate-enough timing in a software emulator.

 

We used to count-cycles all of the time, back-in-the-day, and this would just be a matter of "degree", not of "kind". It could be done to a decent level of accuracy.

 

If you 100% *dedicate* a 1.7GHz ARM core to the task, with *no* linux time-sharing or other BS, you get back into the cycle-counting days, where you can tweak the time taken by each emulated-instruction down to the single-ARM-cycle if you have the right tools.

 

1.7GHz gives you 1700 ARM cycles per 1 VirtualCPU cycle. You can do one-heck-of-a-lot of bit-twiddling and other emulation in 1700 ARM cycles, if you're an assembly-language programmer that knows the *exact* target processor and can count.

 

If your ARM CPU has a cycle-accurate real-time-clock, you can do the same thing, but be a bit sloppier and write it in C code.

 

Now ... none of this speculation says that's that what these guys have done, or if there wouldn't be some show-stopper problem down-the-line.

 

It would be one-heck-of-a-lot of work, and doesn't seem reasonable in the time period that they say that they've been developing this.

 

It's a theory.

 

I could be 100% wrong and full-of-cr*p.

 

But, as an experienced assembly-language programmer, I *believe* that there's a good chance that it *could* be done on the fast modern ARM SoCs that have only appeared in that last decade-or-so.

 

So I'm willing to give these guys a *chance* to show their hand, and really *prove* that their hype is justified (BEFORE the KickStarter).

 

I'm massively skeptical, and whatever the truth ... I still prefer the idea of Kevtris's Zimba3K, and trust his approach more than these guys.

 

But this team is NOT showing quite the same signs of absolute-total-raving-BS as the RetroVGS crew, IMHO ... at least not just yet.

 

There are *huge* concerns ... but I'd like to remain a "skeptic", rather then a member of the "AtariAge Hater Brigade" for a little while longer.

[philyso]

I think this is pretty clear from their statement (and from their initial press release) what they mean by 'Hybrid Emulation' (and it's probably a term they 'invented', not something related to an existing concept, even if that term is already used elsewhere or trademarked by other companies).

 

I think the 'FPGA' thing is only there to indicate they will deal with cartridge interface at signal levels , I'm pretty sure stock console hardware emulation level will remain unchanged and I doubt they will be writing their own emulators for all these systems from scratch, it would be too much costly for no benefits at all, so this will be as much accurate as whatever existing emulator they are using as code base.

 

The concept of 'Hybrid Emulation' is simply to remove the 'cartridge hardware' (and maybe also input controller hardware, not 100% sure) emulation part from the software emulator and let it only handle stock console hardware emulation. As already said, this is certainly more accurate than what existing SNES emulators are doing when it comes to DSP or co-processor emulation and could make emulation of games with exotic mappers easier but it will not necessarily make any differences to end-users since all those mappers, DSPS, etc are already well documented and emulated.

[enoofu]

Pretty sure they are just using Hybrid Emulation and FPGA since they are newer industry terms to make it sound like they are cutting edge

 

Also the ARM SoC they are using should be able to run a SNES with pretty close 100 speed and accuracy with software alone

[elmer]

The concept of 'Hybrid Emulation' is simply to remove the 'cartridge hardware' (and maybe also input controller hardware, not 100% sure) emulation part from the software emulator and let it only handle stock console hardware emulation. As already said, this is certainly more accurate than what existing SNES emulators are doing when it comes to DSP or co-processor emulation and could make emulation of games with exotic mappers easier but it will not necessarily make any differences to end-users since all those mappers, DSPS, etc are already well documented and emulated.

Yep, that would be consistent (IMHO) with what they've actually had the time to do, given that they claim to have been doing this for a little over a year.

 

And I agree ... at the end-of-the-day, why bother? What advantage does it really give to the end-user?

 

I've not had any problems running stuff in an emulator like Mednafen in years.

 

I don't get why folks would contemplate paying them that kind of money just to plug a cartridge into an emulator???

 

 

I've come up with a hypothesis.

 

I think the guy writing all the PR and the Kickstarter pitch have employed someone much like elmer working behind the scenes. I'll refer to this unknown man as 'Evilmer' from now on.

Hahaha ... excellent ... but you're getting a bit paranoid!

 

I get it ... you're concerned that I'm trolling.

 

You obviously don't remember my posts from the RetroVGS threads, even though I remember your posts and watched your videos, and AFAIK you don't seem to hang around the PCEngineFX forum (which is my usual haunt).

 

(Sorry, but AtariAge has lousy coverage of the PC-Engine/TurboGrafx16, and I sold my Atari 800 many years ago.)

 

No, I'm not on the RetroBlox team, and couldn't-care-less whether they crash-n-burn (BEFORE the KickStarter, after that, I would care, because they'd better deliver).

 

But if it makes you feel happy to be paranoid, go ahead.

 

You can check me out anytime just by looking. I'm easily traceable.

[philyso]

If you 100% *dedicate* a 1.7GHz ARM core to the task, with *no* linux time-sharing or other BS, you get back into the cycle-counting days, where you can tweak the time taken by each emulated-instruction down to the single-ARM-cycle if you have the right tools.

 

1.7GHz gives you 1700 ARM cycles per 1 VirtualCPU cycle. You can do one-heck-of-a-lot of bit-twiddling and other emulation in 1700 ARM cycles, if you're an assembly-language programmer that knows the *exact* target processor and can count.

 

If your ARM CPU has a cycle-accurate real-time-clock, you can do the same thing, but be a bit sloppier and write it in C code.

 

Now ... none of this speculation says that's that what these guys have done, or if there wouldn't be some show-stopper problem down-the-line.

 

It would be one-heck-of-a-lot of work, and doesn't seem reasonable in the time period that they say that they've been developing this.

 

It's a theory.

 

There is much more than just original CPU to emulate, there are PPU, VDP(s), various sound chips, bus arbiters, etc... and not all of them behave like a traditional CPU.

Also, one of the hardest aspect of emulation and the one that takes most of your host CPU cycles is the synchronization between all these emulated chips. On original hardware (or a FPGA), all these 'cores' would run in parallel and synchronize themselves naturally but with software emulation running on a CPU, you have to run each core sequentially and keep them synchronized (i.e when one access another, you need to make sure the latter did not advance further than the former). Even if you are using multi-core CPU, the task is not easier (and sometime more complicated than with single threaded design) because of this synchronization.

 

Simply put, they are using an ARM Soc which means they are using software emulation running on a CPU as a base: they will use whatever emulation technique has been used for decades, it's just that their 'hybrid emulation' concept let them argue they are doing it 'differently' but , as already said, that's more than likely limited to how they interface with some real hardware instead of emulating it, not how they emulate the original console hardware.

Edited February 9, 2017 by philyso

[godslabrat]

Do the math!

you are not e

[Andromeda Stardust]

Errr ... it is taking place in software on multiple cores in the RK3288 ARM SoC.

 

I thought that was quite obvious from their many postings.

 

It's just that while normal emuators concentrate exclusively on *what* the emulated VirtualCPU instruction does to memory, and registers and flags, they're going down a step below that and also concerning themselves with timings of the bus-access patterns so that they can emulate the signals on the cartridge-bus, and so access real physical data from a real cartridge, and not do it too fast, or too slow.

 

It's the kind of thing that Kevtris must have to think about when he writes his code that programs the FPGA.

 

They're probably just skipping some of the more-annoying steps and letting ARM instructions handle those.

 

I can see how it *could* work in practice ... and how it *could* provide some benefits to balance the costs.

 

Most obviously ... they wouldn't have to care about what expansion chips are on a SNES cartridge., or try to emulate them or figure out what "mapper" is used.

 

They'd just pretend to be the emulated-console's main CPU, and access the cartridge hardware in just the way that it would, with just the same electrical signals on the cartridge bus.

 

So to the coprocessor on the cartridge ... it would just look like it was plugged into a real machine.

 

It's a nice theory, but how well they've got it to work in *practice* is anyone's guess, and that's even if they're doing that, and not something else entirely.

 

There's also the huge question of what benefits would this scheme actually provide, except to run real hardware cartridges in a world where nobody under 30 cares, and would just prefer 100% digital.

 

All-in-all, even if these guys are legit (as they still may well be), their vision of a "fun" machine isn't one that I share, with its lockdown and HomeBrew Store, and expensive add-ons, and all of the other stuff that goes beyond making a cool product, and instead, into following Mike Kennedy's RetroVGS business plan to create an EMPIRE!

Agreed on most points, but one crucial detail here is that unlike Mike and Company, they have actually created a viable prototype. It is basically the dream that Mike Kennedy had, envisioned by someone else, and I am cool with that. And if this thing does in fact work with flash carts, I won't need the ability to run ROMs through the SD or some other backdoor method.

 

That said, I only hope the final pricing isn't $300 for the console and $60 for each additional module, which someone in this thread quoted without actually linking to hard evidence. They may have listed prices but I didn't see anything on the site, though I admit I haven't read everything they have posted yet.

 

It's a theory.

 

I could be 100% wrong and full-of-cr*p.

 

But, as an experienced assembly-language programmer, I *believe* that there's a good chance that it *could* be done on the fast modern ARM SoCs that have only appeared in that last decade-or-so.

 

So I'm willing to give these guys a *chance* to show their hand, and really *prove* that their hype is justified (BEFORE the KickStarter).

 

I'm massively skeptical, and whatever the truth ... I still prefer the idea of Kevtris's Zimba3K, and trust his approach more than these guys.

 

But this team is NOT showing quite the same signs of absolute-total-raving-BS as the RetroVGS crew, IMHO ... at least not just yet.

 

There are *huge* concerns ... but I'd like to remain a "skeptic", rather then a member of the "AtariAge Hater Brigade" for a little while longer.

QFT.

[Flojomojo]

you are not e

WELCO

METOT

HENEX

TLEVEL

[godslabrat]

Agreed on most points, but one crucial detail here is that unlike Mike and Company, they have actually created a viable prototype. It is basically the dream that Mike Kennedy had, envisioned by someone else, and I am cool with that. And if this thing does in fact work with flash carts, I won't need the ability to run ROMs through the SD or some other backdoor method.

 

That said, I only hope the final pricing isn't $300 for the console and $60 for each additional module, which someone in this thread quoted without actually linking to hard evidence. They may have listed prices but I didn't see anything on the site, though I admit I haven't read everything they have posted yet.

Agreed. I'm not being critical of Retroblox for its own sake. On the contrary... this is a concept that holds a lot of appeal to me. There are lots of systems out there I'd like to try, for the sake of two or three games, but don't want to invest in the hardware for practical reasons. I've longed for a "one-off" console for a long time now, and Retroblox is conceptually EXACTLY what I want. BUT, that doesn't change the fact that this is the latest in a long, long line of failed concepts and broken promises, not to mention outright scams. If Retroblox wants to fill that niche (which is very real and likely very lucrative) then they do need to show that they can deliver where others failed. And they need to show it in positive terms, not just a lack of outright lies. As I said before, benefit of the doubt died at the New York Toy Fair.

[godslabrat]

WELCO

METOT

HENEX

TLEVEL

 

It only does everything.

[+GoldenWheels]

Can't be 300$ plus the modules. Gamester81 said this potential game changer would be very reasonably priced. When has he ever led people astray?

[Andromeda Stardust]

Can't be 300$ plus the modules. Gamester81 said this potential game changer would be very reasonably priced. When has he ever led people astray?

He also once shilled for RetroVGS, and later had to make a public apology video to save face. Also $300 may reasonably priced for one collector, absurd for another. I personally feel the Switch is worth $300 as a bleeding edge console (despite naysayers that the PS4 Slim and Xbox 1s are cheaper, the Pro and Scorpio versions are not) but I put my spending cap at $200 for retro devices. That said, the AVS was well worth the money but compared to Retroblox, the upcoming Kevtris all-in-one FPGA will likely be better value.

 

If Kevtris ever goes on Kickstarter to design a PCB, enclosure, and game modules for his Zimba 3000, I would back him in a heartbeat.