Update to v099r13 release.
byuu says:
Changelog:
- GB core code cleanup completed
- GBA core code cleanup completed
- some more cleanup on missed processor/arm functions/variables
- fixed FC loading icarus bug
- "Load ROM File" icarus functionality restored
- minor code unification efforts all around (not perfect yet)
- MMIO->IO
- mmio.cpp->io.cpp
- read,write->readIO,writeIO
It's been a very long work in progress ... starting all the way back with
v094r09, but the major part of the higan code cleanup is now completed! Of
course, it's very important to note that this is only for the basic style:
- under_score functions and variables are now camelCase
- return-type function-name() are now auto function-name() -> return-type
- Natural<T>/Integer<T> replace (u)intT_n types where possible
- signed/unsigned are now int/uint
- most of the x==true,x==false tests changed to x,!x
A lot of spot improvements to consistency, simplicity and quality have
gone in along the way, of course. But we'll probably never fully finishing
beautifying every last line of code in the entire codebase. Still,
this is a really great start. Going forward, WIP diffs should start
being smaller and of higher quality once again.
I know the joke is, "until my coding style changes again", but ... this
was way too stressful, way too time consuming, and way too risky. I'm
too old and tired now for extreme upheavel like this again. The only
major change I'm slowly mulling over would be renaming the using
Natural<T>/Integer<T> = (u)intT; shorthand to something that isn't as
easily confused with the (u)int_t types ... but we'll see. I'll definitely
continue to change small things all the time, but for the larger picture,
I need to just accept the style I have and live with it.
2016-06-29 11:10:28 +00:00
|
|
|
auto PPU::readIO(uint32 addr) -> uint8 {
|
2012-04-01 01:41:15 +00:00
|
|
|
switch(addr) {
|
2012-03-31 08:14:31 +00:00
|
|
|
|
2012-03-31 08:17:36 +00:00
|
|
|
//DISPCNT
|
2016-02-25 10:38:03 +00:00
|
|
|
case 0x0400'0000: return (
|
Update to v102r19 release.
byuu says:
Note: add `#undef OUT` to the top of higan/gba/ppu/ppu.hpp to compile on
Windows (ugh ...) Now to await posts about this in four more threads
again ;)
Changelog:
- GBA: rewrote PPU from a scanline-based renderer to a pixel-based
renderer
- ruby: fixed video/gdi bugs
Note that there's an approximately 21% speed penalty compared to v102r18
for the pixel-based renderer.
Also, horizontal mosaic effects are not yet implemented. But they should
be prior to v103. This one is a little tricky as it currently works on
fully rendered scanlines. I need to roll the mosaic into the background
renderers, and then for sprites, well ... see below.
The trickiest part by far of this new renderer is the object (sprite)
system. Unlike every other system I emulate, the GBA supports affine
rendering of its sprites. Or in other words, rotation effects. And it
also has a very complex priority system.
Right now, I can't see any way that the GBA PPU could render pixels in
real-time like this. My belief is that there's a 240-entry buffer that
fills up the next scanline's row of pixels. Which means it probably also
runs on the last scanline of Vblank so that the first scanline has
sprite data.
However, I didn't design my object renderer like this just yet. For now,
it creates a buffer of all 240 pixels right away at the start of the
scanline. I know\!\! That's technically scanline-based. But it's only
for fetching object tiledata, and it's only temporary.
What needs to happen is I need a way to run something like a "mini libco
thread" inside of the main thread, so that the object renderer can run
in parallel with the rest of the PPU, yet not be a hideous abomination
of a state machine, yet also not be horrendously slow as a full libco
thread would be.
I'm envisioning some kind of stackless yielding coroutine. But I'll need
to think through how to design that, given the absence of coroutines
even in C++17.
2017-06-04 03:16:44 +00:00
|
|
|
Background::IO::mode << 0
|
|
|
|
|
| io.gameBoyColorMode << 3
|
|
|
|
|
| Background::IO::frame << 4
|
|
|
|
|
| objects.io.hblank << 5
|
|
|
|
|
| objects.io.mapping << 6
|
|
|
|
|
| io.forceBlank << 7
|
2016-02-25 10:38:03 +00:00
|
|
|
);
|
|
|
|
|
case 0x0400'0001: return (
|
Update to v102r19 release.
byuu says:
Note: add `#undef OUT` to the top of higan/gba/ppu/ppu.hpp to compile on
Windows (ugh ...) Now to await posts about this in four more threads
again ;)
Changelog:
- GBA: rewrote PPU from a scanline-based renderer to a pixel-based
renderer
- ruby: fixed video/gdi bugs
Note that there's an approximately 21% speed penalty compared to v102r18
for the pixel-based renderer.
Also, horizontal mosaic effects are not yet implemented. But they should
be prior to v103. This one is a little tricky as it currently works on
fully rendered scanlines. I need to roll the mosaic into the background
renderers, and then for sprites, well ... see below.
The trickiest part by far of this new renderer is the object (sprite)
system. Unlike every other system I emulate, the GBA supports affine
rendering of its sprites. Or in other words, rotation effects. And it
also has a very complex priority system.
Right now, I can't see any way that the GBA PPU could render pixels in
real-time like this. My belief is that there's a 240-entry buffer that
fills up the next scanline's row of pixels. Which means it probably also
runs on the last scanline of Vblank so that the first scanline has
sprite data.
However, I didn't design my object renderer like this just yet. For now,
it creates a buffer of all 240 pixels right away at the start of the
scanline. I know\!\! That's technically scanline-based. But it's only
for fetching object tiledata, and it's only temporary.
What needs to happen is I need a way to run something like a "mini libco
thread" inside of the main thread, so that the object renderer can run
in parallel with the rest of the PPU, yet not be a hideous abomination
of a state machine, yet also not be horrendously slow as a full libco
thread would be.
I'm envisioning some kind of stackless yielding coroutine. But I'll need
to think through how to design that, given the absence of coroutines
even in C++17.
2017-06-04 03:16:44 +00:00
|
|
|
bg0.io.enable << 0
|
|
|
|
|
| bg1.io.enable << 1
|
|
|
|
|
| bg2.io.enable << 2
|
|
|
|
|
| bg3.io.enable << 3
|
|
|
|
|
| objects.io.enable << 4
|
|
|
|
|
| window0.io.enable << 5
|
|
|
|
|
| window1.io.enable << 6
|
|
|
|
|
| window2.io.enable << 7
|
2016-02-25 10:38:03 +00:00
|
|
|
);
|
2012-03-31 08:17:36 +00:00
|
|
|
|
|
|
|
|
//GRSWP
|
Update to v102r19 release.
byuu says:
Note: add `#undef OUT` to the top of higan/gba/ppu/ppu.hpp to compile on
Windows (ugh ...) Now to await posts about this in four more threads
again ;)
Changelog:
- GBA: rewrote PPU from a scanline-based renderer to a pixel-based
renderer
- ruby: fixed video/gdi bugs
Note that there's an approximately 21% speed penalty compared to v102r18
for the pixel-based renderer.
Also, horizontal mosaic effects are not yet implemented. But they should
be prior to v103. This one is a little tricky as it currently works on
fully rendered scanlines. I need to roll the mosaic into the background
renderers, and then for sprites, well ... see below.
The trickiest part by far of this new renderer is the object (sprite)
system. Unlike every other system I emulate, the GBA supports affine
rendering of its sprites. Or in other words, rotation effects. And it
also has a very complex priority system.
Right now, I can't see any way that the GBA PPU could render pixels in
real-time like this. My belief is that there's a 240-entry buffer that
fills up the next scanline's row of pixels. Which means it probably also
runs on the last scanline of Vblank so that the first scanline has
sprite data.
However, I didn't design my object renderer like this just yet. For now,
it creates a buffer of all 240 pixels right away at the start of the
scanline. I know\!\! That's technically scanline-based. But it's only
for fetching object tiledata, and it's only temporary.
What needs to happen is I need a way to run something like a "mini libco
thread" inside of the main thread, so that the object renderer can run
in parallel with the rest of the PPU, yet not be a hideous abomination
of a state machine, yet also not be horrendously slow as a full libco
thread would be.
I'm envisioning some kind of stackless yielding coroutine. But I'll need
to think through how to design that, given the absence of coroutines
even in C++17.
2017-06-04 03:16:44 +00:00
|
|
|
case 0x0400'0002: return io.greenSwap;
|
2016-02-25 10:38:03 +00:00
|
|
|
case 0x0400'0003: return 0;
|
2012-03-31 08:17:36 +00:00
|
|
|
|
|
|
|
|
//DISPSTAT
|
2016-02-25 10:38:03 +00:00
|
|
|
case 0x0400'0004: return (
|
Update to v102r19 release.
byuu says:
Note: add `#undef OUT` to the top of higan/gba/ppu/ppu.hpp to compile on
Windows (ugh ...) Now to await posts about this in four more threads
again ;)
Changelog:
- GBA: rewrote PPU from a scanline-based renderer to a pixel-based
renderer
- ruby: fixed video/gdi bugs
Note that there's an approximately 21% speed penalty compared to v102r18
for the pixel-based renderer.
Also, horizontal mosaic effects are not yet implemented. But they should
be prior to v103. This one is a little tricky as it currently works on
fully rendered scanlines. I need to roll the mosaic into the background
renderers, and then for sprites, well ... see below.
The trickiest part by far of this new renderer is the object (sprite)
system. Unlike every other system I emulate, the GBA supports affine
rendering of its sprites. Or in other words, rotation effects. And it
also has a very complex priority system.
Right now, I can't see any way that the GBA PPU could render pixels in
real-time like this. My belief is that there's a 240-entry buffer that
fills up the next scanline's row of pixels. Which means it probably also
runs on the last scanline of Vblank so that the first scanline has
sprite data.
However, I didn't design my object renderer like this just yet. For now,
it creates a buffer of all 240 pixels right away at the start of the
scanline. I know\!\! That's technically scanline-based. But it's only
for fetching object tiledata, and it's only temporary.
What needs to happen is I need a way to run something like a "mini libco
thread" inside of the main thread, so that the object renderer can run
in parallel with the rest of the PPU, yet not be a hideous abomination
of a state machine, yet also not be horrendously slow as a full libco
thread would be.
I'm envisioning some kind of stackless yielding coroutine. But I'll need
to think through how to design that, given the absence of coroutines
even in C++17.
2017-06-04 03:16:44 +00:00
|
|
|
io.vblank << 0
|
|
|
|
|
| io.hblank << 1
|
|
|
|
|
| io.vcoincidence << 2
|
|
|
|
|
| io.irqvblank << 3
|
|
|
|
|
| io.irqhblank << 4
|
|
|
|
|
| io.irqvcoincidence << 5
|
2016-02-25 10:38:03 +00:00
|
|
|
);
|
|
|
|
|
case 0x0400'0005: return (
|
Update to v102r19 release.
byuu says:
Note: add `#undef OUT` to the top of higan/gba/ppu/ppu.hpp to compile on
Windows (ugh ...) Now to await posts about this in four more threads
again ;)
Changelog:
- GBA: rewrote PPU from a scanline-based renderer to a pixel-based
renderer
- ruby: fixed video/gdi bugs
Note that there's an approximately 21% speed penalty compared to v102r18
for the pixel-based renderer.
Also, horizontal mosaic effects are not yet implemented. But they should
be prior to v103. This one is a little tricky as it currently works on
fully rendered scanlines. I need to roll the mosaic into the background
renderers, and then for sprites, well ... see below.
The trickiest part by far of this new renderer is the object (sprite)
system. Unlike every other system I emulate, the GBA supports affine
rendering of its sprites. Or in other words, rotation effects. And it
also has a very complex priority system.
Right now, I can't see any way that the GBA PPU could render pixels in
real-time like this. My belief is that there's a 240-entry buffer that
fills up the next scanline's row of pixels. Which means it probably also
runs on the last scanline of Vblank so that the first scanline has
sprite data.
However, I didn't design my object renderer like this just yet. For now,
it creates a buffer of all 240 pixels right away at the start of the
scanline. I know\!\! That's technically scanline-based. But it's only
for fetching object tiledata, and it's only temporary.
What needs to happen is I need a way to run something like a "mini libco
thread" inside of the main thread, so that the object renderer can run
in parallel with the rest of the PPU, yet not be a hideous abomination
of a state machine, yet also not be horrendously slow as a full libco
thread would be.
I'm envisioning some kind of stackless yielding coroutine. But I'll need
to think through how to design that, given the absence of coroutines
even in C++17.
2017-06-04 03:16:44 +00:00
|
|
|
io.vcompare
|
2016-02-25 10:38:03 +00:00
|
|
|
);
|
2012-03-31 08:17:36 +00:00
|
|
|
|
2012-03-31 08:14:31 +00:00
|
|
|
//VCOUNT
|
Update to v102r19 release.
byuu says:
Note: add `#undef OUT` to the top of higan/gba/ppu/ppu.hpp to compile on
Windows (ugh ...) Now to await posts about this in four more threads
again ;)
Changelog:
- GBA: rewrote PPU from a scanline-based renderer to a pixel-based
renderer
- ruby: fixed video/gdi bugs
Note that there's an approximately 21% speed penalty compared to v102r18
for the pixel-based renderer.
Also, horizontal mosaic effects are not yet implemented. But they should
be prior to v103. This one is a little tricky as it currently works on
fully rendered scanlines. I need to roll the mosaic into the background
renderers, and then for sprites, well ... see below.
The trickiest part by far of this new renderer is the object (sprite)
system. Unlike every other system I emulate, the GBA supports affine
rendering of its sprites. Or in other words, rotation effects. And it
also has a very complex priority system.
Right now, I can't see any way that the GBA PPU could render pixels in
real-time like this. My belief is that there's a 240-entry buffer that
fills up the next scanline's row of pixels. Which means it probably also
runs on the last scanline of Vblank so that the first scanline has
sprite data.
However, I didn't design my object renderer like this just yet. For now,
it creates a buffer of all 240 pixels right away at the start of the
scanline. I know\!\! That's technically scanline-based. But it's only
for fetching object tiledata, and it's only temporary.
What needs to happen is I need a way to run something like a "mini libco
thread" inside of the main thread, so that the object renderer can run
in parallel with the rest of the PPU, yet not be a hideous abomination
of a state machine, yet also not be horrendously slow as a full libco
thread would be.
I'm envisioning some kind of stackless yielding coroutine. But I'll need
to think through how to design that, given the absence of coroutines
even in C++17.
2017-06-04 03:16:44 +00:00
|
|
|
case 0x0400'0006: return io.vcounter.byte(0);
|
|
|
|
|
case 0x0400'0007: return io.vcounter.byte(1);
|
2016-02-25 10:38:03 +00:00
|
|
|
|
Update to v102r19 release.
byuu says:
Note: add `#undef OUT` to the top of higan/gba/ppu/ppu.hpp to compile on
Windows (ugh ...) Now to await posts about this in four more threads
again ;)
Changelog:
- GBA: rewrote PPU from a scanline-based renderer to a pixel-based
renderer
- ruby: fixed video/gdi bugs
Note that there's an approximately 21% speed penalty compared to v102r18
for the pixel-based renderer.
Also, horizontal mosaic effects are not yet implemented. But they should
be prior to v103. This one is a little tricky as it currently works on
fully rendered scanlines. I need to roll the mosaic into the background
renderers, and then for sprites, well ... see below.
The trickiest part by far of this new renderer is the object (sprite)
system. Unlike every other system I emulate, the GBA supports affine
rendering of its sprites. Or in other words, rotation effects. And it
also has a very complex priority system.
Right now, I can't see any way that the GBA PPU could render pixels in
real-time like this. My belief is that there's a 240-entry buffer that
fills up the next scanline's row of pixels. Which means it probably also
runs on the last scanline of Vblank so that the first scanline has
sprite data.
However, I didn't design my object renderer like this just yet. For now,
it creates a buffer of all 240 pixels right away at the start of the
scanline. I know\!\! That's technically scanline-based. But it's only
for fetching object tiledata, and it's only temporary.
What needs to happen is I need a way to run something like a "mini libco
thread" inside of the main thread, so that the object renderer can run
in parallel with the rest of the PPU, yet not be a hideous abomination
of a state machine, yet also not be horrendously slow as a full libco
thread would be.
I'm envisioning some kind of stackless yielding coroutine. But I'll need
to think through how to design that, given the absence of coroutines
even in C++17.
2017-06-04 03:16:44 +00:00
|
|
|
//BG0CNT
|
|
|
|
|
case 0x0400'0008: return bg0.io.priority << 0 | bg0.io.characterBase << 2 | bg0.io.unused << 4 | bg0.io.mosaic << 6 | bg0.io.colorMode << 7;
|
|
|
|
|
case 0x0400'0009: return bg0.io.screenBase << 0 | bg0.io.affineWrap << 5 | bg0.io.screenSize << 6;
|
|
|
|
|
|
|
|
|
|
//BG1CNT
|
|
|
|
|
case 0x0400'000a: return bg1.io.priority << 0 | bg1.io.characterBase << 2 | bg1.io.unused << 4 | bg1.io.mosaic << 6 | bg1.io.colorMode << 7;
|
|
|
|
|
case 0x0400'000b: return bg1.io.screenBase << 0 | bg1.io.affineWrap << 5 | bg1.io.screenSize << 6;
|
|
|
|
|
|
|
|
|
|
//BG2CNT
|
|
|
|
|
case 0x0400'000c: return bg2.io.priority << 0 | bg2.io.characterBase << 2 | bg2.io.unused << 4 | bg2.io.mosaic << 6 | bg2.io.colorMode << 7;
|
|
|
|
|
case 0x0400'000d: return bg2.io.screenBase << 0 | bg2.io.affineWrap << 5 | bg2.io.screenSize << 6;
|
|
|
|
|
|
|
|
|
|
//BG3CNT
|
|
|
|
|
case 0x0400'000e: return bg3.io.priority << 0 | bg3.io.characterBase << 2 | bg3.io.unused << 4 | bg3.io.mosaic << 6 | bg3.io.colorMode << 7;
|
|
|
|
|
case 0x0400'000f: return bg3.io.screenBase << 0 | bg3.io.affineWrap << 5 | bg3.io.screenSize << 6;
|
|
|
|
|
|
|
|
|
|
//WININ0
|
|
|
|
|
case 0x0400'0048: return window0.io.active[BG0] << 0 | window0.io.active[BG1] << 1 | window0.io.active[BG2] << 2 | window0.io.active[BG3] << 3 | window0.io.active[OBJ] << 4 | window0.io.active[SFX] << 5;
|
|
|
|
|
|
|
|
|
|
//WININ1
|
|
|
|
|
case 0x0400'0049: return window1.io.active[BG0] << 0 | window1.io.active[BG1] << 1 | window1.io.active[BG2] << 2 | window1.io.active[BG3] << 3 | window1.io.active[OBJ] << 4 | window1.io.active[SFX] << 5;
|
|
|
|
|
|
|
|
|
|
//WINOUT
|
|
|
|
|
case 0x0400'004a: return window3.io.active[BG0] << 0 | window3.io.active[BG1] << 1 | window3.io.active[BG2] << 2 | window3.io.active[BG3] << 3 | window3.io.active[OBJ] << 4 | window3.io.active[SFX] << 5;
|
|
|
|
|
|
|
|
|
|
//WININ2
|
Update to v102r21 release.
byuu says:
Changelog:
- GBA: fixed WININ2 reads, BG3PB writes [Jonas Quinn]
- R65816: added support for yielding/resuming from WAI/STP¹
- SFC: removed status.dmaCounter functionality (also fixes possible
TAS desync issue)
- tomoko: added support for combinatorial inputs [hex\_usr\]²
- nall: fixed missing return value from Arithmetic::operator--
[Hendricks266]
Now would be the time to start looking for major regressions with the
new GBA PPU renderer, I suppose ...
¹: this doesn't matter for the master thread (SNES CPU), but is
important for slave threads (SNES SA1). If you try to save a state and
the SA1 is inside of a WAI instruction, it will get stuck there forever.
This was causing attempts to create a save state in Super Bomberman
- Panic Bomber W to deadlock the emulator and crash it. This is now
finally fixed.
Note that I still need to implement similar functionality into the Mega
Drive 68K and Z80 cores. They still have the possibility of deadlocking.
The SNES implementation was more a dry-run test for this new
functionality. This possible crashing bug in the Mega Drive core is the
major blocking bug for a new official release.
²: many, many thanks to hex\_usr for coming up with a really nice
design. I mostly implemented it the exact same way, but with a few tiny
differences that don't really matter (display " and ", " or " instead of
" & ", " | " in the input settings windows; append → bind;
assignmentName changed to displayName.)
The actual functionality is identical to the old higan v094 and earlier
builds. Emulated digital inputs let you combine multiple possible keys
to trigger the buttons. This is OR logic, so you can map to eg
keyboard.up OR gamepad.up for instance. Emulated analog inputs always
sum together. Emulated rumble outputs will cause all mapped devices to
rumble, which is probably not at all useful but whatever. Hotkeys use
AND logic, so you have to press every key mapped to trigger them. Useful
for eg Ctrl+F to trigger fullscreen.
Obviously, there are cases where OR logic would be nice for hotkeys,
too. Eg if you want both F11 and your gamepad's guide button to trigger
the fullscreen toggle. Unfortunately, this isn't supported, and likely
won't ever be in tomoko. Something I might consider is a throw switch in
the configuration file to swap between AND or OR logic for hotkeys, but
I'm not going to allow construction of mappings like "(Keyboard.Ctrl and
Keyboard.F) or Gamepad.Guide", as that's just too complicated to code,
and too complicated to make a nice GUI to set up the mappings for.
2017-06-06 13:44:40 +00:00
|
|
|
case 0x0400'004b: return window2.io.active[BG0] << 0 | window2.io.active[BG1] << 1 | window2.io.active[BG2] << 2 | window2.io.active[BG3] << 3 | window2.io.active[OBJ] << 4 | window2.io.active[SFX] << 5;
|
Update to v102r19 release.
byuu says:
Note: add `#undef OUT` to the top of higan/gba/ppu/ppu.hpp to compile on
Windows (ugh ...) Now to await posts about this in four more threads
again ;)
Changelog:
- GBA: rewrote PPU from a scanline-based renderer to a pixel-based
renderer
- ruby: fixed video/gdi bugs
Note that there's an approximately 21% speed penalty compared to v102r18
for the pixel-based renderer.
Also, horizontal mosaic effects are not yet implemented. But they should
be prior to v103. This one is a little tricky as it currently works on
fully rendered scanlines. I need to roll the mosaic into the background
renderers, and then for sprites, well ... see below.
The trickiest part by far of this new renderer is the object (sprite)
system. Unlike every other system I emulate, the GBA supports affine
rendering of its sprites. Or in other words, rotation effects. And it
also has a very complex priority system.
Right now, I can't see any way that the GBA PPU could render pixels in
real-time like this. My belief is that there's a 240-entry buffer that
fills up the next scanline's row of pixels. Which means it probably also
runs on the last scanline of Vblank so that the first scanline has
sprite data.
However, I didn't design my object renderer like this just yet. For now,
it creates a buffer of all 240 pixels right away at the start of the
scanline. I know\!\! That's technically scanline-based. But it's only
for fetching object tiledata, and it's only temporary.
What needs to happen is I need a way to run something like a "mini libco
thread" inside of the main thread, so that the object renderer can run
in parallel with the rest of the PPU, yet not be a hideous abomination
of a state machine, yet also not be horrendously slow as a full libco
thread would be.
I'm envisioning some kind of stackless yielding coroutine. But I'll need
to think through how to design that, given the absence of coroutines
even in C++17.
2017-06-04 03:16:44 +00:00
|
|
|
|
|
|
|
|
//MOSAIC (write-only)
|
2012-03-31 08:17:36 +00:00
|
|
|
|
|
|
|
|
//BLTCNT
|
2016-02-25 10:38:03 +00:00
|
|
|
case 0x0400'0050: return (
|
Update to v102r19 release.
byuu says:
Note: add `#undef OUT` to the top of higan/gba/ppu/ppu.hpp to compile on
Windows (ugh ...) Now to await posts about this in four more threads
again ;)
Changelog:
- GBA: rewrote PPU from a scanline-based renderer to a pixel-based
renderer
- ruby: fixed video/gdi bugs
Note that there's an approximately 21% speed penalty compared to v102r18
for the pixel-based renderer.
Also, horizontal mosaic effects are not yet implemented. But they should
be prior to v103. This one is a little tricky as it currently works on
fully rendered scanlines. I need to roll the mosaic into the background
renderers, and then for sprites, well ... see below.
The trickiest part by far of this new renderer is the object (sprite)
system. Unlike every other system I emulate, the GBA supports affine
rendering of its sprites. Or in other words, rotation effects. And it
also has a very complex priority system.
Right now, I can't see any way that the GBA PPU could render pixels in
real-time like this. My belief is that there's a 240-entry buffer that
fills up the next scanline's row of pixels. Which means it probably also
runs on the last scanline of Vblank so that the first scanline has
sprite data.
However, I didn't design my object renderer like this just yet. For now,
it creates a buffer of all 240 pixels right away at the start of the
scanline. I know\!\! That's technically scanline-based. But it's only
for fetching object tiledata, and it's only temporary.
What needs to happen is I need a way to run something like a "mini libco
thread" inside of the main thread, so that the object renderer can run
in parallel with the rest of the PPU, yet not be a hideous abomination
of a state machine, yet also not be horrendously slow as a full libco
thread would be.
I'm envisioning some kind of stackless yielding coroutine. But I'll need
to think through how to design that, given the absence of coroutines
even in C++17.
2017-06-04 03:16:44 +00:00
|
|
|
screen.io.blendAbove[BG0] << 0
|
|
|
|
|
| screen.io.blendAbove[BG1] << 1
|
|
|
|
|
| screen.io.blendAbove[BG2] << 2
|
|
|
|
|
| screen.io.blendAbove[BG3] << 3
|
|
|
|
|
| screen.io.blendAbove[OBJ] << 4
|
|
|
|
|
| screen.io.blendAbove[SFX] << 5
|
|
|
|
|
| screen.io.blendMode << 6
|
2016-02-25 10:38:03 +00:00
|
|
|
);
|
|
|
|
|
case 0x0400'0051: return (
|
Update to v102r19 release.
byuu says:
Note: add `#undef OUT` to the top of higan/gba/ppu/ppu.hpp to compile on
Windows (ugh ...) Now to await posts about this in four more threads
again ;)
Changelog:
- GBA: rewrote PPU from a scanline-based renderer to a pixel-based
renderer
- ruby: fixed video/gdi bugs
Note that there's an approximately 21% speed penalty compared to v102r18
for the pixel-based renderer.
Also, horizontal mosaic effects are not yet implemented. But they should
be prior to v103. This one is a little tricky as it currently works on
fully rendered scanlines. I need to roll the mosaic into the background
renderers, and then for sprites, well ... see below.
The trickiest part by far of this new renderer is the object (sprite)
system. Unlike every other system I emulate, the GBA supports affine
rendering of its sprites. Or in other words, rotation effects. And it
also has a very complex priority system.
Right now, I can't see any way that the GBA PPU could render pixels in
real-time like this. My belief is that there's a 240-entry buffer that
fills up the next scanline's row of pixels. Which means it probably also
runs on the last scanline of Vblank so that the first scanline has
sprite data.
However, I didn't design my object renderer like this just yet. For now,
it creates a buffer of all 240 pixels right away at the start of the
scanline. I know\!\! That's technically scanline-based. But it's only
for fetching object tiledata, and it's only temporary.
What needs to happen is I need a way to run something like a "mini libco
thread" inside of the main thread, so that the object renderer can run
in parallel with the rest of the PPU, yet not be a hideous abomination
of a state machine, yet also not be horrendously slow as a full libco
thread would be.
I'm envisioning some kind of stackless yielding coroutine. But I'll need
to think through how to design that, given the absence of coroutines
even in C++17.
2017-06-04 03:16:44 +00:00
|
|
|
screen.io.blendBelow[BG0] << 0
|
|
|
|
|
| screen.io.blendBelow[BG1] << 1
|
|
|
|
|
| screen.io.blendBelow[BG2] << 2
|
|
|
|
|
| screen.io.blendBelow[BG3] << 3
|
|
|
|
|
| screen.io.blendBelow[OBJ] << 4
|
|
|
|
|
| screen.io.blendBelow[SFX] << 5
|
2016-02-25 10:38:03 +00:00
|
|
|
);
|
2012-03-31 08:14:31 +00:00
|
|
|
|
Update to v095r05 release.
byuu says:
Changelog:
- GBA: lots of emulation improvements
- PPU PRAM is 16-bits wide
- DMA masks &~1/Half, &~3/Word
- VRAM OBJ 8-bit writes are ignored
- OAM 8-bit writes are ignored
- BGnCNT unused bits are writable*
- BG(0,1)CNT can't set the d13
- BLDALPHA is readable (fixes Donkey Kong Country, etc)
- SNES: lots of code cleanups
- sfc/chip => sfc/coprocessor
- UI: save most recent controller selection
GBA test scores: 1552/1552, 37/38, 1020/1260
(* forgot to add the value to the read function, so endrift's I/O tests
for them will fail. Fixed locally.)
Note: SNES is the only system with multiple controller/expansion port
options, and as such is the only one with a "None" option. Because it's
shared by the controller and expansion port, it ends up sorted first in
the list. This means that on your first run, you'll need to go to Super
Famicom->Controller Port 1 and select "Gamepad", otherwise input won't
work.
Also note that changing the expansion port device requires loading a new
cart. Unlike controllers, you aren't meant to hotplug expansion port
devices.
2015-11-12 10:15:03 +00:00
|
|
|
//BLDALPHA
|
Update to v102r19 release.
byuu says:
Note: add `#undef OUT` to the top of higan/gba/ppu/ppu.hpp to compile on
Windows (ugh ...) Now to await posts about this in four more threads
again ;)
Changelog:
- GBA: rewrote PPU from a scanline-based renderer to a pixel-based
renderer
- ruby: fixed video/gdi bugs
Note that there's an approximately 21% speed penalty compared to v102r18
for the pixel-based renderer.
Also, horizontal mosaic effects are not yet implemented. But they should
be prior to v103. This one is a little tricky as it currently works on
fully rendered scanlines. I need to roll the mosaic into the background
renderers, and then for sprites, well ... see below.
The trickiest part by far of this new renderer is the object (sprite)
system. Unlike every other system I emulate, the GBA supports affine
rendering of its sprites. Or in other words, rotation effects. And it
also has a very complex priority system.
Right now, I can't see any way that the GBA PPU could render pixels in
real-time like this. My belief is that there's a 240-entry buffer that
fills up the next scanline's row of pixels. Which means it probably also
runs on the last scanline of Vblank so that the first scanline has
sprite data.
However, I didn't design my object renderer like this just yet. For now,
it creates a buffer of all 240 pixels right away at the start of the
scanline. I know\!\! That's technically scanline-based. But it's only
for fetching object tiledata, and it's only temporary.
What needs to happen is I need a way to run something like a "mini libco
thread" inside of the main thread, so that the object renderer can run
in parallel with the rest of the PPU, yet not be a hideous abomination
of a state machine, yet also not be horrendously slow as a full libco
thread would be.
I'm envisioning some kind of stackless yielding coroutine. But I'll need
to think through how to design that, given the absence of coroutines
even in C++17.
2017-06-04 03:16:44 +00:00
|
|
|
case 0x0400'0052: return screen.io.blendEVA;
|
|
|
|
|
case 0x0400'0053: return screen.io.blendEVB;
|
Update to v095r05 release.
byuu says:
Changelog:
- GBA: lots of emulation improvements
- PPU PRAM is 16-bits wide
- DMA masks &~1/Half, &~3/Word
- VRAM OBJ 8-bit writes are ignored
- OAM 8-bit writes are ignored
- BGnCNT unused bits are writable*
- BG(0,1)CNT can't set the d13
- BLDALPHA is readable (fixes Donkey Kong Country, etc)
- SNES: lots of code cleanups
- sfc/chip => sfc/coprocessor
- UI: save most recent controller selection
GBA test scores: 1552/1552, 37/38, 1020/1260
(* forgot to add the value to the read function, so endrift's I/O tests
for them will fail. Fixed locally.)
Note: SNES is the only system with multiple controller/expansion port
options, and as such is the only one with a "None" option. Because it's
shared by the controller and expansion port, it ends up sorted first in
the list. This means that on your first run, you'll need to go to Super
Famicom->Controller Port 1 and select "Gamepad", otherwise input won't
work.
Also note that changing the expansion port device requires loading a new
cart. Unlike controllers, you aren't meant to hotplug expansion port
devices.
2015-11-12 10:15:03 +00:00
|
|
|
|
Update to v102r19 release.
byuu says:
Note: add `#undef OUT` to the top of higan/gba/ppu/ppu.hpp to compile on
Windows (ugh ...) Now to await posts about this in four more threads
again ;)
Changelog:
- GBA: rewrote PPU from a scanline-based renderer to a pixel-based
renderer
- ruby: fixed video/gdi bugs
Note that there's an approximately 21% speed penalty compared to v102r18
for the pixel-based renderer.
Also, horizontal mosaic effects are not yet implemented. But they should
be prior to v103. This one is a little tricky as it currently works on
fully rendered scanlines. I need to roll the mosaic into the background
renderers, and then for sprites, well ... see below.
The trickiest part by far of this new renderer is the object (sprite)
system. Unlike every other system I emulate, the GBA supports affine
rendering of its sprites. Or in other words, rotation effects. And it
also has a very complex priority system.
Right now, I can't see any way that the GBA PPU could render pixels in
real-time like this. My belief is that there's a 240-entry buffer that
fills up the next scanline's row of pixels. Which means it probably also
runs on the last scanline of Vblank so that the first scanline has
sprite data.
However, I didn't design my object renderer like this just yet. For now,
it creates a buffer of all 240 pixels right away at the start of the
scanline. I know\!\! That's technically scanline-based. But it's only
for fetching object tiledata, and it's only temporary.
What needs to happen is I need a way to run something like a "mini libco
thread" inside of the main thread, so that the object renderer can run
in parallel with the rest of the PPU, yet not be a hideous abomination
of a state machine, yet also not be horrendously slow as a full libco
thread would be.
I'm envisioning some kind of stackless yielding coroutine. But I'll need
to think through how to design that, given the absence of coroutines
even in C++17.
2017-06-04 03:16:44 +00:00
|
|
|
//BLDY (write-only)
|
2015-11-14 00:52:51 +00:00
|
|
|
|
2012-03-31 08:14:31 +00:00
|
|
|
}
|
|
|
|
|
|
2016-02-25 10:38:03 +00:00
|
|
|
return 0;
|
2012-03-31 08:14:31 +00:00
|
|
|
}
|
|
|
|
|
|
Update to v099r13 release.
byuu says:
Changelog:
- GB core code cleanup completed
- GBA core code cleanup completed
- some more cleanup on missed processor/arm functions/variables
- fixed FC loading icarus bug
- "Load ROM File" icarus functionality restored
- minor code unification efforts all around (not perfect yet)
- MMIO->IO
- mmio.cpp->io.cpp
- read,write->readIO,writeIO
It's been a very long work in progress ... starting all the way back with
v094r09, but the major part of the higan code cleanup is now completed! Of
course, it's very important to note that this is only for the basic style:
- under_score functions and variables are now camelCase
- return-type function-name() are now auto function-name() -> return-type
- Natural<T>/Integer<T> replace (u)intT_n types where possible
- signed/unsigned are now int/uint
- most of the x==true,x==false tests changed to x,!x
A lot of spot improvements to consistency, simplicity and quality have
gone in along the way, of course. But we'll probably never fully finishing
beautifying every last line of code in the entire codebase. Still,
this is a really great start. Going forward, WIP diffs should start
being smaller and of higher quality once again.
I know the joke is, "until my coding style changes again", but ... this
was way too stressful, way too time consuming, and way too risky. I'm
too old and tired now for extreme upheavel like this again. The only
major change I'm slowly mulling over would be renaming the using
Natural<T>/Integer<T> = (u)intT; shorthand to something that isn't as
easily confused with the (u)int_t types ... but we'll see. I'll definitely
continue to change small things all the time, but for the larger picture,
I need to just accept the style I have and live with it.
2016-06-29 11:10:28 +00:00
|
|
|
auto PPU::writeIO(uint32 addr, uint8 data) -> void {
|
2012-04-01 01:41:15 +00:00
|
|
|
switch(addr) {
|
2012-03-31 08:14:31 +00:00
|
|
|
|
|
|
|
|
//DISPCNT
|
2016-02-25 10:38:03 +00:00
|
|
|
case 0x0400'0000:
|
Update to v102r19 release.
byuu says:
Note: add `#undef OUT` to the top of higan/gba/ppu/ppu.hpp to compile on
Windows (ugh ...) Now to await posts about this in four more threads
again ;)
Changelog:
- GBA: rewrote PPU from a scanline-based renderer to a pixel-based
renderer
- ruby: fixed video/gdi bugs
Note that there's an approximately 21% speed penalty compared to v102r18
for the pixel-based renderer.
Also, horizontal mosaic effects are not yet implemented. But they should
be prior to v103. This one is a little tricky as it currently works on
fully rendered scanlines. I need to roll the mosaic into the background
renderers, and then for sprites, well ... see below.
The trickiest part by far of this new renderer is the object (sprite)
system. Unlike every other system I emulate, the GBA supports affine
rendering of its sprites. Or in other words, rotation effects. And it
also has a very complex priority system.
Right now, I can't see any way that the GBA PPU could render pixels in
real-time like this. My belief is that there's a 240-entry buffer that
fills up the next scanline's row of pixels. Which means it probably also
runs on the last scanline of Vblank so that the first scanline has
sprite data.
However, I didn't design my object renderer like this just yet. For now,
it creates a buffer of all 240 pixels right away at the start of the
scanline. I know\!\! That's technically scanline-based. But it's only
for fetching object tiledata, and it's only temporary.
What needs to happen is I need a way to run something like a "mini libco
thread" inside of the main thread, so that the object renderer can run
in parallel with the rest of the PPU, yet not be a hideous abomination
of a state machine, yet also not be horrendously slow as a full libco
thread would be.
I'm envisioning some kind of stackless yielding coroutine. But I'll need
to think through how to design that, given the absence of coroutines
even in C++17.
2017-06-04 03:16:44 +00:00
|
|
|
Background::IO::mode = data.bits(0,2);
|
|
|
|
|
io.gameBoyColorMode = data.bit (3);
|
|
|
|
|
Background::IO::frame = data.bit (4);
|
|
|
|
|
objects.io.hblank = data.bit (5);
|
|
|
|
|
objects.io.mapping = data.bit (6);
|
|
|
|
|
io.forceBlank = data.bit (7);
|
2016-02-25 10:38:03 +00:00
|
|
|
return;
|
|
|
|
|
case 0x0400'0001:
|
Update to v102r19 release.
byuu says:
Note: add `#undef OUT` to the top of higan/gba/ppu/ppu.hpp to compile on
Windows (ugh ...) Now to await posts about this in four more threads
again ;)
Changelog:
- GBA: rewrote PPU from a scanline-based renderer to a pixel-based
renderer
- ruby: fixed video/gdi bugs
Note that there's an approximately 21% speed penalty compared to v102r18
for the pixel-based renderer.
Also, horizontal mosaic effects are not yet implemented. But they should
be prior to v103. This one is a little tricky as it currently works on
fully rendered scanlines. I need to roll the mosaic into the background
renderers, and then for sprites, well ... see below.
The trickiest part by far of this new renderer is the object (sprite)
system. Unlike every other system I emulate, the GBA supports affine
rendering of its sprites. Or in other words, rotation effects. And it
also has a very complex priority system.
Right now, I can't see any way that the GBA PPU could render pixels in
real-time like this. My belief is that there's a 240-entry buffer that
fills up the next scanline's row of pixels. Which means it probably also
runs on the last scanline of Vblank so that the first scanline has
sprite data.
However, I didn't design my object renderer like this just yet. For now,
it creates a buffer of all 240 pixels right away at the start of the
scanline. I know\!\! That's technically scanline-based. But it's only
for fetching object tiledata, and it's only temporary.
What needs to happen is I need a way to run something like a "mini libco
thread" inside of the main thread, so that the object renderer can run
in parallel with the rest of the PPU, yet not be a hideous abomination
of a state machine, yet also not be horrendously slow as a full libco
thread would be.
I'm envisioning some kind of stackless yielding coroutine. But I'll need
to think through how to design that, given the absence of coroutines
even in C++17.
2017-06-04 03:16:44 +00:00
|
|
|
bg0.io.enable = data.bit(0);
|
|
|
|
|
bg1.io.enable = data.bit(1);
|
|
|
|
|
bg2.io.enable = data.bit(2);
|
|
|
|
|
bg3.io.enable = data.bit(3);
|
|
|
|
|
objects.io.enable = data.bit(4);
|
|
|
|
|
window0.io.enable = data.bit(5);
|
|
|
|
|
window1.io.enable = data.bit(6);
|
|
|
|
|
window2.io.enable = data.bit(7);
|
|
|
|
|
//outside window is enabled whenever any inside window is enabled
|
|
|
|
|
window3.io.enable = (bool)data.bits(5,7);
|
2016-02-25 10:38:03 +00:00
|
|
|
return;
|
2012-03-31 08:14:31 +00:00
|
|
|
|
2012-03-31 08:17:36 +00:00
|
|
|
//GRSWP
|
2016-02-25 10:38:03 +00:00
|
|
|
case 0x0400'0002:
|
Update to v102r19 release.
byuu says:
Note: add `#undef OUT` to the top of higan/gba/ppu/ppu.hpp to compile on
Windows (ugh ...) Now to await posts about this in four more threads
again ;)
Changelog:
- GBA: rewrote PPU from a scanline-based renderer to a pixel-based
renderer
- ruby: fixed video/gdi bugs
Note that there's an approximately 21% speed penalty compared to v102r18
for the pixel-based renderer.
Also, horizontal mosaic effects are not yet implemented. But they should
be prior to v103. This one is a little tricky as it currently works on
fully rendered scanlines. I need to roll the mosaic into the background
renderers, and then for sprites, well ... see below.
The trickiest part by far of this new renderer is the object (sprite)
system. Unlike every other system I emulate, the GBA supports affine
rendering of its sprites. Or in other words, rotation effects. And it
also has a very complex priority system.
Right now, I can't see any way that the GBA PPU could render pixels in
real-time like this. My belief is that there's a 240-entry buffer that
fills up the next scanline's row of pixels. Which means it probably also
runs on the last scanline of Vblank so that the first scanline has
sprite data.
However, I didn't design my object renderer like this just yet. For now,
it creates a buffer of all 240 pixels right away at the start of the
scanline. I know\!\! That's technically scanline-based. But it's only
for fetching object tiledata, and it's only temporary.
What needs to happen is I need a way to run something like a "mini libco
thread" inside of the main thread, so that the object renderer can run
in parallel with the rest of the PPU, yet not be a hideous abomination
of a state machine, yet also not be horrendously slow as a full libco
thread would be.
I'm envisioning some kind of stackless yielding coroutine. But I'll need
to think through how to design that, given the absence of coroutines
even in C++17.
2017-06-04 03:16:44 +00:00
|
|
|
io.greenSwap = data.bit(0);
|
|
|
|
|
return;
|
|
|
|
|
case 0x0400'0003:
|
2016-02-25 10:38:03 +00:00
|
|
|
return;
|
2012-03-31 08:17:36 +00:00
|
|
|
|
|
|
|
|
//DISPSTAT
|
Update to v097r17 release.
byuu says:
Changelog:
- ruby: if DirectSoundCreate fails (no sound device present), return
false from init instead of crashing
- nall: improved edge case return values for
(basename,pathname,dirname,...)
- nall: renamed file_system_object class to inode
- nall: varuint_t replaced with VariadicNatural; which contains
.bit,.bits,.byte ala Natural/Integer
- nall: fixed boolean compilation error on Windows
- WS: popa should not restore SP
- GBA: rewrote the CPU/APU cores to use the .bit,.bits functions;
removed registers.cpp from each
Note that the GBA changes are extremely major. This is about five hours
worth of extremely delicate work. Any slight errors could break
emulation in extremely bad ways. Let's hold off on extensive testing
until the next WIP, after I do the same to the PPU.
So far ... endrift's SOUNDCNT_X I/O test is failing, although that code
didn't change, so clearly I messed up SOUNDCNT_H somehow ...
To compile on Windows:
1. change nall/string/platform.hpp line 47 to
return slice(result, 0, 3);
2. change ruby/video.wgl.cpp line 72 to
auto lock(uint32_t*& data, uint& pitch, uint width, uint height) -> bool {
3. add this line to the very top of hiro/windows/header.cpp:
#define boolean FuckYouMicrosoft
2016-02-23 11:08:44 +00:00
|
|
|
case 0x0400'0004:
|
Update to v102r19 release.
byuu says:
Note: add `#undef OUT` to the top of higan/gba/ppu/ppu.hpp to compile on
Windows (ugh ...) Now to await posts about this in four more threads
again ;)
Changelog:
- GBA: rewrote PPU from a scanline-based renderer to a pixel-based
renderer
- ruby: fixed video/gdi bugs
Note that there's an approximately 21% speed penalty compared to v102r18
for the pixel-based renderer.
Also, horizontal mosaic effects are not yet implemented. But they should
be prior to v103. This one is a little tricky as it currently works on
fully rendered scanlines. I need to roll the mosaic into the background
renderers, and then for sprites, well ... see below.
The trickiest part by far of this new renderer is the object (sprite)
system. Unlike every other system I emulate, the GBA supports affine
rendering of its sprites. Or in other words, rotation effects. And it
also has a very complex priority system.
Right now, I can't see any way that the GBA PPU could render pixels in
real-time like this. My belief is that there's a 240-entry buffer that
fills up the next scanline's row of pixels. Which means it probably also
runs on the last scanline of Vblank so that the first scanline has
sprite data.
However, I didn't design my object renderer like this just yet. For now,
it creates a buffer of all 240 pixels right away at the start of the
scanline. I know\!\! That's technically scanline-based. But it's only
for fetching object tiledata, and it's only temporary.
What needs to happen is I need a way to run something like a "mini libco
thread" inside of the main thread, so that the object renderer can run
in parallel with the rest of the PPU, yet not be a hideous abomination
of a state machine, yet also not be horrendously slow as a full libco
thread would be.
I'm envisioning some kind of stackless yielding coroutine. But I'll need
to think through how to design that, given the absence of coroutines
even in C++17.
2017-06-04 03:16:44 +00:00
|
|
|
io.irqvblank = data.bit(3);
|
|
|
|
|
io.irqhblank = data.bit(4);
|
|
|
|
|
io.irqvcoincidence = data.bit(5);
|
2012-03-31 08:17:36 +00:00
|
|
|
return;
|
Update to v097r17 release.
byuu says:
Changelog:
- ruby: if DirectSoundCreate fails (no sound device present), return
false from init instead of crashing
- nall: improved edge case return values for
(basename,pathname,dirname,...)
- nall: renamed file_system_object class to inode
- nall: varuint_t replaced with VariadicNatural; which contains
.bit,.bits,.byte ala Natural/Integer
- nall: fixed boolean compilation error on Windows
- WS: popa should not restore SP
- GBA: rewrote the CPU/APU cores to use the .bit,.bits functions;
removed registers.cpp from each
Note that the GBA changes are extremely major. This is about five hours
worth of extremely delicate work. Any slight errors could break
emulation in extremely bad ways. Let's hold off on extensive testing
until the next WIP, after I do the same to the PPU.
So far ... endrift's SOUNDCNT_X I/O test is failing, although that code
didn't change, so clearly I messed up SOUNDCNT_H somehow ...
To compile on Windows:
1. change nall/string/platform.hpp line 47 to
return slice(result, 0, 3);
2. change ruby/video.wgl.cpp line 72 to
auto lock(uint32_t*& data, uint& pitch, uint width, uint height) -> bool {
3. add this line to the very top of hiro/windows/header.cpp:
#define boolean FuckYouMicrosoft
2016-02-23 11:08:44 +00:00
|
|
|
case 0x0400'0005:
|
Update to v102r19 release.
byuu says:
Note: add `#undef OUT` to the top of higan/gba/ppu/ppu.hpp to compile on
Windows (ugh ...) Now to await posts about this in four more threads
again ;)
Changelog:
- GBA: rewrote PPU from a scanline-based renderer to a pixel-based
renderer
- ruby: fixed video/gdi bugs
Note that there's an approximately 21% speed penalty compared to v102r18
for the pixel-based renderer.
Also, horizontal mosaic effects are not yet implemented. But they should
be prior to v103. This one is a little tricky as it currently works on
fully rendered scanlines. I need to roll the mosaic into the background
renderers, and then for sprites, well ... see below.
The trickiest part by far of this new renderer is the object (sprite)
system. Unlike every other system I emulate, the GBA supports affine
rendering of its sprites. Or in other words, rotation effects. And it
also has a very complex priority system.
Right now, I can't see any way that the GBA PPU could render pixels in
real-time like this. My belief is that there's a 240-entry buffer that
fills up the next scanline's row of pixels. Which means it probably also
runs on the last scanline of Vblank so that the first scanline has
sprite data.
However, I didn't design my object renderer like this just yet. For now,
it creates a buffer of all 240 pixels right away at the start of the
scanline. I know\!\! That's technically scanline-based. But it's only
for fetching object tiledata, and it's only temporary.
What needs to happen is I need a way to run something like a "mini libco
thread" inside of the main thread, so that the object renderer can run
in parallel with the rest of the PPU, yet not be a hideous abomination
of a state machine, yet also not be horrendously slow as a full libco
thread would be.
I'm envisioning some kind of stackless yielding coroutine. But I'll need
to think through how to design that, given the absence of coroutines
even in C++17.
2017-06-04 03:16:44 +00:00
|
|
|
io.vcompare = data;
|
2012-03-31 08:17:36 +00:00
|
|
|
return;
|
|
|
|
|
|
Update to v102r19 release.
byuu says:
Note: add `#undef OUT` to the top of higan/gba/ppu/ppu.hpp to compile on
Windows (ugh ...) Now to await posts about this in four more threads
again ;)
Changelog:
- GBA: rewrote PPU from a scanline-based renderer to a pixel-based
renderer
- ruby: fixed video/gdi bugs
Note that there's an approximately 21% speed penalty compared to v102r18
for the pixel-based renderer.
Also, horizontal mosaic effects are not yet implemented. But they should
be prior to v103. This one is a little tricky as it currently works on
fully rendered scanlines. I need to roll the mosaic into the background
renderers, and then for sprites, well ... see below.
The trickiest part by far of this new renderer is the object (sprite)
system. Unlike every other system I emulate, the GBA supports affine
rendering of its sprites. Or in other words, rotation effects. And it
also has a very complex priority system.
Right now, I can't see any way that the GBA PPU could render pixels in
real-time like this. My belief is that there's a 240-entry buffer that
fills up the next scanline's row of pixels. Which means it probably also
runs on the last scanline of Vblank so that the first scanline has
sprite data.
However, I didn't design my object renderer like this just yet. For now,
it creates a buffer of all 240 pixels right away at the start of the
scanline. I know\!\! That's technically scanline-based. But it's only
for fetching object tiledata, and it's only temporary.
What needs to happen is I need a way to run something like a "mini libco
thread" inside of the main thread, so that the object renderer can run
in parallel with the rest of the PPU, yet not be a hideous abomination
of a state machine, yet also not be horrendously slow as a full libco
thread would be.
I'm envisioning some kind of stackless yielding coroutine. But I'll need
to think through how to design that, given the absence of coroutines
even in C++17.
2017-06-04 03:16:44 +00:00
|
|
|
//BG0CNT
|
|
|
|
|
case 0x0400'0008:
|
|
|
|
|
bg0.io.priority = data.bits(0,1);
|
|
|
|
|
bg0.io.characterBase = data.bits(2,3);
|
|
|
|
|
bg0.io.unused = data.bits(4,5);
|
|
|
|
|
bg0.io.mosaic = data.bit (6);
|
|
|
|
|
bg0.io.colorMode = data.bit (7);
|
2012-04-09 06:41:27 +00:00
|
|
|
return;
|
Update to v102r19 release.
byuu says:
Note: add `#undef OUT` to the top of higan/gba/ppu/ppu.hpp to compile on
Windows (ugh ...) Now to await posts about this in four more threads
again ;)
Changelog:
- GBA: rewrote PPU from a scanline-based renderer to a pixel-based
renderer
- ruby: fixed video/gdi bugs
Note that there's an approximately 21% speed penalty compared to v102r18
for the pixel-based renderer.
Also, horizontal mosaic effects are not yet implemented. But they should
be prior to v103. This one is a little tricky as it currently works on
fully rendered scanlines. I need to roll the mosaic into the background
renderers, and then for sprites, well ... see below.
The trickiest part by far of this new renderer is the object (sprite)
system. Unlike every other system I emulate, the GBA supports affine
rendering of its sprites. Or in other words, rotation effects. And it
also has a very complex priority system.
Right now, I can't see any way that the GBA PPU could render pixels in
real-time like this. My belief is that there's a 240-entry buffer that
fills up the next scanline's row of pixels. Which means it probably also
runs on the last scanline of Vblank so that the first scanline has
sprite data.
However, I didn't design my object renderer like this just yet. For now,
it creates a buffer of all 240 pixels right away at the start of the
scanline. I know\!\! That's technically scanline-based. But it's only
for fetching object tiledata, and it's only temporary.
What needs to happen is I need a way to run something like a "mini libco
thread" inside of the main thread, so that the object renderer can run
in parallel with the rest of the PPU, yet not be a hideous abomination
of a state machine, yet also not be horrendously slow as a full libco
thread would be.
I'm envisioning some kind of stackless yielding coroutine. But I'll need
to think through how to design that, given the absence of coroutines
even in C++17.
2017-06-04 03:16:44 +00:00
|
|
|
case 0x0400'0009:
|
|
|
|
|
bg0.io.screenBase = data.bits(0,4);
|
|
|
|
|
bg0.io.affineWrap = false;
|
|
|
|
|
bg0.io.screenSize = data.bits(6,7);
|
2012-04-09 06:41:27 +00:00
|
|
|
return;
|
2012-03-31 08:17:36 +00:00
|
|
|
|
Update to v102r19 release.
byuu says:
Note: add `#undef OUT` to the top of higan/gba/ppu/ppu.hpp to compile on
Windows (ugh ...) Now to await posts about this in four more threads
again ;)
Changelog:
- GBA: rewrote PPU from a scanline-based renderer to a pixel-based
renderer
- ruby: fixed video/gdi bugs
Note that there's an approximately 21% speed penalty compared to v102r18
for the pixel-based renderer.
Also, horizontal mosaic effects are not yet implemented. But they should
be prior to v103. This one is a little tricky as it currently works on
fully rendered scanlines. I need to roll the mosaic into the background
renderers, and then for sprites, well ... see below.
The trickiest part by far of this new renderer is the object (sprite)
system. Unlike every other system I emulate, the GBA supports affine
rendering of its sprites. Or in other words, rotation effects. And it
also has a very complex priority system.
Right now, I can't see any way that the GBA PPU could render pixels in
real-time like this. My belief is that there's a 240-entry buffer that
fills up the next scanline's row of pixels. Which means it probably also
runs on the last scanline of Vblank so that the first scanline has
sprite data.
However, I didn't design my object renderer like this just yet. For now,
it creates a buffer of all 240 pixels right away at the start of the
scanline. I know\!\! That's technically scanline-based. But it's only
for fetching object tiledata, and it's only temporary.
What needs to happen is I need a way to run something like a "mini libco
thread" inside of the main thread, so that the object renderer can run
in parallel with the rest of the PPU, yet not be a hideous abomination
of a state machine, yet also not be horrendously slow as a full libco
thread would be.
I'm envisioning some kind of stackless yielding coroutine. But I'll need
to think through how to design that, given the absence of coroutines
even in C++17.
2017-06-04 03:16:44 +00:00
|
|
|
//BG1CNT
|
|
|
|
|
case 0x0400'000a:
|
|
|
|
|
bg1.io.priority = data.bits(0,1);
|
|
|
|
|
bg1.io.characterBase = data.bits(2,3);
|
|
|
|
|
bg1.io.unused = data.bits(4,5);
|
|
|
|
|
bg1.io.mosaic = data.bit (6);
|
|
|
|
|
bg1.io.colorMode = data.bit (7);
|
2012-04-09 06:41:27 +00:00
|
|
|
return;
|
Update to v102r19 release.
byuu says:
Note: add `#undef OUT` to the top of higan/gba/ppu/ppu.hpp to compile on
Windows (ugh ...) Now to await posts about this in four more threads
again ;)
Changelog:
- GBA: rewrote PPU from a scanline-based renderer to a pixel-based
renderer
- ruby: fixed video/gdi bugs
Note that there's an approximately 21% speed penalty compared to v102r18
for the pixel-based renderer.
Also, horizontal mosaic effects are not yet implemented. But they should
be prior to v103. This one is a little tricky as it currently works on
fully rendered scanlines. I need to roll the mosaic into the background
renderers, and then for sprites, well ... see below.
The trickiest part by far of this new renderer is the object (sprite)
system. Unlike every other system I emulate, the GBA supports affine
rendering of its sprites. Or in other words, rotation effects. And it
also has a very complex priority system.
Right now, I can't see any way that the GBA PPU could render pixels in
real-time like this. My belief is that there's a 240-entry buffer that
fills up the next scanline's row of pixels. Which means it probably also
runs on the last scanline of Vblank so that the first scanline has
sprite data.
However, I didn't design my object renderer like this just yet. For now,
it creates a buffer of all 240 pixels right away at the start of the
scanline. I know\!\! That's technically scanline-based. But it's only
for fetching object tiledata, and it's only temporary.
What needs to happen is I need a way to run something like a "mini libco
thread" inside of the main thread, so that the object renderer can run
in parallel with the rest of the PPU, yet not be a hideous abomination
of a state machine, yet also not be horrendously slow as a full libco
thread would be.
I'm envisioning some kind of stackless yielding coroutine. But I'll need
to think through how to design that, given the absence of coroutines
even in C++17.
2017-06-04 03:16:44 +00:00
|
|
|
case 0x0400'000b:
|
|
|
|
|
bg1.io.screenBase = data.bits(0,4);
|
|
|
|
|
bg1.io.affineWrap = false;
|
|
|
|
|
bg1.io.screenSize = data.bits(6,7);
|
2012-04-09 06:41:27 +00:00
|
|
|
return;
|
2012-03-31 08:17:36 +00:00
|
|
|
|
Update to v102r19 release.
byuu says:
Note: add `#undef OUT` to the top of higan/gba/ppu/ppu.hpp to compile on
Windows (ugh ...) Now to await posts about this in four more threads
again ;)
Changelog:
- GBA: rewrote PPU from a scanline-based renderer to a pixel-based
renderer
- ruby: fixed video/gdi bugs
Note that there's an approximately 21% speed penalty compared to v102r18
for the pixel-based renderer.
Also, horizontal mosaic effects are not yet implemented. But they should
be prior to v103. This one is a little tricky as it currently works on
fully rendered scanlines. I need to roll the mosaic into the background
renderers, and then for sprites, well ... see below.
The trickiest part by far of this new renderer is the object (sprite)
system. Unlike every other system I emulate, the GBA supports affine
rendering of its sprites. Or in other words, rotation effects. And it
also has a very complex priority system.
Right now, I can't see any way that the GBA PPU could render pixels in
real-time like this. My belief is that there's a 240-entry buffer that
fills up the next scanline's row of pixels. Which means it probably also
runs on the last scanline of Vblank so that the first scanline has
sprite data.
However, I didn't design my object renderer like this just yet. For now,
it creates a buffer of all 240 pixels right away at the start of the
scanline. I know\!\! That's technically scanline-based. But it's only
for fetching object tiledata, and it's only temporary.
What needs to happen is I need a way to run something like a "mini libco
thread" inside of the main thread, so that the object renderer can run
in parallel with the rest of the PPU, yet not be a hideous abomination
of a state machine, yet also not be horrendously slow as a full libco
thread would be.
I'm envisioning some kind of stackless yielding coroutine. But I'll need
to think through how to design that, given the absence of coroutines
even in C++17.
2017-06-04 03:16:44 +00:00
|
|
|
//BG2CNT
|
|
|
|
|
case 0x0400'000c:
|
|
|
|
|
bg2.io.priority = data.bits(0,1);
|
|
|
|
|
bg2.io.characterBase = data.bits(2,3);
|
|
|
|
|
bg2.io.unused = data.bits(4,5);
|
|
|
|
|
bg2.io.mosaic = data.bit (6);
|
|
|
|
|
bg2.io.colorMode = data.bit (7);
|
2012-04-09 06:41:27 +00:00
|
|
|
return;
|
Update to v102r19 release.
byuu says:
Note: add `#undef OUT` to the top of higan/gba/ppu/ppu.hpp to compile on
Windows (ugh ...) Now to await posts about this in four more threads
again ;)
Changelog:
- GBA: rewrote PPU from a scanline-based renderer to a pixel-based
renderer
- ruby: fixed video/gdi bugs
Note that there's an approximately 21% speed penalty compared to v102r18
for the pixel-based renderer.
Also, horizontal mosaic effects are not yet implemented. But they should
be prior to v103. This one is a little tricky as it currently works on
fully rendered scanlines. I need to roll the mosaic into the background
renderers, and then for sprites, well ... see below.
The trickiest part by far of this new renderer is the object (sprite)
system. Unlike every other system I emulate, the GBA supports affine
rendering of its sprites. Or in other words, rotation effects. And it
also has a very complex priority system.
Right now, I can't see any way that the GBA PPU could render pixels in
real-time like this. My belief is that there's a 240-entry buffer that
fills up the next scanline's row of pixels. Which means it probably also
runs on the last scanline of Vblank so that the first scanline has
sprite data.
However, I didn't design my object renderer like this just yet. For now,
it creates a buffer of all 240 pixels right away at the start of the
scanline. I know\!\! That's technically scanline-based. But it's only
for fetching object tiledata, and it's only temporary.
What needs to happen is I need a way to run something like a "mini libco
thread" inside of the main thread, so that the object renderer can run
in parallel with the rest of the PPU, yet not be a hideous abomination
of a state machine, yet also not be horrendously slow as a full libco
thread would be.
I'm envisioning some kind of stackless yielding coroutine. But I'll need
to think through how to design that, given the absence of coroutines
even in C++17.
2017-06-04 03:16:44 +00:00
|
|
|
case 0x0400'000d:
|
|
|
|
|
bg2.io.screenBase = data.bits(0,4);
|
|
|
|
|
bg2.io.affineWrap = data.bit (5);
|
|
|
|
|
bg2.io.screenSize = data.bits(6,7);
|
2012-04-09 06:41:27 +00:00
|
|
|
return;
|
2012-03-31 08:17:36 +00:00
|
|
|
|
Update to v102r19 release.
byuu says:
Note: add `#undef OUT` to the top of higan/gba/ppu/ppu.hpp to compile on
Windows (ugh ...) Now to await posts about this in four more threads
again ;)
Changelog:
- GBA: rewrote PPU from a scanline-based renderer to a pixel-based
renderer
- ruby: fixed video/gdi bugs
Note that there's an approximately 21% speed penalty compared to v102r18
for the pixel-based renderer.
Also, horizontal mosaic effects are not yet implemented. But they should
be prior to v103. This one is a little tricky as it currently works on
fully rendered scanlines. I need to roll the mosaic into the background
renderers, and then for sprites, well ... see below.
The trickiest part by far of this new renderer is the object (sprite)
system. Unlike every other system I emulate, the GBA supports affine
rendering of its sprites. Or in other words, rotation effects. And it
also has a very complex priority system.
Right now, I can't see any way that the GBA PPU could render pixels in
real-time like this. My belief is that there's a 240-entry buffer that
fills up the next scanline's row of pixels. Which means it probably also
runs on the last scanline of Vblank so that the first scanline has
sprite data.
However, I didn't design my object renderer like this just yet. For now,
it creates a buffer of all 240 pixels right away at the start of the
scanline. I know\!\! That's technically scanline-based. But it's only
for fetching object tiledata, and it's only temporary.
What needs to happen is I need a way to run something like a "mini libco
thread" inside of the main thread, so that the object renderer can run
in parallel with the rest of the PPU, yet not be a hideous abomination
of a state machine, yet also not be horrendously slow as a full libco
thread would be.
I'm envisioning some kind of stackless yielding coroutine. But I'll need
to think through how to design that, given the absence of coroutines
even in C++17.
2017-06-04 03:16:44 +00:00
|
|
|
//BG3CNT
|
|
|
|
|
case 0x0400'000e:
|
|
|
|
|
bg3.io.priority = data.bits(0,1);
|
|
|
|
|
bg3.io.characterBase = data.bits(2,3);
|
|
|
|
|
bg3.io.unused = data.bits(4,5);
|
|
|
|
|
bg3.io.mosaic = data.bit (6);
|
|
|
|
|
bg3.io.colorMode = data.bit (7);
|
|
|
|
|
return;
|
|
|
|
|
case 0x0400'000f:
|
|
|
|
|
bg3.io.screenBase = data.bits(0,4);
|
|
|
|
|
bg3.io.affineWrap = data.bit (5);
|
|
|
|
|
bg3.io.screenSize = data.bits(6,7);
|
|
|
|
|
return;
|
2016-02-25 10:38:03 +00:00
|
|
|
|
Update to v102r19 release.
byuu says:
Note: add `#undef OUT` to the top of higan/gba/ppu/ppu.hpp to compile on
Windows (ugh ...) Now to await posts about this in four more threads
again ;)
Changelog:
- GBA: rewrote PPU from a scanline-based renderer to a pixel-based
renderer
- ruby: fixed video/gdi bugs
Note that there's an approximately 21% speed penalty compared to v102r18
for the pixel-based renderer.
Also, horizontal mosaic effects are not yet implemented. But they should
be prior to v103. This one is a little tricky as it currently works on
fully rendered scanlines. I need to roll the mosaic into the background
renderers, and then for sprites, well ... see below.
The trickiest part by far of this new renderer is the object (sprite)
system. Unlike every other system I emulate, the GBA supports affine
rendering of its sprites. Or in other words, rotation effects. And it
also has a very complex priority system.
Right now, I can't see any way that the GBA PPU could render pixels in
real-time like this. My belief is that there's a 240-entry buffer that
fills up the next scanline's row of pixels. Which means it probably also
runs on the last scanline of Vblank so that the first scanline has
sprite data.
However, I didn't design my object renderer like this just yet. For now,
it creates a buffer of all 240 pixels right away at the start of the
scanline. I know\!\! That's technically scanline-based. But it's only
for fetching object tiledata, and it's only temporary.
What needs to happen is I need a way to run something like a "mini libco
thread" inside of the main thread, so that the object renderer can run
in parallel with the rest of the PPU, yet not be a hideous abomination
of a state machine, yet also not be horrendously slow as a full libco
thread would be.
I'm envisioning some kind of stackless yielding coroutine. But I'll need
to think through how to design that, given the absence of coroutines
even in C++17.
2017-06-04 03:16:44 +00:00
|
|
|
//BG0HOFS
|
|
|
|
|
case 0x0400'0010: bg0.io.hoffset.bits(0,7) = data.bits(0,7); return;
|
2017-06-06 01:39:27 +00:00
|
|
|
case 0x0400'0011: bg0.io.hoffset.bit (8) = data.bit (0); return;
|
Update to v102r19 release.
byuu says:
Note: add `#undef OUT` to the top of higan/gba/ppu/ppu.hpp to compile on
Windows (ugh ...) Now to await posts about this in four more threads
again ;)
Changelog:
- GBA: rewrote PPU from a scanline-based renderer to a pixel-based
renderer
- ruby: fixed video/gdi bugs
Note that there's an approximately 21% speed penalty compared to v102r18
for the pixel-based renderer.
Also, horizontal mosaic effects are not yet implemented. But they should
be prior to v103. This one is a little tricky as it currently works on
fully rendered scanlines. I need to roll the mosaic into the background
renderers, and then for sprites, well ... see below.
The trickiest part by far of this new renderer is the object (sprite)
system. Unlike every other system I emulate, the GBA supports affine
rendering of its sprites. Or in other words, rotation effects. And it
also has a very complex priority system.
Right now, I can't see any way that the GBA PPU could render pixels in
real-time like this. My belief is that there's a 240-entry buffer that
fills up the next scanline's row of pixels. Which means it probably also
runs on the last scanline of Vblank so that the first scanline has
sprite data.
However, I didn't design my object renderer like this just yet. For now,
it creates a buffer of all 240 pixels right away at the start of the
scanline. I know\!\! That's technically scanline-based. But it's only
for fetching object tiledata, and it's only temporary.
What needs to happen is I need a way to run something like a "mini libco
thread" inside of the main thread, so that the object renderer can run
in parallel with the rest of the PPU, yet not be a hideous abomination
of a state machine, yet also not be horrendously slow as a full libco
thread would be.
I'm envisioning some kind of stackless yielding coroutine. But I'll need
to think through how to design that, given the absence of coroutines
even in C++17.
2017-06-04 03:16:44 +00:00
|
|
|
|
|
|
|
|
//BG0VOFS
|
|
|
|
|
case 0x0400'0012: bg0.io.voffset.bits(0,7) = data.bits(0,7); return;
|
2017-06-06 01:39:27 +00:00
|
|
|
case 0x0400'0013: bg0.io.voffset.bit (8) = data.bit (0); return;
|
Update to v102r19 release.
byuu says:
Note: add `#undef OUT` to the top of higan/gba/ppu/ppu.hpp to compile on
Windows (ugh ...) Now to await posts about this in four more threads
again ;)
Changelog:
- GBA: rewrote PPU from a scanline-based renderer to a pixel-based
renderer
- ruby: fixed video/gdi bugs
Note that there's an approximately 21% speed penalty compared to v102r18
for the pixel-based renderer.
Also, horizontal mosaic effects are not yet implemented. But they should
be prior to v103. This one is a little tricky as it currently works on
fully rendered scanlines. I need to roll the mosaic into the background
renderers, and then for sprites, well ... see below.
The trickiest part by far of this new renderer is the object (sprite)
system. Unlike every other system I emulate, the GBA supports affine
rendering of its sprites. Or in other words, rotation effects. And it
also has a very complex priority system.
Right now, I can't see any way that the GBA PPU could render pixels in
real-time like this. My belief is that there's a 240-entry buffer that
fills up the next scanline's row of pixels. Which means it probably also
runs on the last scanline of Vblank so that the first scanline has
sprite data.
However, I didn't design my object renderer like this just yet. For now,
it creates a buffer of all 240 pixels right away at the start of the
scanline. I know\!\! That's technically scanline-based. But it's only
for fetching object tiledata, and it's only temporary.
What needs to happen is I need a way to run something like a "mini libco
thread" inside of the main thread, so that the object renderer can run
in parallel with the rest of the PPU, yet not be a hideous abomination
of a state machine, yet also not be horrendously slow as a full libco
thread would be.
I'm envisioning some kind of stackless yielding coroutine. But I'll need
to think through how to design that, given the absence of coroutines
even in C++17.
2017-06-04 03:16:44 +00:00
|
|
|
|
|
|
|
|
//BG1HOFS
|
|
|
|
|
case 0x0400'0014: bg1.io.hoffset.bits(0,7) = data.bits(0,7); return;
|
2017-06-06 01:39:27 +00:00
|
|
|
case 0x0400'0015: bg1.io.hoffset.bit (8) = data.bit (0); return;
|
Update to v102r19 release.
byuu says:
Note: add `#undef OUT` to the top of higan/gba/ppu/ppu.hpp to compile on
Windows (ugh ...) Now to await posts about this in four more threads
again ;)
Changelog:
- GBA: rewrote PPU from a scanline-based renderer to a pixel-based
renderer
- ruby: fixed video/gdi bugs
Note that there's an approximately 21% speed penalty compared to v102r18
for the pixel-based renderer.
Also, horizontal mosaic effects are not yet implemented. But they should
be prior to v103. This one is a little tricky as it currently works on
fully rendered scanlines. I need to roll the mosaic into the background
renderers, and then for sprites, well ... see below.
The trickiest part by far of this new renderer is the object (sprite)
system. Unlike every other system I emulate, the GBA supports affine
rendering of its sprites. Or in other words, rotation effects. And it
also has a very complex priority system.
Right now, I can't see any way that the GBA PPU could render pixels in
real-time like this. My belief is that there's a 240-entry buffer that
fills up the next scanline's row of pixels. Which means it probably also
runs on the last scanline of Vblank so that the first scanline has
sprite data.
However, I didn't design my object renderer like this just yet. For now,
it creates a buffer of all 240 pixels right away at the start of the
scanline. I know\!\! That's technically scanline-based. But it's only
for fetching object tiledata, and it's only temporary.
What needs to happen is I need a way to run something like a "mini libco
thread" inside of the main thread, so that the object renderer can run
in parallel with the rest of the PPU, yet not be a hideous abomination
of a state machine, yet also not be horrendously slow as a full libco
thread would be.
I'm envisioning some kind of stackless yielding coroutine. But I'll need
to think through how to design that, given the absence of coroutines
even in C++17.
2017-06-04 03:16:44 +00:00
|
|
|
|
|
|
|
|
//BG1VOFS
|
|
|
|
|
case 0x0400'0016: bg1.io.voffset.bits(0,7) = data.bits(0,7); return;
|
2017-06-06 01:39:27 +00:00
|
|
|
case 0x0400'0017: bg1.io.voffset.bit (8) = data.bit (0); return;
|
Update to v102r19 release.
byuu says:
Note: add `#undef OUT` to the top of higan/gba/ppu/ppu.hpp to compile on
Windows (ugh ...) Now to await posts about this in four more threads
again ;)
Changelog:
- GBA: rewrote PPU from a scanline-based renderer to a pixel-based
renderer
- ruby: fixed video/gdi bugs
Note that there's an approximately 21% speed penalty compared to v102r18
for the pixel-based renderer.
Also, horizontal mosaic effects are not yet implemented. But they should
be prior to v103. This one is a little tricky as it currently works on
fully rendered scanlines. I need to roll the mosaic into the background
renderers, and then for sprites, well ... see below.
The trickiest part by far of this new renderer is the object (sprite)
system. Unlike every other system I emulate, the GBA supports affine
rendering of its sprites. Or in other words, rotation effects. And it
also has a very complex priority system.
Right now, I can't see any way that the GBA PPU could render pixels in
real-time like this. My belief is that there's a 240-entry buffer that
fills up the next scanline's row of pixels. Which means it probably also
runs on the last scanline of Vblank so that the first scanline has
sprite data.
However, I didn't design my object renderer like this just yet. For now,
it creates a buffer of all 240 pixels right away at the start of the
scanline. I know\!\! That's technically scanline-based. But it's only
for fetching object tiledata, and it's only temporary.
What needs to happen is I need a way to run something like a "mini libco
thread" inside of the main thread, so that the object renderer can run
in parallel with the rest of the PPU, yet not be a hideous abomination
of a state machine, yet also not be horrendously slow as a full libco
thread would be.
I'm envisioning some kind of stackless yielding coroutine. But I'll need
to think through how to design that, given the absence of coroutines
even in C++17.
2017-06-04 03:16:44 +00:00
|
|
|
|
|
|
|
|
//BG2HOFS
|
|
|
|
|
case 0x0400'0018: bg2.io.hoffset.bits(0,7) = data.bits(0,7); return;
|
2017-06-06 01:39:27 +00:00
|
|
|
case 0x0400'0019: bg2.io.hoffset.bit (8) = data.bit (0); return;
|
Update to v102r19 release.
byuu says:
Note: add `#undef OUT` to the top of higan/gba/ppu/ppu.hpp to compile on
Windows (ugh ...) Now to await posts about this in four more threads
again ;)
Changelog:
- GBA: rewrote PPU from a scanline-based renderer to a pixel-based
renderer
- ruby: fixed video/gdi bugs
Note that there's an approximately 21% speed penalty compared to v102r18
for the pixel-based renderer.
Also, horizontal mosaic effects are not yet implemented. But they should
be prior to v103. This one is a little tricky as it currently works on
fully rendered scanlines. I need to roll the mosaic into the background
renderers, and then for sprites, well ... see below.
The trickiest part by far of this new renderer is the object (sprite)
system. Unlike every other system I emulate, the GBA supports affine
rendering of its sprites. Or in other words, rotation effects. And it
also has a very complex priority system.
Right now, I can't see any way that the GBA PPU could render pixels in
real-time like this. My belief is that there's a 240-entry buffer that
fills up the next scanline's row of pixels. Which means it probably also
runs on the last scanline of Vblank so that the first scanline has
sprite data.
However, I didn't design my object renderer like this just yet. For now,
it creates a buffer of all 240 pixels right away at the start of the
scanline. I know\!\! That's technically scanline-based. But it's only
for fetching object tiledata, and it's only temporary.
What needs to happen is I need a way to run something like a "mini libco
thread" inside of the main thread, so that the object renderer can run
in parallel with the rest of the PPU, yet not be a hideous abomination
of a state machine, yet also not be horrendously slow as a full libco
thread would be.
I'm envisioning some kind of stackless yielding coroutine. But I'll need
to think through how to design that, given the absence of coroutines
even in C++17.
2017-06-04 03:16:44 +00:00
|
|
|
|
|
|
|
|
//BG2VOFS
|
|
|
|
|
case 0x0400'001a: bg2.io.voffset.bits(0,7) = data.bits(0,7); return;
|
2017-06-06 01:39:27 +00:00
|
|
|
case 0x0400'001b: bg2.io.voffset.bit (8) = data.bit (0); return;
|
Update to v102r19 release.
byuu says:
Note: add `#undef OUT` to the top of higan/gba/ppu/ppu.hpp to compile on
Windows (ugh ...) Now to await posts about this in four more threads
again ;)
Changelog:
- GBA: rewrote PPU from a scanline-based renderer to a pixel-based
renderer
- ruby: fixed video/gdi bugs
Note that there's an approximately 21% speed penalty compared to v102r18
for the pixel-based renderer.
Also, horizontal mosaic effects are not yet implemented. But they should
be prior to v103. This one is a little tricky as it currently works on
fully rendered scanlines. I need to roll the mosaic into the background
renderers, and then for sprites, well ... see below.
The trickiest part by far of this new renderer is the object (sprite)
system. Unlike every other system I emulate, the GBA supports affine
rendering of its sprites. Or in other words, rotation effects. And it
also has a very complex priority system.
Right now, I can't see any way that the GBA PPU could render pixels in
real-time like this. My belief is that there's a 240-entry buffer that
fills up the next scanline's row of pixels. Which means it probably also
runs on the last scanline of Vblank so that the first scanline has
sprite data.
However, I didn't design my object renderer like this just yet. For now,
it creates a buffer of all 240 pixels right away at the start of the
scanline. I know\!\! That's technically scanline-based. But it's only
for fetching object tiledata, and it's only temporary.
What needs to happen is I need a way to run something like a "mini libco
thread" inside of the main thread, so that the object renderer can run
in parallel with the rest of the PPU, yet not be a hideous abomination
of a state machine, yet also not be horrendously slow as a full libco
thread would be.
I'm envisioning some kind of stackless yielding coroutine. But I'll need
to think through how to design that, given the absence of coroutines
even in C++17.
2017-06-04 03:16:44 +00:00
|
|
|
|
|
|
|
|
//BG3HOFS
|
|
|
|
|
case 0x0400'001c: bg3.io.hoffset.bits(0,7) = data.bits(0,7); return;
|
2017-06-06 01:39:27 +00:00
|
|
|
case 0x0400'001d: bg3.io.hoffset.bit (8) = data.bit (0); return;
|
Update to v102r19 release.
byuu says:
Note: add `#undef OUT` to the top of higan/gba/ppu/ppu.hpp to compile on
Windows (ugh ...) Now to await posts about this in four more threads
again ;)
Changelog:
- GBA: rewrote PPU from a scanline-based renderer to a pixel-based
renderer
- ruby: fixed video/gdi bugs
Note that there's an approximately 21% speed penalty compared to v102r18
for the pixel-based renderer.
Also, horizontal mosaic effects are not yet implemented. But they should
be prior to v103. This one is a little tricky as it currently works on
fully rendered scanlines. I need to roll the mosaic into the background
renderers, and then for sprites, well ... see below.
The trickiest part by far of this new renderer is the object (sprite)
system. Unlike every other system I emulate, the GBA supports affine
rendering of its sprites. Or in other words, rotation effects. And it
also has a very complex priority system.
Right now, I can't see any way that the GBA PPU could render pixels in
real-time like this. My belief is that there's a 240-entry buffer that
fills up the next scanline's row of pixels. Which means it probably also
runs on the last scanline of Vblank so that the first scanline has
sprite data.
However, I didn't design my object renderer like this just yet. For now,
it creates a buffer of all 240 pixels right away at the start of the
scanline. I know\!\! That's technically scanline-based. But it's only
for fetching object tiledata, and it's only temporary.
What needs to happen is I need a way to run something like a "mini libco
thread" inside of the main thread, so that the object renderer can run
in parallel with the rest of the PPU, yet not be a hideous abomination
of a state machine, yet also not be horrendously slow as a full libco
thread would be.
I'm envisioning some kind of stackless yielding coroutine. But I'll need
to think through how to design that, given the absence of coroutines
even in C++17.
2017-06-04 03:16:44 +00:00
|
|
|
|
|
|
|
|
//BG3VOFS
|
|
|
|
|
case 0x0400'001e: bg3.io.voffset.bits(0,7) = data.bits(0,7); return;
|
2017-06-06 01:39:27 +00:00
|
|
|
case 0x0400'001f: bg3.io.voffset.bit (8) = data.bit (0); return;
|
Update to v102r19 release.
byuu says:
Note: add `#undef OUT` to the top of higan/gba/ppu/ppu.hpp to compile on
Windows (ugh ...) Now to await posts about this in four more threads
again ;)
Changelog:
- GBA: rewrote PPU from a scanline-based renderer to a pixel-based
renderer
- ruby: fixed video/gdi bugs
Note that there's an approximately 21% speed penalty compared to v102r18
for the pixel-based renderer.
Also, horizontal mosaic effects are not yet implemented. But they should
be prior to v103. This one is a little tricky as it currently works on
fully rendered scanlines. I need to roll the mosaic into the background
renderers, and then for sprites, well ... see below.
The trickiest part by far of this new renderer is the object (sprite)
system. Unlike every other system I emulate, the GBA supports affine
rendering of its sprites. Or in other words, rotation effects. And it
also has a very complex priority system.
Right now, I can't see any way that the GBA PPU could render pixels in
real-time like this. My belief is that there's a 240-entry buffer that
fills up the next scanline's row of pixels. Which means it probably also
runs on the last scanline of Vblank so that the first scanline has
sprite data.
However, I didn't design my object renderer like this just yet. For now,
it creates a buffer of all 240 pixels right away at the start of the
scanline. I know\!\! That's technically scanline-based. But it's only
for fetching object tiledata, and it's only temporary.
What needs to happen is I need a way to run something like a "mini libco
thread" inside of the main thread, so that the object renderer can run
in parallel with the rest of the PPU, yet not be a hideous abomination
of a state machine, yet also not be horrendously slow as a full libco
thread would be.
I'm envisioning some kind of stackless yielding coroutine. But I'll need
to think through how to design that, given the absence of coroutines
even in C++17.
2017-06-04 03:16:44 +00:00
|
|
|
|
|
|
|
|
//BG2PA
|
|
|
|
|
case 0x0400'0020: bg2.io.pa.byte(0) = data; return;
|
|
|
|
|
case 0x0400'0021: bg2.io.pa.byte(1) = data; return;
|
|
|
|
|
|
|
|
|
|
//BG2PB
|
|
|
|
|
case 0x0400'0022: bg2.io.pb.byte(0) = data; return;
|
|
|
|
|
case 0x0400'0023: bg2.io.pb.byte(1) = data; return;
|
|
|
|
|
|
|
|
|
|
//BG2PC
|
|
|
|
|
case 0x0400'0024: bg2.io.pc.byte(0) = data; return;
|
|
|
|
|
case 0x0400'0025: bg2.io.pc.byte(1) = data; return;
|
|
|
|
|
|
|
|
|
|
//BG2PD
|
|
|
|
|
case 0x0400'0026: bg2.io.pd.byte(0) = data; return;
|
|
|
|
|
case 0x0400'0027: bg2.io.pd.byte(1) = data; return;
|
|
|
|
|
|
|
|
|
|
//BG2X
|
|
|
|
|
case 0x0400'0028: bg2.io.x.bits( 0, 7) = data.bits(0,7); bg2.io.lx = bg2.io.x; return;
|
|
|
|
|
case 0x0400'0029: bg2.io.x.bits( 8,15) = data.bits(0,7); bg2.io.lx = bg2.io.x; return;
|
|
|
|
|
case 0x0400'002a: bg2.io.x.bits(16,23) = data.bits(0,7); bg2.io.lx = bg2.io.x; return;
|
|
|
|
|
case 0x0400'002b: bg2.io.x.bits(24,27) = data.bits(0,3); bg2.io.lx = bg2.io.x; return;
|
|
|
|
|
|
|
|
|
|
//BG2Y
|
|
|
|
|
case 0x0400'002c: bg2.io.y.bits( 0, 7) = data.bits(0,7); bg2.io.ly = bg2.io.y; return;
|
|
|
|
|
case 0x0400'002d: bg2.io.y.bits( 8,15) = data.bits(0,7); bg2.io.ly = bg2.io.y; return;
|
|
|
|
|
case 0x0400'002e: bg2.io.y.bits(16,23) = data.bits(0,7); bg2.io.ly = bg2.io.y; return;
|
|
|
|
|
case 0x0400'002f: bg2.io.y.bits(24,27) = data.bits(0,3); bg2.io.ly = bg2.io.y; return;
|
|
|
|
|
|
|
|
|
|
//BG3PA
|
|
|
|
|
case 0x0400'0030: bg3.io.pa.byte(0) = data; return;
|
|
|
|
|
case 0x0400'0031: bg3.io.pa.byte(1) = data; return;
|
|
|
|
|
|
|
|
|
|
//BG3PB
|
|
|
|
|
case 0x0400'0032: bg3.io.pb.byte(0) = data; return;
|
Update to v102r21 release.
byuu says:
Changelog:
- GBA: fixed WININ2 reads, BG3PB writes [Jonas Quinn]
- R65816: added support for yielding/resuming from WAI/STP¹
- SFC: removed status.dmaCounter functionality (also fixes possible
TAS desync issue)
- tomoko: added support for combinatorial inputs [hex\_usr\]²
- nall: fixed missing return value from Arithmetic::operator--
[Hendricks266]
Now would be the time to start looking for major regressions with the
new GBA PPU renderer, I suppose ...
¹: this doesn't matter for the master thread (SNES CPU), but is
important for slave threads (SNES SA1). If you try to save a state and
the SA1 is inside of a WAI instruction, it will get stuck there forever.
This was causing attempts to create a save state in Super Bomberman
- Panic Bomber W to deadlock the emulator and crash it. This is now
finally fixed.
Note that I still need to implement similar functionality into the Mega
Drive 68K and Z80 cores. They still have the possibility of deadlocking.
The SNES implementation was more a dry-run test for this new
functionality. This possible crashing bug in the Mega Drive core is the
major blocking bug for a new official release.
²: many, many thanks to hex\_usr for coming up with a really nice
design. I mostly implemented it the exact same way, but with a few tiny
differences that don't really matter (display " and ", " or " instead of
" & ", " | " in the input settings windows; append → bind;
assignmentName changed to displayName.)
The actual functionality is identical to the old higan v094 and earlier
builds. Emulated digital inputs let you combine multiple possible keys
to trigger the buttons. This is OR logic, so you can map to eg
keyboard.up OR gamepad.up for instance. Emulated analog inputs always
sum together. Emulated rumble outputs will cause all mapped devices to
rumble, which is probably not at all useful but whatever. Hotkeys use
AND logic, so you have to press every key mapped to trigger them. Useful
for eg Ctrl+F to trigger fullscreen.
Obviously, there are cases where OR logic would be nice for hotkeys,
too. Eg if you want both F11 and your gamepad's guide button to trigger
the fullscreen toggle. Unfortunately, this isn't supported, and likely
won't ever be in tomoko. Something I might consider is a throw switch in
the configuration file to swap between AND or OR logic for hotkeys, but
I'm not going to allow construction of mappings like "(Keyboard.Ctrl and
Keyboard.F) or Gamepad.Guide", as that's just too complicated to code,
and too complicated to make a nice GUI to set up the mappings for.
2017-06-06 13:44:40 +00:00
|
|
|
case 0x0400'0033: bg3.io.pb.byte(1) = data; return;
|
Update to v102r19 release.
byuu says:
Note: add `#undef OUT` to the top of higan/gba/ppu/ppu.hpp to compile on
Windows (ugh ...) Now to await posts about this in four more threads
again ;)
Changelog:
- GBA: rewrote PPU from a scanline-based renderer to a pixel-based
renderer
- ruby: fixed video/gdi bugs
Note that there's an approximately 21% speed penalty compared to v102r18
for the pixel-based renderer.
Also, horizontal mosaic effects are not yet implemented. But they should
be prior to v103. This one is a little tricky as it currently works on
fully rendered scanlines. I need to roll the mosaic into the background
renderers, and then for sprites, well ... see below.
The trickiest part by far of this new renderer is the object (sprite)
system. Unlike every other system I emulate, the GBA supports affine
rendering of its sprites. Or in other words, rotation effects. And it
also has a very complex priority system.
Right now, I can't see any way that the GBA PPU could render pixels in
real-time like this. My belief is that there's a 240-entry buffer that
fills up the next scanline's row of pixels. Which means it probably also
runs on the last scanline of Vblank so that the first scanline has
sprite data.
However, I didn't design my object renderer like this just yet. For now,
it creates a buffer of all 240 pixels right away at the start of the
scanline. I know\!\! That's technically scanline-based. But it's only
for fetching object tiledata, and it's only temporary.
What needs to happen is I need a way to run something like a "mini libco
thread" inside of the main thread, so that the object renderer can run
in parallel with the rest of the PPU, yet not be a hideous abomination
of a state machine, yet also not be horrendously slow as a full libco
thread would be.
I'm envisioning some kind of stackless yielding coroutine. But I'll need
to think through how to design that, given the absence of coroutines
even in C++17.
2017-06-04 03:16:44 +00:00
|
|
|
|
|
|
|
|
//BG3PC
|
|
|
|
|
case 0x0400'0034: bg3.io.pc.byte(0) = data; return;
|
|
|
|
|
case 0x0400'0035: bg3.io.pc.byte(1) = data; return;
|
|
|
|
|
|
|
|
|
|
//BG3PD
|
|
|
|
|
case 0x0400'0036: bg3.io.pd.byte(0) = data; return;
|
|
|
|
|
case 0x0400'0037: bg3.io.pd.byte(1) = data; return;
|
|
|
|
|
|
|
|
|
|
//BG3X
|
|
|
|
|
case 0x0400'0038: bg3.io.x.bits( 0, 7) = data.bits(0,7); bg3.io.lx = bg3.io.x; return;
|
|
|
|
|
case 0x0400'0039: bg3.io.x.bits( 8,15) = data.bits(0,7); bg3.io.lx = bg3.io.x; return;
|
|
|
|
|
case 0x0400'003a: bg3.io.x.bits(16,23) = data.bits(0,7); bg3.io.lx = bg3.io.x; return;
|
|
|
|
|
case 0x0400'003b: bg3.io.x.bits(24,27) = data.bits(0,3); bg3.io.lx = bg3.io.x; return;
|
|
|
|
|
|
|
|
|
|
//BG3Y
|
|
|
|
|
case 0x0400'003c: bg3.io.y.bits( 0, 7) = data.bits(0,7); bg3.io.ly = bg3.io.y; return;
|
|
|
|
|
case 0x0400'003d: bg3.io.y.bits( 8,15) = data.bits(0,7); bg3.io.ly = bg3.io.y; return;
|
|
|
|
|
case 0x0400'003e: bg3.io.y.bits(16,23) = data.bits(0,7); bg3.io.ly = bg3.io.y; return;
|
|
|
|
|
case 0x0400'003f: bg3.io.y.bits(24,27) = data.bits(0,3); bg3.io.ly = bg3.io.y; return;
|
2012-03-31 08:17:36 +00:00
|
|
|
|
|
|
|
|
//WIN0H
|
Update to v102r19 release.
byuu says:
Note: add `#undef OUT` to the top of higan/gba/ppu/ppu.hpp to compile on
Windows (ugh ...) Now to await posts about this in four more threads
again ;)
Changelog:
- GBA: rewrote PPU from a scanline-based renderer to a pixel-based
renderer
- ruby: fixed video/gdi bugs
Note that there's an approximately 21% speed penalty compared to v102r18
for the pixel-based renderer.
Also, horizontal mosaic effects are not yet implemented. But they should
be prior to v103. This one is a little tricky as it currently works on
fully rendered scanlines. I need to roll the mosaic into the background
renderers, and then for sprites, well ... see below.
The trickiest part by far of this new renderer is the object (sprite)
system. Unlike every other system I emulate, the GBA supports affine
rendering of its sprites. Or in other words, rotation effects. And it
also has a very complex priority system.
Right now, I can't see any way that the GBA PPU could render pixels in
real-time like this. My belief is that there's a 240-entry buffer that
fills up the next scanline's row of pixels. Which means it probably also
runs on the last scanline of Vblank so that the first scanline has
sprite data.
However, I didn't design my object renderer like this just yet. For now,
it creates a buffer of all 240 pixels right away at the start of the
scanline. I know\!\! That's technically scanline-based. But it's only
for fetching object tiledata, and it's only temporary.
What needs to happen is I need a way to run something like a "mini libco
thread" inside of the main thread, so that the object renderer can run
in parallel with the rest of the PPU, yet not be a hideous abomination
of a state machine, yet also not be horrendously slow as a full libco
thread would be.
I'm envisioning some kind of stackless yielding coroutine. But I'll need
to think through how to design that, given the absence of coroutines
even in C++17.
2017-06-04 03:16:44 +00:00
|
|
|
case 0x0400'0040: window0.io.x2 = data; return;
|
|
|
|
|
case 0x0400'0041: window0.io.x1 = data; return;
|
2012-03-31 08:17:36 +00:00
|
|
|
|
|
|
|
|
//WIN1H
|
Update to v102r19 release.
byuu says:
Note: add `#undef OUT` to the top of higan/gba/ppu/ppu.hpp to compile on
Windows (ugh ...) Now to await posts about this in four more threads
again ;)
Changelog:
- GBA: rewrote PPU from a scanline-based renderer to a pixel-based
renderer
- ruby: fixed video/gdi bugs
Note that there's an approximately 21% speed penalty compared to v102r18
for the pixel-based renderer.
Also, horizontal mosaic effects are not yet implemented. But they should
be prior to v103. This one is a little tricky as it currently works on
fully rendered scanlines. I need to roll the mosaic into the background
renderers, and then for sprites, well ... see below.
The trickiest part by far of this new renderer is the object (sprite)
system. Unlike every other system I emulate, the GBA supports affine
rendering of its sprites. Or in other words, rotation effects. And it
also has a very complex priority system.
Right now, I can't see any way that the GBA PPU could render pixels in
real-time like this. My belief is that there's a 240-entry buffer that
fills up the next scanline's row of pixels. Which means it probably also
runs on the last scanline of Vblank so that the first scanline has
sprite data.
However, I didn't design my object renderer like this just yet. For now,
it creates a buffer of all 240 pixels right away at the start of the
scanline. I know\!\! That's technically scanline-based. But it's only
for fetching object tiledata, and it's only temporary.
What needs to happen is I need a way to run something like a "mini libco
thread" inside of the main thread, so that the object renderer can run
in parallel with the rest of the PPU, yet not be a hideous abomination
of a state machine, yet also not be horrendously slow as a full libco
thread would be.
I'm envisioning some kind of stackless yielding coroutine. But I'll need
to think through how to design that, given the absence of coroutines
even in C++17.
2017-06-04 03:16:44 +00:00
|
|
|
case 0x0400'0042: window1.io.x2 = data; return;
|
|
|
|
|
case 0x0400'0043: window1.io.x1 = data; return;
|
2012-03-31 08:17:36 +00:00
|
|
|
|
|
|
|
|
//WIN0V
|
Update to v102r19 release.
byuu says:
Note: add `#undef OUT` to the top of higan/gba/ppu/ppu.hpp to compile on
Windows (ugh ...) Now to await posts about this in four more threads
again ;)
Changelog:
- GBA: rewrote PPU from a scanline-based renderer to a pixel-based
renderer
- ruby: fixed video/gdi bugs
Note that there's an approximately 21% speed penalty compared to v102r18
for the pixel-based renderer.
Also, horizontal mosaic effects are not yet implemented. But they should
be prior to v103. This one is a little tricky as it currently works on
fully rendered scanlines. I need to roll the mosaic into the background
renderers, and then for sprites, well ... see below.
The trickiest part by far of this new renderer is the object (sprite)
system. Unlike every other system I emulate, the GBA supports affine
rendering of its sprites. Or in other words, rotation effects. And it
also has a very complex priority system.
Right now, I can't see any way that the GBA PPU could render pixels in
real-time like this. My belief is that there's a 240-entry buffer that
fills up the next scanline's row of pixels. Which means it probably also
runs on the last scanline of Vblank so that the first scanline has
sprite data.
However, I didn't design my object renderer like this just yet. For now,
it creates a buffer of all 240 pixels right away at the start of the
scanline. I know\!\! That's technically scanline-based. But it's only
for fetching object tiledata, and it's only temporary.
What needs to happen is I need a way to run something like a "mini libco
thread" inside of the main thread, so that the object renderer can run
in parallel with the rest of the PPU, yet not be a hideous abomination
of a state machine, yet also not be horrendously slow as a full libco
thread would be.
I'm envisioning some kind of stackless yielding coroutine. But I'll need
to think through how to design that, given the absence of coroutines
even in C++17.
2017-06-04 03:16:44 +00:00
|
|
|
case 0x0400'0044: window0.io.y2 = data; return;
|
|
|
|
|
case 0x0400'0045: window0.io.y1 = data; return;
|
2012-03-31 08:17:36 +00:00
|
|
|
|
|
|
|
|
//WIN1V
|
Update to v102r19 release.
byuu says:
Note: add `#undef OUT` to the top of higan/gba/ppu/ppu.hpp to compile on
Windows (ugh ...) Now to await posts about this in four more threads
again ;)
Changelog:
- GBA: rewrote PPU from a scanline-based renderer to a pixel-based
renderer
- ruby: fixed video/gdi bugs
Note that there's an approximately 21% speed penalty compared to v102r18
for the pixel-based renderer.
Also, horizontal mosaic effects are not yet implemented. But they should
be prior to v103. This one is a little tricky as it currently works on
fully rendered scanlines. I need to roll the mosaic into the background
renderers, and then for sprites, well ... see below.
The trickiest part by far of this new renderer is the object (sprite)
system. Unlike every other system I emulate, the GBA supports affine
rendering of its sprites. Or in other words, rotation effects. And it
also has a very complex priority system.
Right now, I can't see any way that the GBA PPU could render pixels in
real-time like this. My belief is that there's a 240-entry buffer that
fills up the next scanline's row of pixels. Which means it probably also
runs on the last scanline of Vblank so that the first scanline has
sprite data.
However, I didn't design my object renderer like this just yet. For now,
it creates a buffer of all 240 pixels right away at the start of the
scanline. I know\!\! That's technically scanline-based. But it's only
for fetching object tiledata, and it's only temporary.
What needs to happen is I need a way to run something like a "mini libco
thread" inside of the main thread, so that the object renderer can run
in parallel with the rest of the PPU, yet not be a hideous abomination
of a state machine, yet also not be horrendously slow as a full libco
thread would be.
I'm envisioning some kind of stackless yielding coroutine. But I'll need
to think through how to design that, given the absence of coroutines
even in C++17.
2017-06-04 03:16:44 +00:00
|
|
|
case 0x0400'0046: window1.io.y2 = data; return;
|
|
|
|
|
case 0x0400'0047: window1.io.y1 = data; return;
|
|
|
|
|
|
|
|
|
|
//WININ0
|
|
|
|
|
case 0x0400'0048:
|
|
|
|
|
window0.io.active[BG0] = data.bit(0);
|
|
|
|
|
window0.io.active[BG1] = data.bit(1);
|
|
|
|
|
window0.io.active[BG2] = data.bit(2);
|
|
|
|
|
window0.io.active[BG3] = data.bit(3);
|
|
|
|
|
window0.io.active[OBJ] = data.bit(4);
|
|
|
|
|
window0.io.active[SFX] = data.bit(5);
|
|
|
|
|
return;
|
|
|
|
|
|
|
|
|
|
//WININ1
|
|
|
|
|
case 0x0400'0049:
|
|
|
|
|
window1.io.active[BG0] = data.bit(0);
|
|
|
|
|
window1.io.active[BG1] = data.bit(1);
|
|
|
|
|
window1.io.active[BG2] = data.bit(2);
|
|
|
|
|
window1.io.active[BG3] = data.bit(3);
|
|
|
|
|
window1.io.active[OBJ] = data.bit(4);
|
|
|
|
|
window1.io.active[SFX] = data.bit(5);
|
|
|
|
|
return;
|
|
|
|
|
|
|
|
|
|
//WINOUT
|
|
|
|
|
case 0x0400'004a:
|
|
|
|
|
window3.io.active[BG0] = data.bit(0);
|
|
|
|
|
window3.io.active[BG1] = data.bit(1);
|
|
|
|
|
window3.io.active[BG2] = data.bit(2);
|
|
|
|
|
window3.io.active[BG3] = data.bit(3);
|
|
|
|
|
window3.io.active[OBJ] = data.bit(4);
|
|
|
|
|
window3.io.active[SFX] = data.bit(5);
|
|
|
|
|
return;
|
|
|
|
|
|
|
|
|
|
//WININ2
|
|
|
|
|
case 0x0400'004b:
|
|
|
|
|
window2.io.active[BG0] = data.bit(0);
|
|
|
|
|
window2.io.active[BG1] = data.bit(1);
|
|
|
|
|
window2.io.active[BG2] = data.bit(2);
|
|
|
|
|
window2.io.active[BG3] = data.bit(3);
|
|
|
|
|
window2.io.active[OBJ] = data.bit(4);
|
|
|
|
|
window2.io.active[SFX] = data.bit(5);
|
2016-02-25 10:38:03 +00:00
|
|
|
return;
|
2012-03-31 08:17:36 +00:00
|
|
|
|
|
|
|
|
//MOSAIC
|
Update to v097r17 release.
byuu says:
Changelog:
- ruby: if DirectSoundCreate fails (no sound device present), return
false from init instead of crashing
- nall: improved edge case return values for
(basename,pathname,dirname,...)
- nall: renamed file_system_object class to inode
- nall: varuint_t replaced with VariadicNatural; which contains
.bit,.bits,.byte ala Natural/Integer
- nall: fixed boolean compilation error on Windows
- WS: popa should not restore SP
- GBA: rewrote the CPU/APU cores to use the .bit,.bits functions;
removed registers.cpp from each
Note that the GBA changes are extremely major. This is about five hours
worth of extremely delicate work. Any slight errors could break
emulation in extremely bad ways. Let's hold off on extensive testing
until the next WIP, after I do the same to the PPU.
So far ... endrift's SOUNDCNT_X I/O test is failing, although that code
didn't change, so clearly I messed up SOUNDCNT_H somehow ...
To compile on Windows:
1. change nall/string/platform.hpp line 47 to
return slice(result, 0, 3);
2. change ruby/video.wgl.cpp line 72 to
auto lock(uint32_t*& data, uint& pitch, uint width, uint height) -> bool {
3. add this line to the very top of hiro/windows/header.cpp:
#define boolean FuckYouMicrosoft
2016-02-23 11:08:44 +00:00
|
|
|
case 0x0400'004c:
|
Update to v102r19 release.
byuu says:
Note: add `#undef OUT` to the top of higan/gba/ppu/ppu.hpp to compile on
Windows (ugh ...) Now to await posts about this in four more threads
again ;)
Changelog:
- GBA: rewrote PPU from a scanline-based renderer to a pixel-based
renderer
- ruby: fixed video/gdi bugs
Note that there's an approximately 21% speed penalty compared to v102r18
for the pixel-based renderer.
Also, horizontal mosaic effects are not yet implemented. But they should
be prior to v103. This one is a little tricky as it currently works on
fully rendered scanlines. I need to roll the mosaic into the background
renderers, and then for sprites, well ... see below.
The trickiest part by far of this new renderer is the object (sprite)
system. Unlike every other system I emulate, the GBA supports affine
rendering of its sprites. Or in other words, rotation effects. And it
also has a very complex priority system.
Right now, I can't see any way that the GBA PPU could render pixels in
real-time like this. My belief is that there's a 240-entry buffer that
fills up the next scanline's row of pixels. Which means it probably also
runs on the last scanline of Vblank so that the first scanline has
sprite data.
However, I didn't design my object renderer like this just yet. For now,
it creates a buffer of all 240 pixels right away at the start of the
scanline. I know\!\! That's technically scanline-based. But it's only
for fetching object tiledata, and it's only temporary.
What needs to happen is I need a way to run something like a "mini libco
thread" inside of the main thread, so that the object renderer can run
in parallel with the rest of the PPU, yet not be a hideous abomination
of a state machine, yet also not be horrendously slow as a full libco
thread would be.
I'm envisioning some kind of stackless yielding coroutine. But I'll need
to think through how to design that, given the absence of coroutines
even in C++17.
2017-06-04 03:16:44 +00:00
|
|
|
Background::IO::mosaicWidth = data.bits(0,3);
|
|
|
|
|
Background::IO::mosaicHeight = data.bits(4,7);
|
2012-03-31 08:17:36 +00:00
|
|
|
return;
|
Update to v097r17 release.
byuu says:
Changelog:
- ruby: if DirectSoundCreate fails (no sound device present), return
false from init instead of crashing
- nall: improved edge case return values for
(basename,pathname,dirname,...)
- nall: renamed file_system_object class to inode
- nall: varuint_t replaced with VariadicNatural; which contains
.bit,.bits,.byte ala Natural/Integer
- nall: fixed boolean compilation error on Windows
- WS: popa should not restore SP
- GBA: rewrote the CPU/APU cores to use the .bit,.bits functions;
removed registers.cpp from each
Note that the GBA changes are extremely major. This is about five hours
worth of extremely delicate work. Any slight errors could break
emulation in extremely bad ways. Let's hold off on extensive testing
until the next WIP, after I do the same to the PPU.
So far ... endrift's SOUNDCNT_X I/O test is failing, although that code
didn't change, so clearly I messed up SOUNDCNT_H somehow ...
To compile on Windows:
1. change nall/string/platform.hpp line 47 to
return slice(result, 0, 3);
2. change ruby/video.wgl.cpp line 72 to
auto lock(uint32_t*& data, uint& pitch, uint width, uint height) -> bool {
3. add this line to the very top of hiro/windows/header.cpp:
#define boolean FuckYouMicrosoft
2016-02-23 11:08:44 +00:00
|
|
|
case 0x0400'004d:
|
Update to v102r19 release.
byuu says:
Note: add `#undef OUT` to the top of higan/gba/ppu/ppu.hpp to compile on
Windows (ugh ...) Now to await posts about this in four more threads
again ;)
Changelog:
- GBA: rewrote PPU from a scanline-based renderer to a pixel-based
renderer
- ruby: fixed video/gdi bugs
Note that there's an approximately 21% speed penalty compared to v102r18
for the pixel-based renderer.
Also, horizontal mosaic effects are not yet implemented. But they should
be prior to v103. This one is a little tricky as it currently works on
fully rendered scanlines. I need to roll the mosaic into the background
renderers, and then for sprites, well ... see below.
The trickiest part by far of this new renderer is the object (sprite)
system. Unlike every other system I emulate, the GBA supports affine
rendering of its sprites. Or in other words, rotation effects. And it
also has a very complex priority system.
Right now, I can't see any way that the GBA PPU could render pixels in
real-time like this. My belief is that there's a 240-entry buffer that
fills up the next scanline's row of pixels. Which means it probably also
runs on the last scanline of Vblank so that the first scanline has
sprite data.
However, I didn't design my object renderer like this just yet. For now,
it creates a buffer of all 240 pixels right away at the start of the
scanline. I know\!\! That's technically scanline-based. But it's only
for fetching object tiledata, and it's only temporary.
What needs to happen is I need a way to run something like a "mini libco
thread" inside of the main thread, so that the object renderer can run
in parallel with the rest of the PPU, yet not be a hideous abomination
of a state machine, yet also not be horrendously slow as a full libco
thread would be.
I'm envisioning some kind of stackless yielding coroutine. But I'll need
to think through how to design that, given the absence of coroutines
even in C++17.
2017-06-04 03:16:44 +00:00
|
|
|
objects.io.mosaicWidth = data.bits(0,3);
|
|
|
|
|
objects.io.mosaicHeight = data.bits(4,7);
|
2012-03-31 08:17:36 +00:00
|
|
|
return;
|
|
|
|
|
|
|
|
|
|
//BLDCNT
|
2016-02-25 10:38:03 +00:00
|
|
|
case 0x0400'0050:
|
Update to v102r19 release.
byuu says:
Note: add `#undef OUT` to the top of higan/gba/ppu/ppu.hpp to compile on
Windows (ugh ...) Now to await posts about this in four more threads
again ;)
Changelog:
- GBA: rewrote PPU from a scanline-based renderer to a pixel-based
renderer
- ruby: fixed video/gdi bugs
Note that there's an approximately 21% speed penalty compared to v102r18
for the pixel-based renderer.
Also, horizontal mosaic effects are not yet implemented. But they should
be prior to v103. This one is a little tricky as it currently works on
fully rendered scanlines. I need to roll the mosaic into the background
renderers, and then for sprites, well ... see below.
The trickiest part by far of this new renderer is the object (sprite)
system. Unlike every other system I emulate, the GBA supports affine
rendering of its sprites. Or in other words, rotation effects. And it
also has a very complex priority system.
Right now, I can't see any way that the GBA PPU could render pixels in
real-time like this. My belief is that there's a 240-entry buffer that
fills up the next scanline's row of pixels. Which means it probably also
runs on the last scanline of Vblank so that the first scanline has
sprite data.
However, I didn't design my object renderer like this just yet. For now,
it creates a buffer of all 240 pixels right away at the start of the
scanline. I know\!\! That's technically scanline-based. But it's only
for fetching object tiledata, and it's only temporary.
What needs to happen is I need a way to run something like a "mini libco
thread" inside of the main thread, so that the object renderer can run
in parallel with the rest of the PPU, yet not be a hideous abomination
of a state machine, yet also not be horrendously slow as a full libco
thread would be.
I'm envisioning some kind of stackless yielding coroutine. But I'll need
to think through how to design that, given the absence of coroutines
even in C++17.
2017-06-04 03:16:44 +00:00
|
|
|
screen.io.blendAbove[BG0] = data.bit (0);
|
|
|
|
|
screen.io.blendAbove[BG1] = data.bit (1);
|
|
|
|
|
screen.io.blendAbove[BG2] = data.bit (2);
|
|
|
|
|
screen.io.blendAbove[BG3] = data.bit (3);
|
|
|
|
|
screen.io.blendAbove[OBJ] = data.bit (4);
|
|
|
|
|
screen.io.blendAbove[SFX] = data.bit (5);
|
|
|
|
|
screen.io.blendMode = data.bits(6,7);
|
2016-02-25 10:38:03 +00:00
|
|
|
return;
|
|
|
|
|
case 0x0400'0051:
|
Update to v102r19 release.
byuu says:
Note: add `#undef OUT` to the top of higan/gba/ppu/ppu.hpp to compile on
Windows (ugh ...) Now to await posts about this in four more threads
again ;)
Changelog:
- GBA: rewrote PPU from a scanline-based renderer to a pixel-based
renderer
- ruby: fixed video/gdi bugs
Note that there's an approximately 21% speed penalty compared to v102r18
for the pixel-based renderer.
Also, horizontal mosaic effects are not yet implemented. But they should
be prior to v103. This one is a little tricky as it currently works on
fully rendered scanlines. I need to roll the mosaic into the background
renderers, and then for sprites, well ... see below.
The trickiest part by far of this new renderer is the object (sprite)
system. Unlike every other system I emulate, the GBA supports affine
rendering of its sprites. Or in other words, rotation effects. And it
also has a very complex priority system.
Right now, I can't see any way that the GBA PPU could render pixels in
real-time like this. My belief is that there's a 240-entry buffer that
fills up the next scanline's row of pixels. Which means it probably also
runs on the last scanline of Vblank so that the first scanline has
sprite data.
However, I didn't design my object renderer like this just yet. For now,
it creates a buffer of all 240 pixels right away at the start of the
scanline. I know\!\! That's technically scanline-based. But it's only
for fetching object tiledata, and it's only temporary.
What needs to happen is I need a way to run something like a "mini libco
thread" inside of the main thread, so that the object renderer can run
in parallel with the rest of the PPU, yet not be a hideous abomination
of a state machine, yet also not be horrendously slow as a full libco
thread would be.
I'm envisioning some kind of stackless yielding coroutine. But I'll need
to think through how to design that, given the absence of coroutines
even in C++17.
2017-06-04 03:16:44 +00:00
|
|
|
screen.io.blendBelow[BG0] = data.bit(0);
|
|
|
|
|
screen.io.blendBelow[BG1] = data.bit(1);
|
|
|
|
|
screen.io.blendBelow[BG2] = data.bit(2);
|
|
|
|
|
screen.io.blendBelow[BG3] = data.bit(3);
|
|
|
|
|
screen.io.blendBelow[OBJ] = data.bit(4);
|
|
|
|
|
screen.io.blendBelow[SFX] = data.bit(5);
|
2016-02-25 10:38:03 +00:00
|
|
|
return;
|
2012-03-31 08:17:36 +00:00
|
|
|
|
|
|
|
|
//BLDALPHA
|
Update to v102r19 release.
byuu says:
Note: add `#undef OUT` to the top of higan/gba/ppu/ppu.hpp to compile on
Windows (ugh ...) Now to await posts about this in four more threads
again ;)
Changelog:
- GBA: rewrote PPU from a scanline-based renderer to a pixel-based
renderer
- ruby: fixed video/gdi bugs
Note that there's an approximately 21% speed penalty compared to v102r18
for the pixel-based renderer.
Also, horizontal mosaic effects are not yet implemented. But they should
be prior to v103. This one is a little tricky as it currently works on
fully rendered scanlines. I need to roll the mosaic into the background
renderers, and then for sprites, well ... see below.
The trickiest part by far of this new renderer is the object (sprite)
system. Unlike every other system I emulate, the GBA supports affine
rendering of its sprites. Or in other words, rotation effects. And it
also has a very complex priority system.
Right now, I can't see any way that the GBA PPU could render pixels in
real-time like this. My belief is that there's a 240-entry buffer that
fills up the next scanline's row of pixels. Which means it probably also
runs on the last scanline of Vblank so that the first scanline has
sprite data.
However, I didn't design my object renderer like this just yet. For now,
it creates a buffer of all 240 pixels right away at the start of the
scanline. I know\!\! That's technically scanline-based. But it's only
for fetching object tiledata, and it's only temporary.
What needs to happen is I need a way to run something like a "mini libco
thread" inside of the main thread, so that the object renderer can run
in parallel with the rest of the PPU, yet not be a hideous abomination
of a state machine, yet also not be horrendously slow as a full libco
thread would be.
I'm envisioning some kind of stackless yielding coroutine. But I'll need
to think through how to design that, given the absence of coroutines
even in C++17.
2017-06-04 03:16:44 +00:00
|
|
|
case 0x0400'0052: screen.io.blendEVA = data.bits(0,4); return;
|
|
|
|
|
case 0x0400'0053: screen.io.blendEVB = data.bits(0,4); return;
|
2012-03-31 08:17:36 +00:00
|
|
|
|
|
|
|
|
//BLDY
|
Update to v102r19 release.
byuu says:
Note: add `#undef OUT` to the top of higan/gba/ppu/ppu.hpp to compile on
Windows (ugh ...) Now to await posts about this in four more threads
again ;)
Changelog:
- GBA: rewrote PPU from a scanline-based renderer to a pixel-based
renderer
- ruby: fixed video/gdi bugs
Note that there's an approximately 21% speed penalty compared to v102r18
for the pixel-based renderer.
Also, horizontal mosaic effects are not yet implemented. But they should
be prior to v103. This one is a little tricky as it currently works on
fully rendered scanlines. I need to roll the mosaic into the background
renderers, and then for sprites, well ... see below.
The trickiest part by far of this new renderer is the object (sprite)
system. Unlike every other system I emulate, the GBA supports affine
rendering of its sprites. Or in other words, rotation effects. And it
also has a very complex priority system.
Right now, I can't see any way that the GBA PPU could render pixels in
real-time like this. My belief is that there's a 240-entry buffer that
fills up the next scanline's row of pixels. Which means it probably also
runs on the last scanline of Vblank so that the first scanline has
sprite data.
However, I didn't design my object renderer like this just yet. For now,
it creates a buffer of all 240 pixels right away at the start of the
scanline. I know\!\! That's technically scanline-based. But it's only
for fetching object tiledata, and it's only temporary.
What needs to happen is I need a way to run something like a "mini libco
thread" inside of the main thread, so that the object renderer can run
in parallel with the rest of the PPU, yet not be a hideous abomination
of a state machine, yet also not be horrendously slow as a full libco
thread would be.
I'm envisioning some kind of stackless yielding coroutine. But I'll need
to think through how to design that, given the absence of coroutines
even in C++17.
2017-06-04 03:16:44 +00:00
|
|
|
case 0x0400'0054: screen.io.blendEVY = data.bits(0,4); return;
|
Update to v097r17 release.
byuu says:
Changelog:
- ruby: if DirectSoundCreate fails (no sound device present), return
false from init instead of crashing
- nall: improved edge case return values for
(basename,pathname,dirname,...)
- nall: renamed file_system_object class to inode
- nall: varuint_t replaced with VariadicNatural; which contains
.bit,.bits,.byte ala Natural/Integer
- nall: fixed boolean compilation error on Windows
- WS: popa should not restore SP
- GBA: rewrote the CPU/APU cores to use the .bit,.bits functions;
removed registers.cpp from each
Note that the GBA changes are extremely major. This is about five hours
worth of extremely delicate work. Any slight errors could break
emulation in extremely bad ways. Let's hold off on extensive testing
until the next WIP, after I do the same to the PPU.
So far ... endrift's SOUNDCNT_X I/O test is failing, although that code
didn't change, so clearly I messed up SOUNDCNT_H somehow ...
To compile on Windows:
1. change nall/string/platform.hpp line 47 to
return slice(result, 0, 3);
2. change ruby/video.wgl.cpp line 72 to
auto lock(uint32_t*& data, uint& pitch, uint width, uint height) -> bool {
3. add this line to the very top of hiro/windows/header.cpp:
#define boolean FuckYouMicrosoft
2016-02-23 11:08:44 +00:00
|
|
|
case 0x0400'0055: return;
|
2012-03-31 08:17:36 +00:00
|
|
|
|
2012-03-31 08:14:31 +00:00
|
|
|
}
|
|
|
|
|
}
|