Retroblox

[enoofu]

Why are we re hashing Coleco Chameleon topic in this thread

 

Retroblox is it own version of idiocy

 

Backing up games- Could be consider unlawful under DMCA

CD's game usually have full version music songs --Could open RIAA action against them or users since the backup games including their music

 

Usually need the official bios to run CD games, non official bios don't usually support most games

 

Modular system never have worked well when you have to connect them and unconnected them to connect another modular part, as connectors can break,or modular parts will get lost

 

What the points of reading carts from games, when the system is running a emulator also considiering the system resources that would be lost doing this efficiently which may not be possible

Edited February 26, 2017 by enoofu

[Kismet]

There is a SNES FPGA but for now the author isn't sharing it (either commercially or open source):

 

Genesis is being developed for the MiST now, there is a working beta available with sound. PC Engine works (arguably not fully a 16 bit console though).

 

On the computer side you have the Atari ST, Amiga with AGA chipset, Acorn Archimedes, Mac Plus with 4MB RAM expansion, and the russian 16bit computer BK0011M.

 

Now these are all open source projects, meaning they can survive if the author stops working in it (in fact many were ports of older projects). But it also means it's being done by volunteers so progress depends only on motivation. It will keep progressing though and code sharing for big parts (e.g. accurate implementations of the Z80 or 68K chips) is already happenning.

 

Ahem

 

 

There has been no less than 3 SNES FPGA attempts. The one above is likely the most likely to not become vaporware. See his other videos.

 

Most of the time the reason you won't see a SNES FPGA released is because they are student projects that used WDC IP in it. http://ece545.com/F15/reports/F10_SNES.pdf

 

Plus the SNES is unique in that you can't create a FPGA of "just the SNES", as that doesn't cover the expansion chip games, and those are the games that don't run even on clones.

[Keatah]

Plus the SNES is unique in that you can't create a FPGA of "just the SNES", as that doesn't cover the expansion chip games, and those are the games that don't run even on clones.

 

I thought that's why they need cartridges. You make the snes fpga rig, then plug a cartridge into it. Otherwise you'll need to model each cartridge's internal circuitry, too. That's where BSNES/HIGAN come then. It does that.

[Kismet]

 

I thought that's why they need cartridges. You make the snes fpga rig, then plug a cartridge into it. Otherwise you'll need to model each cartridge's internal circuitry, too. That's where BSNES/HIGAN come then. It does that.

 

The clone hardware has never supported SA-1, Flash carts like the SD2SNES and Everdrive do not support it either. Software emulators (eg Retron5/RetroFreak) with slots can't run them either.

 

A perfect FPGA SNES would be able to run a real SA-1 game. So far nothing but a real SNES does. Software emulators kinda-sorta run them, but need speed hacks.

[Newsdee]

There has been no less than 3 SNES FPGA attempts. The one above is likely the most likely to not become vaporware. See his other videos.

I'm convinced somebody will release a SNES core sooner or later and this one does look promising. I'm not too worried about 8bit and 16bit systems as a whole, slowly they will get there.

 

For 32bit and above, in general 3D systems, it's going to be more challenging due to specialized chips. But 3D is an area where I think emulation makes more sense, upscaling to much bigger resolutions and making the animation smoother. Some emus even allow inserting high resolution textures to some games.

[Kismet]

I'm convinced somebody will release a SNES core sooner or later and this one does look promising. I'm not too worried about 8bit and 16bit systems as a whole, slowly they will get there.

 

For 32bit and above, in general 3D systems, it's going to be more challenging due to specialized chips. But 3D is an area where I think emulation makes more sense, upscaling to much bigger resolutions and making the animation smoother. Some emus even allow inserting high resolution textures to some games.

 

True, however if you look at arcade systems, they used FPGA's in some versions of the Playstation-based hardware (I believe all it does is add mpeg-decoding in the case of the Bemani kit with it), so it's not much of a logical leap that FPGA based emulators make sense for games that are timing-based (eg DDR), that otherwise software emulation will remain terrible at dealing with. With the PS/N64 and later it will be a personal taste of either wanting high-resolution output or low-latency-high-accuracy output since you can't have both, but not every game actually needs both.

[Keatah]

For 32bit and above, in general 3D systems, it's going to be more challenging due to specialized chips. But 3D is an area where I think emulation makes more sense, upscaling to much bigger resolutions and making the animation smoother. Some emus even allow inserting high resolution textures to some games.

 

So do I, naturally ..

 

Some recent experiments with multi-core processing and software emulation is showing immense promise. Which reminds me, the more complex consoles/systems should work better if they are split up between several fpgas.

 

It's just a matter of time.

[Keatah]

True, however if you look at arcade systems, they used FPGA's in some versions of the Playstation-based hardware (I believe all it does is add mpeg-decoding in the case of the Bemani kit with it), so it's not much of a logical leap that FPGA based emulators make sense for games that are timing-based (eg DDR), that otherwise software emulation will remain terrible at dealing with. With the PS/N64 and later it will be a personal taste of either wanting high-resolution output or low-latency-high-accuracy output since you can't have both, but not every game actually needs both.

 

Software emulation is currently ahead of fpga. And likely to remain that way for some time. Especially with SNES. Currently people are enamored with the (mystical) notion that fpga dupes the original console's circuitry. It does not.

[Newsdee]

 

Software emulation is currently ahead of fpga. And likely to remain that way for some time. Especially with SNES. Currently people are enamored with the (mystical) notion that fpga dupes the original console's circuitry. It does not.

But FPGA dupes the timings of the original console much more easily than software emumation, and as such can - eventually - act as full replacement with lower power draw than the original. That's pretty interesting IMHO.

[Tusecsy]

 

Software emulation is currently ahead of fpga. And likely to remain that way for some time. Especially with SNES. Currently people are enamored with the (mystical) notion that fpga dupes the original console's circuitry. It does not.

 

15k posts and you don't even understand how fpga works or why its vastly superior to emulators.

[Keatah]

Wonder if fpga can achieve a lower power dissipation than the original hardware. My guess is yes, though I have no figures for either. But I do have numbers for x86 software emulation.

 

With both fpga and x86 software you have added complexity, and in the case of x86 some overhead. But at the same time both techniques are using modern process geometry so there is less waste heat.

 

Right now on x86 software emulation (with monitor and chintzy speakers) it's costing me:

 

15W-22W for Doom in DosBox depending on what's going on in the game

21W for the Commodore 64

20W for the Atari VCS with some NTSC TV effects

18W for Sony PlayStation 1

17W for the Atari 400/800

16W for Amiga 500

16W for early arcade games like Gyruss, Tempest, Zaxxon, Discs of Tron, Blasteroids, Assault, Sky Raiders

13W for the Apple II

 

Certainly in the case of the arcade games and home consoles/computers the PC and emulation looks to be a huge savings in power. I believe it's safe to say it costs a nice round 20 watts on average to do software emulation of classic game and vintage computing platforms.

 

That's pretty damned nice!

Edited February 27, 2017 by Keatah

[Keatah]

Here we go again. And while we're going, I fixed it for you.

 

15k posts and you don't even understand how fpga works or why its vastly moderately (in some aspects) superior to emulators.

 

So tell me which fpgas you've programmed, and what electrical designs you've integrated them into..? yes? Speak up boy! I can't hear you!

[Newsdee]

Certainly in the case of the arcade games and home consoles/computers the PC and emulation looks to be a huge savings in power. I believe it's safe to say it costs a nice round 20 watts on average to do software emulation of classic game and vintage computing platforms. That's pretty damned nice!

How are you measuring those? Seems much lower than those I've made on my PC only (without monitor).

 

To quote an independent source:

http://www.cs.columbia.edu/~sedwards/apple2fpga/

 

Original Apple II: 25 to 31 watts

Emulation on PC: 62 watts

FPGA implementation: 5 watts

 

That was with an FPGA education board, dedicated boards consume even less. FPGAs could be very useful for portable retro computing.

 

My own measurement was about 100 watts on idle for my gaming PC (Win10 box), but it stays constant as long as the 3D acceleration isn't used. Emulators of that list wouldn't make a difference in consumption.

Edited February 27, 2017 by Newsdee

[Tusecsy]

Here we go again. And while we're going, I fixed it for you.

 

 

So tell me which fpgas you've programmed, and what electrical designs you've integrated them into..? yes? Speak up boy! I can't hear you!

I'll refer to kevtris, son.

[Keatah]

Come back and see me after he's schooled you up.

[Guspaz]

Why are we re hashing Coleco Chameleon topic in this thread

 

Retroblox is it own version of idiocy

 

Backing up games- Could be consider unlawful under DMCA

 

No, it isn't. The DMCA prohibits circumvention of DRM that controls access to copyrighted works, and none of the protection mechanism in retro consoles acted as a gatekeeper to the content itself, they instead prevented the host machine from *executing* the content. NES games, for example, aren't encrypted, and later official NES consoles didn't even have a 10NES.

 

CD's game usually have full version music songs --Could open RIAA action against them or users since the backup games including their music

 

That would only be a problem for distribution, not backing up. As long as the anti-circumvention rules aren't being violated, the RIAA does not have the right to restrict you from backing up your stuff, so long as you don't distribute it.

 

Usually need the official bios to run CD games, non official bios don't usually support most games

 

I'm not sure that I see the issue, Kevtris has placed the same restriction on the NT Mini, where most of the supported platforms require the user to supply their own BIOS files. This requirement clearly hasn't done anything to sap enthusiasm for that platform. They can either use the same solution, or they can do a clean-room reverse engineering of the BIOS and provide their own replacement. For some platforms, particularly the early ones, you can get away without having one at all. The GameBoy, for example. The BIOS just sets up the initial execution environment, and you can actually ditch the whole BIOS by more or less starting your emulation with the registers at certain pre-set values.

 

What the points of reading carts from games, when the system is running a emulator also considiering the system resources that would be lost doing this efficiently which may not be possible

 

They've been pretty clear about why they'd want to do that, I think: loading the cartridges directly enables greater accuracy by using real expansion hardware (don't need to use a potentially inaccurate emulation of the SA-1, SuperFX, DSP, etc), and enables compatibility with cartridges that can't work with dump-and-run approach: flash carts, Super Gameboy, etc.

 

What remains to be seen is if their proposed approach is actually practical. I've spent the last several weeks writing an emulator from scratch, and while accuracy hasn't been my goal, I've got a bunch of games running well enough that most people wouldn't notice the difference (you can fudge a lot of low-level timing, it turns out). This has given me quite an appreciation for just how difficult it is to even simulate accurate timing in batches, let alone to get emulated events to happen in accurate real-time down to the sort of level required here. Writing my own emulator has only made me more skeptical of the Retroblox approach. I can still think of some ways that you might pull something like that off, but they all seem like an absolutely enormous amount of work to me...

Edited February 27, 2017 by Guspaz

[androvsky]

 

No, it isn't. The DMCA prohibits circumvention of DRM that controls access to copyrighted works, and none of the protection mechanism in retro consoles acted as a gatekeeper to the content itself, they instead prevented the host machine from *executing* the content. NES games, for example, aren't encrypted, and later official NES consoles didn't even have a 10NES.

 

 

That would only be a problem for distribution, not backing up. As long as the anti-circumvention rules aren't being violated, the RIAA does not have the right to restrict you from backing up your stuff, so long as you don't distribute it.

 

 

I'm not sure that I see the issue, Kevtris has placed the same restriction on the NT Mini, where most of the supported platforms require the user to supply their own BIOS files. This requirement clearly hasn't done anything to sap enthusiasm for that platform. They can either use the same solution, or they can do a clean-room reverse engineering of the BIOS and provide their own replacement. For some platforms, particularly the early ones, you can get away without having one at all. The GameBoy, for example. The BIOS just sets up the initial execution environment, and you can actually ditch the whole BIOS by more or less starting your emulation with the registers at certain pre-set values.

 

 

They've been pretty clear about why they'd want to do that, I think: loading the cartridges directly enables greater accuracy by using real expansion hardware (don't need to use a potentially inaccurate emulation of the SA-1, SuperFX, DSP, etc), and enables compatibility with cartridges that can't work with dump-and-run approach: flash carts, Super Gameboy, etc.

 

What remains to be seen is if their proposed is actually practical. I've spent the last several weeks writing an emulator from scratch, and while accuracy hasn't been my goal, I've got a bunch of games running well enough that you'd probably not notice the difference. This has given me quite an appreciation for just how difficult it is to even simulate accurate timing in batches, let alone to get emulated events to happen in accurate real-time down to the sort of level required here. Writing my own emulator has only made me more skeptical of the Retroblox approach. I can still think of some ways that you might pull something like that off, but they all seem like an absolutely enormous amount of work to me...

I'm glad you posted your explanation of the DMCA first, it makes more sense than what I had down. (also glad this forum lets you know when there's a new post, lol).

 

Anyway... my problem with asking users to provide a BIOS in my view is you're asking them to go to the same dodgy websites that have all the games they're about to run. If someone's going to violate copyright to make a product work, why not just grab all the .iso and rom files while you're there and skip the middle-man? It's probably okay for an enthusiast product like what kevtris is working with, but for a regular person product like the Retroblox that doesn't seem like a reasonable approach. I still expect a reversed BIOS for the CD systems to be a stretch goal, or be limited to PS1 games.

Edited February 27, 2017 by androvsky

[Guspaz]

Some systems, you can get away without a BIOS at all (like the Gameboy, as I mentioned in my edited post). Some systems don't require one (I don't think the SNES did for the core system, and the enhancement chip BIOS wouldn't be required if real carts are used). Others have been reverse engineered in the past.

 

Take the Playstation, for example. Two companies reverse engineered the Playstation BIOS back in the late 90s and sold Playstation emulators while the Playstation was still Sony's latest console. Sony sued both of them and lost both times, but they probably wouldn't sue today because they no longer sell a console that can play Playstation discs.

 

There is also the option of licensing an existing modern effort to reverse engineer the Playstation BIOS, or building on an opensource effort.

[androvsky]

I believe there's an open source implementation for the PS1 BIOS already, I remember running it for a demo (don't remember which emulator, possibly PCSX-R?). Even yabause has a reversed BIOS for Saturn games. I think the standout ones are Sega CD, Turbografx CD (someone mentioned a game card that has the BIOS though), Jaguar CD, 3DO, and CD-i. There's definitely a pattern for CD systems. I'm coming from the perspective of the software emulators, I don't know how many of those implementations would be usable in an FPGA environment.

 

I'm also assuming that the Retroblox is basically going to be 95% software emulators with the GPIO pins memory-mapped into the emulator's address space, so pointers from the emulated CPU access the actual ROM hardware. It's something I discovered with my beaglebone-black project, but I didn't pursue it since I didn't want to mess with low-level parts of the emulators for so many systems for what I felt was no real benefit. kevtris' warnings about timings makes me feel better about my decision, but we'll see what gets demoed soon. I'm curious to see how far along they are currently.

[Keatah]

How are you measuring those? Seems much lower than those I've made on my PC only (without monitor).

 

To quote an independent source:

http://www.cs.columbia.edu/~sedwards/apple2fpga/

 

Original Apple II: 25 to 31 watts

Emulation on PC: 62 watts

FPGA implementation: 5 watts

 

That was with an FPGA education board, dedicated boards consume even less. FPGAs could be very useful for portable retro computing.

 

My own measurement was about 100 watts on idle for my gaming PC (Win10 box), but it stays constant as long as the 3D acceleration isn't used. Emulators of that list wouldn't make a difference in consumption.

 

Well sure. It would seem that emulators are using less power than I ever expected. And they “get lost” in a box that consumes 100 or more watts.

 

I'm using mobile-class hardware and that makes a huge difference. It allows you to see the small differences. I'm going to guess a lot of your efficiency is being lost in the power supply and the speed-stepping of the processor. A lot of times this isn’t optimized, and the voltage only swings from min to max, never operating in-between. Nor does the processor operate at the full range of intermediate frequencies. Not unlike my older P3 gaming rig, which is an extreme example and seems to consume 500 watts whether it needs it or not. Runs full speed at 1.4GHz. No power management besides screensaver. Needless to say I don't use it very much other than for legacy things needing legacy ports and legacy slots.

 

Back in the dot-com era I had a Pentium Northwood EE running 3.6GHz and a 6800ultra card and RAMBUS memory. Bitch had 4 fans screaming. And it was not possible to remove the memory until it cooled down, it was that hot. And while I never measured the power, it was much hotter than my P3. I swear it consumed 800w!

 

I tested the emulators on one of my utility computers "right-sized" for the task at hand. 2GHz class, CULV processor. 15" LED/LCD. Mobile chipset. Correctly working speed-step and voltage reduction. Typically the emulators used 30-80% of available CPU resources. Not so low they got lost in the noise of background system operations. And not so high that the processor was going full speed and threatening to drop frames.

https://en.wikipedia.org/wiki/Consumer_Ultra-Low_Voltage

 

When totally idle a system can consume around 5W-10W. With 10W being my goal for several of my utility computers. They're on a lot of the time doing duty as instant internet, email, and file-servers. The ace in the hole here is that most of these intel processors can still be undervolted just a tiny bit more than their spec. Thereby shaving off another watt. And I take advantage of that. And I understand the ATOM lineup uses even less power still, 2.5watts! But that will be future project.

 

So. I used a standard inline power logger to get the numbers and ran the test with and without the emulator running. I also turned off the frame-rate limiters to let them go full-tilt. I also did a CPU burn-in test. In all cases the power consumption doubled or tripled vs idle. This to verify changes were being measured.

 

---

 

My take-away is that emulator power consumption seems to be based on the level of detail and accuracy of the emulator more so than anything. The more accurate the implementation the more power used. What platform being emulated doesn't seem to have as much an effect as one would think. Not with the early 8-bit machines.

 

What may be surprising is that turning on video effects like CRT and NTSC artifacting, scanlines, and scaling can take as much as 20% more electrical power.

 

The PC platform having more background functions consumes more than FPGA. But because it is built with newer technology parts, even software emulation lets it clock in way under the original vintage hardware's power usage.

 

There is a complex interrelationship between process geometry size, speed, number of cycles, number of transistors, software efficiency, support hardware, and power saving features(that actually work). All of which can sway the numbers.

Edited February 27, 2017 by Keatah

[Flojomojo]

I like how this has become the do-everything emulation and FPGA discussion thread. (not complaining at all, I really do like it)

[Tusecsy]

You can get technical all you want, fact is games always feel better on FPGA simulation, not software emulation, and that's what matters to the end player. Emulators have always been crap, and will always be crap compared to original hardware, good riddance.

Edited February 27, 2017 by Tusecsy

[Kismet]

I like how this has become the do-everything emulation and FPGA discussion thread. (not complaining at all, I really do like it)

 

Probably because too many of the posts are in the Zimba 3K thread and it's hard to track anything in that thread that kevtris doesn't respond to directly.

 

Anyway, when it comes down to it, if you don't directly address the cartridges or discs, then what you are developing is a piracy device. That is exactly how it looks to the copyright police everywhere. Any device that can run Kodi looks the same as any Video game device that runs libretro. They can't play any of the original physical media and their primary selling point is playing pirated content even if they can play legal content. The only games you can legally play on these are games you backed up yourself, which almost nobody has the equipment to do.

 

When you directly address the cartridges and discs, then you can go "hey our device isn't a piracy device", even if everyone knows it is, and the device is going to primarily be used to backup the games. Basically the MPAA vs the VCR is the legal precedent that says "as long as the device is neutral to what it can record", the MPAA lost the ability to control how movies are distributed as a consequence, but we still got Macrovision as a crappy DRM scheme that was also easily defeated with an image stabilizer.

 

https://en.wikipedia.org/wiki/Sony_Corp._of_America_v._Universal_City_Studios,_Inc.

Edited February 27, 2017 by Kismet

[Keatah]

@Newsdee: a little additional followup.

 

I further crosschecked things and found the power consumption rates I previously mentioned to be spot on. And to get the real usage I subtracted the 12watts which the test setup consumes when standing idle, waiting at the desktop. It's actually 11.7 but I'm feeling generous and rounded it up to an even 12 to account for the occasional blip in background tasks, the occasional disk access, and USB port operation. USB polling just loves to keep processors out of the higher sleep states. Anyhow.. The numbers are impressive to say the least.

 

So this is what is costs to run specifically, and only, the software emulator itself. It includes drawing the screen and playing sound through small speakers at low-moderate volume levels.

 

3W-10W for Doom in DosBox

9W for the Commodore 64 playing Gyruss or Frantic Freddie

8W for the Atari VCS with some TV effects and playing Video Pinball, Combat, or Scramble DPC+

6W for Sony PlayStation 1 playing Tempest or Xevious 3D/G

5W for Atari 400/800 playing Star Raiders or MemoPad

4W for Amiga 500 sitting at the Workbench Desktop

4W for classic arcade games like Gyruss, Tempest, Zaxxon, Discs of Tron, Blasteroids, Sky Raiders, Assault

And an amazing 1W for the Apple II playing A2-FS1

 

In fact I'm so impressed that I want to create a new test and patch directly into the supply rails of the CPU. And do the same thing with the motherboard overall. With this test I'm not interested in the precise CPU power consumption but rather the inefficiencies of power supply and motherboard regulators. I want to flush that out. I may do a bonus with CPU temperature and realtime cache usage measurements.

 

Side note1: What i uncovered was a flaw in Emulator Stella for the VCS. The ROM selection screen takes an extra 3 watts above and beyond what is consumed while running the emulator. Must be some sort of faulty programming with funky loops in the sort routine going on. Could even be the graphic mode. Don't know. Don't care to investigate further.

 

Side note2: I also made sure that the host CPU was actually able to enter lower power states like c1-c3 when conditions permitted. Hastily setup gamer PC's often have problems here. The more time a processor spends in a higher c state the more it's sleeping. You can use Emulator Stella or MAME to deny/allow such snoozing and directly observe the states being entered or not. And you can observe corresponding decreases/increases in power usage.

 

A quick way of looking it at is modern CPUs can turn parts of themselves off. This is nothing new. The newest ones from Pentium-M onward selectively activate/deactivate parts of the cache. So you now have a balance to consider. Do you run the chip a little faster so it doesn't use the cache as much and burns a little more energy for a short amount of time? Or do you slow it down, and give it fast access via cache, thus using less energy but over a longer timeframe? The end-user won't noticed a damned thing, but the power consumption changes. Yes indeed. And it depends on the style of programming.

 

Another observation, DosBox power usage can be all over the graph depending on the task given it. Granted I have not checked all the CPU options it has and it may be possible to stabilize it. Whereas Things like the VCS or Apple II, which are totally alien to PC hardware, are rather steady no matter what type of software you run; bouncing around as little 0.5 - 1 watt.

 

Stella consumes what it consumes. 8 to 8.5 watts no matter if you're playing. The original pack-in Combat or a sophisticated 2017 DPC+ game like Scramble, they both use the same power. If you look at N64 and other "edgy" emulators, their power usage is all over the chart.

 

The more accurate the emulator, the more isolated virtual load fluctuations are from the host CPU. This means you could be running a simple counter or a flight simulator and the usage stays the same.

 

In general:

The more "distant" a simulated machine is from from the host platform the more raw wattage it will use.

The more accurate the emulator the more raw wattage it will use.

The more complex the emulated machine the more raw wattage it will use.

The more accurate the emulator and less trickery it uses, the more stable it's raw wattage power draw will be. Assuming the simulated machine doesn't have power save features, which means almost all 8 and 16 bit rigs of the day.

Using software rendering vs GPU rendering makes a huge difference. Turning on the GPU is going to suck power, yet at the same time do things so much quicker and efficiently, if your emulator needs that sort of gusto to begin with. Newer GPUs that can turn off unused cores are much more preferable, unlike the beasts of the immediate post dot-com era variants. Integrated ones are the best for efficiency.

 

And therein lies a complex load balance. And don't forget the "art of programming" too. It's not always a science. Look at the emulated VCS vs Apple II AppleWin figures? Amusing, eh?

 

Carry on.

[Keatah]

Probably because too many of the posts are in the Zimba 3K thread and it's hard to track anything in that thread that kevtris doesn't respond to directly.

 

It's become a complaint and feature-request thread. I want this, I want that. This doesn't work in 1080p mode, this game glitches. That game doesn't load. Not all is bad, there has to be feedback of some sort.