| Age | Commit message (Collapse) | Author |
|---|
|
|
|
|
|
regression from previous commits; better handling
|
|
Timing is not as good as it needs to be,
but servicable in more forgiving scenarios.
Clock drift between two paired systems sits
around 8 - 32 cycles when tested locally.
|
|
The y offset used for windows is not based on LY
but another internal window counter that is incremented
alongside LY but only when the window is on screen. This
fixes an issue with the dmg-acid2 and cgb-acid2 test roms.
https://github.com/mattcurrie/dmg-acid2
https://gbdev.io/pandocs/Tile_Maps.html#window
|
|
|
|
|
|
|
|
this pushes all responsibility for timing to opl3, absolving
dmid(1) and other writers from constantly sending sync
events to force opl3 to synthesize audio in between events.
it reduces cpu usage and syscalls dramatically and enables
applications other than dmid(1) to modify its state in real
time, for instance to use it as a synth.
|
|
|
|
akai mpk mini 2 and similar midi pianos: this is a nice
way to select opl3 banks 0-127 using a knob, while the
pads are mapped to percussions on channel 9
|
|
|
|
same as 89c60481afd8307f7825281bd561995f83a7bfb2.
|
|
if tempo changes while older events are in flight at different
timings in a multitrack file, and since there's no compensation
for it, tracks desyncronise, the order of events get jumbled up
and everything just falls apart.
rather than doing dances with the old code to figure out what
corrective factor to apply and where, just use the simplest and
most robust way, advance one tic at a time.
also add a tracing mode and don't always print useless and
annoying warnings.
|
|
fixes streaming, doesn't really affect performance elsewhere
|
|
makes very large/detailed maps work; raising max intercepts and
spechits may break demos and cause desynchronizations, so they're left
alone despite their potential issues; savegame buffer overflows can
happen for stupidly huge maps with tons of entities
|
|
use all mouse deltas during a tic instead of just the last one, to
prevent extremely annoying stutters and jumps in mouse movement;
adjust filtering/sensitivity, without additional knobs
|
|
side-bonus: fullscreen 1920x1200 working perfectly on t61p :)
|
|
one can still play with just the mouse via m_forward, there's no
longer any need for a button to move forward
|
|
|
|
implement use_mouse
|
|
|
|
MBC3 write switches on a>>13, so the RTC register is 5 (0xA000-0xBFFF).
Mask off upper bits of DH register when updating the timer. Only the
lowest bit is part of the day counter.
Use uint for x in timerforward() so that we don't set negative values
for timer registers if it happens to overflow.
Update timer and then latch rather than the other way around.
Otherwise, timer remains static and will overflow after 512 days.
|
|
Some gba cartridges use flash chips produced by a few different
manufacturers for backup memory. A game rom may then try to read the
device id for its flash chip and break if it's the wrong one. There's
no way for us to know which chip is supposed to be there, save for
looking it up in some database. These chips are either 64k or 128k
big. gba(1) hardcodes the id for the SST 64k chip, but games like the
Pokémon ones use a 128k Macronix chip and expect a different id,
completely breaking them.
This patch sets a different default for 128k flash backups, and gives
the ability to set the exact type when creating the save file if it's
really necessary. This new default fixes the Pokémons. The type is
saved in the save file, but this will *not* break existing ones. It
may be that we don't need to worry about the type and just have an id
that corresponds to the right chip size, which is why these defaults
make sense, but I haven't tested more than a dozen roms, mostly since
I don't really know which games use 128k flash.
|
|
remove old /sys/src/games/nes/joynes in favor of joy(1).
joy(1) has more buttons for the other emulators; there is
no longer a significance in the order of the keys.
document nusb/joy, add information in each emulator manpage.
|
|
|
|
games/dmid uses the same sample rate as the chip for music, but other
applications do not. opl3 and its older version opl2 (not in 9front)
read an input stream of commands in basically IMF format, something
used in other id Software games and some others, which assumes a
given input sampling rate: 700 Hz for Wolfenstein 3D music, 560 Hz
for Commander Keen, 60 Hz for Ultima 6, etc.
The opl3 emulation on the other hand is not really intended to run at
a sampling rate different that the chip's 49.716 kHz sampling rate.
Previously, we assumed it runs at 44.1 kHz and just used the input
rate as a divisor to get the number of samples per delay tic.
From what I understand, the correct way to use it for accurate
emulation is to run the opl chip emulator at its intended sampling
frequency, then downsample to 44.1 kHz. This means better output
but more code. The alternative is to basically do the same as
before rev 8433, except with no buffering, but at accuracy/quality
loss. This change implements the former and just forks pcmconv to
deal with resampling.
|
|
this fixes real-time applications.
-n previously specified a rate divisor rather than the rate itself,
which was used for specific applications outside of 9front. instead,
just set the rate directly, more useful and straightforward.
|
|
|
|
|
|
kemal)
i have found one bug. when i put glenda in a position like this
i somehow win, but the glenda can escape from there.
in addition, i have changed the games manpage to include more info about glendy.
|
|
This is noticeably better than nearest-neighbor.
|
|
|
|
|
|
I'm not sure if this LFSR is the same one used by the hardware or is
arbitrary, but it matches the noise sequence used by all other snes
emulators I looked at.
|
|
s1 and s2 should store the last and next to last output, but were set
in the wrong order, causing them both to be the last output. This
breaks filters 2 and 3, which both utilize s2.
|
|
The high bits correspond to the left channel, and the low bits to the
right channel.
Reference: https://gbdev.io/pandocs/#sound-control-registers
Tested with pokemon crystal.
|
|
H-blank DMA should only transfer 16 bytes per h-blank, rather than
waiting for the first h-blank and then transferring the whole size.
HDMAC should read 0xff when the transfer is finished, and 0 in the
high bit when the transfer is ongoing. Also, if 0 is written in the
high bit, the current transfer should be aborted.
Introduce two flags, DMAREADY and DMAHBLANK rather than special
constants 1 and -1. If dma is non-zero, there is an ongoing DMA. If
DMAREADY is set, the next chunk is ready to transfer.
Reference: https://gbdev.io/pandocs/#ff55-hdma5-cgb-mode-only-new-dma-length-mode-start
Tested with pokemon crystal.
What was happening is that when the game was loading N background tiles
into vram (each 16 bytes, so one per h-blank), it did something like
this:
- start an hdma transfer for N+1 tiles
- after the Nth tile is transferred, it would read HDMA5, clear the
high bit, then write it back to abort the transfer.
games/gb would instead transfer all N+1 tiles at once, overwriting one
extra tile with whatever was 1 past the end of the source array, and
then would interpret the cancel request as the start of a new transfer
of 16 bytes, which would copy an additional tile past the end. The end
result is that every transfer would end up copying N+2 tiles instead
of just N, overwriting certain tiles with whatever was after the end
of the source data.
|
|
According to [0], input clock 0 should divide by 1024=2¹⁰, not 2¹².
This caused audio to run at quarter-speed in one game I tried.
[0] https://gbdev.io/pandocs/#ff07-tac-timer-control-r-w
Tested with zelda: oracle of seasons, and dr. mario
---
|
|
|
|
MIX shift instructions shift by bytes not bits.
|
|
Plan 9 memcpy(2) uses the same implementation as memmove(2) to handle
overlapping ranges. Hovewer, the MIX MOVE instruction, as described
in TAOCP, specifically does not do this. It copies words one at a
time starting from the lowest address.
This change also expands the address validation to check that all
addresses within the source and destination ranges are valid before
proceeding.
|
|
|
|
It seems like on amd64, we're overflowing the stack.
Let's not do that.
|
|
The mount() and bind() syscalls return -1 on error,
and the mountid sequence number on success.
The manpage states that the mountid sequence number
is a positive integer, but the kernels implementation
currently uses a unsigned 32-bit integer and does not
guarantee that the mountid will not become negative.
Most code just cares about the error, so test for
the -1 error value only.
|
|
|
|
|
|
drawn
|
|
|
|
|
