mirror of https://github.com/inolen/redream.git
remove old docs dir
This commit is contained in:
Anthony Pesch
parent
d0024b8c42
commit
2bd404641c
29
README.md
29
README.md
|
|
@ -10,14 +10,35 @@ redream is licensed under the GPLv3 license (see [LICENSE.txt](LICENSE.txt)) and
|
|||
|
||||
Ask questions and help answer them on [our Slack group](http://slack.redream.io).
|
||||
|
||||
## Building
|
||||
|
||||
To build the latest binaries, checkout out the [building](http://redream.io/docs/building) docs.
|
||||
|
||||
## Downloading
|
||||
|
||||
The latest pre-built binaries can be found on the [downloads](http://redream.io/download) page.
|
||||
|
||||
## Building
|
||||
|
||||
Start by cloning the repository and setting up a build directory.
|
||||
|
||||
```
|
||||
git clone https://github.com/inolen/redream.git
|
||||
mkdir redream_build
|
||||
cd redream_build
|
||||
```
|
||||
|
||||
Next, generate a makefile or project file for your IDE of choice. For more info on the supported IDEs, checkout the [CMake documentation](http://www.cmake.org/cmake/help/latest/manual/cmake-generators.7.html).
|
||||
|
||||
```
|
||||
# Makefile
|
||||
cmake -DCMAKE_BUILD_TYPE=RELEASE ../redream
|
||||
|
||||
# Xcode project
|
||||
cmake -G "Xcode" ../redream
|
||||
|
||||
# Visual Studio project
|
||||
cmake -G "Visual Studio 14 Win64" ../redream
|
||||
```
|
||||
|
||||
Finally, you can either run `make` from the command line if you've generated a Makefile or load up the project file and compile the code from inside of your IDE.
|
||||
|
||||
## Reporting bugs
|
||||
|
||||
Report bugs via the [GitHub issue queue](https://github.com/inolen/redream/issues).
|
||||
|
|
|
|||
|
|
@ -1,4 +0,0 @@
|
|||
_site/
|
||||
.*
|
||||
Gemfile
|
||||
Gemfile.lock
|
||||
|
|
@ -1 +0,0 @@
|
|||
redream.io
|
||||
|
|
@ -1,34 +0,0 @@
|
|||
title: redream.io
|
||||
baseurl: ""
|
||||
url:
|
||||
|
||||
disqus:
|
||||
shortname: redream
|
||||
|
||||
collections:
|
||||
docs:
|
||||
output: true
|
||||
|
||||
defaults:
|
||||
- scope:
|
||||
path: ""
|
||||
type: posts
|
||||
values:
|
||||
permalink: /:collection/:title
|
||||
layout: post
|
||||
- scope:
|
||||
path: ""
|
||||
type: docs
|
||||
values:
|
||||
permalink: /:collection/:title
|
||||
layout: doc
|
||||
|
||||
markdown: kramdown
|
||||
|
||||
kramdown:
|
||||
input: GFM
|
||||
syntax_highlighter: rouge
|
||||
|
||||
exclude:
|
||||
- Gemfile
|
||||
- Gemfile.lock
|
||||
|
|
@ -1,29 +0,0 @@
|
|||
---
|
||||
title: Building
|
||||
---
|
||||
|
||||
Start by cloning the repository and setting up a build directory.
|
||||
|
||||
```
|
||||
git clone https://github.com/inolen/redream.git
|
||||
mkdir redream_build
|
||||
cd redream_build
|
||||
```
|
||||
|
||||
Next, generate a makefile or project file for your IDE of choice. For more info on the supported IDEs, checkout the [CMake documentation](http://www.cmake.org/cmake/help/latest/manual/cmake-generators.7.html).
|
||||
|
||||
```
|
||||
# Makefile
|
||||
cmake -DCMAKE_BUILD_TYPE=RELEASE ../redream
|
||||
|
||||
# Xcode project
|
||||
cmake -G "Xcode" ../redream
|
||||
|
||||
# Visual Studio project
|
||||
cmake -G "Visual Studio 14 Win64" ../redream
|
||||
```
|
||||
|
||||
Finally, you can either run `make` from the command line if you've generated a Makefile or load up the project file and compile the code from inside of your IDE.
|
||||
|
||||
The build has been tested on OSX 10.10 with clang 3.6, Ubuntu 14.04 with GCC 4.9 and Windows 8.1 with Visual Studio 2015.
|
||||
|
||||
|
|
@ -1,5 +0,0 @@
|
|||
---
|
||||
title: Community
|
||||
---
|
||||
|
||||
Ask questions and help answer them on [Slack](http://slack.redream.io).
|
||||
|
|
@ -1,4 +0,0 @@
|
|||
---
|
||||
title: Contributing
|
||||
---
|
||||
|
||||
|
|
@ -1,40 +0,0 @@
|
|||
---
|
||||
title: Directory Structure
|
||||
---
|
||||
|
||||
## audio
|
||||
|
||||
Audio backend implementation. Responsible for reading fully mixed data from the Dreamcast and playing it.
|
||||
|
||||
## core
|
||||
|
||||
Asserts, logging and data structures.
|
||||
|
||||
## hw
|
||||
|
||||
Contains subfolders for each of the major hardware components of the Dreamcast:
|
||||
|
||||
* `aica` audio chip with its own dsp and cpu to synthesize and mix audio data
|
||||
* `arm7` audio cpu, part of the aica chip
|
||||
* `gdrom` optical disc drive
|
||||
* `holly` interface between the sh4 cpu and the pvr chip / maple bus
|
||||
* `maple` interface between holly and external peripherals
|
||||
* `pvr` graphics chip. processes and renders texture / polygon data
|
||||
* `rom` boot and flash rom chips
|
||||
* `sh4` main cpu
|
||||
|
||||
## jit
|
||||
|
||||
Contains the frontend, backend, ir and optimization passes used by the just-in-time compiler.
|
||||
|
||||
## sys
|
||||
|
||||
Cross-platform abstractions for signal handling, paths, virtual memory, threads and time.
|
||||
|
||||
## ui
|
||||
|
||||
Window creation and user interface code.
|
||||
|
||||
## video
|
||||
|
||||
Video backend implementation. Responsible for rendering parsed texture / polygon data from the Dreamcast.
|
||||
|
|
@ -1,3 +0,0 @@
|
|||
---
|
||||
title: JIT Design
|
||||
---
|
||||
|
|
@ -1,149 +0,0 @@
|
|||
---
|
||||
title: Memory Access
|
||||
---
|
||||
|
||||
Memory operations are the most frequently occuring type of instruction. From a quick sample of code running during Sonic Adventure gameplay, a whopping 37% of the instructions are memory operations. Due to their high frequency, this is the single most important operation to optimize.
|
||||
|
||||
# The beginning
|
||||
|
||||
In the beginning, all memory access went through a function call, e.g.:
|
||||
|
||||
```c
|
||||
uint32_t load_i32(uint32_t addr) {
|
||||
if (addr < 0x04000000) {
|
||||
return system_ram[addr];
|
||||
} else if (addr < 0x08000000) {
|
||||
return video_ram[addr - 0x04000000];
|
||||
} else {
|
||||
mmio_callback_t cb = mmio_callbacks[addr - 0x08000000];
|
||||
return cb();
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
This function would be called by the compiled x64 code like so:
|
||||
|
||||
```nasm
|
||||
mov edi, <guest_address>
|
||||
call load_i32
|
||||
mov <dst_reg>, eax
|
||||
```
|
||||
|
||||
This is simple and straight forward, but now a single guest instruction has transformed into ~10-20 host instructions: a function call, multiples moves to copy arguments / result, stack push / pop, multiple comparisons, multiple branches and a few arithmetic ops.
|
||||
|
||||
With some back-of-the envelope calculations it's evident that trying to run the 200mhz SH4 CPU on a 2ghz host is going to be difficult if 37% of the instructions are exploded by a factor of 10-20.
|
||||
|
||||
# The next generation
|
||||
|
||||
The next implementation is what most emulators refer to as "fastmem". The general idea is to map the entire 32-bit guest address space into an unused 4 GB area of the 64-bit host address spaace. By doing so, each guest memory access can be performed with some simple pointer arithmetic.
|
||||
|
||||
To illustrate with code:
|
||||
|
||||
```c
|
||||
/* memory_base is the base address in the virtual address space where there's
|
||||
a 4 GB block of unused pages to map the shared memory into */
|
||||
void init_memory(void *memory_base) {
|
||||
/* create the shared memory object representing the guest address space */
|
||||
int handle = shm_open("/redream_memory", O_RDWR | O_CREAT | O_EXCL, S_IREAD | S_IWRITE);
|
||||
|
||||
/* resize shared memory object to 4 GB */
|
||||
ftruncate(handle, 0x100000000);
|
||||
|
||||
/* map shared memory object into host address space */
|
||||
mmap(memory_base, 0xffffffff, PROT_READ | PROT_WRITE, MAP_SHARED | MAP_FIXED, handle, 0x0);
|
||||
}
|
||||
```
|
||||
|
||||
With the entire guest address space being mapped into the host address space relative to `memory_base`, each memory lookup now looks like:
|
||||
|
||||
```nasm
|
||||
mov rax, memory_base
|
||||
mov <dst_reg>, [rax + <guest_address>]
|
||||
```
|
||||
|
||||
In redream's JIT, an extra register is reserved to hold `memory_base`, so the initial mov is avoided:
|
||||
|
||||
```nasm
|
||||
mov <dst_reg>, [<mem_base_reg> + <guest_address>]
|
||||
```
|
||||
|
||||
# Handling MMIO accesses
|
||||
|
||||
The above example glosses over the part where this solution doesn't handle MMIO accesses, which still need to call a higher-level callback function on each access.
|
||||
|
||||
Initially, it may seem that the only option is to conditionally branch at each memory access:
|
||||
|
||||
```nasm
|
||||
cmp <guest_addr>, 0x08000000
|
||||
jge .slowmem
|
||||
# fast path when guest_addr < 0x08000000
|
||||
mov <dst_reg>, [<mem_base_reg> + <guest_address>]
|
||||
jmp .end
|
||||
# slow path when guest_addr >= 0x08000000
|
||||
.slowmem:
|
||||
mov rdi, <guest_address>
|
||||
call load_i32
|
||||
.end:
|
||||
```
|
||||
|
||||
This isn't _awful_ and is much improved over the original implementation. While there is still a compare and branch, the branch will at least be predicted correctly in most cases due to it now being inlined in the generated code. However, valuable instruction cache space is now being wasted by the same inlining.
|
||||
|
||||
Fortunately, we can have our cake and eat it too thanks to segfaults.
|
||||
|
||||
## Generating segfaults
|
||||
|
||||
The idea with segfaults is to disable access to the pages representing the MMIO region of the guest address space, and _always_ optimistically emit the fastmem code.
|
||||
|
||||
Extending on the above `init_memory` function, the code to disable access would look like:
|
||||
|
||||
```c
|
||||
/* disable access to the mmio region */
|
||||
mprotect(memory_base + 0x08000000, 0x04000000, PROT_NONE);
|
||||
```
|
||||
|
||||
Now, when a fastmem-optimized piece of code tries to perform an MMIO access, a segfault will be generated at which point we can either:
|
||||
|
||||
* "backpatch" the original code
|
||||
* recompile the code with fastmem optimizations disabled
|
||||
|
||||
### Backpatching
|
||||
|
||||
This is the easier to implement of the two options, and what redream did originally. The technique involves always writing out the fastmem code with enough padding such that, inside of the signal handler, it can be overwritten with the "slowmem" code.
|
||||
|
||||
All memory accesses would by default look like:
|
||||
|
||||
```nasm
|
||||
mov <dst_reg>, [<mem_base_reg> + <guest_addr_reg>]
|
||||
nop
|
||||
nop
|
||||
nop
|
||||
nop
|
||||
...
|
||||
```
|
||||
|
||||
Then, when the signal handler is entered, the current PC would be extracted from the thread context and the code would be overwritten with:
|
||||
|
||||
```c
|
||||
mov edi, <guest_addr_reg>
|
||||
call load_i32
|
||||
mov <dst_reg>, eax
|
||||
```
|
||||
|
||||
When the signal handler returns, the thread will resume at the same PC that originally generated the segfault, but it will now execute the backpatched slow path. This approach works well, but the `nop` padding can add up depending on the size of the slow path code, which can very negatively impact performance.
|
||||
|
||||
|
||||
### Recompiling
|
||||
|
||||
This is what redream currently does. The idea itself is simple: when the signal is raised, recompile the block to not use any fastmem optimizations and execute the recompiled block. However, while this sounds easy, the devil truly is in the details.
|
||||
|
||||
For starters, it's not possible to recompile the block inside of the signal handler itself due to the [limitations of what can be done inside of a signal handler](https://www.securecoding.cert.org/confluence/display/c/SIG30-C.+Call+only+asynchronous-safe+functions+within+signal+handlers).
|
||||
|
||||
Because of this, the actual recompilation is deferred to a later time, and the MMIO access is handled somewhat-inside of the signal handler itself. I say "somewhat-inside" because, for the same reason the block itself can't be recompiled inside of the signal handler, it's not safe to directly invoke the MMIO callbacks inside of the signal handler. Instead of directly invoking the callback, the signal handler adjusts the program counter to land in a thunk that will invoke the callback when the thread resumes.
|
||||
|
||||
This is what the control flow looks like when an MMIO segfault occurs:
|
||||
|
||||
|
||||
|
||||
From looking at this diagram it should be apparent that this method of servicing the MMIO request is _extremely_ slow. However, this penalty is only paid once, as the block will be recompiled with all fastmem optimizations disabled before the next run.
|
||||
|
||||
The trade off of all this effort is that, now the fastmem route needs no padding, providing non-MMIO guest memory access with the absolute minimum amount of overhead.
|
||||
|
|
@ -1,34 +0,0 @@
|
|||
---
|
||||
title: PowerVR Notes
|
||||
---
|
||||
|
||||
The Dreamcast's rendering is powered by a PowerVR chip with a hardware 3D engine called the Tile Accelerator.
|
||||
|
||||
Games directly submit primitive data, texture data and rendering parameters to this Tile Accelerator, it in turn [renders them](http://mc.pp.se/dc/pvr.html), writes the rasterized output to video ram and finally raises an external interrupt signalling when the rendering is complete. Many details are left out here because, for the most part, how the Tile Accelerator works internally is unimportant to our cause.
|
||||
|
||||
For our purpose, this input data needs to be translated into equivalent OpenGL commands and rendered, and the same interrupt must be generated when once this process is done - the internals of the tile-based rendering can be ignored.
|
||||
|
||||
# Receiving the data
|
||||
|
||||
Data is submitted to the TA through a DMA transfer to its internal FIFO buffer. On the hardware, this data is not immediately rendered, but instead generates a display list in memory which is rendered at later time through the [STARTRENDER](https://github.com/inolen/redream/blob/master/src/hw/pvr/ta.c#L995) register.
|
||||
|
||||
As mentioned above, it's safe to ignore generating the actual display list used internally by the TA, however the data still must be written out somewhere and rendered in a deferred fashion when `STARTRENDER` is written to. This data is received in [ta_poly_fifo_write](https://github.com/inolen/redream/blob/master/src/hw/pvr/ta.c#L787) and in turn written to an internal [tile_context](https://github.com/inolen/redream/blob/master/src/hw/pvr/ta_types.h#L440) structure.
|
||||
|
||||
This `tile_context` structure not only store the raw data stream, but all state necessary to render the data. When a display list is told to start rendering, various registers are read that can control the final output. By capturing this state as well, the data can be rendered completely offline in the [tracer tool](running).
|
||||
|
||||
# Converting the data
|
||||
|
||||
As mentioned above, all of the raw data relative to a given display list is written to our own `tile_context` structure. This structure is meant to only hold the raw data stream and register state needed to render the display list, it's not processed in any way.
|
||||
|
||||
Before this raw context can be rendered, it must be converted into a [tile_render_context](https://github.com/inolen/redream/blob/master/src/hw/pvr/tr.h#L62) structure by [tr_parse_context](https://github.com/inolen/redream/blob/master/src/hw/pvr/tr.c#L953). The purpose of this separation is so that raw `tile_context` structures can be dumped while running a game and viewed offline in the [tracer tool](running). This makes it fast-er to iterate on bugs where a context is being converted or rendered incorrectly in some way.
|
||||
|
||||
For the most part, converting the data is straight forward. There are numerous polygon and vertex types, each which have different attributes (blend mode, xyz, color, uv, etc.) specified in different formats (packed, unpacked, quantized, etc.). Each polygon is converted into a [surface instance](https://github.com/inolen/redream/blob/master/src/render/render_backend.h#L89) and each vertex is converted into a [vertex instance](https://github.com/inolen/redream/blob/master/src/render/render_backend.h#L81) which is used by the vertex buffers in the rendering backend. For more information on this, please see [tr_parse_poly_param](https://github.com/inolen/redream/blob/master/src/hw/pvr/tr.c#L517) and [tr_parse_vert_param](https://github.com/inolen/redream/blob/master/src/hw/pvr/tr.c#L651).
|
||||
|
||||
In addition to converting the actual data, some additional operations need to be performed like [sorting translucent polygons](https://github.com/inolen/redream/blob/master/src/hw/pvr/tr.c#L1013). This process currently isn't emulated perfectly, as the real hardware supported per-pixel sorting, where as they're currently only being sorted per-polygon.
|
||||
|
||||
# Rendering the data
|
||||
|
||||
The TA supported various per-pixel effects, all of which are implemented through a single [mega-shader](https://github.com/inolen/redream/blob/master/src/render/ta.glsl).
|
||||
|
||||
The real problem of note when rendering the data, is that the XYZ / UV coordinates are not in a state friendly to the OpenGL pipeline. The X and Y cooordinates are in screen space, with the Z component being 1/W. The UV coordinates however have not had perspective division applied yet.
|
||||
|
||||
|
|
@ -1,31 +0,0 @@
|
|||
---
|
||||
title: Running
|
||||
---
|
||||
|
||||
```
|
||||
redream <cdi, chd or gdi file>
|
||||
```
|
||||
|
||||
Command line options are loaded from and saved to `$HOME/.redream/config` each run.
|
||||
|
||||
### All options
|
||||
|
||||
```
|
||||
--debug Show debug menu [default: 1]
|
||||
--aspect Video aspect ratio [default: stretch, valid: stretch, 16:9, 4:3]
|
||||
--region System region [default: auto, valid: japan, usa, europe, auto]
|
||||
--language System language [default: english, valid: japanese, english, german, french, spanish, italian]
|
||||
--broadcast System broadcast mode [default: ntsc, valid: ntsc, pal, pal_m, pal_n]
|
||||
--audio Enable audio [default: 1]
|
||||
--latency Preferred audio latency in MS [default: 100]
|
||||
--fullscreen Start window fullscreen [default: 0]
|
||||
--perf Write perf-compatible maps for generated code [default: 0]
|
||||
```
|
||||
|
||||
### Boot ROM
|
||||
|
||||
The Dreamcast had a boot ROM which provided various system calls for games to use.
|
||||
|
||||
By default, redream will attempt to high-level emulate this boot ROM. However, this process is currently not perfect, resulting in some games failing to boot. If you have a real boot ROM you'd like to use instead, it can be placed in `$HOME/.redream/boot.bin` and will take priority over redream's HLE implementation.
|
||||
|
||||
Please note, the HLE implementation only works with `.gdi` discs at the moment.
|
||||
|
|
@ -1,7 +0,0 @@
|
|||
---
|
||||
title: Testing
|
||||
---
|
||||
|
||||
The `test` directory contains unit tests for some of redream's core data structures, as well as assembly-based tests for the SH4 instruction set.
|
||||
|
||||
These tests are compiled and built as the `retest` binary.
|
||||
|
|
@ -1,19 +0,0 @@
|
|||
{% if page.comments != false %}
|
||||
<div id="disqus_thread"></div>
|
||||
<script>
|
||||
var disqus_config = function () {
|
||||
this.page.url = '{{ page.url | absolute_url }}';
|
||||
this.page.identifier = '{{ page.url | absolute_url }}';
|
||||
};
|
||||
|
||||
(function() {
|
||||
var d = document, s = d.createElement('script');
|
||||
|
||||
s.src = 'https://{{ site.disqus.shortname }}.disqus.com/embed.js';
|
||||
|
||||
s.setAttribute('data-timestamp', +new Date());
|
||||
(d.head || d.body).appendChild(s);
|
||||
})();
|
||||
</script>
|
||||
<noscript>Please enable JavaScript to view the <a href="https://disqus.com/?ref_noscript" rel="nofollow">comments powered by Disqus.</a></noscript>
|
||||
{% endif %}
|
||||
|
|
@ -1,33 +0,0 @@
|
|||
<!DOCTYPE html>
|
||||
<html>
|
||||
<head>
|
||||
<title>{% if page.title %}{{ page.title | escape }}{% else %}{{ site.title | escape }}{% endif %}</title>
|
||||
<link rel="stylesheet" href="https://fonts.googleapis.com/css?family=Open+Sans|Roboto:400,900">
|
||||
<link rel="stylesheet" href="http://yandex.st/highlightjs/8.0/styles/github.min.css"></link>
|
||||
<link rel="stylesheet" href="{{ site.github.url }}/css/main.css"></link>
|
||||
<link rel="shortcut icon" href="/favicon.ico" type="image/x-icon">
|
||||
<link rel="icon" href="{{ site.github.url }}/favicon.ico" type="image/x-icon">
|
||||
</head>
|
||||
<body>
|
||||
<div id="header">
|
||||
<div class="container">
|
||||
<div id="banner">
|
||||
<a href="{{ site.github.url }}/"><img src="{{ site.github.url }}/img/logo.png" /></a>
|
||||
</div>
|
||||
<div id="navbar">
|
||||
<a href="{{ site.github.url }}/download">Download</a>
|
||||
<a href="{{ site.github.url }}/media">Media</a>
|
||||
<a href="{{ site.github.url }}/docs">Docs</a>
|
||||
<a href="{{ site.github.url }}/contact">Contact</a>
|
||||
<a class="slack" href="http://slack.redream.io"><img src="http://slack.redream.io/badge.svg"></a>
|
||||
</div>
|
||||
</div>
|
||||
</div>
|
||||
|
||||
<div id="content" class="container">
|
||||
<div>
|
||||
{{ content }}
|
||||
</div>
|
||||
</div>
|
||||
</body>
|
||||
</html>
|
||||
|
|
@ -1,37 +0,0 @@
|
|||
---
|
||||
layout: default
|
||||
---
|
||||
|
||||
<ul id="docs">
|
||||
<ul>
|
||||
<li><a {% if page.url == '/docs/' %} class="current"{% endif %} href="{{ site.github.url }}/docs">About</a></li>
|
||||
</ul>
|
||||
<hr>
|
||||
<ul>
|
||||
<li><a {% if page.url == '/docs/building' %} class="current"{% endif %} href="{{ site.github.url }}/docs/building">Building</a></li>
|
||||
<li><a {% if page.url == '/docs/running' %} class="current"{% endif %} href="{{ site.github.url }}/docs/running">Running</a></li>
|
||||
<li><a {% if page.url == '/docs/testing' %} class="current"{% endif %} href="{{ site.github.url }}/docs/testing">Testing</a></li>
|
||||
<li>
|
||||
</ul>
|
||||
<hr>
|
||||
<ul>
|
||||
<li><a {% if page.url == '/docs/directory-structure' %} class="current"{% endif %} href="{{ site.github.url }}/docs/directory-structure">Directory structure</a></li>
|
||||
<li><a {% if page.url == '/docs/memory-access' %} class="current"{% endif %} href="{{ site.github.url }}/docs/memory-access">Memory access</a></li>
|
||||
<li><a {% if page.url == '/docs/powervr-notes' %} class="current"{% endif %} href="{{ site.github.url }}/docs/powervr-notes">PowerVR notes</a></li>
|
||||
<li><a {% if page.url == '/docs/jit-design' %} class="current"{% endif %} href="{{ site.github.url }}/docs/cpu-design">JIT design</a></li>
|
||||
</ul>
|
||||
<hr>
|
||||
<ul>
|
||||
<li><a {% if page.url == '/docs/contributing' %} class="current"{% endif %} href="{{ site.github.url }}/docs/contributing">Contributing</a></li>
|
||||
</ul>
|
||||
</ul>
|
||||
|
||||
<article class="article doc">
|
||||
<header>
|
||||
<h1>{{ page.title | escape }}</h1>
|
||||
</header>
|
||||
|
||||
<div class="article-content">
|
||||
{{ content }}
|
||||
</div>
|
||||
</article>
|
||||
|
|
@ -1,18 +0,0 @@
|
|||
---
|
||||
layout: default
|
||||
---
|
||||
|
||||
<article class="article">
|
||||
<header>
|
||||
<h1>{{ page.title | escape }}</h1>
|
||||
<time datetime="{{ page.date | date_to_xmlschema }}">{{ page.date | date: "%B %-d, %Y" }}</time>
|
||||
</header>
|
||||
|
||||
<div class="article-content">
|
||||
{{ content }}
|
||||
</div>
|
||||
|
||||
{% if site.disqus.shortname %}
|
||||
{% include disqus-comments.html %}
|
||||
{% endif %}
|
||||
</article>
|
||||
|
|
@ -1,36 +0,0 @@
|
|||
---
|
||||
title: "Getting started contributing to an emulator"
|
||||
date: 2016-12-05
|
||||
---
|
||||
|
||||
I've been browsing [r/emulation](https://www.reddit.com/r/emulation) a lot lately, and a common question I see is ["I want to help a project, but I have no idea where to begin"](https://www.reddit.com/r/emulation/comments/5fafea/its_pretty_strange_how_dreamcast_emulation_on_pc/dalaywa/). With the holidays approaching, I wanted to provide an answer for any would-be emulator developer looking to hack on something during them.
|
||||
|
||||
It's important to start off by mentioning that it's not a requirement to possess excellent low-level programming skills or in-depth knowledge of the hardware being emulated in order to contribute to emulators. Emulator projects are like any other sufficiently complicated project, there is a ton of work to do for all skill levels.
|
||||
|
||||
With that said however, it can be overwhelming to look at an emulation project and find an appropriate place to start contributing. To help bridge that gap, I've been creating more-detailed-than-normal issues in [redream's issue queue](https://github.com/inolen/redream/issues) this past week. These issues are tagged by difficulty level (easy, medium and hard), and prefixed by the section of code they apply to.
|
||||
|
||||
## Documentation
|
||||
|
||||
* [docs: add initial compatibility chart (easy)](https://github.com/inolen/redream/issues/37)
|
||||
|
||||
## UI
|
||||
|
||||
* [ui: fullscreen elements don't scale properly as window size changes (easy)](https://github.com/inolen/redream/issues/34)
|
||||
|
||||
## Input
|
||||
|
||||
* [maple: uniquely name vmu save files (easy)](https://github.com/inolen/redream/issues/31)
|
||||
* [maple: multiple controller profiles (easy)](https://github.com/inolen/redream/issues/32)
|
||||
* [maple: add joystick connected / disconnected events (medium)](https://github.com/inolen/redream/issues/33)
|
||||
|
||||
## Graphics
|
||||
|
||||
* [pvr: add missing palette texture converters (easy)](https://github.com/inolen/redream/issues/30)
|
||||
* [pvr: support shading instructions (medium)](https://github.com/inolen/redream/issues/35)
|
||||
* [pvr: support alpha testing for punch-through polygons (medium)](https://github.com/inolen/redream/issues/36)
|
||||
|
||||
## JIT
|
||||
|
||||
* [jit: expession simplification pass (medium)](https://github.com/inolen/redream/issues/39)
|
||||
|
||||
If you would like to chat more about any of these issues you can find me on our [Slack group](http://slack.redream.io/) channel under `@inolen`.
|
||||
|
|
@ -1,114 +0,0 @@
|
|||
---
|
||||
title: "Progress Report July 2017"
|
||||
date: 2017-07-20
|
||||
---
|
||||
|
||||
After a slow period at the beginning of the year, the pace has started picking up the past few months on redream's development.
|
||||
|
||||
I wanted to take some time to bring everyone up to date on where the development is at, and where it's planning to go by the end of the year.
|
||||
|
||||
# Where Development Is At
|
||||
|
||||
My focus with respect to development mostly centralizes around stability and usability. There's been a lot of work on getting games running, making them performant and making sure they're easy to play.
|
||||
|
||||
Many grahpical bells and whistles from the PowerVR are still unsupported, and similarly, quite a few audio features are still missing from the AICA emulation code. However, in the past few months tens of new games are running, and the graphics and audio emulation is enough such that many of the games are fun to play through.
|
||||
|
||||
## Audio Improvements
|
||||
|
||||
Audio in redream has been lacking for a _long_ time. Up until 9 months ago, there was absolutely zero audio support.
|
||||
|
||||
In around November, there was a major push to write the initial interpreter for the Dreamcast's audio processor, wire it up and get 8-bit / 16-bit PCM audio working. Most background music used this format, which was a step forward. However, almost all of the sound effects used the ADPCM format, which meant most games were still not very immersive to play.
|
||||
|
||||
Finally, in March support for [decoding the ADPCM data was added](https://github.com/inolen/redream/commit/b95d67b39f6a19e6a57ba06d8290fe710cd87561) as well, [support for the master and per-channel volume registers was added](https://github.com/inolen/redream/commit/02470dc3d3dcacf240e2056f951a1e77f7747675).
|
||||
|
||||
While many major features of the AICA chip (e.g. the DSP) are still missing, many games are playable now that these featues have landed.
|
||||
|
||||
## High-level BIOS and Flash Rom Emulation
|
||||
|
||||
In order to simplify getting up and running with redream, extensive work was done in May to [high-level emulate the Flash rom operations](https://github.com/inolen/redream/commit/acd9e6c4a9cd6ca596a9d52dbbefb05c194e5776) as well as [the syscalls provided by the BIOS](https://github.com/inolen/redream/commit/fae06b247cfe1f59ac92c43a6477db305684e128).
|
||||
|
||||
By doing so, users are no longer required to source the BIOS and flash roms from a real system in order to run games.
|
||||
|
||||
In addition to the new HLE functionality, new options have been added to override the system's region, language and broadcast settings, eliminating the need to swap out roms if still using an original BIOS and flash rom.
|
||||
|
||||
|
||||
|
||||
## Depth Buffer Fixes
|
||||
|
||||
On the Dreamcast, vertices are submitted for rendering in screen space, with the z component being equal to `1/w`. These values are not normalized to any particular range, which is fine for the PowerVR's 32-bit floating-point depth buffer.
|
||||
|
||||
When rendering in OpenGL, these vertices must be converted back to normalized device coordinates. While unprojecting the x and y components is trivial, getting a z value that maintains the same depth ordering is not.
|
||||
|
||||
Originally, redream linearly scaled the z-component to the range of `[0.0, 1.0]` with the equation `z = (z-zmin)/(zmax-min)` and passed it off to the depth buffer. This worked ok for many games, but some games had an extremely large z range (e.g. zmin of `0.000001` and zmax of `100000.0`) which caused a serious precision loss when normalizing, especially after the value was quantized to a 24-bit integer to be written to OpenGL's depth buffer.
|
||||
|
||||
After [writing a small tool](https://github.com/inolen/redream/blob/master/tools/retrace/depth.c) to measure the accuracy of the results of different normalization methods, the previous linear scaling was replaced with the logarithmic equation `z = log2(1.0 + w) / 17.0`. Using this method, the accuracy of the depth ordering went from as low as 30% to 99% in every problematic scene I could get my hands on.
|
||||
|
||||
|
||||
*Dynamite Cop before and after*
|
||||
|
||||
## Widescreen patching
|
||||
|
||||
Piggy backing on the work being done by Esppiral on the [AssemblerGames forums](https://assemblergames.com/threads/dreamcast-widescreen-hacks.58620), support has been added to automatically apply these widescreen patches at runtime.
|
||||
|
||||
|
||||
|
||||
Only patches for Sonic Adventure and Dynamite Cop have been added for now - contributions would be welcome to finish bringing the known patches in.
|
||||
|
||||
<center>
|
||||
<iframe width="853" height="480" src="https://www.youtube.com/embed/NcSa2B3pCR8" frameborder="0" allowfullscreen></iframe>
|
||||
</center>
|
||||
|
||||
## Gamepad support
|
||||
|
||||
Support for SDL2's Gamepad API has landed, meaning most controllers are now plug and play, with no configuration required.
|
||||
|
||||
## Performance Improvements
|
||||
|
||||
In the past month, redream has gotten a 2-3x performance boost.
|
||||
|
||||
The primary contributors:
|
||||
|
||||
* [more aggressively batch polygons](https://github.com/inolen/redream/commit/7e16a14c85cc9ed503ce716eb397c0af49376291) before rendering
|
||||
* [idle loop detector](https://github.com/inolen/redream/commit/d73c4cd2ee5cc1c7f6ab99de31bf95142fa4a25a) which speeds up their execution to raise interrupts faster
|
||||
* [reworked video rendering](https://github.com/inolen/redream/commit/37bb1137b6a0a845165715d42c4a4358815c618f) to lessen the amount of thread synchronization required
|
||||
|
||||
## Notable new games
|
||||
|
||||
### Cannon Spike
|
||||
|
||||
Cannon Spike would hang during the bootup process, spinning inside the game code waiting for the GD-ROM to be in the paused state. The problem being that, there was no code that would ever put it into the pause state. By more accurately [emulating the drive state when processing SPI commands](https://github.com/inolen/redream/commit/044a9f6a67cf1b03202d8cc242140861ebf0bb46), Cannon Spike now runs great.
|
||||
|
||||
<center>
|
||||
<iframe width="853" height="480" src="https://www.youtube.com/embed/5zVdEiWsEWs" frameborder="0" allowfullscreen></iframe>
|
||||
</center>
|
||||
|
||||
### Conflict Zone
|
||||
|
||||
Conflict Zone would boot, but then curiously hang at the controller select screen complaining about an unsupported device, "Dreamcast Controller."
|
||||
|
||||
After double-checking dumps of an actual controller communicating over the Maple bus, it was discovered that strings in the messages [should not be null-terminated, but padded with spaces](https://github.com/inolen/redream/commit/9067186c9fa31c7de64bbf28254034883cfbc155).
|
||||
|
||||
### Ikaruga
|
||||
|
||||
Ikaruga relied on a limited subset of MMU functionality for performing store queue writes.
|
||||
|
||||
Thanks to [patches provided by skmp](https://github.com/inolen/redream/commit/3fade7f1fb0cdd5f599ca90773d4202ee6cd4202), support for this limited functionality has been added an Ikaruga now runs.
|
||||
|
||||
### Ready 2 Rumble Boxing
|
||||
|
||||
Ready 2 Rumble Boxing would end up in an infinite loop waiting for an interrupt during boot.
|
||||
|
||||
In order to take a closer look, the [gdb-based debugger was revived](https://github.com/inolen/redream/commit/fe43c2415af73145315b76ddf02060d301fd2acc), and the issue was narrowed down to the SH4's negc instruction [not correctly calculating the carry flag](https://github.com/inolen/redream/commit/fe43c2415af73145315b76ddf02060d301fd2acc).
|
||||
|
||||
### Sturmwind
|
||||
|
||||
After adding [support for loading CDI images](https://github.com/inolen/redream/commit/78cf487c1913a7fa5ac4e00a59c25e61817da9e7), implementing [support for the SH4 sleep instruction](https://github.com/inolen/redream/commit/dc698f8d67df9ed914ab8f0027cc30001bd2baa0) and [fixing a bug in the rte instruction](https://github.com/inolen/redream/commit/2994a4eb97933e89a50d069db149a6a4ba3686b7), this indie favorite finally booted.
|
||||
|
||||
# Where Development Is Going
|
||||
|
||||
During the next 2 months, the main priority is to improve the accuracy of the CPU emulation through more extensive unit testing, and automated video-based regression testing to catch newly introduced bugs fast.
|
||||
|
||||
Additionally, an Android / AArch64 port is actively being worked on - news should be available for that soon.
|
||||
|
||||
As always, if you have any questions or are interested in contributing, drop by the [Slack group](http://slack.redream.io/).
|
||||
|
||||
Binary file not shown.
|
Before Width: | Height: | Size: 109 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 439 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 43 KiB |
|
|
@ -1,8 +0,0 @@
|
|||
---
|
||||
title: Contact
|
||||
layout: default
|
||||
---
|
||||
|
||||
For general questions about the project, drop by the [Slack group](http://slack.redream.io).
|
||||
|
||||
For inquiries regarding dual-licensing opportunities, e-mail [anthony@recompiled.io](mailto:anthony@recompiled.io).
|
||||
|
|
@ -1,258 +0,0 @@
|
|||
---
|
||||
---
|
||||
|
||||
body {
|
||||
margin: 0;
|
||||
color: #464646;
|
||||
font-family: 'Open Sans', sans-serif;
|
||||
}
|
||||
|
||||
a {
|
||||
text-decoration: none;
|
||||
color: #3a76c3;
|
||||
}
|
||||
|
||||
a:hover {
|
||||
color: #202020;
|
||||
}
|
||||
|
||||
h1, h2, h3 {
|
||||
color: #202020;
|
||||
font-family: 'Roboto' sans-serif;
|
||||
line-height: 1em;
|
||||
}
|
||||
|
||||
h1 a, h2 a, h3 a {
|
||||
color: #202020;
|
||||
}
|
||||
|
||||
h1 {
|
||||
font-size: 1.5em;
|
||||
}
|
||||
|
||||
h2 {
|
||||
font-size: 1.27em;
|
||||
}
|
||||
|
||||
h3 {
|
||||
font-size: 1.17em;
|
||||
}
|
||||
|
||||
code {
|
||||
padding: 3px 4px;
|
||||
color: #d14;
|
||||
background-color: #f7f7f9;
|
||||
border: 1px solid #e1e1e8;
|
||||
}
|
||||
|
||||
pre code {
|
||||
padding: 0;
|
||||
color: inherit;
|
||||
background-color: transparent;
|
||||
border: 0;
|
||||
}
|
||||
|
||||
.container {
|
||||
width: 1100px;
|
||||
margin-left: auto;
|
||||
margin-right: auto;
|
||||
}
|
||||
|
||||
#header {
|
||||
background-color: #f8f8f8;
|
||||
border-bottom: solid 1px #ededed;
|
||||
margin-bottom: 30px;
|
||||
}
|
||||
|
||||
#header .container {
|
||||
display: table;
|
||||
}
|
||||
|
||||
#banner {
|
||||
float: left;
|
||||
padding: 10px 0 10px 10px;
|
||||
}
|
||||
|
||||
#navbar {
|
||||
float: right;
|
||||
color: #202020;
|
||||
font-family: 'Roboto', sans-serif;
|
||||
font-weight: bold;
|
||||
font-size: 1.4em;
|
||||
text-align: center;
|
||||
text-transform: uppercase;
|
||||
padding: 32px 10px 32px 0;
|
||||
}
|
||||
|
||||
#navbar a {
|
||||
margin: 0 10px;
|
||||
color: #202020;
|
||||
}
|
||||
|
||||
#navbar a:hover {
|
||||
color: #3a76c3;
|
||||
}
|
||||
|
||||
#navbar .slack {
|
||||
vertical-align: middle;
|
||||
}
|
||||
|
||||
#content {
|
||||
position: relative;
|
||||
}
|
||||
|
||||
/*
|
||||
* articles
|
||||
*/
|
||||
#articles {
|
||||
list-style: none;
|
||||
margin: 0;
|
||||
padding: 0;
|
||||
}
|
||||
|
||||
#articles li {
|
||||
margin: 0 0 1em;
|
||||
padding-bottom: 1em;
|
||||
border-bottom: solid 2px #e6e6e6;
|
||||
}
|
||||
|
||||
#articles li:last-child {
|
||||
border-bottom: 0;
|
||||
}
|
||||
|
||||
.article header h1,
|
||||
.article header h2 {
|
||||
margin-top: 0;
|
||||
margin-bottom: .4em;
|
||||
}
|
||||
|
||||
.article time {
|
||||
color: #b9b9b9;
|
||||
font-family: 'Roboto', sans-serif;
|
||||
}
|
||||
|
||||
.article pre {
|
||||
font-size: .8em;
|
||||
}
|
||||
|
||||
.article img {
|
||||
max-width: 100%;
|
||||
}
|
||||
|
||||
.article pre {
|
||||
background-color: #f8f8f8;
|
||||
border: 1px solid #ddd;
|
||||
font-size: 13px;
|
||||
line-height: 19px;
|
||||
overflow: auto;
|
||||
padding: 6px 10px;
|
||||
border-radius: 3px;
|
||||
}
|
||||
|
||||
/*
|
||||
* docs
|
||||
*/
|
||||
|
||||
#docs {
|
||||
position: absolute;
|
||||
top: 0;
|
||||
left: 0;
|
||||
margin: 0;
|
||||
padding: 6px 10px;
|
||||
width: 200px;
|
||||
overflow: hidden;
|
||||
list-style: none;
|
||||
background-color: #f8f8f8;
|
||||
border: 1px solid #ddd;
|
||||
border-radius: 3px;
|
||||
}
|
||||
|
||||
#docs hr {
|
||||
border: 1px solid #ddd;
|
||||
border-bottom: 0;
|
||||
}
|
||||
|
||||
#docs ul {
|
||||
list-style: none;
|
||||
margin: 0 0 0 20px;
|
||||
padding: 0;
|
||||
}
|
||||
|
||||
#docs .current {
|
||||
color: #202020;
|
||||
}
|
||||
|
||||
.doc {
|
||||
margin-left: 250px;
|
||||
}
|
||||
|
||||
/**
|
||||
* Syntax highlighting styles
|
||||
*/
|
||||
.highlight {
|
||||
background: #fff;
|
||||
|
||||
.highlighter-rouge & {
|
||||
background: #eef;
|
||||
}
|
||||
|
||||
.c { color: #998; font-style: italic } // Comment
|
||||
.err { color: #a61717; background-color: #e3d2d2 } // Error
|
||||
.k { font-weight: bold } // Keyword
|
||||
.o { font-weight: bold } // Operator
|
||||
.cm { color: #998; font-style: italic } // Comment.Multiline
|
||||
.cp { color: #999; font-weight: bold } // Comment.Preproc
|
||||
.c1 { color: #998; font-style: italic } // Comment.Single
|
||||
.cs { color: #999; font-weight: bold; font-style: italic } // Comment.Special
|
||||
.gd { color: #000; background-color: #fdd } // Generic.Deleted
|
||||
.gd .x { color: #000; background-color: #faa } // Generic.Deleted.Specific
|
||||
.ge { font-style: italic } // Generic.Emph
|
||||
.gr { color: #a00 } // Generic.Error
|
||||
.gh { color: #999 } // Generic.Heading
|
||||
.gi { color: #000; background-color: #dfd } // Generic.Inserted
|
||||
.gi .x { color: #000; background-color: #afa } // Generic.Inserted.Specific
|
||||
.go { color: #888 } // Generic.Output
|
||||
.gp { color: #555 } // Generic.Prompt
|
||||
.gs { font-weight: bold } // Generic.Strong
|
||||
.gu { color: #aaa } // Generic.Subheading
|
||||
.gt { color: #a00 } // Generic.Traceback
|
||||
.kc { font-weight: bold } // Keyword.Constant
|
||||
.kd { font-weight: bold } // Keyword.Declaration
|
||||
.kp { font-weight: bold } // Keyword.Pseudo
|
||||
.kr { font-weight: bold } // Keyword.Reserved
|
||||
.kt { color: #458; font-weight: bold } // Keyword.Type
|
||||
.m { color: #099 } // Literal.Number
|
||||
.s { color: #d14 } // Literal.String
|
||||
.na { color: #008080 } // Name.Attribute
|
||||
.nb { color: #0086B3 } // Name.Builtin
|
||||
.nc { color: #458; font-weight: bold } // Name.Class
|
||||
.no { color: #008080 } // Name.Constant
|
||||
.ni { color: #800080 } // Name.Entity
|
||||
.ne { color: #900; font-weight: bold } // Name.Exception
|
||||
.nf { color: #900; font-weight: bold } // Name.Function
|
||||
.nn { color: #555 } // Name.Namespace
|
||||
.nt { color: #000080 } // Name.Tag
|
||||
.nv { color: #008080 } // Name.Variable
|
||||
.ow { font-weight: bold } // Operator.Word
|
||||
.w { color: #bbb } // Text.Whitespace
|
||||
.mf { color: #099 } // Literal.Number.Float
|
||||
.mh { color: #099 } // Literal.Number.Hex
|
||||
.mi { color: #099 } // Literal.Number.Integer
|
||||
.mo { color: #099 } // Literal.Number.Oct
|
||||
.sb { color: #d14 } // Literal.String.Backtick
|
||||
.sc { color: #d14 } // Literal.String.Char
|
||||
.sd { color: #d14 } // Literal.String.Doc
|
||||
.s2 { color: #d14 } // Literal.String.Double
|
||||
.se { color: #d14 } // Literal.String.Escape
|
||||
.sh { color: #d14 } // Literal.String.Heredoc
|
||||
.si { color: #d14 } // Literal.String.Interpol
|
||||
.sx { color: #d14 } // Literal.String.Other
|
||||
.sr { color: #009926 } // Literal.String.Regex
|
||||
.s1 { color: #d14 } // Literal.String.Single
|
||||
.ss { color: #990073 } // Literal.String.Symbol
|
||||
.bp { color: #999 } // Name.Builtin.Pseudo
|
||||
.vc { color: #008080 } // Name.Variable.Class
|
||||
.vg { color: #008080 } // Name.Variable.Global
|
||||
.vi { color: #008080 } // Name.Variable.Instance
|
||||
.il { color: #099 } // Literal.Number.Integer.Long
|
||||
}
|
||||
|
|
@ -1,10 +0,0 @@
|
|||
---
|
||||
title: About
|
||||
layout: doc
|
||||
---
|
||||
|
||||
redream is a work-in-progress SEGA Dreamcast emulator written in C for Mac, Linux and Windows.
|
||||
|
||||
redream is licensed under the [GPLv3 license](https://github.com/inolen/redream/blob/master/LICENSE).
|
||||
|
||||
Ask questions and help answer them on [our Slack group](http://slack.redream.io).
|
||||
Binary file not shown.
|
Before Width: | Height: | Size: 88 KiB |
|
|
@ -1,28 +0,0 @@
|
|||
---
|
||||
title: Download
|
||||
layout: default
|
||||
---
|
||||
|
||||
## Source
|
||||
|
||||
The source code is hosted on [GitHub](https://github.com/inolen/redream).
|
||||
|
||||
View the [documentation](/docs/building) for instructions on building.
|
||||
|
||||
## Binaries
|
||||
|
||||
The latest binaries built by our continuous integration are available below.
|
||||
|
||||
View the [documentation](/docs/running) for instructions on running.
|
||||
|
||||
### Linux
|
||||
|
||||
[redream.x86_64-linux-HEAD.tar.gz](https://github.com/inolen/redream/releases/download/ci-latest/redream.x86_64-linux-HEAD.tar.gz)
|
||||
|
||||
### Mac
|
||||
|
||||
[redream.x86_64-darwin-HEAD.tar.gz](https://github.com/inolen/redream/releases/download/ci-latest/redream.x86_64-darwin-HEAD.tar.gz)
|
||||
|
||||
### Windows
|
||||
|
||||
[redream.x86_64-windows-HEAD.tar.gz](https://github.com/inolen/redream/releases/download/ci-latest/redream.x86_64-windows-HEAD.tar.gz)
|
||||
BIN
docs/favicon.ico
BIN
docs/favicon.ico
Binary file not shown.
|
Before Width: | Height: | Size: 1.1 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 10 KiB |
|
|
@ -1,20 +0,0 @@
|
|||
---
|
||||
layout: default
|
||||
---
|
||||
|
||||
<ul id="articles">
|
||||
{% for post in site.posts %}
|
||||
<li>
|
||||
<article class="article article-short">
|
||||
<header>
|
||||
<h2><a href="{{ post.url | prepend: site.github.url }}">{{ post.title }}</a></h2>
|
||||
<time datetime="{{ post.date | data_to_xmlschema }}">{{ post.date | date: "%B %-d, %Y" }}</time>
|
||||
</header>
|
||||
|
||||
{{ post.excerpt }}
|
||||
|
||||
<a href="{{ post.url }}">Continue reading</a>
|
||||
</article>
|
||||
</li>
|
||||
{% endfor %}
|
||||
</ul>
|
||||
|
|
@ -1,12 +0,0 @@
|
|||
---
|
||||
title: Media
|
||||
layout: default
|
||||
---
|
||||
|
||||
<center>
|
||||
<iframe width="853" height="480" src="https://www.youtube.com/embed/NcSa2B3pCR8" frameborder="0" allowfullscreen></iframe>
|
||||
</center>
|
||||
|
||||
<center>
|
||||
<iframe width="853" height="480" src="https://www.youtube.com/embed/5zVdEiWsEWs" frameborder="0" allowfullscreen></iframe>
|
||||
</center>
|
||||
Loading…
Reference in New Issue