Why I can not do it even after more than 30 years - Page 1
Forum section: electronics / projects

author: ali_asadzadeh
author_rank: Super Contributor
timestamp: June 28, 2017, 01:01:51 pm
content: Hi,When I was a kid I remember that I was playing with the Nintendohttps://en.wikipedia.org/wiki/Nintendo_Entertainment_SystemThey have used an 8-bit CPU running the code in the order of 2MHz, the cartridges had at least 4 games like super mario, Contra etc...I think they were under 512KB of rom,Now I can code in Cortex M, in the order of 200MHz processing power, have about 2MB of internal flash and can have as much as 512MB external SDRAM or external Flash, but even now, have segger emwin support, I cannot achieve what they have achieved 30 years ago!!! actually how do they did it? how did they implemented the games! in such low density and low capable devices! They had sound too…I member they got hot ( because they used 7805 as their main Regulator) and we used to turn a fan on the whole console to be able to play more than 3 hours!

author: Rerouter
author_rank: Super Contributor
timestamp: June 28, 2017, 01:12:34 pm
content: They did it by optimising for every last clock cycle, and offloading parts to external hardware, e.g. does the CPU need to control the screen, or just push rendered frames to a memory buffer,Do you need every bit of an image stored, or can you reduce the colour palette and reuse a lot of your backgroundsWith a 32 bit micro you can far exceed what they accomplished, but you cant use the same approaches, as ARM is a different architecture to what was used at the time,E.g. a lowly atmel sam 3x8e can push 16 bit colour to a 480x320 pixel lcd at over 100Hz using just its dma, and some cycle code, meaning almost all the computing power is left free to handle things like rendering, collisions, and player input.You can even use things like run length encoding on what you need to read to render an image, reducing the file size without much code size change.Your a single person, not a team of specilised engineers, you can accomplish it, but dont expect it to be as easy as an arduino library.

author: coppice
author_rank: Super Contributor
timestamp: June 28, 2017, 01:18:56 pm
content: Carefully adapted screen refresh hardware was a big factor in getting good results from these early machines. It had to be fairly low complexity, because of cost, but it also had to minimise the effort of the CPU needed to keep the screen updated. They only had to manipulate a few bits per pixel, as these were not deep colour machines, and the resolution wasn't that great. These things substantially reduce the CPU workload. Also, as Rerouter commented, they were really aggressive in optimising every spare cycle out of heavily used sections of code.

author: Mechatrommer
author_rank: Super Contributor
timestamp: June 28, 2017, 01:44:11 pm
content: Quote from: ali_asadzadeh on June 28, 2017, 01:01:51 pmcoding (learning the language, all the syntaxes and features) is the chapter 1 in programming, data structure and algorithm is chapter 2, optimizing them is chapter 3. optimize color by using pallete/table. lookup table of limited size and do extrapolation, algorithm of simplest division or square root, using fixed integer in place of floating point math, decision between ram limited vs cpu computation (flash size) limited etc etc is something you need to familiarize yourself with if you want to maximize the resources at hand. game engine (and hardware specific for cross platformness) is chapter 4. those who programmed nintendo were sharp people that chapter 3 and above is their bread and butter, not someone who think he can program something.

author: rstofer
author_rank: Super Contributor
timestamp: June 28, 2017, 01:56:53 pm
content: Google for something like 'architecture of pacman' and there are sites with the Z80 source code and hardware layout descriptions. The Z80 could run as high as 6 MHz but didn't need to for PacMan. This was smokin' fast compared to the 2 MHz 8080.I bought one of the Commodore computers and there was a game project included. One thing I learned is the concept of a super loop. The computer ran the loop for every frame. The thing is, it took more than one pass through the loop to complete an update. Some things were updated on one pass, other things on a different pass.Here is a great description of PacMan - note that the Z80 only ran at 3.072 MHz.https://www.lomont.org/Software/Games/PacMan/PacmanEmulation.pdfSprites are the tricky bit of the hardware. This allows an image (a sprite) to move over the top of the background image. This hardware was available on the Commodore and it may have been available on the Apple II - memory fades...Here are the schematics for PacMan. Note that there is a barn full of logic outside the Z80:http://www.classicgaming.cc/classics/pac-man/files/tech/Pac-Man-Schematics.pdfThe main site:http://www.classicgaming.cc/classics/pac-man/technical-infoI am pretty sure there are similar sources for other games. I picked on PacMan because I have a great FPGA implementation using the T80 core (Z80) from OpenCores.org. I doubt that it is the same as this project:http://arcade.gadgetfactory.net/index.php?n=Main.PacManHelpGoogle for 'fpga pacman' ...

author: NivagSwerdna
author_rank: Super Contributor
timestamp: June 28, 2017, 01:58:30 pm
content: Games hardware was often architected to be effective within the specific application area it was targeted rather than being general purpose so you find hardware solutions to what you are trying to achieve e.g. NES had a dedicated video controller (PPU) and also sound hardware. In Arcade machines you often see similar... e.g. early Konami machines had a Z80 for the game code but a secondary Z80 for sound processing and even then some of the sound functions were performed by dedicated hardware.But...Maybe you aren't trying hard enough... modern processors (and bus bandwidths) are so high you should be able to achieve the same games with emulation.

author: rstofer
author_rank: Super Contributor
timestamp: June 28, 2017, 02:02:00 pm
content: It is worth researching the MAME project:http://mamedev.org/They have a way to emulate the CPU and then tack on the various RAMs and ROMs. The result is a system that will play 100s of games in their original format. I built a MAME based arcade machine 10 or 11 years ago. Interesting project!

author: Mechatrommer
author_rank: Super Contributor
timestamp: June 28, 2017, 02:08:14 pm
content: Quote from: rstofer on June 28, 2017, 01:56:53 pmsprite is a concept in software development. you only draw where it needs to and save previous frame of that tiny area in memory for the next frame when the sprite moves away, much like swap/push and pop in stack/memory management, except this is graphical (2D) data instead of numeric/binary data. sprite will avoid the need of refreshing the whole screen everytime.

author: tooki
author_rank: Super Contributor
timestamp: June 28, 2017, 02:41:13 pm
content: Quote from: ali_asadzadeh on June 28, 2017, 01:01:51 pmUltimately it boils down to abstraction: modern systems use many layers of abstraction, which make them easier to program, more robust, and more secure. (And the code is far more portable.)They did so much with so little by basically writing it all in assembler with every clock cycle optimized, every trick in the book used, etc. Very efficient, but also very difficult, very error prone, and damned near impossible to port to other hardware - you have to write the entire thing from scratch.

author: madires
author_rank: Super Contributor
timestamp: June 28, 2017, 02:42:57 pm
content: They didn't link a bunch of fancy libs to create bloatwareIMHO the best starting point for learning to program is to start with an 8 bit MCU and a lot of resource restraints.

author: LaserSteve
author_rank: Super Contributor
timestamp: June 28, 2017, 03:04:03 pm
content: This page, from a game developer demi-god, is worth reading to understand how to think "High Performance" on minimal hardware. He's talking vector, not raster, but the model of how to think high performance, is similar. He has quite a few more similar pages on his site.http://www.jmargolin.com/vgens/vgens.htmSteve

author: DBecker
author_rank: Frequent Contributor
timestamp: June 28, 2017, 04:55:38 pm
content: I started in the late '70s using hand-assembled 6502 code and counting cycles.You could do quite a bit with the system, but it was a constant search for short-cuts.As an example, you won't see a modern system without nice fonts. Back then there wasn't "fonts", there was a single font. If it was an advanced system, it might have lower case. It was a rare system with lower case descenders (e.g. 'y' extends below the baseline). The typical system had a 5x7 glyph in an 8x8 box. That meant that character position calculation was a bit operation, avoiding even an add. By today's standards, it looked like crap. But it used several orders of magnitude less memory, and at least an order of magnitude less processor power.Bounds checking was also minimal. Today the rule is that everything is bounds checked. You'll get dinged in a code review if every input and every array reference isn't checked. Even if you can prove the bounds, the argument is that the code might change. Back then you only checked critical values that were likely to both be wrong and cause problems. You might accept that divide-by-zero will regularly occur and not put a check in the code if the only result was e.g. a display glitch. That's not lazy coding -- it actually takes much more thought, and can result in much faster code with a predictable run-time. But like a F1 car, the next person that works on the code needs to understand that everything is tied together -- a frame tube might also be carrying coolant and a vital part of the aerodynamics.

author: rstofer
author_rank: Super Contributor
timestamp: June 28, 2017, 05:57:48 pm
content: Figure out the video and sprite layers first. Consider a background (layer 0) with a moving cloud drifting by (layer 1). Then add an airplane (layer 2) in front of that cloud and add another cloud at the top layer (layer 3) that the airplane flies behind.So, the layers have a priority order. On the airplane layer, there is only the airplane, every other space is 'clear'. Same for the cloud layers. Now all you have to do is combine the layers in priority order.Remember, early arcade games didn't have a lot of resolution and therefore, there weren't all that many pixels to deal with.

author: Siwastaja
author_rank: Super Contributor
timestamp: June 28, 2017, 06:30:25 pm
content: 1) Specialized, even though trivial, HW blocks that offloaded the CPU (often even on the cartridge, to provide game-specific HW acceleration). Granted, modern MCUs have more advanced HW acceleration features, but they might not be optimal for building games; also, using them efficiently requires skill (just like it did back then).2) Today's bloated coding standard and general lack of skill (buzzwords over understanding), using many layers of poorly-designed libraries and run-time "frameworks", with the mindset of little thought given to how the actual machine runs the code. While this is rationalized by explaining that it's necessary to increase code readibility, maintainability, portability and reusability, sadly, way too often, the modern code fails to achieve these goals, by being difficult to write and maintain, so the added complexity may be there for no reason, just from the habit, because "this is the way it's done today". Most young coders are too accustomed to "the modern ways", because this been going on for more than 15 years, to the level that even talking about it this way is a taboo subject (no one wants to have the way they practice their profession totally questioned!)The issue here is actually the modern paradigm: "Write the code to describe your intentions and let the compiler handle the implementation; do not try to describe the operations you want the machine to do". This isverywidely spread and universally seen as the truth, and it indeed sounds like a very nice way to think.However, while this paradigm is quite right in that it makes little sense to always micromanage each code line today, you can still easily gain 1000x performance increases by knowing the rightgeneral ideahow the machine performs its operation, so you won't do it in a generally very stupid way, which happens at level too high so that the compiler couldn't optimize it, because you are asking for a slightly differentresult(or a radically differentwayfor the exact same result) than you'd be asking for if you knew what you actually wanted the machine to perform.When I write software where performance is important, I can often see how changes in the way of thinking and rewriting the slow part can easily achieve 100x performance increases. I couldn't do that if I didn't have an idea how CPUs, memory and caches work, or if I had a mindset of describing my intentions about the end result only. And this 100x difference is even without any bloatware in the middle, because I won't use it in the first place. It can easily make another 100x difference to ditch all the unnecessary, complicating shit.If your code does something in a second, it's often not fundamentally impossible to do it in a millisecond instead, and it doesn't usually require writing assembler or counting single clock cycles or whatever; because those are the tricks that often give you the final 20-50% performance gain if you are not satisfied with the 1000x increase you got by a sane, knowledgeable design. I very rarely need those tricks, although I do sometimes. It's usually something related to a specific instruction in the instruction set, around which I can build a higher-level idea, that cannot be expressed in C directly so that the compiler could do it automatically.

author: T3sl4co1l
author_rank: Super Contributor
timestamp: June 28, 2017, 06:52:55 pm
content: Besides optimization and language / library differences, ponder this:A Cortex-M4 is very roughly on par with the CPU of a Pentium PC, or Nintendo 64.The memory is very different: much less ROM and RAM on a stock micro -- but similar amounts can be added when external interfaces are available. The peripherals are much more limited as well: a truly huge amount of bandwidth is dedicated to visual output, whether it's a PC's 1MB+ SVGA video device, or the N64's RPU.Ponder this as well:When I was growing up, I had a 486 PC (25MHz, 32 bits -- slower than a typical M4, but similar capability otherwise). Among other things, I taught myself 2D and 3D graphics programming, in QBasic.Now, QBasic runs in 16 bit mode, and is interpreted (even when compiled to EXE, it works by calling the same subroutines). The run-time library is very heavy weight: every function call is FAR type (a 32 bit address, with dozens of clock cycles of overhead to execute the CALL instruction), and even a basic arithmetic expression might consume dozens of these function calls. (The floating point support is particularly slow: the run-time doesn't autodetect an FPU, so there's a half dozen CALLs just to test if it can use the hardware FPU, or if it has to branch to another part of the library that calculates it in software!)The best performance I got, with a stock QBasic implementation, was something like 20 frames per second with pretty simple models. It wasn't optimal by any means, I didn't know things that in-depth at the time -- but we're talking on the order of 100kFLOPs (floating point operations per second) here, out of a 25MHz clock. That's slow! (The 486DX, by the way, completes hardware floating operations in a few dozen cycles. Not nearly as fast as today's CPUs, but no slouch -- and a great improvement on the ~300 cycles typical of what QBasic arithmetic was designed for: the 8087 FPU.)For perspective:I came back to these programs, here and there, over the years. On a Pentium, with fixed point arithmetic and assembler subroutines for the most intensive functions (the innermost loop in the rendering process, and writing graphics to the video buffer), I approached screen refresh rate: 40 to 70 FPS.Later still, I "ported" the whole thing (everything from the outer control loop to the innermost render loop) into pure assembler. Also using floating point with optimal calculations (not stuffed away in subroutines). This pushed higher still. Although it also helped that I had a modern CPU at that time: a 1666MHz AMD Duron ran this at 450 FPS.(That fits the entire program, and all its data, entirely into CPU caches. Only video writes and device I/O has to touch the bus. The CPU is at a disadvantage, running in 16 bit mode still -- but it's clearly capable of executing about one instruction per cycle, on average!)So, in summary: you can always burden yourself with exponentially slower, while still semantically correct, code. (That is: the code still accomplishes the same exact task, but through very different sequences of instructions.) You can always add layers of abstraction. But each added layer slows down your program by some factor. Shake loose from those layers of overhead, and you can harness the pure speed of your CPU. You don't need to write in cryptic languages, like assembly, to achieve this: C does just fine. You do need to avoid using excessively heavy libraries and function calls, when a simple expression or loop will do.Tim

author: igendel
author_rank: Frequent Contributor
timestamp: June 28, 2017, 06:56:57 pm
content: For those interested in hard-code [edit: I meant hard-core!] optimization, I recommend the "Graphics Programming Black Book" by Michael Abrash (one of the programmers of Quake). Some of it is hopelessly outdated (tips and tricks for the 286/386 processor), but the rest can be a real eye opener.http://www.drdobbs.com/parallel/graphics-programming-black-book/184404919

author: rstofer
author_rank: Super Contributor
timestamp: June 28, 2017, 07:54:45 pm
content: Quote from: igendel on June 28, 2017, 06:56:57 pmThanks for the link. I downloaded the files and started reading. The early chapters are quite an exposition!

author: C
author_rank: Super Contributor
timestamp: June 28, 2017, 08:40:37 pm
content: Simple hardware & software can make a huge difference.One of my Z80s had a programmable character generator. That is just a fancy way of saying that the font rom that contained 8 rows of 8 bits, was replaced with a ram chip. Sounds simple but actually required a few chips & some logic to get it to work in video display. A one byte write changed a character on screen.When you look at VGA displays, most think of pixel that has color information in a memory array. It's built to display pictures & video.A CAD system back then wanted to display data like a digital scope, with low compute power. A simple black & white pixel plane in a memory array, one per channel. This makes data display faster with less CPU and makes pictures & video take more CPU power.A cheap CAD system could have one or more of these planes driving a video DAC. The Very high end CAD system could have be one CPU per plane.When you moved up from low end systems back then, you could find some very nice stuff if you wanted to get work done.TurboDos systems with greater then 16 Z80's in a system box that networked to many other system boxes like this. That is 16 CP/M users per box.The 68k was really built to be many CPU's using a system bus with priority vector interrupt system.The 68K system I used could expand from 8 slot system to 58 slots. And that was the recommended limit not actual hardware limit. Money was the big limit back then. This single user desktop system had at times had over $6000 in memory boards installed at times. This system existed before the PCXTTodays systems leave out a lot that was common in some places back then.

author: ali_asadzadeh
author_rank: Super Contributor
timestamp: June 29, 2017, 11:42:44 am
content: Thanks for your responsesI'm kinda professional in my own ways, I had designed systems with real time limits, mainly Protection relays with more than 60K lines of code, that they are monsters in their own ways, I should do optimization for a lot of things, calculating RMS,FFT,Frequency, time cure, event recording, modbus communications etc... Here you can see a sample Design from the Side view,The problem is that I do not know how to write a game, how a game engine works! and how super mario would do it's voodoo thing!

author: BradC
author_rank: Super Contributor
timestamp: June 29, 2017, 11:55:56 am
content: Quote from: ali_asadzadeh on June 29, 2017, 11:42:44 amI can not recommend this :http://www.ic0nstrux.com/products/books/game-programming-for-the-propeller-powered-hydra-book.. highly enough. It breaks game development down into the absolute basic building blocks, starting from ground zero. Grab a Parallax Propeller Demo board, and you can pretty much do all the stuff in the book step by step.I'm not much into games, and I've spent most of my life writing them rather than playing with them, but when I was into the Propeller a few years ago I got a Parallax gift voucher and bought that book. If I was starting out from scratch, that'd be an awesome place to start.

author: FreddyVictor
author_rank: Regular Contributor
timestamp: June 29, 2017, 12:25:20 pm
content: Quote from: rstofer on June 28, 2017, 01:56:53 pmalternatively, he could just have a peek at some code for STM32F429Disco:http://mikrocontroller.bplaced.net/wordpress/?page_id=3014there's also a version for F7Disco aswellnot sure about running it on an MProbably not the best way to learn tho'

author: Mechatrommer
author_rank: Super Contributor
timestamp: June 29, 2017, 12:43:29 pm
content: Quote from: ali_asadzadeh on June 29, 2017, 11:42:44 amsoftware engineering or computing science is a broad subject. real time control is very well different to database management (sql) application, so does game and many other areas. a game developer may screwed up in realtime control system and vice versa... you can invent or imagine your own game/physic engine to define the reality of your applications, but as many will advice, we learn from experts, besides the free links above, you may get the specialized book for the subject. i have a book that i havent read for many many years, i got interest but when thinking the outcome, i thought its not worth of my effort...https://www.amazon.com/Programming-2D-Games-Charles-Kelly/dp/146650868Xhttps://www.amazon.com/Cutting-Edge-3d-Game-Programming-C/dp/1883577705https://www.amazon.com/Building-3D-Game-Engine-C/dp/0471123269https://en.wikipedia.org/wiki/Game_enginehttps://en.wikipedia.org/wiki/Physics_enginealthough the nintendo back then may not be as bloated as current game development, so it took expertise to decide/optimize game engine for a particular system. game engine for nintendo may not be as fancy OOP as current game engine development, its probably highly coupled/locked/dependent to the hardware, as said every bits of codes and tables are tuned to that specific system probably unapplicable to other system. fwiw...

author: Nusa
author_rank: Super Contributor
timestamp: June 29, 2017, 01:24:49 pm
content: Quote from: Mechatrommer on June 28, 2017, 02:08:14 pmThat's a modern implementation using powerful CPU's and ignoring the history of sprites. Originally it was implemented as a hardware feature that merged small bitmaps into the video image. You moved them by changing their coordinates. You animated them by changing the bitmap and/or palette. The hardware took care of actually displaying them. Most consoles from the 70s, 80s, and 90s had hardware sprite features....the details varied by platform.

author: rstofer
author_rank: Super Contributor
timestamp: June 29, 2017, 01:37:45 pm
content: One thing that needs to be discussed is the type of game. An arcade game is an entirely different animal than, say, Unreal Tournament.The arcade game probably uses specialized hardware for the graphics display and a rather common microcomputer for the game play. It is merely an issue of moving sprites across the board and detecting certain events.PC (or play station) type games are entirely different and a LOT more complex with lighting, textures, physics and a host of other details that enrich the game beyond a simple arcade game. There's an entire industry built up around toolkits like Unreal Engine 3 (and there are other free engines as well):https://www.unrealengine.com/what-is-unreal-engine-4But developing these games is done at a much higher level because the graphics details are handled by the engine. If you need light, just plug a light into the map. Control it if you want (switch) but, basically, the engine handles the rendering of shadows and such (ray tracing).I have 3 books on Unreal Tournament development (all obsolete) and they must total a few thousand pages. There are video tutorials all over the Internet.I had forgotten about the Parallax Propeller. I have the game kit and played with it a few years ago. It was possible to build some fairly simple games with not a whole lot of effort.

author: JanJansen
author_rank: Frequent Contributor
timestamp: June 29, 2017, 02:37:33 pm
content: This is a intresting topic.I saw a YouTube movie once from a chinese who used the DSPICFJ128GP802 or DSPICFJ64GP802, he had Mario playing with sound on tv in 1 chip,i cannot find the movie anymore, maybe he removed it ?I am busy programming games also, whats so magic about it ?,i,m also intrested in building a NES in 1 chip ( something Nintendo themself wont do, they using Linux overkill ),there is little info available on how the NES roms exactly work with the hardware, i,m supprised about that.

author: Mechatrommer
author_rank: Super Contributor
timestamp: June 29, 2017, 07:36:56 pm
content: Quote from: Nusa on June 29, 2017, 01:24:49 pmyou are right, but still its a concept in game software, the cpu was so limited that sw blit blitting is out of reach, so its done in hardware...http://ca.olin.edu/2005/fpga_sprites/new_plan.htmsimilarly to things like ray tracing is done in many GPU hardware nowadays. if one day cpu is powerful enough to calculate ray trace in realtime, there is no more need to do it in hardware, but still its a long way to go...

author: T3sl4co1l
author_rank: Super Contributor
timestamp: June 29, 2017, 08:22:31 pm
content: IIRC, Atari 2600 was bit-banged, or nearly so; the CPU fed a shift register or something like that.Or was that another early system?In any case, the Atari was severely underpowered both in the cheap 6502 CPU and the minimal hardware that supported it. This is why its games were so very primitive.Tim

author: ali_asadzadeh
author_rank: Super Contributor
timestamp: July 01, 2017, 05:55:31 am
content: thanks,I always wanted to learn game programming, I guess I Could start learning Unity, since I have a good background of C# and Unity is Hot

author: Rerouter
author_rank: Super Contributor
timestamp: July 01, 2017, 05:57:43 am
content: Well it comes down to if you want to make a standalone console, or just a game, if a console, then unity is probably not anywhere where you want to be, (lots of floating point math), if just a game, then have fun,

author: dmills
author_rank: Super Contributor
timestamp: July 01, 2017, 06:22:24 am
content: This might be of passing interest."The ultimate gameboy talk (33C3)"Regards, Dan.

author: Fungus
author_rank: Super Contributor
timestamp: July 01, 2017, 11:20:33 am
content: Quote from: madires on June 28, 2017, 02:42:57 pmYep. You'll never learn that style of programming on a desktop PC or a big ARM chip. You have to be restricted or you won't get creative.This is Space Invaders running on an Arduino Uno, coded by me last year:32K flash, 2k RAM. Most of the flash is used for the 49K of sound samples taken from MAME.That uses an SPI screen but you can get Arduino shields with video output (eg. Gameduino)

author: rstofer
author_rank: Super Contributor
timestamp: July 01, 2017, 05:05:55 pm
content: Quote from: ali_asadzadeh on July 01, 2017, 05:55:31 amThe learning curve for Unreal Engine and Unity is nearly infinitely steep! There's a LOT to learn to get even a modest game working. Tutorials help.You spend an enormous amount of time on the map. If you can't find a suitable character, you will spend a lifetime creating a wireframe in some kind of CAD program followed by adding skin and texture in another program followed by kinematics in yet another program. That's why game development includes a cast of thousands. Mostly artists!Here's another way to do it where most structures, textures and figures are supplied:https://www.thegamecreators.com/Unity and Unreal Engine provide a foundation but there's an enormous amount of work involved with creating the actual game.Before you settle on an engine, find a tutorial that results in a complete game and use the same tools. Don't try to do this from scratch!There are also 'for sale' tutorials. Try to find one that includes the building supplies - columns, bricks, textures, etc.

author: Mechatrommer
author_rank: Super Contributor
timestamp: July 01, 2017, 11:28:24 pm
content: Quote from: ali_asadzadeh on July 01, 2017, 05:55:31 ami forgot the nintendo is cartridge based game. you plug a cartridge, then it play whatever game inside the cartridge. so i guess in the nintendo console, its just a generic engine or API or translator/parser. it probably will just load the sprite and sound into memory, translate the code in the cartridge for collision and motion logic or keypad respond logic etc. what sound to play if something happens etc etc. imagine you have 100 types of 2d video games (jet fighter, fpv shooting, mario bros etc), and you want to distinguish what is common among them, and then try to make generalization for them, the generic code will go to the console, and specific code will go to cartridges, and the specific code have to be efficient, so you have to specify the generic code (interpreter) so the input code (specialized code) will be efficient and small size . this is requires lof work, expertise and familiarity to my dictionary, good luck...

author: Mechatrommer
author_rank: Super Contributor
timestamp: July 01, 2017, 11:38:20 pm
content: i remember there is a game where you shoot flying duck with real physical pistol, i still wonder how they do it, its like super advance technology during the time where today i will need accelerometer, magnetometer and gps to do it.. was a fun time back then...

author: Nusa
author_rank: Super Contributor
timestamp: July 01, 2017, 11:54:16 pm
content: Quote from: Mechatrommer on July 01, 2017, 11:38:20 pmDo you mean this?:https://en.wikipedia.org/wiki/Duck_HuntIt's light pen technology, which detects the when the raster scan on the TV passes the point the gun is aimed at, which tells the computer where it was pointed.Now that CRT displays are almost dead, alternative technologies have to be used to get the same result.

author: ali_asadzadeh
author_rank: Super Contributor
timestamp: July 02, 2017, 05:36:42 am
content: Maybe Big Companies like (Former ARM) and Microsoft tried hard to make the illusion for us to see ourselves as programmers!!! but it's an illusion and the real programmers are from a small team in the big companies, where the secrets are kept! they hide the trough for us and made us think that we are real ones!

author: Mechatrommer
author_rank: Super Contributor
timestamp: July 02, 2017, 06:31:32 am
content: the illusion from them is for us to become a good user of their invention. the illusion that a good result comes from an easy going chores comes from ourself, or anybody behind the curtain whoever they are...

author: cjs
author_rank: Contributor
timestamp: July 02, 2017, 07:09:19 am
content: Quote from: Rerouter on June 28, 2017, 01:12:34 pmActually, sometimes quite the opposite. As T3sl4co1l the Atari 2600 was basically bit-banged: it had a chip to help with the television output but that had to be fed continuously as each line scanned across the screen. So typically you'd do all your logic and frame setup in a few hundred instructions during the vertical retrace interval, twiddle the the video chip during the first scan line, and then you had something like 17 cycles in the horizontal retrace interval (while the beam moved from the right side back to the left side again) to set up everything you needed for the next scan line.

author: JanJansen
author_rank: Frequent Contributor
timestamp: July 02, 2017, 12:53:45 pm
content: The NES is already more then 30 years old,is it legal to reverse engineer after 30 years ?,it should be in the public domain after all these years including all NES games.How does it works ?.

author: Rerouter
author_rank: Super Contributor
timestamp: July 02, 2017, 01:08:05 pm
content: copy write can last far longer than you ever expected.A 1982 bit of test gear i looked in to releasing files for was still covered by copywrite up to 2051 at minimum, and the company still existed, so i decided to play safe.In general copywrite is atleast 50 years after the creation date.

author: Fungus
author_rank: Super Contributor
timestamp: July 02, 2017, 01:11:26 pm
content: Quote from: Mechatrommer on July 01, 2017, 11:28:24 pmNope.There's no OS, no APIs, no BIOS, no loaders, nothing like this in the NES. The cartridge contains a ROM that goes into the memory space of the 6502 chip. When the 6502 is powered on it goes to the ROM and runs your code.You are responsible for everything that happens from there.There's a video chip that turns part of the 64K of memory into the image on screen. You change that memory to change the image.

author: Fungus
author_rank: Super Contributor
timestamp: July 02, 2017, 01:13:04 pm
content: Quote from: JanJansen on July 02, 2017, 12:53:45 pmThe hardware was legal to reverse engineer on the day it was launched.The games aren't.

author: JanJansen
author_rank: Frequent Contributor
timestamp: July 02, 2017, 02:00:38 pm
content: You need to reverse engineer at least 1 game to get knowing how it works before you can make your own games right ?How is data stored in a game cartridge, the same as the ROMs from online ?, then i can start emulating on PC first before building hardware.How do you find out how ROMS are build, is there info ?

author: Mechatrommer
author_rank: Super Contributor
timestamp: July 02, 2017, 02:24:52 pm
content: Quote from: JanJansen on July 02, 2017, 02:00:38 pmnow i remember i actually have the nes emulator saved in my hdd very long time ago, i've forgotten about it until you mentioned it. its called project64, it seems the site still up... not sure whats in there..http://www.emutalk.net/forums/6-Project64the emulator just load the rom file and start running the game, the rom content should be the same as original? i dont know but it should be, by definition... googling it turned out so many people have done this...http://www.emulator-zone.com/doc.php/nes/https://www.google.com/search?q=nintendo+emulator&ie=utf-8&oe=utf-8&client=firefox-b

author: JanJansen
author_rank: Frequent Contributor
timestamp: July 02, 2017, 02:34:40 pm
content: I also have NES emulator on my Dreamcast.Only how the software works no one explains, ofcourse you can always look for opensource codes, or take hexeditor, or test the hardware EPROM,i have no time for all that, i better write code.

author: T3sl4co1l
author_rank: Super Contributor
timestamp: July 02, 2017, 03:17:22 pm
content: May be relevant:Highly recommend Bisqwit's videos to anyone doing programming, beginner to professional.Tim

author: Fungus
author_rank: Super Contributor
timestamp: July 02, 2017, 04:29:04 pm
content: Quote from: JanJansen on July 02, 2017, 02:00:38 pmThat would be a very difficult way to do it. Normally you'd read the documentation about the video/audio chips in the NES then start poking values into the video RAM to see if anything appears on screen.Quote from: JanJansen on July 02, 2017, 02:00:38 pmThere's nothing magic in the cartridges. In most cases it was literally just a single memory chip connected directly to the console's address and data lines.(well, there weresomecartridges with extra hardware, particularly on the Atari 2600, but it's not necessary. Super Mario Bros on NES was just memory).Quote from: JanJansen on July 02, 2017, 02:00:38 pmBack in the day you'd have a special cartridge with a static RAM chip instead of a ROM and some extra hardware inside it with a cable and a bunch of 74LS logic chips to write to the RAM while it was still plugged into the NES.You'd:a) Assemble the code on a PC (80286, MS-DOS back when we did it)b) Write it to the RAM in the cartridge (eg. via the PC's parallel port)c) Reset the NES.

author: tooki
author_rank: Super Contributor
timestamp: July 02, 2017, 07:25:56 pm
content: Quote from: Rerouter on July 02, 2017, 01:08:05 pmCopyright. Copywritingis the process of writing text ("copy").Quote from: Fungus on July 02, 2017, 04:29:04 pmI was gonna say, there's extra magic in lots of game cartridges, from battery-backed RAM storage to improved sound chips, to extra RAM and even extra CPUs. This makes such games extremely difficult to move to emulation.

author: Nusa
author_rank: Super Contributor
timestamp: July 02, 2017, 07:40:41 pm
content: Anytime someone asks about legality in an international forum, the answers are going to vary by where you live. Even the duration and recognition of copyrights varies by country and issue date.https://en.wikipedia.org/wiki/Reverse_engineeringIn many cases and places, the reverse engineering itself is legal, but what you do with the information after that may not be, especially if you've found a way to make money from it.Also recognize that in this case we're talking about products that predate the DCMA and other modern laws, click-through licenses, and sometimes even the existance of license-holders that care anymore.

author: Fungus
author_rank: Super Contributor
timestamp: July 02, 2017, 08:25:16 pm
content: Quote from: tooki on July 02, 2017, 07:25:56 pmI guess towards the end of the NES/Atari console era it became more and more common for big-name titles to add extra chips. The way the system was run it was the only way to get your game published on NES.(Basically: Nintendo ruled with an iron fist by use of a "lockout chip" on every cartridge. Youneededthat chip in your cartridge and only Nintendo made them. To maximize sales of individual games Nintendo limited how many games were published each year. There was a monthly selection process where you could present your game for consideration. If they rejected it, game over. Your game never got published and all your work was wasted.)

author: JanJansen
author_rank: Frequent Contributor
timestamp: July 03, 2017, 03:21:17 pm
content: Quote from: T3sl4co1l on July 02, 2017, 03:17:22 pmWow, nice one.Only where does this Bisqwit have found the info before he gets started ?, he just starts writing in this movie, impossible if you dont know what to write.

author: Fungus
author_rank: Super Contributor
timestamp: July 03, 2017, 04:01:42 pm
content: Quote from: JanJansen on July 03, 2017, 03:21:17 pmI imagine he goes to somewhere likenesdev.comand reads for a while.(or any of the thousands of web sites devoted to this)

author: T3sl4co1l
author_rank: Super Contributor
timestamp: July 03, 2017, 04:36:07 pm
content: Or for that matter, the fact that he's studied the NES, NES games, emulators and programming for the last decade(s). He founded tasvideos.org.Tim

author: Mechatrommer
author_rank: Super Contributor
timestamp: July 03, 2017, 06:29:22 pm
content: Quote from: JanJansen on July 03, 2017, 03:21:17 pm

author: Siwastaja
author_rank: Super Contributor
timestamp: July 05, 2017, 07:58:54 pm
content: When one looks at the NES specs and wonders how the games achieve what they do using that hardware, the answer is, they don't. It's quite important to notice that most NES games rely heavily on HW extensions, or extra "hardware acceleration", as it might be called today, on the cartridges. Only the early, or very simple-looking games were simple ROMs. The games most people think about when they wonder how they achieved it, however, utilize the external addon chips, misleadingly termed as MMCs or "memory management controllers", even though they do a lot more than what is meant by "memory management" today, even things totally unrelated to memory handling (such as providing extra audio channels, etc.)Supporting all, or even most of these chips is/has been an issue when writing emulators.This made the lifespan of cartridge-based consoles longer, as they could always "upgrade" your console by supplying some new HW; think about how the latest NES games (utilizing the latest addon chips, and doing it well) looked nearly as good (or even better) as the first or cheapest SNES games (utilizing none).