byuu's message board

Yes, it should be called that. Maybe back then they didn't actually realize that it was implemented with a processor. Maybe things are a little hazier if we're talking about a chip with its firmware burned on it and no way to actually read it back in software.



I talked to you about this before.. there's no polygon rendering processor on N64. The part that's HLEed is the processor that handles T&L and audio stuff. That processor (the RSP) takes a list of commands (called ucodes for some reason) and generates a list of different commands to the RDP (the thing that rasterizes polygons).

You can do high res rendering with LLE on N64, MooglyGuy showed a screenshot of this once. PS1, Saturn, and now this DS emulator does higher resolution rendering without HLE.



N64 uses a unified memory system. The RDP renders graphics to a block of memory reserved in RDRAM. As far as it's concerned this is just some normal piece of memory. A separate piece of hardware, called the VI (video interface) then reads from this memory and generates video signals based on it. So when you do high resolution output on the N64 you actually have to change not just the RDP works but also how the VI works, and you probably have to use some weird logic to try to determine when the RDP is rendering something that's not supposed to be shown directly on the screen. I'm sure that's broken something at some time or another.

This is how most SoCs these days work too. But DS doesn't work this way. It doesn't even have a complete framebuffer, just a a line buffer that stores up to 48 rendered scanlines, which passes through directly to 2D engine A. It does however have a capture unit which writes the 3D (or the entire 2D + 3D output) back to some place in one of the VRAM blocks which the game can see. This sucks because it takes away RAM you can use for texturing, but a lot of games use it because it's the only way to get 3D on both screens - you can only actually draw 3D to one screen at a time, but you can have the other screen put up a 2D image that's a capture of the last frame. It's also the only way to render graphics over two frames. And some games, like Splinter Cell, actually do use the CPU to post-process the capture data.

A straightforward "correct" high res implementation for DS would be to render high res to the screen and downscale it for the capture unit when it needs it. But then games that use the capture unit to display 3D on both screens will flicker between low res and high res. X432R bypasses the whole 2D/3D combination logic of the DS entirely and does its own thing. I have no idea how it actually works on dual 3D but it does somehow. My idea is a lot simpler, just make an option to skip frames where no 3D is active, if 3D has normally been active on that screen for a while. Then it'd still at least look okay most of the time, although you lose frames where 2D is changing faster than 3D. But most of the time that doesn't really happen.



Yes, I meant the best possible criteria for accuracy in the context of this thread - where you're deliberately throwing out actual pixel accuracy out of the window. There's still degrees of how well you do your hacks.



And then you're not emulating an N64 but an N64 + some kind of TV..



Sure, it's HLE if you get to define terms however you please. Probably a lot of things can be argued like that. I'd rather stick with a definition that follows how it's been used historically. And on that note I totally disagree with you that it's about internal behavior at all when it comes to hardware.

I think that as long as the output is 100% bit-perfect and identical, and the timing is identical, and there's absolutely no way for the hardware to detect something, then it doesn't really matter whether you are simulating transistors or not.

For instance:



When speaking of accuracy, it really doesn't matter that you didn't do it exactly the same way if you received exactly the same result. So to me, the balance is that HLE is closer to taking your favorite game, looking at how it works, and porting it to a new platform. It's an imposter. It's Godhead's version of Elanor Rigby. People will get the idea of what you're doing, they may even like it more than the original, but it's not the original. LLE is taking the original game instructions, and mimicking the hardware that ran them, to reproduce it faithfully. It's a FLAC rip of The Beatles' Elanor Rigby. Play it side-by-side to the original CD and nobody will be able to tell the difference. In practice, since we haven't achieved perfection, our emulators are varying quality levels of MP3 rips of the original song. I'm somewhere around 320kbps CBR. ZSNES is 20kbps RealAudio.

We look at transistor-level simulation as a holy grail precisely because of all the stuff we don't know about. And the LLE code can start to become an unreadable mess once you get low-level enough. I also don't think transistor-simulation is perfect, either. There are reading errors, and there are propagation delays and physics simulations that just don't happen even in the Pong simulator.

However, it can be said that a transistor simulation preserves more detail about the original hardware. If you had to classify it, I'd just add a third category, TLE (transistor-level emulation.) By the same measurement, I'd say that LLE as in bsnes also preserves the overarching ideas in a way that TLE will not. You can reason about and understand things in bsnes. Just a mess of raw transistors isn't something you can comprehend directly. The code would be about as clear as looking at electron microscope scans of chip dies.

Ideally, I'd like to see both. Keep the TLE model around in case any mistakes are discovered in the LLE, long after the hardware is gone for good. But LLE should be the ultimate goal.

> Maybe back then they didn't actually realize that it was implemented with a processor.

I believe the VSMC guy knew about it, at least. (Or maybe it was the RSRSNES guy? One of those people.) I believe they were simply unable to find anyone who could decap the chip and dump it. At some point, neviksti tried, but it proved too challenging to read directly. I don't really even recall how I got in touch with Dr. Decapitator initially (I'm sure Lord Nightmare was involved), but that really worked out well for us.

> Maybe things are a little hazier if we're talking about a chip with its firmware burned on it and no way to actually read it back in software.

Nah, not to me. I can understand and appreciate when there are insufficient funds and resources to get the data, that there's no choice but HLE. But if code is in there, then code is in there whether you can read it or not. Now if you don't *know* if it's in there, okay, yeah, that can get fuzzy. Schrodinger's DSP, leaving your emulator in a quantum superposition of HLE and LLE.

> I talked to you about this before

I have some sort of memory problem when it comes to retaining information very long-term. The mind naturally forgets things it doesn't use, but in my case the process seems to be accelerated to the point where people often have to repeat things to me that they still remember. It's not Alzheimer's bad, but it's not good, either.

Well, no. I'm not saying that HLE's definition is up in the air, and I'm not saying that it's about internal behavior of hardware. I'm saying that, when you have a piece of emulation, whether it's HLE or not depends at what level (heh) it implements the emulation.

If you have an n64 emulator, which performs emulation by implementing needed APIs on a case by case basis, then you're emulating the API rather than the hardware. So, when you say you're emulating the hardware, you're only emulating the hardware at a high level; but if you have a perfect emulation of the API, then you're emulating the API itself at a low level, though not its original internal mechanics.

If you have an SNES emulator that accurately emulates the behavior of pieces of hardware and how they interact, that's low level emulation of the SNES system as defined by chips that talk to eachother in a fairly abstract manner. But it's high level if you define the SNES as a bunch of transistors.

The definition of HLE isn't arbitrarily drawn at some specific point, like "It emulates the software interfaces instead of the hardware", because emulation as a concept applies to all sorts of systems that might not even have the a concept of a software interface, but there's always a higher or a lower way to emulate any sufficiently complex system.

This is of course completely off-topic, but recollection isn't some monolithic thing, and it works differently for different people. For instance I can generally barely remember what I had for dinner a few hours ago, and I definitely can't remember it for a week, but I can remember specific details about books I've read for many years. There's different confirmed variants of eidetic memory, as well. They don't just remember everything forever, but there's some types of information they're incredibly good at retaining (like passages from a book or digits of pi).

I remember reading an article about people who have an almost perfect memory of past events. An accompanying video had an interview with a woman who described it as constantly seeing two videos side by side - the present, and past events that she somehow associated with the present. For instance, she could tell you exactly what she had for dinner today five years ago. She found it very distracting and not very useful. On the other hand, her recollection of other things, like novels or things learned from books was just average.

Personally, I often wish my memory was better - I can remember barely anything from more than a few years ago. Even important events have faded to nothing more than a faded image and a verbal description - I wouldn't be able to tell the difference between remembering an event, and remembering being told about an event. The idea of losing all my memories through Alzheimer's or dementia is horrifying to me - at that point, what's left of the person you were?

> The definition of HLE isn't arbitrarily drawn at some specific point, like "It emulates the software interfaces instead of the hardware", because emulation as a concept applies to all sorts of systems that might not even have the a concept of a software interface, but there's always a higher or a lower way to emulate any sufficiently complex system.

Relativism can take all knowledge to the extreme of being useless. But to make progress, we have to agree on certain definitions and conclusions and move forward.

This is actually a really nuanced category. At the end of the day, all of these chips are silicon full of mostly transistors. Yet there's a very clear and strong divide in emulation between CPUs that execute instructions (wonderfully succinct and even then we can break those into opcode cycles) from ROM, and from things like the NES APU's psychotic mixing behavior and the NDS GPU's rendering pipeline. Those end up being increasingly large chunks of silicon that aren't being guided by ROM programs.

If you look at the SNES DSP, it looks as though a program of instructions was turned into the raw silicon that each instruction would have done. It's no doubt much cheaper this way when you are talking huge massive scale. The program is so small that even if it had a program ROM in there, the instruction core processor would likely be just as complex as the current emulator is anyway.

So taken to a relativist extreme where we lose the ability to classify emulators, who's to say that the emulation of a CPU is any different than the emulation of an APU or GPU?

I think I agree with you. I have the ideas there, but I don't know where I want to draw the line, because I don't have the knowledge necessary to make a realistic judgment on the subject for myself. But at the same time I don't just want to use a definition that's accepted for consistency.

But what are definitions if not words accepted for consistency? You can't try to argue everything based on nothing but what it says on the tin. It's like being that guy who says that Super Mario Bros is an RPG because you play the role of Mario. I guess you could argue that a ton of games are action, adventure, fighting, maybe even sports genre by that sort of reasoning too.

If I were arguing that an open source emulator is lower level than a closed source one because of the level to which code is visible I don't think you'd agree with it. And if I were arguing that an emulator written in assembly is lower level than one written in C++ I know you wouldn't agree.

The problem is that the term HLE came into being recently, and in a culture where meaning is heavily contentious and technical literacy varies wildly. RPG, at least, you can decide between one of a couple meanings and just tell the person that's what you mean; but when you use the term HLE, you're making a judgment about something that's gradient at some level.

For RPGs, there can be a very low level of ambiguity, but for HLE, the people you talk to might not have the same knowledge as you (as is extremely common in the emulation scene) and you need to describe what you mean from the ground up. I just want to have something that's good enough to a total outsider.

If I call a game an RPG, I can explain the history of RPGs and how they evolved into a few apparently independent genres, and say that it's all about etymology and that I'm referring to a specific instance of RPG history. I might even have to explain that a particular game has some elements that make it like an RPG, but that it's not a full blown RPG, but it's still fine to call it an RPG -- for someone with absolutely no literacy in video game genres. That's the worse case scenario, and I'm fine with it.

With HLE, I have to pick some point where it transitions from low to high level, and it seems really arbitrary unless you just decide what level you want to work at. For games consoles, you could probably get away with picking "HLE = game code APIs, LLE = chip communication APIs", but it breaks down if you want to talk about something where the game code doesn't use APIs -- high level emulation on an NES means something different from high level emulation for the PSX.

It's even worse if you keep diverging. Emulation applies to too wide a variety of hardware and software to easily come up with levels of emulation that are realistic, useful, and not just kind of picked out for each system or kind of system. It seems like a hard problem where I'm not content with just picking an answer for convenience's sake.

On the topic of the definitions of HLE vs LLE, I have very strong opinions about pixel aspect ratios, and everyone who disagrees with me is literally worse than Hitler. Also, NES palettes.

I agree wholeheartedly. Except for the part you're wrong about.

One only need to read my signature.

I have only one comment: The first time I heard of the term HLE was when UltraHLE was released. I don't consider that recent considering it was half my lifetime ago.

You do know that when I said you could quote me, I meant on the one topic, right? Not that I approved ALL your disagreements.

I feel like fifteen years ago is a lot more recent than forty.

So the term emulator was coined in 1963, which was fifty years ago. Is one-third of a lifetime recent?

In the context of linguistics, I would say so, but I'm not sure.