How does a machine determine what is displayed on a screen (6502 specifically)? [closed]

Question

Closed. This question is off-topic. It is not currently accepting answers.

---

Want to improve this question? Update the question so it's on-topic for Stack Overflow.

Closed 8 years ago.

Improve this question

I know this is an incredibly vague question, and it might not be a good question for programmers, since this is really a hardware related thing, but I guess some assembly/machinecode comes into play which would be appropriate for this site.

So what I'm wondering is; imagine the 6502 processor. It has some registers, an instruction set, and access to a certain amount of memory. Then imagine that you have some LCD screen with an arbitrary resolution. How is it determined what is shown on this screen? How is it determined which pixels at which position is given what color? Does the screen always display, for instance, a pixel with the value in the accumulator of the 6502, and with x position stored in register x, and y position stored in y? Or is it interpreted differently by every machine?

Someone wrote a JavaScript 6502 emulator, and the device displays a pixel with its value at some memory position starting with $200. So for instance:

LDA #$08 
STA $200 

would display a pinkish pixel at position x:0, y:0.

LDA #$01
STA $205

would display a white pixel at position x:5, y:0.

If you look at the NES, however, it has a dedicated PPU which displays certain pixels with a certain value at a certain area on the screen.

So how does it work? Is it interpreted differently by every machine (i.e. Apple II, C64, NES), or is there some kind of consistency of how it is interpreted?

As a matter of fact, what would happen if a program compiled for an Apple II was somehow executed on a C64? The machine should be able to read the instructions, right?

Answer 1

How the graphics is displayed is machine dependent, so therte is no definite answer. For example on the C64, the graphics hardware was mapped into the normal address space, So you had to write to a specific part of the memory in order to print characters on the screen. If you wanted to display graphics, then you had to switch the mode, by writing to registers of the display hardware, and also the mapped memory could change. Because of this, the normally accessible memory of the C64 was lower than the 64KB. You could switch off the memory mapping though, and thus get access to the full memory below the graphics memory, so it turned into a machine with no display.

However, on the PC you had e.g. VGA, EGA, Hercules cards and so, which were written to by accessing a specific port and sending commands to it via these ports. A totally different approach. But this is a system design decision, and doesn't depend on the CPU.

As a matter of fact, what would happen if a program compiled for an Apple II was somehow executed on a C64? The machine should be able to read the instructions, right?

Well, the answer is pretty clear. It would most likely crash, because even if the instruction set might be the same (I don't know which CPU the Apples had), the hardware details would differ.

Answer 2

The processor itself doesn't directly deal with displaying things. How a display (if any) is used depends on other hardware components which may vary between different machines. As you say a NES has a PPU, the C64 has a VIC, and an emulator might have something else.

Yes, if the cpu is the same the instructions would be the same, but things such as executable file format, hardware peripherals, memory layout and any OS/ROM services will be different so the program probably won't run.

Answer 3

It is very specific to the the system. The video card or graphics system or whatever you want to call it takes a bit or set of bits in some memory somewhere and turns that into the signals for the video. The interfaces to the displays are a standard, televison inputs, vga, dvi, hdmi, etc. there are popular and clones of popular video cards, etc that get you from memory to those video signals, but you still have to figure out what you have and program for it.

The size of the image, X by Y pixels, how many colors, how many pixels per color, if programmable, are something that someone has to program and/or use the defaults if there are any, and so on. The emulator you are using might be emulating a popular 6502 video system, but it is not necessarily anything related to the 6502 itself. There were some 6502 systems with video integrated or support chips, but it is really separate from the 6502 processor itself, the processor executes the instructions and gets you to a memory interface, the memory and whatever other peripherals are not part of the core processor, but...peripherals...

So you need to look into the specific system, this simulator, a C64, etc and study each one separately to understand its video system, control registers, how video memory is mapped into the processors address space, etc.

Answer 4

Naturally this would differ a lot between different hardware, but a common way to display data on some kind of screen is that there is a chip that reads from a specific memory area and displays it on the screen. To change what's shown you just write to the memory area, and the chip will show the new data in the next display cycle.

I am familiar with the 8 bit Ataris, where the memory area used for display differs depending on graphics mode and available ram, so there is a pointer to the start of the screen stored somewhere in the zero page.

As the way to access different hardware (e.g. screen and keyboard) differs between computer brands, a program for one computer can't run on another. Only a program that wouldn't interact with any hardware at all would be portable, but that would be a pretty useless program.

Answer 5

In addition to a CPU a machine usually also includes another chip for handling display. The GPU. each machine may have a different GPU with different resolution and color depth. So it all depends on the GPU. The 6502 itself has no knowledge of display.

Answer 6

Start surfing here: http://en.wikipedia.org/wiki/Framebuffer, then go here: http://en.wikipedia.org/wiki/Graphics_processing_unit.

Each machine has video subsystem, and CPUs role is usually to program that subsystem to display what the program wants to display. In very simple systems CPU usually creates matrix-like representation of image that will be show on screen. Graphics subsystem then just scans this memory and adjusts pixels on screen to values it sees in this matrix. This prevents CPU from doing more useful work while this happens. In modern systems (OpenGL etc.) CPU just sends commands to graphics card via PCIe and lets it do most of the job itself. Running C64 code on some other machine (with same CPU) would still run 6502 instructions, but the program would expect certain output from peripheral devices, that would not happen, and things would freeze as soon as CPU would start programming one of this subsystems that do not exist (Like c64's VIC).