tcdev

Agreed. The whole patent thing is either absolute self-delusion or a cover story for why the case had to be on the 'prototype' in the video. They not doing anything patentable. I can add MCC, Turbo Chameleon 64, Mist, Suska III and Replay to your list.

Initially they seemed to be talking about storing the FPGA bitstream for the emulation core in the cartridge, which makes perfect sense to me. But that's not an FPGA, simply a SPI flash device that configures the core of the FPGA on the motherboard. Then when they mentioned an FPGA on the cartridge itself for emulation, I started to doubt the competence of these guys. The cartridge I/O just isn't set up for that - you'd have the cartridge directly driving the video DAC's for example - plus it's stupidly expensive. It would just never be designed that way. I gave them the benefit of the doubt and assumed it was a marketing guy getting his wires crossed. FTR, the MVS->AES adapters have CPLD's which implement a relatively simple parallel-to-serial converter for the sprite ROM, no more. The only tricky bit is getting the synchronisation right for the serial stream. No need for an FPGA in there, and certainly not worthy of being called a "core".

Looking at CrowdCharts, the video appears to have had the opposite effect to that which they hoped!

©ommercial (O)ff (T)he (S)helf board. A dev/eval board. Can be used to prototype; on their own generally prove nothing, with hardware extension then yes.

I've said it before recently, and I'll say it again. This is so fake it's wilful fraud. The translucent case isn't there to protect the design, it's there to disguise the fact that it's a COTS dev board with a few random PCB's and cables sitting on top to look like a prototype. The other PCB's on the desk have been thrown on to make it look 'busy'. It's absolutely laughable. Almost as laughable as the claim that they're filing a patent. On what exactly? Maybe a patent for putting an FPGA in a Jaguar case; that's about the only aspect of this design that hasn't been done by someone else before. From the C-One to the Replay (which actually has an ARM and an FPGA) and Kevtris' board, and the indie consoles like the Ouya, there's nothing new. It's more smoke and mirrors to counter the gaping hole in the campaign - there is no prototype. Time will tell. Karma's a bitch.

Transparency? Transparency? Is he kidding? I guess the specs are 'transparent' because there's nothing to block the light coming through!?!

I know there's vey little enthusiasm out there for playing new games on cartridges, and a lot of valid points in support of that viewpoint, but the thing is that if they did produce an FPGA-based system that was capable of playing legacy cartridges for classic systems, then you'd get the aforementioned capability for free!

And to complain that the campaign has been damaged by people... asking valid questions and pointing out the flaws with the campaign!!!

I've really getting tired of the shit they're spewing forth now and it's getting way beyond excusable; it's no longer ignorance but wilfull disception. I actually want this to fail now, because Mike needs his ass handed to him. He claims they've been working for a year on the hardware - and have nothing to show? I could have had a prototype done in a year - working alone! Kevtris has done it before, as has others. Yet these "industry experts" can't come up with anything more than a rendered mock-up that wold have taken about 1/2 day to put together? Not only that, but the specs are still changing and to this day, they haven't been able to provide any details on either the CPU or the FPGA. Complete and utter smoke-and-mirrors BS. Sorry, this is more than naive over-enthusiasm. Way more. It's dishonesty and egotistic stubborness. Period.

OK, this thread has gone way too far. The gloves are off. You can have a go at RGVS. You can have a go at my mother. You can even make disrespectful comments about my sister. But Xevious. Xevious is off-limits. How dare you even hint that Xevious isn't the best arcade game ever produced, let alone not a good game. Choose your weapon sir.

This. Pushing 50 here; never occurred to me in the slightest that I would ever want to use my old computer stuff again, let alone someone else. There's another factor at play though, I think. I look around me at the last- and current-gen consoles and wonder if they'll ever be "collectible". Even the NGC doesn't seem to be anywhere near as desirable as earlier consoles like the N64, nor the PS1 for that matter. Is it because of the sheer amount of shovelware available for them? Or the sheer volume of each title produced? Or is it more to do with the attitudes of the modern (younger) gamer? Do modern games generate anywhere near the level of excitement it did when we opened our consoles on Xmas day in the 70's & 80's in the youth of today? I pretty much stopped collecting at the NGC & PS2. I own a PS3 because it was bundled for free with the TV and it got used as a media client. And I recently picked up a Wii because it was bundled for 'free' with a used TV and I thought my kids would get a kick out of it. But I have zero interest in collecting for these systems - in fact I'm really only interested in retro compilations for the PS2. I guess for me cartridge systems are really where it's at, hence my (initial) interest in the RVGS.

Congratulations! When can we expect your IGG campaign to start?

"We have confirmed, according to our IGG rep that Paypal is canceling some pledges for no reason(having to do with something triggering their fraud dept), and we are discussing with them now." Nice story bro'.

Pull the damn plug already! How can you possibly believe this will get funded when even the "media" is reading your obituary?

IMHO I think your above statements are a little at-odds with one-another. I don't know how anyone can be happy with a base product when enhancements are dangled in front of them, especially a game-changer like the FPGA. Specify the hardware required to achieve your vision, and leave it at that. Why add a half-baked solution in the mix, other than because you're hedging your bets and want to mitigate the possibility that your vision isn't a viable product in this market.

They can't have a routed design if they're adding and subtracting FPGA's every 2nd day, and I can assure you that it would only be the tip of the iceberg. That PCB rendering was complete BS, discussed elsewhere on this forum. I asked for a block diagram weeks ago, and it never went answered. The C-One had two FPGA's, three with the expander board, but it was still a stinking pile of poo. Depends on how it's all hooked up.

Head on over to the Coco3FPGA yahoo group. That's exactly what someone is doing now.

Yeah, the campaign might have tanked before you release it at that rate!

There's only one reason why anyone in this thread cares, albeit a good one. At some point quite a few months ago, we were promised a console with certain features and capabilities; a console that stood out from the crowd with its unique and exciting design. It was exactly what many of us had been waiting on for a long time, and the slick marketing replete with PCB renderings, gameplay videos, shiny case renderings and all the hype sucked us in. Then at the 11th hour they switched the gameplan, and we also saw the man behind the curtain. The one discerning feature we wanted (the FPGA) was gone together with, as would later be revealed, the only person who could make it useful within a reasonable timeframe. And when it finally came time to put our money up, we expressed disdain at the lack of technical details and discovered - much to everyone's disbelief - that they don't even have a prototype! Now the significance of that one fact may be lost on the less technical amongst us, but there is a reason why Kickstarter require (at least officially) a working prototype before running a hardware campaign. It's abundantly clear now that they haven't even settled on a design, and certain comments even suggest they're not even capable of it, and after working in engineering for over two decades I can assure you that it's a recipe for almost certain disaster. That is why this thread is 84 pages and counting. We're not here to bash a product that we never wanted. I looked briefly at the Ouya when it was being developed, yawned, and went on my way - I didn't hang around forums proclaiming it was rubbish or useless. You can't show your cat a shiny bauble, taunt it and then take it away. It's bound to get pissed.

There are several misnomers about FPGA vs Software emulation and I'd like to at least attempt to put them to rest once and for all. FPGA is not emulation. Wrong. It most certainly is emulation. Exactly like software, you're using a tool to model the behaviour of the original system. It just so happens that with FPGA's, your tool is more closely related to the system you're modelling. But you are building the system out of fundamentally different (albeit functionally similar) building blocks, based on the observed (or in some cases, documented) behaviour of the original system. FPGA emulation is inherently more accurate. Wrong. And there are several reasons for this. Like any tool, FPGA's have their limitations. 'Digital' electronic circuits used for classic gaming aren't purely 'digital'; some aspects of the design may rely on the analogue nature of digital components (eg propagation delays). Other aspects, such as asynchronous and/or dual-edge clocks, don't map well to FPGA's. Certainly analogue portions of the design, such as audio filters, are very difficult (and resource intensive) to model in an FPGA. A lot of gaming systems have proprietary IC's which have to be modelled via 'black-box' reverse engineering and then emulated, whether it ultimately be in an FPGA or software. FPGA's have limited capacity to synthesize arbitrary frequencies and arbitrary numbers of clock networks. Inevitably the FPGA is connected to external (modern) components such as memories and displays that require modification and/or addition to the hardware being emulated which may in turn impact aspects of the overall design, such as clocking. And, in some cases, there are easier ways to achieve certain things and there's very little utility in implementing portions of the original circuit verbatim just for the sake of it. As a result, often an FPGA emulation resembles the original design only at the higher levels. This is especially true for example, of CPU cores implemented in FPGA's. And somewhat paradoxically, some aspects of the design are only possible, or at the very least only practical, on modern systems via software emulation. The obvious example here are audio filters, some of which are emulated in MAME by describing the network of discrete components on the PCB - and for which no FPGA emulations currently exist. None of this is to say that an FPGA can't be made more accurate, or to suggest that it's not easier to make it more accurate. It's true in a lot of cases that the nature of FPGA's and the features of the HDL do map well to the original design and you can go a long way by simply describing the digital aspects of the circuit at 'gate' level. And there's certainly less infrastructure required to handle timing (clocking) and parallel events - just look at the core MAME code to see what's involved there! Software emulators can be used to document classic systems. Well, up to a point, yes. What they can describe perfectly of course are the software objects (ROM's) as they are used verbatim. They can also decribe the high-level design of the circuit; which CPU's and common peripheral IC's are used (eg. PIA's), and how they are connected together. How I/O and memory is mapped, how CPU IRQ lines are driven (sort of) and some sundry logic. However all this is at the higher level of the design and there's still a lot of information missing. Obviously proprietary IC's are emulated by observation and the emulation tells you nothing about their internal implementation. Hardware that employs several proprietary IC's such as the Neo Geo result in emulation that bears almost no resemblence what-so-ever to the actual original implemented design. Similary the code often gives no clues as to how IRQ triggers, for example, are implemented in the original hardware. Perhaps most significantly, anything implemented in the MAME framework - and the video circuitry is a major component of that - bears no resemblence to any orginal design and tells you absolutely nothing about it. So whilst emulator code can tell you what is happening on a macro level, it often tells you nothing of how that is acheived at the fundamental level. All of this can also be true of FPGA emulation as well; it comes down to how the author has implemented the emulation. For example, in a lot of my designs I was focused on proof-of-concept and (in some cases) playability; like MAME I developed a video framework that made no attempt to model the original video circuitry of any specific board for tilemaps and sprites. It expedited development of multiple cores, and had no implications on the final product. So what's better? There is of course no correct answer. It all depends on the specific implementation and the requirements of the end user.

I can tell I'm wasting my time but I'll give it one more shot. "FPGAs do not operate by emulation." Actually, they do. Do you know anything about the internal structure of an FPGA? They emulate logic gates by using lookup tables. That's how they're able to be made reconfigurable. "They use a process called synthesis. There are very significant differences between hardware synthesis and software emulation." The synthesis process is akin to the compilation process in software development. Your above statement is attempting to contrast two completely unrelated concepts; it's nonsensical. Of course despite your claims to the contrary, I did no such thing, but rather compared the process of modelling the behaviour of a circuit in HDL, and modelling it in software. I didn't mention the compiler at all. Nor did I mention it had anything to do with the syntax. But you do bring up a good point, albeit inadvertently, since VHDL is based on ADA and Verilog has very C-like syntax. Isn't that a hint at all? I made no assertion that you "said" FPGA's were a magic bullet. But it's clear from your comments that you firmly believe it to be the case. I did read most of what you wrote, but I do admit that my eyes started to glaze over when it became clear that you lack some understanding of the basic concepts, and then you went on a tangent in an attempt to correct philyso who was actually correct. I also notice you ignored my whole point on the topic of timing. LPT: If you're going to accuse others of "not [understanding] FPGA's and never [used] them" then be prepared to be taken to task on your own comments.

Well, since you asked, you can add my name to the list. I've used MAME and MESS for references when implementing classic systems (and I've done dozens) in FPGA's. +1 for philyso

Just a couple of points. Decades of experience in an industry says absolutely nothing about your competence. I personally know a programmer who has been working for almost 30 years in the same industry; at uni he was a terrible coder and I last saw his code a few years ago and it is still absolutely horrible. I also had the misfortune to work with another programmer a few years back and 'incompetent' is an understatement. I know for a fact that he still works in the same position. These people slips through the cracks and somehow manage to bungle their way along under the radar for years! Being involved in also says absolutely nothing about the significance of the role you played. Lastly, as someone else pointed out, a 25KLE Cyclone part is definitely adequate to emulate most of the classic systems. The DE1, for example, has a mere EP2C20 and runs Minimig just fine. I'd even venture to say that a 50KLE device is actually overkill unless you're targeting more advanced systems, and a 100KLE device is simply unnecessary expense. 2D tilemap-and-sprite engines are trivial and are composed of little more than registers, counters and muxes, with some on-chip RAM for line caches and (optionally) tilemap memory. I am working on a prototype design (for my own projects) with a 144KLE Cyclone V and my crude experiment suggested it would fit no less than 32 TG68 (68K) cores - imagine how many 6502 cores would fit! It's clear if they're touting those devices that they have no idea what they're designing or the hardware required to achieve it. Then again, I don't have any professional video game industry experience, so what would I know?

Wow, reading this and your previous posts blew me away. How can someone who has (reportedly) worked with FPGA's be so... wrong? philyso definitely has a far superior grasp on the concepts than you do. First, you constrast software emulation with FPGA synthesis which is akin to comparing apples and cats. I don't even... Writing HDL for an FPGA is very much like writing a software emulator to run on a CPU. Without being privy to the gate-level design of the component you're implementing, you most certainly are emulating it, regardless of whether you're modelling the behaviour in HDL or a software language. As someone else in this thread cited, an FPGA is not a magic bullet. A case in point is John Kent's 6809 core which is software-compatible but not cycle-accurate; you can't emulate a Vectrex with it for example, or run certain Coco software, but there are several software emulators for either that run perfectly fine. So to rebutt your rebuttal of philyso's statement regarding a dependence on how either is written - it is definitely true! You talk a lot of the timing advantages of an FPGA implementation. On the surface there are most definitely advantages and you can in a lot of cases achieve true real-time synchronisation, but there are also plenty of caveats and limitations as well. Limitations in PLL capabilities, number of clock networks, synchronisations between different clock domains for starters. Very often it's necessary to run emulations at higher clock frequencies in order to interface with off-chip resources, or to approximate some analogue and/or asynchronous behaviours. Often some 'digital' circuits rely on the analogue nature of the components (eg propagation delays) to work correctly that cannot be directly modelled in an FPGA (and certainly not at the system clock frequency). And some components are proprietary in nature and their behaviour needs to be approximated anyway, so having an accurate clock is a moot point. Timing also transcends the base logic gate speed and affects components at a higer level, eg. CPU cycles and/or interrupt behaviour. In some cases, it's actually easier to 'synchronise' emulation behaviours in software, because you're effectively simulating elapsed time and don't have the constraints of a few coarse clocks. Yes, technically they generally don't happen in parallel, but in most cases it does not affect the emulation in any way perceivable by a human being playing the game. FTR I wrote my first software emulator about 16 years ago. I've been designing FPGA-based hardware and programming them professionally for over 10 years now, and emulating classic systems on them for almost as long.

I kinda think there's just a handful of us picking at the bones of the stripped carcass as it is... a few more days of drying out in the sun and even us vultures won't be circling anymore.