How does the machine determine what is displayed on the screen (6502 specifically)?

I know this is an incredibly vague question, and this may not be a very good question for programmers, since it is really hardware related, but I assume that the assembly / machine code comes in a game that is suitable for this site.

So I'm wondering: Imagine a 6502 processor. It has several registers, a set of instructions, and access to a specific amount of memory. Then imagine that you have an arbitrary resolution LCD screen. How is what shown on this screen determined? How is it determined which pixels, in which position is given what color? Is a screen always displayed, for example, a pixel with a value in the battery 6502 and with the position x stored in the register x, and the y-position stored in y? Or is this interpreted differently on each machine?

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

LDA #$08 STA $200 

will display a pinkish pixel at x: 0, y: 0.

 LDA #$01 STA $205 

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

However, if you look at NES, it has a dedicated PPU that displays specific pixels with a specific value in a specific area on the screen.

So how does it work? Is it interpreted differently by each machine (e.g. Apple II, C64, NES), or is there some sort of sequence of how it is interpreted?

In fact, what happens if a program compiled for Apple II somehow runs on C64? The machine should be able to read the instructions, right?

+4
source share
6 answers

How graphics are displayed depends on the machine, so therte is not a definite answer. For example, on C64, graphic equipment was mapped to the usual address space, so you had to write to a specific part of the memory to print characters on the screen. If you want to display graphics, you had to switch the mode by writing to the display hardware registers, and the displayed memory may change. Because of this, the normally available C64 memory was lower than 64 KB. You can turn off the display of the memory, and thus access the full memory under the graphic memory so that it turns into a machine without a display.

However, on the PC, you had, for example, VGA, EGA, Hercules, etc., which were recorded by accessing a specific port and sending commands through these ports. A completely different approach. But this solution is for system design and does not depend on the processor.

In fact, what happens if a program compiled for Apple II somehow runs on C64? The machine should be able to read the instructions, right?

Well, the answer is pretty clear. Most likely, this will work, because even if the set of instructions can be the same (I do not know which processor had the apples), the details of the equipment will be different.

+4
source

The processor itself is not directly related to the display of things. The use of the display (if any) depends on other hardware components, which may vary between different machines. As you say, NES has PPU, C64 has VIC, and the emulator may have something else.

Yes, if the processor is the same, the instructions will be the same, but things like the executable file format, hardware peripherals, memory layout and any OS / ROM services will be different, so the program will probably not work.

+5
source

This is very system specific. A video card or graphics system or whatever you want to call requires a certain number of bits or a set of bits in some memory and turns this into signals for video. The interfaces to the displays are standard, television inputs, vga, dvi, hdmi, etc. There are popular clones of popular video cards, etc. that will take you from the memory to these video signals, but you still need to find out what you have a program for him.

Image size, X by Y pixels, number of colors, number of pixels per color, if programmed, is what someone should program and / or use the default values, if any, and so on. The emulator that you use can emulate the popular 6502 video system, but this is not necessarily related to the 6502 itself. There were about 6502 systems with integrated video or support chips, but it is really separate from the 6502 processor itself, the processor follows the instructions and displays you on the interface memory, memory, and any other peripheral devices are not part of the main processor, but ... peripheral devices ...

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

+4
source

In addition to the processor, the machine usually also includes another chip for processing the display. GPU each machine may have a different graphics processor with different resolutions and color depths. So it all depends on the GPU. The 6502 itself has no idea about the display.

+2
source

Naturally, this varied greatly between different hardware, but the general way to display data on a screen is a chip that reads from a specific area of โ€‹โ€‹memory and displays it on the screen. To change what is shown, you simply write to the memory area, and the chip will display the new data in the next display cycle.

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

Since the way of accessing various hardware (for example, a screen and a keyboard) differs between computer brands, a program for one computer cannot work on another. Only a program that does not interact with any equipment at all would be portable, but it would be a rather useless program.

+2
source

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

Each machine has a video subsystem, and the role of the CPU is usually to program this subsystem to display what the program wants to display. In very simple systems, the CPU typically creates a matrix representation of the image that will be displayed on the screen. Then the graphics subsystem scans this memory and corrects the pixels on the screen to the values โ€‹โ€‹that it sees in this matrix. This prevents the CPU from doing more useful work while this is happening. In modern systems (OpenGL, etc.), the processor simply transfers commands to the graphics card through PCIe and allows you to do most of the work. Running C64 code on some other machine (with the same processor) will still work with instructions 6502, but the program would expect a certain exit from peripheral devices, whatever would happen, and something freezes as soon as The CPU will start programming one of these subsystems; it does not exist (like c64 VIC ).

+1
source

Source: https://habr.com/ru/post/1486414/


All Articles