Commit graph

9777 commits

Author SHA1 Message Date
tildearrow
4c166b9b5a move blip_buf to extern
so it can be used by other cores
2025-03-06 12:07:28 -05:00
tildearrow
2078949093 Amiga: tweak the filters once again 2025-03-06 02:00:07 -05:00
tildearrow
abaea665af GUI: find/replace selection in selected channels
issue #2393
2025-03-05 19:27:15 -05:00
tildearrow
43891b8d79 PCE: optimize 5ms 2025-03-05 19:07:10 -05:00
tildearrow
68a550a419 update the acquireDirect API
size_t offset is no more - it is always 0
2025-03-05 18:57:17 -05:00
tildearrow
bc9dd4c2e7 aaaaaa 2025-03-05 18:33:51 -05:00
tildearrow
efaf0a15e7 remove instructions for standalone MinGW 2025-03-05 18:18:03 -05:00
tildearrow
a1d191634d more updates including troubleshooting section 2025-03-05 18:15:39 -05:00
tildearrow
97a83a0b55 update compilation guide 2025-03-05 16:39:11 -05:00
tildearrow
e9604aa0b7 update contributing.md 2025-03-05 15:26:50 -05:00
tildearrow
ec451cd80e Amiga: acquireDirect, part 3 2025-03-05 15:26:17 -05:00
tildearrow
69a43a70fc Amiga: improve filter calc 2025-03-05 05:40:39 -05:00
tildearrow
e941dfb174 Amiga: acquireDirect, part 2
the filter is back!
2025-03-05 04:49:22 -05:00
tildearrow
e116f2e523 PCE: fix anti-click 2025-03-05 00:17:09 -05:00
tildearrow
e5fe291c33 Merge branch 'master' into amigaOpt 2025-03-04 13:53:16 -05:00
tildearrow
ccfa46f833 use Momo by default on Windows
because intl/iconv are dynamic libraries on MSYS2 D:
2025-03-04 13:52:31 -05:00
tildearrow
655b3621f6 Merge branch 'master' into amigaOpt 2025-03-04 13:18:07 -05:00
tildearrow
6e40a6980b PCE: fix chan osc!
ready to merge...
2025-03-04 12:57:59 -05:00
tildearrow
ac8df480ab PCE: half working channel osc
it doesn't look right
2025-03-04 12:37:31 -05:00
tildearrow
11c99f9f96 PCE: push it even further!
now a bit faster
2025-03-04 12:21:56 -05:00
tildearrow
ec5aafb9ad PCE: PCM works
CPU usage increases though when it's in use :<
2025-03-04 12:19:46 -05:00
tildearrow
5d3a22a502 PCE: PCM might work again 2025-03-04 11:57:41 -05:00
tildearrow
f0a3e3f590 PCE: Mednafen is wonderful
the PSG emulator already comes with heuristics... I stripped them off
for Furnace but now that we have acquireDirect() we can give it our
blip_buf and handle everything there

from 40-70% to 10% CPU usage on my phone, and highest quality!

TODO:
- PCM
- chan osc (should be very easy)
2025-03-03 20:29:34 -05:00
tildearrow
95b1085aed I have no idea what's going on 2025-03-03 17:18:52 -05:00
tildearrow
acdce2c795 Amiga: acquireDirect, part 1
filter no longer works... I'll think of a possible approach
2025-03-03 04:11:01 -05:00
tildearrow
f5589d0084 Amiga: increase DMA off delay 2025-03-03 02:32:11 -05:00
tildearrow
71ac185cbf FDS: lower CPU usage 2025-03-03 02:27:00 -05:00
tildearrow
b3b50bdb66 ESFM: optimize osc buf 2025-03-03 01:45:42 -05:00
tildearrow
cf4807b5d0 optimize putSample a bit
use 16-bit precision even on 64-bit....
this allows some code optimizations
2025-03-03 00:51:47 -05:00
tildearrow
2926fad77e ASHA SDGFHJKLADG F;LHKJ 2025-03-02 23:18:02 -05:00
tildearrow
6f8da93714 size_t 2025-03-02 23:04:48 -05:00
tildearrow
8dcbd0fe1c Merge branch 'ga20opt' 2025-03-02 20:53:53 -05:00
tildearrow
f39039766e possibly fix build. 2025-03-02 20:49:10 -05:00
tildearrow
6d55c8088c GA20: yaaaay I fixed chan osc 2025-03-02 20:41:34 -05:00
tildearrow
8f54445625 GA20: acquireDirect optimizations, part 1
buggy, slow and glitchy
output is good but chan osc is now broken

from 1.5 to 0.4 seconds
2025-03-02 20:29:28 -05:00
tildearrow
2c75555fae GA20: excellent... 2025-03-02 19:34:52 -05:00
tildearrow
f13824525a MORE NOTES FOR NEW OSC BUFFER API
in your init or setFlags function,
instead of `oscBuf[i]->rate=rate;` do `oscBuf[i]->setRate(rate)`. this is necessary as it sets the appropriate needle multiplier for it to remain 65536Hz.

if your dispatch submits to the osc buffers at a slower rate (check out nes.cpp for an example), do not divide the rate anymore. it will work regardless.

this ends the notes (hopefully)
2025-03-02 18:56:11 -05:00
tildearrow
cf86b9ab9a Merge branch 'newChanOsc' - read for info
copy-paste from Discord

the new DivDispatch::acquireDirect() function allows optimizing emulation cores by only rendering what is needed (such as state changes in PC Speaker).
it gives DivDispatch direct access to blip_buf structures in order to allow that.

however, this requires changes to the chan osc buffer API since we're not gonna fill entire bufs anymore with acquireDirect

the accommodations consist of:
- new functions to fill a chan osc buffer
- the sample `-1` means "no changes" (don't worry, the new funcs will handle this for you), and
- all chan osc bufs now run at 65536Hz (as opposed to a rate defined by the dispatch). this also avoids buffer overruns and maybe glitches when audio buf size is too large.

if you've been working on a DivDispatch (in other words, a new chip or system), make sure to adapt your code to the new API. here are some guidelines:
1. in your acquire() function, call begin(len) of all DivDispatchOscBuffers before you run emu code and fill the out buffer.
2. replace `oscBuf[]->data[oscBuf[]->needle++]=val` with `oscBuf[]->putSample(h,val)`. `h` is the position of the buffer iterator (e.g. in the `for (size_t h=0; h<len; h++)` function). yes, this API is positional...
3. after emulation code runs and you fill the out buf (including all osc bufs), call end(len). this will advance the needle and all.

here's some sample code.

```
int DivPlatformDango::acquire(short** buf, size_t len) {
  for (size_t h=0; h<len; h++) {
    buf[0][h]=dango.tick();
    for (int i=0; i<16; i++) {
      oscBuf[i]->data[oscBuf[i]->needle++]=dango.getChOut(i);
    }
  }
}
```

```
int DivPlatformDango::acquire(short** buf, size_t len) {
  for (int i=0; i<16; i++) {
    oscBuf[i]->begin(len);
  }
  for (size_t h=0; h<len; h++) {
    buf[0][h]=dango.tick();
    for (int i=0; i<16; i++) {
      oscBuf[i]->putSample(h,dango.getChOut(i));
    }
  }
  for (int i=0; i<16; i++) {
    oscBuf[i]->end(len);
  }
}
```

thanks and sorry for any trouble this may cause
i kept running into the character limit
2025-03-02 18:52:01 -05:00
tildearrow
6813c30e3a new chan osc, part 8
fix remaining bugs
2025-03-02 18:02:38 -05:00
tildearrow
49a8693dcb new chan osc, part 7
i am done
2025-03-02 16:14:49 -05:00
tildearrow
6265d2cd39 new chan osc, part 6
more adaptations

how can I get you out of my head... I want to go back to work!
2025-03-02 04:11:10 -05:00
tildearrow
fe00ee805d new chan osc, part 5
fix C64 rate
2025-03-01 19:57:16 -05:00
tildearrow
a16d20e190 new chan osc, part 4
adapt dispatch code to it
2025-03-01 19:49:56 -05:00
tildearrow
c0e4552c52 new chan osc, part 3
fix the jerkiness!
2025-03-01 18:46:11 -05:00
tildearrow
10e60ec8c1 new chan osc, part 2
why is it jerky?
2025-03-01 17:22:34 -05:00
tildearrow
6dc4f16689 GUI: add an audio load chart 2025-03-01 06:10:59 -05:00
tildearrow
dd7e1def3d new chan osc work in progress 2025-03-01 05:05:50 -05:00
tildearrow
0eea0ec139 a new method for setting chan osc rate... 2025-03-01 00:33:15 -05:00
LionHeartChiptuner
8bfb174b4f
2 Demos (#2390)
* Add files via upload

* Delete demos/c64/UnreeealSuperhero3.fur
2025-03-01 00:07:58 -05:00
tildearrow
c83ecfe993 prepare new chan osc code
chan osc output will be 65536Hz - always
new functions for initializing the osc buffer and all
2025-02-26 20:29:13 -05:00