Jump to content
IGNORED

FPGA vs. EMULATION? What is your choice?


Keatah

FPGA or Emulation?  

85 members have voted

  1. 1. Which do you prefer?

    • FPGA
      48
    • Emulation
      37
  2. 2. Which do you think has the most potential for perfection?

    • FPGA
      64
    • Emulation
      21

  • Please sign in to vote in this poll.

Recommended Posts

I think an FPGA doesn't really 'shine' in emulation. They are really good with algorithms, bitcoin mining, video manipulations etc. They can do emulation too, but it's not like emulating 20+ year old technology is cutting edge or something.

Edited by roland p
  • Like 1
Link to comment
Share on other sites

  • 3 weeks later...

How many games does mist do?

 

The MIST board was designed to implement classic 16 bit computers like the Amiga and Atari ST(E) as System-on-a-Chip using modern hardware. But it equally well supports 8 bit systems like the Atari XL, ZX81, ZX Spectrum, C64, Atari VCS, Atari 5200, Colecovision, Apple II, Sega Master System, NES, Odyssey2 and more ...

Link to comment
Share on other sites

  • 5 weeks later...

I am a convert to MIST from software emulation. After having had a chance to compare MIST side by side to the original hardware, I can never see myself going back to emulation on a PC or Mac. MIST is only painful 2 times, once when you pay for it and once when you set it up. For me, MIST is definitely the way to go if you can afford it and can handle setting it up.

 

 

Sent from my iPhone using Tapatalk

Edited by Grover Torbel
Link to comment
Share on other sites

I am a convert to MIST from software emulation. After having had a chance to compare MIST side by side to the original hardware, I can never see myself going back to emulation on a PC or Mac. MIST is only painful 2 times, once when you pay for it and once when you set it up. For me, MIST is definitely the way to go if you can afford it and can handle setting it up.

 

 

Sent from my iPhone using Tapatalk

 

For me the painful part was waiting for it to arrive from Hungary.

Link to comment
Share on other sites

Wow, sorry to say but many of these replies sound like people don't understand FPGAs and have never used them. FPGAs do not operate by emulation. They use a process called synthesis. There are very significant differences between hardware synthesis and software emulation. One of the most significant differences is in timing, which is very difficult to get right in software. In a hardware solution (like an FPGA), it's integral to the design.

 

I have a MiST and it's definitely superior to any kind of emulation. FPGAs are the best way to preserve old hardware because we can make them operate just like the original.

 

None of this is to suggest that I discount emulation. It's a great way to keep interest alive and give everyone quick-and-easy access to older software or hardware. MAME is probably the best example of the value and success of emulation.

Link to comment
Share on other sites

 

 

Correct...However, I believe the intention is whether you prefer (ultimately) software emulation over hardware emulation (At least that is how I viewed the question/poll).

 

Absolutely both can be cycle accurate (It would be a dream come true for the 7800); long term though, any FPGA falls to the same ultimate pitfall as any piece of hardware - it has a 'mortality' that is not present with (software) emulation.

 

I like to have both options, but again if I had to choose one over the other (software) emulation wins over FPGA (hardware emulation).

 

 

Software emulation has the problem of backwards compatibility. I had a bunch of emulators I knew how to use very well and upgrades to the OS, which were unavoidable rendered them useless. Unless the emulator is continuously updated (which possibly means open source if the original programmer gets bored of the project), emulators can become obsolete.

 

As for the poll, I was thinking more of a Plug and play type system where the choices are a software emulator and a reproduction of the original hardware, even if is done by something like an FPGA. A lot of the emulation PNP machines SUCK.

Link to comment
Share on other sites

Wow, sorry to say but many of these replies sound like people don't understand FPGAs and have never used them. FPGAs do not operate by emulation. They use a process called synthesis. There are very significant differences between hardware synthesis and software emulation. One of the most significant differences is in timing, which is very difficult to get right in software. In a hardware solution (like an FPGA), it's integral to the design.

 

I have a MiST and it's definitely superior to any kind of emulation. FPGAs are the best way to preserve old hardware because we can make them operate just like the original.

 

None of this is to suggest that I discount emulation. It's a great way to keep interest alive and give everyone quick-and-easy access to older software or hardware. MAME is probably the best example of the value and success of emulation.

Programming a console core in HDL is still emulation, just more "hardware" emulation. Just because it is on FPGA does not mean it will be automatically more accurate or that timings will be cycle exact to the emulated console hardware.

 

Just look at available open CPU cores (68000, Z80, etc), they are still using good old opcode interpreters, the original microcode is not being replicated but instructions behavior emulated using FPGA functions, with a rough timing approximation based on what is known on the chip (often similar to what is used in software emulators).

 

Same goes for proprietary ASICs (like PPU, VDP, SPU), sound chips, bus arbiters, etc... They are not replicated at gate level but again, emulated using FPGA functionnalities. The accuracy of emulation on FPGA depends a lot on the available documentation for the console hardware, which generally comes down to look how it is implemented in an accurate software emulator.

 

No, the REAL advantage of FPGA implementation is that it makes parallelizing code easier, which makes cycle perfect synchronization between emulated chips much easier to achieve than with traditionnal software emulation (even with multi-cores processors). But that certainly does not mean it WILL be timing -and functional- exact to the original hardware, never forget that the accuracy of emulation depends on a lot more things than cycle-exact synchronization. Looking at the available SNES (http://pgate1.at-ninja.jp/SNES_on_FPGA/) and Genesis (https://code.google.com/p/fpgagen/) cores, they are still far from perfection and definitively less accurate / compatible than existing software emulators.

 

Another advantage I can see of FPGA implementation is that it can interface more directly with legacy hardware, which can make it better for supporting things like original cartridge connectors, original controllers, RGB video out, etc... which indeed can give you the illusion that it's more close to the "real thing" than emulating roms on your computer.

Edited by philyso
  • Like 6
Link to comment
Share on other sites

 

Looking at the available SNES (http://pgate1.at-nin...p/SNES_on_FPGA/) and Genesis (https://code.google.com/p/fpgagen/) cores, they are still far from perfection and definitively less accurate / compatible than existing software emulators.

 

I presume that is mainly so due to the fact that with software based emulation, it is a faster development cycle. That is why I voted for software emulation. It is the most flexible in terms of getting the most people contributing efforts to it the quickest.

  • Like 1
Link to comment
Share on other sites

It might also be due to the fact that accurately emulating complex chips / consoles with a FPGA may require much higher-end hardware than software emulation which basically only use raw CPU computation power. It's one thing emulating a simple tile-based video processor like the ones used in NES or SMS, but getting more complex PPU, DSP or even FM sound chips accurately replicated likely requires much more knowledge... and much more gates, with potential limitations risk increasing with the complexity of the chips, thus impacting the accuracy of emulation.

  • Like 1
Link to comment
Share on other sites

Programming a console core in HDL is still emulation, just more "hardware" emulation. Just because it is on FPGA does not mean it will be automatically more accurate or that timings will be cycle exact to the emulated console hardware.

 

Just look at available open CPU cores (68000, Z80, etc), they are still using good old opcode interpreters, the original microcode is not being replicated but instructions behavior emulated using FPGA functions, with a rough timing approximation based on what is known on the chip (often similar to what is used in software emulators).

 

Same goes for proprietary ASICs (like PPU, VDP, SPU), sound chips, bus arbiters, etc... They are not replicated at gate level but again, emulated using FPGA functionnalities. The accuracy of emulation on FPGA depends a lot on the available documentation for the console hardware, which generally comes down to look how it is implemented in an accurate software emulator.

 

No, the REAL advantage of FPGA implementation is that it makes parallelizing code easier, which makes cycle perfect synchronization between emulated chips much easier to achieve than with traditionnal software emulation (even with multi-cores processors). But that certainly does not mean it WILL be timing -and functional- exact to the original hardware, never forget that the accuracy of emulation depends on a lot more things than cycle-exact synchronization. Looking at the available SNES (http://pgate1.at-ninja.jp/SNES_on_FPGA/) and Genesis (https://code.google.com/p/fpgagen/) cores, they are still far from perfection and definitively less accurate / compatible than existing software emulators.

 

Another advantage I can see of FPGA implementation is that it can interface more directly with legacy hardware, which can make it better for supporting things like original cartridge connectors, original controllers, RGB video out, etc... which indeed can give you the illusion that it's more close to the "real thing" than emulating roms on your computer.

 

Your statements on timing and emulation are not accurate. It seems clear that you don't understand how an FPGA works.

 

From someone that has actually written for and deployed on an FPGA, I can tell you that timing is a huge advantage. And it's a massive difference to be able to configure hardware at the gate-level for synthesis, rather than emulating behaviour in software.

 

And again, what you're saying about it "coming down to [how] it is implemented [in a software emulator]" is just plain wrong. You clearly have never written an emulator or programmed an FPGA. Hardware documentation for things like 8-bit Atari computers is pretty wide-spread, at this point. Reading schematics, testing against real hardware, etc. is a much better benchmark. Try talking with someone who actually works with FPGAs and you will get a better understanding than the assumptions you've made, above.

Edited by lightman
  • Like 2
Link to comment
Share on other sites

From someone that has actually written for and deployed on an FPGA, I can tell you that timing is a huge advantage.

Which timing? I am not sure what you mean by "timing is a huge advantage"? Software emulators use timings too to emulate chips, and they can be fairly accurate depending on the emulator and available documentation.

 

And it's a massive difference to be able to configure hardware at the gate-level for synthesis, rather than emulating behaviour in software.

All I am saying is that for complex systems like 16-bit consoles, current cores implementations are certainly not "configured" at "gate level" because it's hard to know how the various chips EXACTLY work internally cycle after cycle, how they were internally designed and assembled, etc... without decapping them, hence why it's more re-implemented with some form of emulation, based on real hardware testing off course, but just like software emulation is. Off couse, the beauty of VHDL is that you can replicate I/O signals timings accurately but there is more than this when it comes to emulate all the internals of the chip accurately.

 

Also, I think I know enough about software emulator programming and I can read VHDL/Verilog : this (https://github.com/Torlus/fpgagen/blob/master/src/TG68_fast.vhd) and this (https://github.com/Torlus/fpgagen/blob/master/src/vdp.vhd) aren't much different from what software emulators are doing: in the first, opcodes are being decoded then interpreted and in the second, VDP commands are being processed, data being transfered and video screen being rendered. From reading the code, nothing is done at gate level, the CPU and the VDP are treated just like two functionnal black boxes and their internal behavior is being replicated using common emulation techniques. The only difference is that FPGA code consumes input signals and outputs other signals, while a software emulator will simply get arguments from a function call and generate data to memory or call other functions. I agree that the code design is more close to the real hardware in FPGA but the internal implementation is not fundamentally different and, most importantly, it does not make one more accurate than other (actually, this VDP implementation is even less accurate than the ones used in current Genesis emulators).

 

Do you understand my point? For me, the most important advantage of FPGA is that every chips implementation are running in parralel while being clocked to a common master clock (just like on real hardware), which makes perfect sync between each of them much easier than with software running on a CPU. But for the implementation of any single chip itself, is not necessarely more accurate because it's on FPGA, and there is surely nothing that couldn't be replicated at that level in software with as much accuracy, as long as there is good documentation on how the chip internally operates and its timing.

Edited by philyso
  • Like 3
Link to comment
Share on other sites

 

Your statements on timing and emulation are not accurate. It seems clear that you don't understand how an FPGA works.

 

From someone that has actually written for and deployed on an FPGA...

 

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.

  • Like 4
Link to comment
Share on other sites

To philyso: Well, it sounds to me like you are comparing the syntax of VHDL, which doesn't have much to do with the final product. The way circuits in an FPGA behave after being configured through synthesis is very different from a CPU that is executing compiled code that ultimately emulates something else. I think I understand your point about things running in parallel; that is definitely part of what I mean about the timing. And it's a big advantage - I agree - but I don't think I'd say it's the biggest (or perhaps, most important).

 

To

tcdev: You say that *I* "constrast (sic) software emulation with FPGA synthesis"? That's what this whole thread is about. Haven't you looked at it? What do you suppose the topic "FPGA vs. Emulation" means? *My point* was that it's like comparing "apples and cats", as you put it. Of course, immediately after you make this statement you go ahead and do just what you seem so astounded by - you contrast and compare the two! Not only that, you make it sound like they are the same because of syntax. Where did I say or suggest that an FPGA was a "magic bullet"? Give me a break. Did you even read what I wrote? My 'rebuttal' to philyso was a reply to this:

 

The accuracy of emulation on FPGA depends a lot on the available documentation for the console hardware, which generally comes down to look how it is implemented in an accurate software emulator.

 

Philyso says that FPGA accuracy (and hardware documentation!) depends on looking at software emulators to see how it's done. I don't agree with that.

Edited by lightman
Link to comment
Share on other sites

Well, it sounds to me like you are comparing the syntax of VHDL, which doesn't have much to do with the final product. The way circuits in an FPGA behave after being configured through synthesis is very different from a CPU that is executing compiled code that ultimately emulates something else.

No, I am comparing the structure of the code and what it actually does. They do quite the same thing with similar level of abstraction to the chip hardware they are emulating.

 

What you don't get is that just because a FPGA can be configured at gate-level through HDL code does not necessarely mean the synthetized FPGA will be a gate-level clone of the replicated hardware. That's why it's still emulation, because the accuracy is determined by the accuracy of HDL code and that the HDL code does not try to reproduce original gates or transistors (unless the emulated chip is very precisely documented at die level) but emulate the chip behavior.

 

 

Philyso says that FPGA accuracy (and hardware documentation!) depends on looking at software emulators to see how it's done. I don't agree with that.

I said "generally" and obviously did not meant that hardware documentation came FROM software emulators but that their code COULD be used as documentation for other implementations, which includes FPGA implementations. I do not deny that some people do their own real hardware measurements to figure accurate timing and functionnal behavior of emulated chips for a FPGA implementation but, "generally", this work has been already done for software emulators (as it is needed for accurate emulation) so it's easier to just reuse what has been figured in software emulators and adapt it to HDL software or reimplement in HDL the available documentation. But the opposite is true as well, you could somehow port more accurate HDL implementation to a software emulator or use the hardware timings you measured for writing a more accurate software emulator. Again, the code implementation is not that much different, what is different is how it is executed. Edited by philyso
  • Like 2
Link to comment
Share on other sites

No, I am comparing the structure of the code and what it actually does. They do quite the same thing with similar level of abstraction to the chip hardware they are emulating.

 

What you don't get is that just because a FPGA can be configured at gate-level through HDL code does not necessarely mean the synthetized FPGA will be a gate-level clone of the replicated hardware. That's why it's still emulation, because the accuracy is determined by the accuracy of HDL code and that the HDL code does not try to reproduce original gates or transistors (unless the emulated chip is very precisely documented at die level) but emulate the chip behavior.

 

Yeah, I just don't agree with you on this and I don't think you're getting my point. Even though I don't agree, I appreciate your replies and I'll keep them in mind for future research. It might end up changing my perspective and it might not.

 

 

I said "generally" and obviously did not meant that hardware documentation came FROM software emulators but that their code could be used AS documentation for other implementations, which inclused FPGA implementations. I do not deny that some people do their own real hardware measurements to figure accurate timing and functionnal behavior of emulated chips for a FPGA implementation but, "generally", this work has been already done for software emulators (as it is needed for accurate emulation) so it's easier to just reuse what has been figured in software emulators and adapt it to HDL software. But the opposite is true as well, you could somehow port more accurate HDL implementation to a software emulator. Again, the code implementation is not that much different, what is different is how it is executed.

 

"Generally"? Based on what data? Do you have a list of authors and which emulation code they used for FPGA work? Which parts are carried over or used as reference? Again, there's lots of actual hardware documentation for older systems. I think you need to elaborate, if you're going to claim emulation sourcecode is the primary basis for FPGA implementations.

Edited by lightman
  • Like 1
Link to comment
Share on other sites

 

Do you have a list of authors and which emulation code they used for FPGA work?

 

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

  • Like 1
Link to comment
Share on other sites

Cool. One is a start. ;) It's definitely interesting to learn about how people work with FPGAs.

 

Ultimately, I still contend that you can't compare synthesis with emulation (executing code on a CPU is simply not comparable) and that FPGAs are still the best for preserving older hardware. Of course, a badly written FPGA core is no good and an expertly-written emulator is worth a lot. As I said in my first reply, emulators are great and I don't discount them but I think it's important to understand the difference in how an FPGA operates vs. an emulator.

  • Like 2
Link to comment
Share on other sites

You say that *I* "constrast (sic) software emulation with FPGA synthesis"? That's what this whole thread is about. Haven't you looked at it? What do you suppose the topic "FPGA vs. Emulation" means? *My point* was that it's like comparing "apples and cats", as you put it. Of course, immediately after you make this statement you go ahead and do just what you seem so astounded by - you contrast and compare the two! Not only that, you make it sound like they are the same because of syntax. Where did I say or suggest that an FPGA was a "magic bullet"? Give me a break. Did you even read what I wrote?

 

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.

  • Like 2
Link to comment
Share on other sites

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.

  • Like 4
Link to comment
Share on other sites

 

For proper emulation, you build a dedicated emulation computer. One that doesn't need constant updating, dual boot and VM if necessary.

 

 

I'm actually in the process of trying to do that (dual boot via CD/DVD), but it's a major pain in the ass so far. I have 2 dedicated emulation machines, but they are handheld device and I never bought the base for the one that has a base, and so I can't use it as anything but a handheld (GP32 and a GP2X).

 

I'm trying to get a working Puppy Arcade setup which will be a CD a thumbdrive and the hard disk for rom storage. Some problems I am running into are no video driver available (I think it's using a VESA mode) and up until now, I've been trying to use the CD for persistence and it hasn't worked because it will not write the persistence track when I shut down (I've not finalized the CD and it's re-writeable and I've tried several times).

 

I know you can write a puppy linux cd from the cd itself and I'm wondering if I can make all the changes I want and then write a new CD (to the original, since it's re-writeable) or if it will write just the original and not write a new image based on whatever changes I make to the system after boot-up. I just would rather it be CD only and not tie up a thumb drive and I definitely don't want it making a persistent system file on the hard disk.

 

I wish I had the room to have a dedicated machine for emulation. Even if I had a monitor/KB/mouse sharing device, I still don't have the room for it.

If I could find a base for my GP2X at a reasonable price, that would be pretty good. With the base I could use any USB joystick and output to my TV and it handles most of my emulation wants (the PSX/Saturn era forwards are not that interesting to me). The great thing about them is they can run on AA cells which will be available pretty much forever and there's no need to upgrade the firmware so the emulators will always work as well (or poorly) as they do now (unless updates come out).

 

I've also considered using a Bluetooth joystick with my android device, but I don't know how well they are supported and the screen isn't that big (like 8 inches).

Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...