This is how we roll

[_Mitch]

What implementation do you intend? Something that acts as a minimalistic HAL, with JIT cross-compiling? You'll need some kind of F/R OS though, for it to work. If you're going through all that effort, why not just do your own FPGA implementation, and aim for an ASIC?

I think you'll find that the sheer number of memory mappers for the NES/FC, and directly implementing them at an assembly level will be a gigantic stumbling block, particularly M90 mMC5, and VRC7.

I've liked what I've seen of AngelScript, primarily because it allows C, and C++ syntax, including a mixture of both; and it's a ZLIB license. It's still an interpreter though, and there is no real reason that you couldn't allow four different syntaxes to compile to the same engine... The main disadvantage of C# that it's designed for Windows, and I'm shaky on support for PSOX-based OSes, which is why I'd be wary of it, although admittedly, I haven;t enough experience to form an objective opinion...

Sorry Gleeok, but Posix OS compatibility is always high on my priority list. Besides, you'll never be happy until you write your own interpreter from scratch, and you know it.

Maybe I should make ZPASCAL or ZCOBOL90, to prove a point. Then I can take an extended leave to a padded resort!

I'm steering clear of FPGA for now. But I do intend on using it at some point; it's not a simple topic, and something I'd like a little practice with first (I have no real experience with hardware descriptive languages in the first place). My console won't be designed like the NES exactly, just similar in usage. I've never done anything with JIT compilation, have you (I'd like some tips)? JIT-compilation can be interesting but machine level compilers tend to be insanely complex, plus if I wrote my own I doubt I'd get decent performance out of it (except in a multiprocessor environment).

It'll be very simple in design, and use stuff I have in my junk drawer. I will be using an ATmega32 as a cheap video display controller (crazy, but it works), and a ARM cortex M3 (underpowered, but it's retro) for processing everything. I'm going to use NES controllers (just because I have a few). An SD card will store all the games in raw Intel HEX format, in individual directories (with graphics); on boot you choose one to play. Once a game is chosen, it'll re-program the micro with the game; It's basic, won't have a lot of memory, and no background processes running (just the game).

I admit I have been thinking about an FPGA like custom GPU- but I'll save that for another time; I'm sure it'll take a few months till I get anywhere. There won't be any removable cartridges, or (E)EPROM chips. I worked on an NES emulator once, pretty painful to be honest. I'm also hoping to make something easier to develop (6502 isn't my definition of easy, decimal support or not).

If I add any scripting to any game (on the console or not) I usually implement it with an external program that you write in, and compiles it into a bytecode. The interpreter is usually pretty basic; and (like the bytecode compiler) game/program specific. I prefer to use a switch statement, because of performance reasons (plus function pointers can be a pain to debug). But any scripting would be in a C-like syntax, of course. I would go into detail about past implementations, but that would just be a wall of text here. I've never combined both compiler and interpreter for a write and run environment before (never had to), but for complex stuff that would be helpful. I've never written GP scripting, only stuff embedded into a game (for map making).

If you design your own interpreter, it'll likely be faster (for the specific task / planned usage) and probably easier for you to write in (especially on memory constrained systems). Originally C# was designed for Windows, but it's just a language, and recently, I have seen Linux and Unix implementations. Similarly I have a thing against C# because of it's Microsoft orientation, and portability issues. I grudge against Microsoft for attempting to overthrow C++ with C#- but what I really hate is .NET and Microsoft's anti C agenda. The only real thing I have against angelscript is I didn't write it TBH .

BTW I didn't intend to hijack any threads, so I'll try to stop now (it's a bad habit I have). Also, sorry about the wall.

[ZoriaRPG]

I'm steering clear of FPGA for now. But I do intend on using it at some point; it's not a simple topic, and something I'd like a little practice with first (I have no real experience with hardware descriptive languages in the first place). My console won't be designed like the NES exactly, just similar in usage. I've never done anything with JIT compilation, have you (I'd like some tips)? JIT-compilation can be interesting but machine level compilers tend to be insanely complex, plus if I wrote my own I doubt I'd get decent performance out of it (except in a multiprocessor environment).

It'll be very simple in design, and use stuff I have in my junk drawer. I will be using an ATmega32 as a cheap video display controller (crazy, but it works), and a ARM cortex M3 (underpowered, but it's retro) for processing everything. I'm going to use NES controllers (just because I have a few). An SD card will store all the games in raw Intel HEX format, in individual directories (with graphics); on boot you choose one to play. Once a game is chosen, it'll re-program the micro with the game; It's basic, won't have a lot of memory, and no background processes running (just the game).

I admit I have been thinking about an FPGA like custom GPU- but I'll save that for another time; I'm sure it'll take a few months till I get anywhere. There won't be any removable cartridges, or (E)EPROM chips. I worked on an NES emulator once, pretty painful to be honest. I'm also hoping to make something easier to develop (6502 isn't my definition of easy, decimal support or not).

If I add any scripting to any game (on the console or not) I usually implement it with an external program that you write in, and compiles it into a bytecode. The interpreter is usually pretty basic; and (like the bytecode compiler) game/program specific. I prefer to use a switch statement, because of performance reasons (plus function pointers can be a pain to debug). But any scripting would be in a C-like syntax, of course. I would go into detail about past implementations, but that would just be a wall of text here. I've never combined both compiler and interpreter for a write and run environment before (never had to), but for complex stuff that would be helpful. I've never written GP scripting, only stuff embedded into a game (for map making).

If you design your own interpreter, it'll likely be faster (for the specific task / planned usage) and probably easier for you to write in (especially on memory constrained systems). Originally C# was designed for Windows, but it's just a language, and recently, I have seen Linux and Unix implementations. Similarly I have a thing against C# because of it's Microsoft orientation, and portability issues. I grudge against Microsoft for attempting to overthrow C++ with C#- but what I really hate is .NET and Microsoft's anti C agenda. The only real thing I have against angelscript is I didn't write it TBH .

BTW I didn't intend to hijack any threads, so I'll try to stop now (it's a bad habit I have). Also, sorry about the wall.

My only tip for the present: Design your USB to SSR bridge PIC to use dual 4021 SSRs as inputs. That will give you SNES/SuFami, and NES/FC controller support, with no sacrifices. I did some basic JIT stuff in the past, but applicability to this project, is rather thin. As to FPGA design, the best thing, is to jump into it head first, and play with it, so that you can acclimate. It's the ultimate fusion of SE and EE, and depends on knowing the logic of both. There are tools to convert schem designs into FPGA instructions, but I can't attest to the best of those, at present.

If you want to discuss it further, a new topic would probably be best.

Regarding C#: Taking something that works, that everyone understands, and hijacking it, to make something proprietary, is exactly what Microsoft do as daily business. I'm more shocked that it can be used withotut .NET on Posix OSes. (I never expected that, and anticipated more of a boycott from the OSS community, regarding .NET reliance.)