I didn't know whether to ask this from /g/ or /vr/, but

>>3811453

>Is there a good book about computer architecture that could really help me out? I'm still a novice when it comes to stacks and heaps and counters and all that stuff.
I don't know any good general books about computer architecture, but you'll definitely want to pick up a copy of the processor manual for the z80 (if you don't already have one).

Do you have any more specific questions about computer architecture stuff, or are you just looking for good reading material?

>Also semi related, would it be beneficial to learn x86 assembly first before tackling z80 assembly? I've heard they have some similarities, but I'm not sure if it would actually be easier.
Yes and no. On one hand, learning any assembly language will make the rest of them easier, but x86 is a nightmare to read and even worse to disassemble. You're probably better off spending that time getting better at the architecture you're actually working with.

>>3811453
I don't understand. If you want to emulate Pac-Man, why not just use MAME?

In either case, not only do you need to be intricately familiar with z80 assembly to do anything like this, you need to know Pac-Man's unique memory map and every other piece of hardware in the machine. If you're a novice, this may be way too difficult a project for you to handle.

>>3811467
I'm looking to read pretty much anything tangentially related to the topic at hand. I don't think there's really any books specifically about emulating cpus, but I could be wrong. Maybe I'm just not searching for the right keywords.

I've found quite a few tutorials though, but a lot of them are incomplete.

how would someone who only knows c++, python, etc go about making an emulator, as simple as can be?

>>3811453
OP, and anyone else in this thread interested in computer architecture and low level computing, I HIGHLY recommend watching Chris Terman's MIT CS 6.004 lectures. The class covers how to design the logic of a processor from the ground up.

https://www.youtube.com/watch?v=9DWlqtsNGV0

Do not learn x86 first, or really ever, unless you need to program assembly on your desktop. It really is nasty, mainly because of 40 years worth of backwards compatibility and the growing pains associated with that.

>>3811550
>>3811476
Over all writing software that emulates a CPU or a full blown system isn't really that hard. There are many ways to attack the problem, depending on the level of accuracy that you desire. On one hand, you could literally just brute force emulate the pins on the CPU; for every clock cycle given the input you determine the output. Unless you are simulating circuits, this usually isn't the way to go. On the other hand you can relax things like cycle-perfect emulation to make writing the CPU emulation software more straight forward. Most of the time this is ok, but there are always programmers out there that relied on specifics to make their programs run correctly on actual hardware, and the game may break on less accurate emulators, even if the program runs the same way.

In general, an emulator needs 3 things: input, cpu emulation, and output. The I/O is system dependent, so you have to pick you favorite UI and program against that. Once you have a window to render to, the video output can be drawn with OpenGL. You have to read the documentation for the particular console you are targeting and write software mimicking the graphics hardware. For old systems, the graphics hardware output is fully determined by memory and the setting of some switches in the form of registers.

Of course the devil is in the details, but the majority of an emulator is pretty straight forward.

>>3811476
>I'm looking to read pretty much anything tangentially related to the topic at hand. I don't think there's really any books specifically about emulating cpus, but I could be wrong. Maybe I'm just not searching for the right keywords.

Yeah, I've never come across a full book about emulation - and any tutorials I could recommend to you would basically what you've already found with your google-fu.

>>3811550
>how would someone who only knows c++, python, etc go about making an emulator, as simple as can be?

First things first, learn the architecture for the processor you're emulating. Trying to write an emulator without understanding how the processor handles different opcodes is almost impossible.

Since you know mostly OO languages, you're probably more comfortable thinking of things as classes? You probably want a class that contains the main processor and the general purpose registers, a class for your RAM, maybe a class for your stack, and a class for any external chips on the board (video processing units, sound processing units, etc). You're going to have to read up on how all of those operate from an I/O standpoint, and then you can write your methods to that spec.

Generally speaking, though, you're going to read an opcode from the binary, then execute the instruction you read. How you display things to the screen is going to vary widely by what you're trying to emulate.

>>3811474
>In either case, not only do you need to be intricately familiar with z80 assembly to do anything like this, you need to know Pac-Man's unique memory map and every other piece of hardware in the machine. If you're a novice, this may be way too difficult a project for you to handle.
While I don't disagree with you in the general sense, if he's not trying to make a particularly accurate emulator, a decent portion of that can be hand-waved.

>>3812448
>Do not learn x86 first, or really ever, unless you need to program assembly on your desktop. It really is nasty, mainly because of 40 years worth of backwards compatibility and the growing pains associated with that.

The newer revisions of x86 are interesting enough to learn for a few reasons (memory segmentation, little-endian bullshit, artifacts of it once being an accumulator architecture, etc), but usually those are the same things that make it really annoying to use from a programming perspective.

Plus, x86 has the best compiler:
github . com/xoreaxeaxeax/movfuscator

File: 1458661101171.jpg (86KB, 548x480px) Image search: [Google]

86KB, 548x480px

>>3811453
Go with z80 first, ignore x86 unless you want to make software for x86 processors.

This is a kids book, but it is fucking excellent for the basics. It's written for both z80 and 6502, illustrates counters, registers and how you interact with the CPU using machine language. Check it out, then start looking at documents more specific to the z80.

http://www.worldofspectrum.org/pub/sinclair/books/MachineCodeForBeginners.pdf

Also, don't let >>3811474 discourage you. Yes, you have to know and understand the z80 instruction set and all of the hardware architecture of every chip on the PCB and in the cab, but if you take it step by step you can get there in a couple of years. And on top of it, you'll know a hell of a lot more.

>>3812623
That link didn't seem to work, but I was able to find it on archive.org too.

https://ia600206.us.archive.org/20/items/machine-code-for-beginners/machine-code-for-beginners.pdf

Thanks btw, I wish I would've had this book when I was younger. Very basic, but also very helpful.

File: z80_reg.gif (4KB, 420x439px) Image search: [Google]

4KB, 420x439px

Do you guys understand how processors operate?

It's really fun to learn and yields knowledge that's portable. Every programming language operates the same way when it comes down to it.

The processor continuously executes instructions. Instructions modify the state of the computer. The computer includes the processor itself and the memory connected to it.

There are memory cells within most processors called registers. Some can be used for any purpose. Some are special.

One special register is called the program counter or instruction pointer or something like that. Its value references the location in memory of the next instruction to execute. The processor simply reads the bytes in memory and executes them. This is called fetching.

These bytes typically encode both operations and their operands, if any. In order to execute bytes from memory, the processor must first break them down into their individual parts. This is called decoding.

Once decoded, the processor will perform whatever operation was specified in the instruction in hardware. For example, if the instruction specified the addition of two registers, it will use its arithmetic logic unit to do so.

loop:

instruction = memory[instruction-pointer]
operation, operands = decode(instruction)
execute(operation, operands)

goto loop

You can find this basic pattern in every processor, in every virtual machine, every emulator. For a beginner, it helps if you view the instruction set of the processor as an API you must implement.

Video games are soft real time applications. Fully emulating them requires modeling the timing characteristics of the original hardware. It's quite a ride. Gotta deal with clocks and synchronization between components and modeling the minutiae that's inside the components that were supposed to be black boxes.

The above is a really nice way to get started though

File: anon pls let me love you.png (416KB, 712x560px) Image search: [Google]

416KB, 712x560px

>>3812448
Damn I love that guy's classes

>>3811453
You won't be able to emulate a z80 plus all the other custom hardware on a z80. It's a fools errand.

>>3812828
I understand very well how many processors operate. Modern programming languages and processors don't operate the way you think they do. They only operate linearly when absolutely necessary. In fact most processors from 1980 on can optimize the execution order in the pipeline. More recent ones can spread tasks out over multiple threads and cores.

>>3813117
>You won't be able to emulate a z80

Are you stuck in 1993?

>>3811453
You're obsessing over the wrong things.

It's not particularly difficult to implement the z80 instruction set and simulate the registers of a CPU (ignoring performance). The difficulty comes from studying the hardware you're emulating to the degree that you can implement all the hardware quirks, including the undocumented ones.

>>3813118
>You won't be able to emulate a z80 plus all the other custom hardware on a z80.
reading comprehension kiddo

>>3813246
There is plenty of documentation about the z80 and there are numerous emulators already on the internet. If they can do it I don't see why someone else can't.

>>3811453
Try programming the Sega Master System first.

>>3811453
>Pac Man

You won't just be emulating a chip, then. You'll be emulating hardware I/O and potentially other chips for graphics and sound depending on what system you're talking about here.

>>3813262
reading comprehension kiddo

File: 6134433+_2dad818482c768863c1e62fd225d9d26.jpg (20KB, 480x480px) Image search: [Google]

20KB, 480x480px

>>3811453
>"Is there a good book about computer architecture that could really help me out?"
Most computer architecture books are just 700-page MIPS advertisements

i haven't read his computer organization book but tanenbaum books tend to be the most "manly" modern intro books on their subject. maybe look at that. good hardware documentation is essentially self-contained but a computer architecture book could help you understand how to fit together the pieces

i also have never written a CPU emulator but i assume it's a software translation of the hardware's microarchitecture. you will have to describe everything that most VLSI/mobo designers don't even think about because their design abstractions protect them from such details

>that could play Pac Man
now you need memory and chipset implementation of Pac-Man's PCB as well as peripherals like joystick and graphics display, as well as making sure data is where it needs to be on the clock

essentially, everything seems magical at the moment but once you crack open architecture book and Zilog documentation your mind will flood with ideas on how to describe them with software. if Z80 ISA is too daunting maybe write a MIPS/8088 interpreter first

>would it be beneficial to learn x86 assembly first before tackling z80 assembly?
god no, x86 was an abortion from the start and now it has 40 years of cruft and a microinstruction interpreter

>>3812448
>for every clock cycle given the input you determine the output
digital systems are nonlinear systems and nonlinear systems as a general rule do not work this way.

i will agree that once you understand the full details of a machine instruction as it snakes its way around the microarchitecture, a straightforward ("naïve") interpretation essentially writes itself.

>>3812828
like >>3813117 said fetch-decode-execute is a nice lie they tell to undergrads

>>3813565
Thank you for your well thought out and informative reply. I do appreciate it.

>>3813595
just trying to help

good luck senpai

>>3813117

is that really the case with the Z80? wikipedia says a pipelined version only came out in 2001

i was under the impression older processors didn't really employ any of the optimization tricks that are common today
tried to learn more modern assembly/architecture and it turned out to be too complicated for my skill level, so I came here because I heard implementing a gameboy or chip8 emulator is a good first project

Don't start with Pacman. Arcade hardware is balls to the wall crazy because they could just slap hardware together to solve the problem and pass the cost to the arcade operator.

Someone else in the thread said master system which is a pretty decent start since it's well documented, fairly simple and there's loads of simple games that you can test your emulator in stages on and get good results as you go.

CPU emulation of 8bit is easy because there are by definition < 255 unique instructions. So you can honestly read a byte array like: switch(z80_ram[z80_prgcounter]){
case 0:
//code for RST
break;
case 1:
//code for add to accumulator
z80_prgcounter++;
break;
etc.

The gameboy is pretty decent too since it's a very simple memory map with graphics hardware that does very well defined things. You can literally get away with simply reading the (emulated) graphics chip registers once a frame and drawing the graphics that you should as a high level simulator. Then you can add complexity to deal with the more complex games as you go and work towards true low level emulation if you wish.

Stay away from Atari machines. The CPU and graphics hardware had to communicate constantly at specific intervals to draw the screen. And later hardware used programmable display lists. Not terribly intuitive.

This is a good thread (:

>>3811453
>Is there a good book about computer architecture that could really help me out?
Yes, for what you're trying to do. Most of them are 30+ years old at this point, though.

>would it be beneficial to learn x86 assembly first before tackling z80 assembly?
No. I'd even go so far as to say it would be detrimental, for reasons outside the scope of this thread. My advice? Learn z80 assembly. Cause, you know, that seems to be the chip you want to work with.

http://sgate.emt.bme.hu/patai/publications/z80guide/

>>3813373

>kiddo

You're going to be dead in 30 years, more or less.

>>3813565
>>for every clock cycle given the input you determine the output
>digital systems are nonlinear systems and nonlinear systems as a general rule do not work this way.

That's absolutely sufficient to model how digital computers works. Given the state of the CPU and the input pins over a cycle, you can update the state of the CPU and the output pins over a cycle. Linearity has nothing to do with it. An operation T on a vectorspace satisfying the following equation for vectors x,y and scalars a,b is linear:

T(a*x + b*y) = a*T(x) + b*T(y)

Sure, very few useful digital systems are linear in the mappings between input and output pins at any given time, but that doesn't change the fact that they can be described as a finite state machine that moves between states synchronized with a discrete clock. What you seem to be trying to get at is the difference combinational and sequential logic, or in other words, stateless and stateful machines. Unless you are talking about analog computers, I am unaware of any digital system that doesn't follow this paradigm.

>>3813761
The z80 isn't a modern processor. It came out in the 70's and I specifically said 1980+. The 65xx is probably an easier place to start.