Z80: the last secrets
This is a modal window.
Das Video konnte nicht geladen werden, da entweder ein Server- oder Netzwerkfehler auftrat oder das Format nicht unterstützt wird.
Formale Metadaten
| Titel |
| |
| Untertitel |
| |
| Serientitel | ||
| Anzahl der Teile | 287 | |
| Autor | ||
| Mitwirkende | ||
| Lizenz | CC-Namensnennung 2.0 Belgien: Sie dürfen das Werk bzw. den Inhalt zu jedem legalen Zweck nutzen, verändern und in unveränderter oder veränderter Form vervielfältigen, verbreiten und öffentlich zugänglich machen, sofern Sie den Namen des Autors/Rechteinhabers in der von ihm festgelegten Weise nennen. | |
| Identifikatoren | 10.5446/56855 (DOI) | |
| Herausgeber | ||
| Erscheinungsjahr | ||
| Sprache |
Inhaltliche Metadaten
| Fachgebiet | ||
| Genre | ||
| Abstract |
|
FOSDEM 20222 / 287
2
4
6
8
12
17
21
23
31
35
37
41
44
45
46
47
50
62
65
66
67
68
71
73
81
84
85
86
90
92
94
100
102
105
111
114
115
116
117
118
121
122
124
127
131
133
135
137
139
140
141
142
145
149
150
156
164
165
167
169
170
171
172
174
176
178
180
183
184
189
190
192
194
198
205
206
207
208
210
218
220
224
225
229
230
232
235
236
238
239
240
242
243
244
245
246
249
250
253
260
262
264
267
273
274
277
282
283
287
00:00
SpieltheorieHalbleiterspeicherKlon <Mathematik>BefehlsprozessorBildschirmmaskeBitFunktionalKomplex <Algebra>LastMaßerweiterungPhysikalisches SystemProjektive EbeneResultanteStichprobenumfangTermZahlenbereichSystemaufrufNichtlinearer OperatorAusnahmebehandlungPunktspektrumCoxeter-GruppeÄußere Algebra eines ModulsCISCSchnittmengeEmulatorInformationsspeicherungGerade ZahlAdressraumSpielkonsoleZoomKonditionszahlNeuroinformatikp-BlockFahne <Mathematik>DickeKontextbezogenes SystemMultiplikationsoperatorPufferüberlaufMobiles EndgerätProgrammHalbleiterspeicherAutomatische IndexierungBefehlsprozessorBitIntelLastMaßerweiterungResultanteTabelleNichtlinearer OperatorZeiger <Informatik>Äußere Algebra eines ModulsAdditionÜbertragEmulatorPCMCIAVorzeichen <Mathematik>Interrupt <Informatik>p-BlockAtomarität <Informatik>Fahne <Mathematik>SymboltabellePufferüberlaufDifferenz <Mathematik>OrtsoperatorComputeranimationDiagrammTechnische Zeichnung
07:18
AnfangswertproblemHardwareOrdnung <Mathematik>HalbleiterspeicherTypentheorieMakrobefehlKategorie <Mathematik>SoftwaretestProgrammiergerätAutomatische IndexierungBefehlsprozessorBitInhalt <Mathematik>RechenwerkResultanteQuick-SortFlächeninhaltAusnahmebehandlungInstantiierungSummierbarkeitSchnittmengeEmulatorHilfesystemUmwandlungsenthalpieAdressraumRechenbuchAutorisierungp-BlockFahne <Mathematik>Einfache GenauigkeitMultiplikationsoperatorGamecontrollerBenutzerfreundlichkeitHardwareAnalog-Digital-UmsetzerSoftwaretestProgrammiergerätAutomatische IndexierungBefehlsprozessorBitInhalt <Mathematik>ResultanteStatistische HypotheseSystemaufrufAdditionEmulatorAdressraumDiskrete-Elemente-MethodeART-NetzInterrupt <Informatik>p-BlockFahne <Mathematik>GamecontrollerZyklische RedundanzprüfungComputeranimation
14:20
AnfangswertproblemBildgebendes VerfahrenInformationMathematikOrdnung <Mathematik>SystemidentifikationSoftwaretestKlon <Mathematik>AggregatzustandBefehlsprozessorBitComputersimulationResultanteSpeicherabzugZahlenbereichZeitzoneTechnische InformatikVersionsverwaltungCASE <Informatik>PunktspektrumEmulatorReverse EngineeringF-VerteilungSoundverarbeitungElektronisches ForumFahne <Mathematik>MultiplikationsoperatorURLStandardabweichungTVD-VerfahrenRechter WinkelSuite <Programmpaket>KoroutineBildgebendes VerfahrenImplementierungMathematikKlon <Mathematik>BefehlsprozessorBitMagnetblasenspeicherPhysikalisches SystemResultanteSelf-consistent FieldWärmeübergangZeitzoneSystemaufrufVersionsverwaltungInternetworkingFontÜbertragEmulatorOffene MengeReverse EngineeringBlackboxDomain <Netzwerk>Fahne <Mathematik>StandardabweichungComputeranimation
21:23
Projektive EbeneMultiplikationsoperatorComputeranimationBesprechung/Interview
22:08
Ordnung <Mathematik>ProgrammierungDeterministischer ProzessWidgetBesprechung/Interview
22:47
Reverse EngineeringMultiplikationsoperator
23:29
SoftwareSpieltheorieSoftwaretestInverser LimesVersionsverwaltungMatchingEigentliche AbbildungEmulatorLimesmengeKontextbezogenes SystemPackprogrammSoftwareentwickler
26:02
SoftwaretestBesprechung/Interview
26:39
CodeTypentheorieMakrobefehlSoftwaretestAggregatzustandBitGarbentheorieBesprechung/Interview
27:24
SoftwaretestBitInhalt <Mathematik>Reelle ZahlSchnittmengeEmulatorFahne <Mathematik>Besprechung/Interview
28:05
HardwareSoftwareFächer <Mathematik>Besprechung/Interview
28:39
ComputerspielDatenverwaltungPunktEmulatorRechter WinkelBesprechung/Interview
29:37
ComputerarchitekturSoftwareSpieltheorieBefehlsprozessorBitKomplex <Algebra>Virtuelle MaschineCISCEmulatorSpielkonsoleMultiplikationsoperatorMobiles EndgerätBesprechung/Interview
31:08
Komplex <Algebra>Rechter WinkelBesprechung/Interview
31:40
Formale SpracheProjektive EbeneVisualisierungCoprozessorHilfesystemRechter WinkelBesprechung/Interview
32:31
DebuggingQuellcodeKonstruktor <Informatik>AutorisierungBesprechung/Interview
33:12
DatensatzImplementierungInformationBefehlsprozessorProjektive EbeneRechenschieberVerschlingungVersionsverwaltungMetropolitan area networkÄußere Algebra eines ModulsReverse EngineeringRechter Winkel
34:49
SoftwareEmulatorBesprechung/Interview
35:34
CodeHardwareInformationKlon <Mathematik>EmulatorElektronisches ForumRechter WinkelBesprechung/Interview
36:11
AnalysisMaschinenschreibenNatürliche ZahlHydrostatikBitBesprechung/Interview
36:51
SoftwaretestBefehlsprozessorComputersimulationMereologieProjektive EbeneGüte der AnpassungRechter WinkelBesprechung/Interview
37:45
Projektive EbeneBesprechung/Interview
38:23
SpieltheorieBitSchlussregelBenutzeroberflächeBesprechung/Interview
39:01
MikroprozessorSoftwareProgrammfehlerBesprechung/Interview
39:42
MAPVerknüpfungsgliedVisualisierungReverse EngineeringQuellcodeTouchscreen
40:33
BitResultanteNotepad-ComputerElektronisches ForumMultiplikationsoperatorBesprechung/Interview
41:52
ComputerspielReelle ZahlChatten <Kommunikation>Besprechung/Interview
42:28
Chatten <Kommunikation>ComputeranimationBesprechung/Interview
Transkript: Englisch(automatisch erzeugt)
00:17
Hi everyone, welcome to my Fosden 2022 talk, Z80, the last secrets.
00:26
So first, who am I? My name is Anis Astier, I've been a Linux engineer for many years now, and worked in embedded and consumer electronics. I like to take my mind off work by working on side projects that are not directly related.
00:44
For instance, I made a presentation two years ago in the GoDev room on an embedded system that I designed that was a toy for kids. I discovered Z80 while writing an emulator on another side project.
01:02
This is not the subject of this talk, but I wanted to share a few discoveries I made along the way. So the Z80 chip was first released in 1976 by Zilog. It's a CPU designed as an extension of Intel 8080, which was already a bit popular in the 70s.
01:29
So it's a CISC design, a complex instruction set, and maybe its name was a bit of a forecast, but it peaked in the 80s, I'd say. But Zilog still exists and sells this chip, the CPU.
01:48
There are a few, many Z80 machines, here are a few. I won't be presenting them all, it would need a talk by itself. But the most popular, I'd say, would be the ZX Spectrum.
02:04
It has a very large community. We have here as well the TRS-80, a sharp pocket computer. TI-80 series, TI-80 calculator, here we have a TI-81. It was not only in computers, but as well embedded systems like game consoles.
02:25
We have the Master System and the Game Gear, which is basically a Master System, but in portable form. Well, to simplify. Z80 had many clones. For some reason, many vendors decided to clone it as early as the late 70s, since it was a very good design.
02:49
The original, as I said, was from Zilog. There were clones from MOS-TECH, Sharp, NEC, Toshiba, Goldstar, which is now known as LG, ST Microelectronics, and even Soviet clones like the T34BM1.
03:07
This CPU is an 8-bit CPU, but it has register pairs and can do a few 16-bit operations. Its main register is A, the accumulator, and it has flags as well.
03:26
AF are the main registers that will interest us during this talk. It has other register pairs like BC, D, HL, which were also, I think, on the AT-AT,
03:41
as well as an alternate register set that can be used for context switch or function call or things like that. So it has double the register space, at least, of the AT-AT. Its instructions, as I said, it's a complex instruction set, so instructions will often do memory load and store as well as the operation.
04:09
It can do 16-bit operations, as I said, like additions, subtractions, or operate on 16-bit addresses. Its instructions are variable length from one to four bytes and can have, depending on the instruction, from one to three operands.
04:31
It also has very interesting memory block instructions that can be used to do memcpy or memcompare in a very little number of instructions.
04:43
For instance, it can do memcpy in one instruction, well, except for the setup, and the instruction can repeat itself without advancing BC if a few conditions are met. What else? We have flags here. We'll zoom into the flags. As I said, it's an 8-bit register in the AF register pair.
05:12
Let's go into what flags it has. It has a carry flag, which is very standard for additions, subtractions, parity on overflow.
05:24
It has an end flag, which is a bit weird, but it's a flag bit that was reserved for DAA, which is an instruction dedicated to binary coded decimal operations. I won't go into detail. The half carry flag is the same, it's dedicated to this kind of operations.
05:47
We have the zero flag, signed flag, and two other bits, five and three, which are documented as not used. This is an extract from the official Zilog CPU manual, so they are not used.
06:07
Except, we've known for a long time that even though they are not used, we can access the flag register. They have a value, which is not documented, at least not officially.
06:23
The most well-known way this flag register bits are modified is through the 5-tree copy. It's a copy from results. If we have an instruction that operates on the accumulator most of the time, bit 5 and 3 of the accumulator will be transferred to bit 5 and 3 of the flag register after the instruction.
06:51
Here's a sample from undocumented Z80 documented, which is a very useful document for emulator authors,
07:02
which documents behavior of the Z80, which you can't find in the CPU manual. We have this instruction called bit nhl, that does not modify bit 5 and 3, here called y and x. I think the term comes from MAME. I'm not sure exactly where it comes from, but let's say it comes from the MAME emulator.
07:27
For this instruction, bit nhl, undocumented Z80 documented, it says it comes from some sort of internal register. This register is related to 16-bit additions, and most instructions do not change this register.
07:44
This register was already documented as early as 1981. Here we have Programming Z80, the third edition, but I think it's also in the previous editions. It was documented as W and Z.
08:04
Here it says that we have two special registers available to the control unit within the Z80, but not to the programmer. It's already known that inside this CPU, there's a temporary area that is used to do a few calculations that is not exposed.
08:27
In the Nocache ZX emulator, which is a proprietary emulator from the Nocache family, it was very popular in the 90s, even the 2000s, by Martin Korth.
08:43
He is the author of Nocache ZX, Martin, he wrote this documentation, ZX docs, and he called this internal register memptr. He documented, he reverse-engineered and documented a few of the behavior of this internal register, but not all.
09:06
And that will be important later, I'll come back to it. In particular, the memory block instructions, which I've talked earlier about, they were not tested, not documented.
09:21
We'll go back to this internal register, and we have this, I want to present this Zexel. If you've written an emulator, you probably already know what this is. This is a Z80 instruction exerciser, written in 1994 by Frank Kringle. It's designed for the ZX spectrum, I think, and it works by generating a binary with a lot of instructions, mainly with macros.
09:58
After each set of instructions that is run, it feeds the CPU state, all the
10:04
registers are dumped, it feeds them into a CRC, and then it continues the test. And once it has finished a category of instructions, it will print the CRC, and in order to pass, you must have the same CRC as the Z80 hardware.
10:21
So it's very true for emulators, except there's a catch. First, let's sum up what we have here, the mystery. We have this internal register called WZ or memptr. It's an internal register, it's 16 bits.
10:41
It clicks through the bit and HL instruction. This instruction, I haven't talked about it yet, but it's basically a bit test instructions. It will load at address HL, HL is the register pair, it will load a single byte,
11:00
and it will test the nth bit of this byte, and puts the result in the flags. So through this instruction, we have two bits from memptr that are leaking. We know a bit instructions, which instruction affects this register, but not all. We don't know the exact behavior, we have a few missing things.
11:33
And this led to something a bit weird, which is that in 2006, at least up until 2006, no emulator passes Zexal, the instruction exerciser.
11:47
They are missing the bit and HL instructions, because a few uses of this memptr aren't known.
12:01
So in order to crack it on a Russian forum, zex.peke.ru, a few hackers, mainly Bubu and Vladimir Kladov, with the help from many other members in the forum, started reverse engineering it. And they summarized all what they knew, which I've pointed out earlier, and they had a breakthrough when reverse engineering it.
12:37
After a few hypothesis, first hypothesis, which is that index instruction, there are specific type of instruction, which is index registers.
12:48
The index instruction, which is index addressing, they always initialize memptr the same way. So this way, we have a way to always set it to a single value, let's say zero, for instance.
13:02
And this led to a discovery that another memory block instruction called CPI, it will increment this 16-bit register memptr, whereas that CPD will decrement it.
13:20
So that was a breakthrough. But why? Why is that a breakthrough? Because I'll tell you why. So we now have, we know how to modify this register, and we can use this to leak the content of this register.
13:41
The goal is to dump it. So, and we will use the fact that CPD decrements the register in order to dump the lowest 14 bits. I'll give you an example. Here we are, I have shown the 16-bit of memptr. Its initial value is three, because its lower bits are 11.
14:08
So it will be decremented with CPD. It will go to two, decremented once, twice, one, zero, the third time. And if we decrement it a fourth time, we can see that the two bits that are leaking, bit 5 and 3 of the upper byte, they go from 00 to 11.
14:33
And we can use this algorithm. I'll let you think about it. If we go exactly from 0 and 0 to 11, if we do exactly this transition,
14:43
then we know that the number of times we decremented it is actually the initial value of the lower 14 bits of memptr. Because we can't, well, with this method, we can't leak the upper two bits, but that's not important. We already have enough information to run all the instructions, and that's exactly what Bubu and Vladimir Kladov did.
15:10
They run every instruction on the Z80, and after each instruction, run a dump routine.
15:22
And this routine allows them to document the remaining behavior of memptr. I won't go into the detail of what instruction modifies it, but they produced this document called memptr-eng.txt. If you've written an emulator, a Z80 emulator in the past 15 years, or modified one, you probably already know about this.
15:45
But that's quite interesting to think about. So what use is this? Because let's go into this. One example use would be to do a CPU ID.
16:04
We know from the result of the previous experiments that clones do have memptr, and they did reverse engineer its behavior, even if it didn't produce a documentation.
16:22
Except we have a small variation on memptr behavior. For instance, the BM1, as the Soviet clones, their effect is documented. So this can be used, for instance, for doing a CPU identification, a CPU variant identification.
16:43
Another example use, with the ZX Vega. Totologie found that this device, which was a ZX Spectrum redesigned as a black box, and released in 2015, it in fact used the FUSE emulator version right before it implemented memptr.
17:08
So it probably had GPL violations here. So is this the end? Most simulator catch up, and they implement very accurately the Z80, even if it's a very arcane behavior, which shouldn't affect most known software?
17:25
Everything is reliable, everything is accurate, I guess it's success. Well, no. There was this other thing that was discovered in 2012 by Patrick Rach. Here is a screenshot from the World of Spectrum forum.
17:43
And he summarizes the situation quite well. After finally having nailed memptr a few years ago, just because of bit-N-HL, it now seems there is yet another internal register which actually affects, at least the outcome of SCF and CCF.
18:02
That's quite disheartening as it means that no Z80 emulation out there is actually accurate again. So what are SCF and CCF? The set carry flag and change carry flag. If you remember, I talked about 5-3 copy, which is the most well known way
18:21
the X or unknown 5-3 bits of the flag register will be modified. Well, in case of SCF and CCF, it's not systematic. It might be a NOR instead, depending on some internal state. This state, it's supposed to be a temporary zone where the flags are assembled, the S register.
18:47
And SCF and CCF will only copy the bit-5 entry from the result if flags have changed during the previous instruction.
19:02
Otherwise, it will OR with this internal register Q, which is the previous F value. So it means that in order to emulate Q, you only need to know if F changed at the previous instruction, and then you can do an OR with the current F instead of a copy.
19:26
And in order to test this behavior, Patrick wrote a test suite called Z80 Test. It's, in my opinion, the gold standard of Z80 instruction exercises.
19:41
It supports both testing of memptr and Q. It also found that Q is only on Xilog's version, not NeXT's chips. I said my talk wouldn't be about my emulator. It won't be.
20:02
But it's called Gears. It's written in Rust. It passes Z80 Test, ZXL, and the FUSE test suite from the FUSE emulator. It's available at this URL. So, are those really the last secrets of the Z80?
20:20
In my opinion, probably not. The behavior of all clones is not 100% known. I've talked, for instance, about the behavior of NeXT, which was found by Patrick, as well as the Soviet clones. But as I said earlier, there are many other clones.
20:42
And when implementing those clones, the hardware engineer probably also had a lot of knowledge that might have been lost to the past. And with this, this concludes my talk. Do not hesitate, if you have any questions, to go into chat right now,
21:04
and we'll answer all the questions. Here are the references and the citations for the images. Well, thank you very much. Have a nice FOSDEM and have a good day.
21:36
I was just asking you, because you're a FOSDEM, I want to say veteran, right?
21:40
You've been to FOSDEM a lot. I saw you had stuff to do with the Go Room for a couple of times. Is that correct? I did a talk for you to go to the Dev Room on an embedded project. I've been to FOSDEM since, I think, 2009. So, I'm a veteran, but not one of the oldest.
22:03
I know there are people in the audience that have been more than me. So, yeah. Yeah, all right. That's fair enough. All right. Are you ready for some questions? Yeah, let's go. All right, so the widget thing where the questions appear,
22:20
you can see it as well, I think. It doesn't show the questions in the order they were asked in, so I apologize in advance if we ask the questions out of order. But there's a question, nearly 50 years later, people are still finding secrets. How does this happen? By coincidence? Undetermined program behavior?
22:40
And there's also a follow-up question, but let's do this one first. Okay. That's actually a great question because I'm not sure people are still finding secrets, but people maybe are finding them again. As I said in my conclusion, some secrets were found.
23:04
The Z80 has been reverse-engineered before for the clones, and they were found and then forgotten again. So what happens is that the publicly available documentation on those secrets, that takes time to come out.
23:24
And sometimes it needs reverse-engineering it again. All right, all right. The follow-up question is interesting. When do you know when everything has been uncovered? You would think that because Z80 is not something that was invented yesterday,
23:41
it's been around for, I don't remember. You said in your talk, 50 years? 1976 is the first. Yeah. So yeah, when do we know that it's 100%? And yeah. Actually, that's a good question. And I'll go back into the context of emulator development.
24:03
Many emulators think that what's in this talk is relatively futile. Why? Let me go into the detail. Because memptr, as far as I know, no software, except maybe a few test suits, depends on it.
24:22
And they can't depend on it because it's not documented. So if the purpose of emulation is to run old software, then you don't need to have an exact match for the hardware, as long as old written software you know already runs.
24:42
So when does this game end? I would say the game ends when all written software before the emulator was written runs properly. Let's give this a limit. Now, if you want to talk about historical and archive
25:01
and the pursuit of knowledge, of course, it never ends. Yeah, okay, but... Okay. How do I say this in a good way? Because Z80 is different from, let's say, PlayStation or Nintendo, whatever, because there you have a limited set of games
25:23
and when they stopped developing the thing, hopefully people stopped developing for it. But with Z80, it's been everywhere and people have been developing... I mean, a friend of mine, he keeps telling me that he's a very big friend of Z80 and he grew up in the Eastern Bloc and he keeps telling me about the Soviet version of Z80.
25:43
I mean, there could be a ton of software out there that we know nothing about that does use it, right? It's true, it's true. So, yeah, it's... I don't know. But it's interesting, it's... Alright. That's also why all emulators written since 14 years now,
26:04
they support memptr because we had this documentation and... Yeah. Alright, alright, alright. And because I don't remember if you spoke about this in your talk because, like I mentioned before the talk,
26:20
you were one of the first speakers who uploaded your talk, so I watched it weeks ago and months ago for the other speakers. But no, because... So, the test set that nobody could pass, right? So, how did that actually come together? Frank, when he wrote his program,
26:46
he wrote tests for many types of instructions and the tests are actually generated with both macros and at runtime as well, because a lot of code is generated.
27:01
So, there's a section of the test that runs the bit and HR instruction, which I've talked about, which is a bit testing instruction. Before the instruction, it means that it will...
27:23
When all the same state is dumped into a CRC, the flag register might be different depending on the content of memptr. So, if you don't know how to emulate memptr properly, you don't know which instruction modified it, and then bit and HR arrive, you arrive to this instruction,
27:43
and you won't know the real value that's in flags. So, that's why noemulator supported it fully. Okay, this is the last thing I'm going to ask about this, because this is very interesting, but didn't people decide, hey guys, Frank is crazy, and his test set is just wrong, right?
28:03
Actually, they did for about 12 years. For about 12 years, no one cared. No one cared. They said, okay, yeah, it runs on hardware and doesn't run on my emulator, but all other software we know of works. So, yeah, that's okay. That's all right.
28:21
But as I said, then some people in the pursuit of knowledge, they wanted more, and they wanted... They were fan of the Speccy and the Z80, so they reverse-engineered, and yeah. Oh, sorry. Okay.
28:41
All right. Let's see. I actually don't remember that I asked anything except my own questions, and this is the reason you should be a devroom manager. You get... But not in real life. In real life, a devroom manager is just... It's boring compared to virtual. Anyways, a question that a lot of people liked.
29:03
So, why are you writing a Z80 emulator yourself, and what are the hardest parts? There's also a follow-up question. Ah, would you recommend that people write a Z80 emulator? And why and when should they do tackle...
29:21
What do you mean? At what point in their emulator code? Yeah, okay, yeah. So, should they start with a Z80, or should Z80... Should they start with... I don't know. A lot of people like to start with a chip 8, which I'm not 100% sure what it is, actually, but... Right? So...
29:40
Oh, it's like Bitcoin. Okay. Why myself? First of all, it was a learning project, so I wanted to learn... It's my first emulator. I wanted to learn how to write an emulator. I've written software for quite some time. I've worked with complex systems, virtualization, kernels, etc.
30:03
And I wanted to learn a bit about Rust, a bit about writing emulators. And I chose the Z80 mainly for nostalgia, because it had one of the machines I liked when I was a kid. It had a Z80 as the main CPU.
30:22
Someone joked that it was the first Steam Deck, which is a portable game console with game gear. So that's the main reason. Should you start with a Z80? That's actually a good question. I think if you want to write an emulator quickly,
30:41
you should probably choose an architecture that has less instructions. This one is a CISC architecture. It has many instructions. It might be simpler to target a smaller machine, but again, it depends on your own motivation and your personal motivation. So I think it's heavily personal.
31:03
You get to choose what you want to do with your hobbies. And very quickly, without going into it, Rust or Go? It's a trick question. Let's say I like both, and I won't go into more details on which one you should choose.
31:25
All right. Let's keep it politically neutral for now. You don't have to. A lot of people might hate you for it. If you like C++ or complex languages, maybe Rust is for you.
31:44
It has interesting things. Even if you don't like complex languages, many people come from the Ruby community, for example. And Go, I would say, if you like the simplicity of Python coupled with C,
32:00
you can choose it. But then it doesn't say much about the languages. Go with whichever is useful for you. All right. Let's see. I keep seeing questions. I'm not asking them. I apologize in advance for that. Okay.
32:20
Do projects like Visual Z80 help with researching the processor's internals? Are they enough to understand everything that's happening in the processor? I've never heard of Visual Z80 before this question. I don't know. I'm guessing it's something. It's a debugger or something. I don't know.
32:43
One important thing, which might not be a good idea, when I started to write this simulator, is that I didn't want to look at others' source code. I didn't want to get any inspiration from any other author. And it might not have been the best idea
33:01
because there were some constructs which I didn't know about, which would have made it faster. Okay. That's learning, I guess. When I first started writing emulators, this is exactly the same thing I did.
33:22
So instead of looking up information or whatever, I would just think that I was smart enough to figure it out myself. And I wasn't. And now I admit this to myself. And I'm a better man for it, I think, or whatever. Sorry.
33:41
Stop laughing. Anyways, let's see. Uninitiated question. Are there any Z80 decapping projects? And if so, how viable would it be to find out about these hidden instructions that way? It's actually a very good question.
34:01
I've thought about it before, and I'm not sure I have a definitive answer. What you need to know is that if you watch my talk in the title image, you can see there are decaps. I've posted links into the room, and it's also one of the first links of the decapping, if you go into the references of the slides for the people watching the recording.
34:23
There are high-res versions of the Z80 publicly available, of the CPU decapping. As far as I know, there are no reverse engineering projects that use this decapping. I know there are alternative FPGA implementations you can find,
34:43
but I don't know of any projects that use these decapping. All right. Let's see. Actually, never mind. Let's see. Another question. Are these secrets known to affect emulator's compatibility with software from that era?
35:05
Kind of what I asked. I've kind of answered this before. I'd say it doesn't affect compatibility, unless you're running Zexo, which now MEM supports, so you should be okay.
35:21
It doesn't affect compatibility as far as you know. There can be some software in the basement, in the KGB somewhere, that will not run with the emulator. As I said at the beginning of the talk, the Z80 is still produced. There are still people writing software for it. All right.
35:43
Let's see. Are there clone detector or emulator detector? I don't understand this one. A piece of code that indicates, based on the behavior, what hardware or code is likely running? I'm not sure I'm qualified to answer this question. I'm sure someone might have written one on a forum or something.
36:04
You have enough information in this talk to start doing your own. Yeah. And then a follow-up to this, it's not a follow-up question, it's a follow-up comment. I think the talk from Thomas about static analysis kind of touches on this subject.
36:22
So, you know, and even if it doesn't, you should be here just to listen to it, because, you know, more people, we get more money. Or not, we don't get money. Let's see. Yes, I'm a 6502 guy, me as well, but when I see all those Z80 registers, I marvel at the luxury.
36:40
And this wasn't really a question, I just liked the comment, so I just upvoted it and now it appears here. Are you familiar with 6502? Naturally. I've looked at it a bit during my research, but I'm not familiar with it. All right. Let's see.
37:00
Your emulator, Gears, passes all the tests. What is your next project? What talk can we expect from you next year? Good question, great question. I'm not sure there will be a talk next year, but you never know. My next project is to finish the simulator by going into ARRA, other than the CPU.
37:27
Maybe... I'll think of that. I may think to emulate if you want to emulate your full machine, and the CPU is just one part of it. Are you still here? Can you hear me?
37:43
Yeah, I can hear you. I'm just playing around with the camera, because you lose signal sometimes. I think your kids are downloading a PlayStation update, or Discord is updating or something. Yeah. This is a small follow-up question for me,
38:05
because Roland, in his talk, he started the project because he wanted to play a specific game, which, ironically enough, he can't play yet. Did this start with you, something like that, or were you just interested in the subject in general?
38:22
If I wanted to just play the games, there are many emulators available out there, and I could just play those games in there. So that's not... That's not the same as what Roland did there. It's a bit harder to just access the original material.
38:43
In my case, there are many emulators, so the main reason was to learn. The final rule is maybe to run a game at some point, yeah. All right, and somebody here is asking, can you play us something on that harp?
39:03
It's not my harp, it's my daughter's, and I don't know how to play the harp, even if sometimes I don't play the harp. Sorry. All right, all right, we'll believe you. It's a common excuse, right?
39:22
Let's see, there's a question. I presume that being a microprocessor that uses micro-programming to discover everything is like discovering all the bugs in a piece of software. Sorry. Yeah, yeah, yeah, it's exactly...
39:41
When you're doing reverse engineering, it's exactly that. You're trying to discover things which you don't have the source code of, and sometimes even if you have the source code, you still don't know everything. It's maybe not documented. This screen was something created by other persons,
40:03
and it's basically like reverse engineering and documenting what you find. And we had a remark from the answer about visual Z80. Apparently, it's Z80 that works directly on the gate level or something that's simulated.
40:20
I don't know exactly how it's done, so maybe go check it out, and I will go check it out, yeah. All right, all right. Let's see. I will ask my lovely assistants. Did I miss any questions? I don't think so.
40:41
We got them all so far. Okay, okay, okay. I want to add maybe one remark to the talk, which I didn't talk about. The Q register is the most recent discovery by Patrick. It's not implemented yet in MAME,
41:02
and I haven't had time to work with real hardware, even if I have some, but it seems that even it's not available in all Zilog variants, all Z80 variants from Zilog. So even this secret is still a bit challenged, I say,
41:21
exactly where is the Q register found, and yeah. This is just a result of my findings in a few forums. All right, cool. All right, I do not see any more questions.
41:43
Personally, I would really like to thank you for doing this. Thank you for being here. I hope you were happy doing the talk. Thanks for having me. Sorry for my weird questions, but I'm nervous and I can't resist and that kind of stuff.
42:03
All right, thank you very much, and yeah, hopefully we'll see you next year in real life. Who knows? Maybe, sorry? If anyone has any more questions, I'll be in the chat for a while, so join the chat.
42:23
If you're watching the recording, I'm sorry. If you're watching the recording, you can still come to the chat, but he won't be there, right? Because we just discovered the chats from last year are still open and we are still in those chats. So you can still come to the chat and you can maybe tag Anis and who knows?
42:44
He might answer or not, right? So thank you very much and have a pleasant Foster. Thank you. Cheers.