elmer

I've not seen a video of that, or of them playing a PC Engine CD game, either. For the PCE, CD games have the System Card BIOS, which is 256KB, and includes lots of utility functions that games use, a sound-driver that games use, and both 12x12 and 16x16 fonts that nearly every game uses. There's only one existing emulator that I know of that has even tried to avoid using a copy of the real BIOS, and that's Magic Engine ... and its own BIOS-replacement compatibility is known to be somewhat poor. So, even if the RetroBlox guys have licensed Magic Engine's BIOS, they'd have a lot of work to do to fix things. It sounds *so* much more plausible that they've just ripped a copy of the real BIOS ... and that they've done the same on the Sega CD. IIRC, the Playstation BIOS booted the console, and then loaded a replacement for it from the CD into the System Software area of memory. I don't remember if the original BIOS was ever used after that, but I'm sure that someone here can answer that.

So what is the RetroBox project going to amount to? Figure out a way to turn ARM/x86 small form factor boxes (from Intel NUCs all the way into XBMC boxes) into plug-and-play game consoles powered by RetroArch. Have a free open source distribution that is very lightweight. Strive for the most optimal conditions possible ie. DRM/KMS mode, no X11, minimal packages installed in this distro other than what libretro ports/RA actually needs. Make this a Proof of Concept for what a game console centred around the libretro API can be. Plug-and-play can be operated with a gamepad entirely, keyboard and mouse are entirely optional. They've already done it, it exists, and it runs on a number of different ARM or Intel boxes. They're not trying to lock folks into a single piece of "approved" hardware ... Lakka is the official Linux distribution of RetroArch and the libretro ecosystem. Each game system is implemented as a libretro core, while the frontend RetroArch takes care of inputs and display. This clear separation ensures modularity and centralized configuration. http://www.lakka.tv/ As soon as that $70 Asus Tinker Board is available for purchase in a few weeks (running the same basic hardware that's promised on the RetroBlox), I'm sure that Lakka will be ported to it very soon afterwards.

From how I read their sales-pitch, that seems to be what they're promising. It'll be amusing to sit back and see how they go about trying to justify those claims, and whether they fail, or whether they succeed (unlikely, but then again, I *could* *potentially* have the winning SuperLotto ticket), Whatever happens ... I really hate softball partisan infomercials like Gamester81's video. It makes my skin crawl. He was practically salivating with his "I'm a Game Developer with a Homebrew Game" comment.

Yep! While there's always something about Gamester81 that makes me feel like I've accidentally wandered into a Used Car Dealership, and I keep on wanting to check that my wallet is still in my pocket ... the geek that he was talking to seemed nice enough. Not that that actually says *anything* about the reality of the product itself. Having read Kevtris's post, I could argue a point-or-two about the little details ... but the overall conclusion is coming from someone that I respect, and a person that has had to deal with all of the "practical" details that can cause a project to sink or swim. I took a look at the RK3288 specs, and the chip only has 32KB L1-cache per core, and a shared 1MB shared L2-cache. That seems to torpedo any "clever" little ideas that I might have had about how you could actually implement stuff in the way that I've theorized, and that's even if these guys had spent years writing bare-metal emulators rather than being a Producer & His Programming Buddy. The likelihiood that everything is just an overhyped modification to a bunch of existing emulator software just got a LOT higher, IMHO. I'm still not 100% counting-out the possibility that they've done something nice, and that it actually runs (only time, and real proof, will make that clear), but the thought that they've actually come up with something "revolutionary" seems to be speeding off towards the horizon. I just hope that Kevtris will eventually have the time and desire to finish off the Zimba3K, and make the hi-def SuperGrafx-ArcadeCard-CD FPGA emulator that I've been wanting for many years. These guys ... meh. I can run a software-emulator on so many other pieces of cheaper and more-convenient hardware. Or just plug in the REAL-THING (apologies to the Coka-Cola Company ... please don't sue me off the planet! ).

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??? 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.

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.

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.

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!

You're misreading the spec. Here are the first 5 modules. You only get to pick one of them for your $300. NES SNES Genesis Atari 2600 PC-Engine And "yes", since it's locked down so that you can only put ROMs on it that you physically plug in and dump using an "Element Module", it's going to get very expensive, very fast. I don't think that they've said how-on-earth they're going to get the Sega CD BIOS on there, either. With the PC-Engine, they could very-well expect folks to plug in a PCE System Card to provide the BIOS. That should help drive up the prices even further for those of us that run real hardware.

Yes, you can certainly do that instead of using a real CD. With more-recent Mednafen builds the whole real CD thing is dropped, and they read directly from a .cue/.bin image on your hardrive, which is (IMHO) much more convenient. There's a lot of wasted cycles in a C/C++ emulator that's running on top of someone else's OS. Do I believe that some smart bastidge could do it? Sure. Just customize your linux kernel so that it's limited to one or two of the four cores, and then carefully write a VirtualCPU emulator for each system that gets its own dedicated 1.7GHz ARM core in order to access the cartridge and run the CPU emulation. If you do that, and write it in assembly-language, then you should be able to control the emulated-cartridge access and emulated-instruction-execution timings tightly enough, even if you are bit-banging the I/O ports to read data from the physical cartridge. Then dedicate another core to doing the VDP emulation, and sync what it is doing on a line-by-line-or-less basis to the other VirtualCPU core with semaphores or even lockless programming. Then you've got one or two cores left to do the sound emulation (not very expensive), and to draw the emulated screen onto the real SoC screen with all of that eye-candy and upscaling and shader effects. With a 1.7GHz ARM core for running the CPU-emulator, you've got plenty of instruction cycles for emulating any of the old 33MHz-or-less (maybe more) CPUs. That's how I'd approach the job. And I *suspect* that it would work. But I don't *know* that it would work, and there could easily be a whole ton of practical problems that would crop up down the line. That's why I believe that these guys need to show some proof. Sure, they claim that they've got some low-level hardware hackers on board who could do that sort of assembly-language programming. And perhaps they do. But have they actually *done* the job on this project, and does it really *work*???

Don't folks remember that lots of emulators have run stuff from real CDs before??? I remember Bleem! coming out back-in-the-day, and lots of early emulators *required* the CD because gamers didn't want to rip large 600MB games onto their < 1GB hard drives. Up until recently, Mednafen also *required* that you use original CD media. That side is nothing new, and putting in a game CD and starting a game doesn't show anything about whether the CD is actually being used, or just randomly accessed, or what emulator they're running, or whether they can actually fulfill any of their claims about playing directly from a real cartridge. It's the playing-from-a-real-cartridge that's the new-and-unproved tech. Where's the demo of that? Everything else so far could be, but certainly needn't be, just running on any of 1000 off-the-shelf boards with a bit of custom programming for the front-end. They haven't been exposed-as-fakers, and they could easily just be hyping something that totally-justifies the hype. But they still haven't offered any reasonable proof to be excited. Just buzzwords and promises.

Fixed that for you ... It would be neat to see a 3-way split screen with Retroblox vs Retropie emulation vs the real thing. of the systems that they've mentioned, actually running off of a cartridge. They're promising a whole lot of systems, using a new and unproven technology, written from scratch in a year, by a bunch of busy professionals with day-jobs, and yet they couldn't show any of this running last weekend, and only had one cartridge-adapter prototype board to show (not running). I'm not quite prepared to say that, yet. But someone on the team is definitely writing a lot of cheques that they've not yet shown they have the ability to actually cash. It just doesn't smell good. If they've got all of this stuff in place, then they should have been able to show a lot more stuff actually working, even if it's not fully-polished. I want to see stuff running, and I don't care about the glitches. Slap a big banner on there that says "prototype, 50% of final speed" or whatever other weasle words they want. But show something that actually gives a flavor of what the end-product will be, and stop making empty promises about how f*cking great everything is.

Ignoring enoofu's point that the patent may be invalid ... the patent mentions using an FPGA to interface to the cartridge. Well, the Rockchip SBC that I linked to earlier doesn't seem to have an FPGA on board, and the picture of the TurboGrafx adapter-board PCB looked like there was no FPGA there either ... just some level-shifters. Most modern ARM SoCs (like the RK3288) have plenty of runtime-configurable I/O pins, so perhaps the RetroBlox guys are just planning on some good old-fashioned bit-twiddling of port settings & values to read data from the cartridges. That could keep one of the ARM cores busy. Aren't most software-emulators single-threaded anyway (at least for the CPU emulation that's reading the cartridge port)? This would be my worry, whether they're using either the CPU or an FPGA to read data from the cartridge. The latency would be 1000s of cycles. Decoupling fast CPUs from slow memory has been one of the big reasons that we've got such fast computers these days. I'd want to actually see this scheme running in action, on all of their supported platforms, as a proof-of-concept, before throwing money at a KickStarter. It was notable, and troubling, that they didn't seem to show any attached-cartridges at last weekend's show.

Why do I get the feeling that the cable on the PC Engine board in that photo is supposed to plug in to the pins on this SBC board??? http://www.boardcon.com/EM3288_SBC/ They seem to be a huge step up from the RetroVGS goons, and have actually bought an SBC, written some software for it, and have at least one prototype interface board (that may or may not work). There's nothing that seems to be "rocket science" in what they're trying to do, it's just a question of how far along they are, can they finish it all off, how much money do they want to charge for it, and do enough people care? Oh ... and then, do folks have faith that it would actually be built solidly-enough to not self-destruct in 6-months?

This looks like it's the board that they're using ... http://www.armdesigner.com/MINI3288_SoM/

Don't forget ... "In fact, through his book imprint, Cardillo Publishing, Cardillo has released two collectors guide: The Complete Guide to Collecting Nintendo Entertainment System Video Games as well as Collecting & Completing Your G.I. Joe Figures and Accessories in collaboration with James DeSimone." http://www.paramuspost.com/article.php/20151116193122623 The Complete Guide to Collecting Nintendo Entertainment System (Nes) Video Games by Chris Cardillo (Author, Photographer), Tim Atwood (Photographer) http://www.amazon.com/Complete-Collecting-Nintendo-Entertainment-System/dp/0974582735

I lasted 14 minutes before turning it off and smashing my head into a wall. So much verbal "noise" from the team, and so little verbal "signal". But it was good to hear again how they had the hardware design pretty much locked-down back then, and just needed money to pay the manufacturers for custom-specified 30um gold-plated connectors and make John Carlsen's excellently-designed boards ... er ... NOT! As someone that had actually designed working FPGA hardware, I can only imagine the look on Kevtris's face each time that he talked to John Carlsen.

I'm still curious about Steve Woita's part in all of this. It's pretty easy to see Mike Kennedy as the classic lying huckster with a "Grand Plan" to get money and attention. It's pretty easy to see John Carlsen as a classic self-important marginally-talented resume padder without the strength to keep a check on Mike's constant stream of promises. But what role did Steve Woita play, except to appear in a photo or two, and then seem clueless and out-of-touch in Triverse's interview? He's the guy that should have had at least some idea of the software side of all of this (or rather, the lack of it). Things like SDKs, documentation, licensing developers, licensing products from other developers, and how much time all of that stuff really takes. Or am I wrong? Was he really only there to add his "brand" to the project because he did a few early console games in the 1980s? He seems to have come out of this pretty cleanly, which is fair, because he never really seemed to do anything wrong, or ... really ... anything at all. I'd love to hear his perspective on all of this.

Errr ... nope. Some folks here have many years of experience in the video game industry, and in video game development, and in the financial aspects and incentives of game development, and saw this as an ego-fueled train-wreck from the start. The major amusement was in just how far Mike Kennedy would lie and pretend in order to try to make his "dream" come true. and in whether people would eventually see through the B.S.

To be fair ... if you go back and look at the record, there were actually some minimal sort-of-specs on their website that got removed just before IGG, and then there were some more minimal sort-of-specs that were posted on IGG after John Carlsen's video and his mention on FaceBook that he was using a RockChip dev board. Here's what I noted back then (please forgive the auto-coloring that I can't figure out how to disable) ... RETRO VGS OUYA CPU 1.6GHz Quad Core ARM Cortex-A9 1.7GHz Quad Core ARM Cortex-A9 RAM 1GB DDR3-800 1GB DDR3-800 PROTOTYPE Manufacturer's SoC eval board Manufacturer's SoC eval board OS We won't have one (NetBSD?) Android CONTROLLER Yes Yes CARTRIDGE Yes No COST $300 $100 As for the more-recent Coleco Chameleon ... not a damned thing was mentioned about the specs that I can find. Totally agreed! *********** Now, since we've got as far as poems and haikus, let me bring things down-market with a limerick ... There was a man from Nantucket, he looked at the fake and said "phucket". I know I've been scammed, I'm sure it was planned, and I bet it all ends in a docket.

One of the things that Mike's whole mess has given some of us is the chance to see some of the "loyal fans" get an education in the ways of the "big-bad-world" and, perhaps, to learn that the guy selling the bag of magic beans really isn't always to be trusted. For example ... poor old Dan Iacovelli (who recently posted here) ... he seems like a good and decent guy, and he abandoned another forum back in early 2015 when some folks were questioning Mike's plan/statements from his original Retro VGS announcement/podcast. Move forward a year, and ... It's been a long road since then ... but if this whole debacle has done anything, I hope that it has helped some folks be a little more cynical, and to question the competence and integrity of people that promise a great deal, but then ask for the money in advance.

It's a pity that Douglas Adams and Terry Pratchett aren't here anymore. IMHO, Mike Kennedy has definitely earned himself a place on the Golgafrincham B Ark. Every time that he opens his mouth to try to explain things and to justify his actions, he just seems to be determined to put his foot in it instead.

Janitor? Janitor? That was the "Vice President of Custodial Product Research" with a job that keeps him in direct contact with the "office of the President of Konami" ... he roams the "Corridors of Power" all day! Didn't you learn anything from the last year of exaggerated Mike-speak?

Thanks for that, it was interesting to watch. I thought that a lot of his points were absolutely valid, particularly when it comes to getting developers to support a new console. But overall, I thought that he was far-too-generous to Mike-and-the-team in even dignifying what they "accomplished" with a serious post-mortem. IMHO, he put more thought and logic into that 30-minute video than Mike-and-the-team put into their year of trying to get other-folks to bankroll their next vacation.

You are right, I overstepped the bounds of polite conversation, and I apologize. You have every right to be proud of your accomplishments, and to attempt to monetize them ... and you are actually one of the "good guys" here in that respect in that you don't carpet-bomb this thread with links to your own videos. My distaste for various aspects of the modern-world doesn't have any relevance to this thread, and I apologize to everyone for intruding it here. YouTube, and YouTube channels are just another example of Sturgeon's Law. There are some stand-out exceptions, and the Retro-VGS/Coleco Chameleon saga has given us some wonderful videos. I, for one, really hope that StopDrop&Retro gets to make his documentary.