Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
Mockingboard plays 30+ minutes of music from one floppy
510 views
Skip to first unread message
vi...@pianoman.cluster.toy
Feb 26, 2018, 4:23:58 PM2/26/18
to
Hello
just posted a new demo, this took a lot longer to get working than I thought.
It's a ym5 chiptune player (though I convert them to an internal format
before playing them). It can play 30+ minutes of the chiptune files from
one 140k disk using only 48k of RAM.
The 48k was the tricky part, as the raw sound data is many times that so
the files have to be decompressed on the fly in chunks using LZ4 and some
careful copying around.
Anyway a video (with rougher sound quality than I'd like) can be found here:
https://www.youtube.com/watch?v=t4xxyrWEeio
A webpage with source code, disk image, and some more technical info
can be found here:
http://www.deater.net/weave/vmwprod/chiptune/
Vince
just posted a new demo, this took a lot longer to get working than I thought.
It's a ym5 chiptune player (though I convert them to an internal format
before playing them). It can play 30+ minutes of the chiptune files from
one 140k disk using only 48k of RAM.
The 48k was the tricky part, as the raw sound data is many times that so
the files have to be decompressed on the fly in chunks using LZ4 and some
careful copying around.
Anyway a video (with rougher sound quality than I'd like) can be found here:
https://www.youtube.com/watch?v=t4xxyrWEeio
A webpage with source code, disk image, and some more technical info
can be found here:
http://www.deater.net/weave/vmwprod/chiptune/
Vince
Antoine Vignau
Feb 27, 2018, 1:45:42 AM2/27/18
to
That is cool, congrats!
av
av
STYNX
Feb 27, 2018, 3:06:49 AM2/27/18
to
Very nice!
Maybe you could collaborate with Marc A. Golombeck to add music to his 3D Demo? The player he would need has to be very efficient.
-Jonas
Maybe you could collaborate with Marc A. Golombeck to add music to his 3D Demo? The player he would need has to be very efficient.
-Jonas
vi...@pianoman.cluster.toy
Feb 27, 2018, 10:43:39 AM2/27/18
to
On 2018-02-27, STYNX <Jonas.Gr...@gmx.de> wrote:
>
> Maybe you could collaborate with Marc A. Golombeck to add music to his
> 3D Demo? The player he would need has to be very efficient.
The whole reason I've been developing this code is because I was testing
>
> Maybe you could collaborate with Marc A. Golombeck to add music to his
> 3D Demo? The player he would need has to be very efficient.
out music routines for my own demo I've been working on.
You can actually get ym5 style music relatively quickly. It's about
1500 cycles or so I think, at 50Hz that's about 7% of the CPU. The problem
is that's for reading raw data, so you only get about 5 seconds of music
per 4k you're willing to dedicate to it (you could probably double that
if you limit your music and pack it more efficiently, i.e. no envelope
effects, merge the fields with empty bits).
Maybe not an issue if you're on a machine with 128k of RAM.
My player code cheats and decompresses on the fly in the background using
up a lot of CPU time. It takes about 700,000 cycles ( .7s ) to decompress
15s of audio using qkumba's LZ4 code. Possibly that can be optimized a bit
(I think that code is optimized for size, not speed).
Vince
vi...@pianoman.cluster.toy
Feb 27, 2018, 10:48:00 AM2/27/18
to
On 2018-02-26, vi...@pianoman.cluster.toy <vi...@pianoman.cluster.toy> wrote:
>
> Anyway a video (with rougher sound quality than I'd like) can be found here:
a note on the sound quality. At first I thought it was my capture setup,
>
> Anyway a video (with rougher sound quality than I'd like) can be found here:
but the problematic music files sound just as bad on a speaker.
It all sounds great in the emulator, and also on my Raspberry-Pi AY-3-8910
card.
So trying to think where the problem would be. It almost sounds like
a few of the channels are quieter than they should be, especially when
there's a lot of bass on the other channels.
I should double check my code to make sure the interrupts aren't taking
too long. If the decompression code doesn't have time to finish running
possibly it would be the R13 data (the envelope generator) that would end up
being programmed weird.
The rasterbars code is the troublemaker here. With them turned off CPU
usage is only 40% but that jumps to an average of at least 80% with them on.
Vince
qkumba
Feb 27, 2018, 2:54:51 PM2/27/18
to
Yes, my LZ4 is optimised for size not speed. I'm guessing that we're losing something ridiculous on the order of 20% performance because of that.
Let me know if it's affecting you significantly enough, and I'll see about making a faster version.
Let me know if it's affecting you significantly enough, and I'll see about making a faster version.
vi...@pianoman.cluster.toy
Feb 27, 2018, 7:38:42 PM2/27/18
to
helped much, but currently the decoding is done in the background so it's
not the limiting factor in this code. To make a difference it would have
to be *a lot* faster, like an order of magnitude faster, because then I
could maybe run the decode from the interrupt handler.
Another thing I was looking into was one of the LZ4 streaming variants, as
that would probably give a better compression ratio but would require a lot
more complicated management of the copy buffer. ym5/Mockingboard audio
compresses by a factor of 10, but only if you interleave the data, which
then makes it a pain to play and to stream, especially in a low-RAM situation.
Vince
Tom Porter
Mar 24, 2018, 8:27:28 AM3/24/18
to
When I replied earlier, I just BS thru a response, and that was because my memory couldn't come up with an answer, even though deep down I knew I had one.
The major problem I believe was that all my early mockingboard software, I was Zeroing out the NOTE registers. What should have been happening if Zeroing out the volumes. After discovering this flaw, a lot of the problems seem to have disappeared... it exhibited low bass'y noise and static on everything but emulator and Plaman's Mock-t. I believe this is the cause. Something to look into if the issue isn't resolved by now.
***I believe you also mentioned poor sound quality in another post...)
....a note on the sound quality. At first I thought it was my capture setup,
The major problem I believe was that all my early mockingboard software, I was Zeroing out the NOTE registers. What should have been happening if Zeroing out the volumes. After discovering this flaw, a lot of the problems seem to have disappeared... it exhibited low bass'y noise and static on everything but emulator and Plaman's Mock-t. I believe this is the cause. Something to look into if the issue isn't resolved by now.
***I believe you also mentioned poor sound quality in another post...)
....a note on the sound quality. At first I thought it was my capture setup,
vi...@pianoman.cluster.toy
Mar 25, 2018, 1:03:46 AM3/25/18
to
On 2018-03-24, Tom Porter <laserac...@gmail.com> wrote:
> The major problem I believe was that all my early mockingboard
> software, I was Zeroing out the NOTE registers. What should have been
> happening if Zeroing out the volumes. After discovering this flaw, a
> lot of the problems seem to have disappeared... it exhibited low
> bass'y noise and static on everything but emulator and Plaman's
> Mock-t. I believe this is the cause. Something to look into if the
> issue isn't resolved by now.
I think the issue is just the time it takes to write the registers.
> The major problem I believe was that all my early mockingboard
> software, I was Zeroing out the NOTE registers. What should have been
> happening if Zeroing out the volumes. After discovering this flaw, a
> lot of the problems seem to have disappeared... it exhibited low
> bass'y noise and static on everything but emulator and Plaman's
> Mock-t. I believe this is the cause. Something to look into if the
> issue isn't resolved by now.
A lot of the fancier YM files, especially with envelope effects, expect
that you can write the registers quickly. On the Apple II at best it's
at least 30 odd cycles per register, worst case with 13 registers that's
390 cycles. If your envelope counter is counting down and you update
the envelope stats it might be running with the old values for many cycles
before all the registers are updated.
In contrast my pi-chiptune player can update all the registers in roughly
8 cycles or so.
And the Atari-ST that some of the YM files runs on were 8MHz 68k machines
and the AY-3-8910 was run at 1.7MHz so likely they were updating faster too.
Now why would it sound better in the emulators? I haven't had a chance
to check but possibly they are batching the register writes together
(rather than trying to be cycle-accurate about it).
I've been meaning to drop a logic analyzer on the hardware to test out
the theory, but I've wasted the last few days trying to figure out how
to get the MMU going on the ARM Cortex-A53 in a pi3.
Vince
Michael J. Mahon
Mar 25, 2018, 10:38:15 AM3/25/18
to
and should be practically inaudible to the human ear if it’s only a delay
between desired sounds.
Consider that updating the envelope 100 times per second is substantially
more frequent than we can hear, and that’s 10,000 cycles apart.
When people play instruments in a group, they are typically a few feet
apart, and the speed of sound in air is about a millisecond per foot.
The thing to think about is the order in which registers are updated. In
the most extreme case, the first update would be to set the volume to zero,
then change frequencies and other parameters, then reset the volume to the
desired level.
The audible perception will be fine as long as loud transients are avoided
by proper update sequencing.
--
-michael - NadaNet 3.1 and AppleCrate II: http://michaeljmahon.com
Dagen Brock
Mar 25, 2018, 11:05:33 PM3/25/18
to
Michael, it sounds like you are might also be intimating that one could also just do fewer envelope updates. Perhaps another strategy is to only do them when the delta is of a certain minimum threshold (smaller envelope changes are even more spread out).
I think the most important thing, as you've already pointed out, is that loud transients are to be avoided.
Also, thanks for illuminating me with the "play[ing] instruments in a group" example. That works lovely for the concept and the timing considerations.
I think the most important thing, as you've already pointed out, is that loud transients are to be avoided.
Also, thanks for illuminating me with the "play[ing] instruments in a group" example. That works lovely for the concept and the timing considerations.
Michael J. Mahon
Mar 26, 2018, 12:11:45 AM3/26/18
to
Dagen Brock <dagen...@gmail.com> wrote:
> Michael, it sounds like you are might also be intimating that one could
> also just do fewer envelope updates. Perhaps another strategy is to only
> do them when the delta is of a certain minimum threshold (smaller
> envelope changes are even more spread out).
The frequency of envelope updates depends upon the relative change in
> Michael, it sounds like you are might also be intimating that one could
> also just do fewer envelope updates. Perhaps another strategy is to only
> do them when the delta is of a certain minimum threshold (smaller
> envelope changes are even more spread out).
intensity of the sound.
A good strategy would be to update only when the intensity change exceeds a
certain relative amount.
> I think the most important thing, as you've already pointed out, is that
> loud transients are to be avoided.
> Also, thanks for illuminating me with the "play[ing] instruments in a
> group" example. That works lovely for the concept and the timing considerations.
about millisecond level timing drifts between Applecrate boards. When I
realized the drift would be inaudible, it allowed me to avoid
resynchronization for songs of a few minutes duration. ;-)
vi...@pianoman.cluster.toy
Apr 10, 2018, 11:15:42 PM4/10/18
to
So I'm still tracking the issue where the sound from my Mockingboard sounds
wrong with some ym5 files. It's been super frustrating.
I've stuck a summary here for anyone interested.
http://www.deater.net/weave/vmwprod/chiptune/mock_problem/
The audio just drops off to nothing at seemingly random (but usually
reproducible) intervals. I've used a debugger on the code and it seems
to be writing the correct values. I've dropped a logic analyzer on
the AY-3-8913 chip and as far as I can tell it's getting the proper
signals.
It's a very strange problem. I have a few more things I plan to try,
but it's annoying because I'm now convinced the Mockingboard should
play these songs properly and there must be something I'm doing wrong
somewhere causing it not to work.
Vince
wrong with some ym5 files. It's been super frustrating.
I've stuck a summary here for anyone interested.
http://www.deater.net/weave/vmwprod/chiptune/mock_problem/
The audio just drops off to nothing at seemingly random (but usually
reproducible) intervals. I've used a debugger on the code and it seems
to be writing the correct values. I've dropped a logic analyzer on
the AY-3-8913 chip and as far as I can tell it's getting the proper
signals.
It's a very strange problem. I have a few more things I plan to try,
but it's annoying because I'm now convinced the Mockingboard should
play these songs properly and there must be something I'm doing wrong
somewhere causing it not to work.
Vince
frank_...@hotmail.com
Apr 11, 2018, 2:08:53 AM4/11/18
to
Not sure, but here's a couple thoughts:
What if you just write one channel, and skip writing the others? Any glitch?
What if you turn off the mockingboard interrupts and use a soft delay instead?
Still a problem under slower/half speed playback using interrupts?
Is your video code waiting for vertical blank, that may be overlapping with the interrupts?
Does the base audio engine play properly if you disable the video bars or extra components?
bad chips in the mockingboard?
????
F
vi...@pianoman.cluster.toy
Apr 14, 2018, 2:51:14 PM4/14/18
to
On 2018-04-11, frank_...@hotmail.com <frank_...@hotmail.com> wrote:
> What if you just write one channel, and skip writing the others? Any glitch?
I should try that next, but I definitely see a glitch in a string of writes
> What if you just write one channel, and skip writing the others? Any glitch?
that are only changing the Channel C fine register. There might be a stray
Channel A write, I will have to check that.
> What if you turn off the mockingboard interrupts and use a soft delay instead?
than using the 6522 interrupt.
> Still a problem under slower/half speed playback using interrupts?
doesn't help, but I didn't try running things at 25Hz.
> Is your video code waiting for vertical blank, that may be overlapping
> with the interrupts?
> Does the base audio engine play properly if you disable the video bars
> or extra components?
disk at all in the program) and still see the glitches.
> bad chips in the mockingboard?
Other things I should check, maybe dropping a scope on the power line?
Could a power sag be resetting the chip?
I'm also routing the audio cable through the case and out near the power
supply, I guess it's not just noise on the line.
This is driving me nuts, especially as only some songs seem to be affected.
Vince
James Davis
Apr 14, 2018, 8:05:22 PM4/14/18
to
Could this be Harmonic Interference? IIRC, there is such a thing, right? MJM?
Michael J. Mahon
Apr 14, 2018, 10:26:44 PM4/14/18
to
James Davis <JPD.Ent...@outlook.com> wrote:
> Could this be Harmonic Interference? IIRC, there is such a thing, right? MJM?
>
I’m not familiar with that term.
> Could this be Harmonic Interference? IIRC, there is such a thing, right? MJM?
>
I’d bet it’s just a software bug, most likely a result of not reading the
AY-3-8913 data sheet carefully.
For example, is it proper just to write to a fine frequency register while
the oscillator is running?
frank_...@hotmail.com
Apr 14, 2018, 11:58:42 PM4/14/18
to
I tried this out on my //e the other night and didn't notice any dropouts. Which songs have this issue?
The 6522 feeds both audio generators so if it's hardware that could be what's not working.
F
The 6522 feeds both audio generators so if it's hardware that could be what's not working.
F
vi...@pianoman.cluster.toy
Apr 16, 2018, 10:11:43 PM4/16/18
to
On 2018-04-15, frank_...@hotmail.com <frank_...@hotmail.com> wrote:
> I tried this out on my //e the other night and didn't notice any
> dropouts. Which songs have this issue?
It's most noticable on SDEMO and DEMO4. With SDEMO (At least on my
> I tried this out on my //e the other night and didn't notice any
> dropouts. Which songs have this issue?
hardware) it appears in the first few seconds of playing.
I notice the dropouts easily because I usually listen to the sound files
on my pi-chiptune player which plays things properly.
> The 6522 feeds both audio generators so if it's hardware that could be
> what's not working.
So they'd both have to be failing in the same way. My logic analyzer
traces are after the 6522, directly on the AY pins and the signals
being fed into the AY look reasonable.
Vince
TomCh
Apr 17, 2018, 5:04:53 PM4/17/18
to
Hi Vince,
I tried the link to your source code (from the webpage):
•Full 6502 assembly code available in the git repository. You'll need cc65 to build it.
https://github.com/deater/dos33fsprogs/chiptune
...but this github link just returns a 404 error.
Ah, I think you may've renamed it:
https://github.com/deater/dos33fsprogs/tree/master/chiptune_player
IIRC (10+ years, when I did the Cybernoid player(*)) I switched from "fast" 6522/AY8910 update routine like yours (using ABS addressing) to a slower routine (using ABS,X), copying what Skyfox did.
I was developing on AppleWin, but did this because I got reports from people with real Mockingboard h/w that the tunes were "noisy".
The versions.txt that I shipped included this notes:
"v3: 04/03/2006 - Use Skyfox's routine to update AY regs"
I'll have to check old code zips for the exact code that was problematic.
NB. I do have real MB h/w now, but haven't tried rebuilding & testing with the older (pre-Skyfox routine).
Perhaps the extra cycle for doing the ABS,X is needed?
Also my routine does a JSR per select & write: adding more delays.
Can you try swapping out your update-AY code for mine.
Tom
(*) https://github.com/tomcw/Cybernoid/blob/master/Common/MB-Macros.a
- see macros SF_UpdateAY and MB_WriteAYRegs
I tried the link to your source code (from the webpage):
•Full 6502 assembly code available in the git repository. You'll need cc65 to build it.
https://github.com/deater/dos33fsprogs/chiptune
...but this github link just returns a 404 error.
Ah, I think you may've renamed it:
https://github.com/deater/dos33fsprogs/tree/master/chiptune_player
IIRC (10+ years, when I did the Cybernoid player(*)) I switched from "fast" 6522/AY8910 update routine like yours (using ABS addressing) to a slower routine (using ABS,X), copying what Skyfox did.
I was developing on AppleWin, but did this because I got reports from people with real Mockingboard h/w that the tunes were "noisy".
The versions.txt that I shipped included this notes:
"v3: 04/03/2006 - Use Skyfox's routine to update AY regs"
I'll have to check old code zips for the exact code that was problematic.
NB. I do have real MB h/w now, but haven't tried rebuilding & testing with the older (pre-Skyfox routine).
Perhaps the extra cycle for doing the ABS,X is needed?
Also my routine does a JSR per select & write: adding more delays.
Can you try swapping out your update-AY code for mine.
Tom
(*) https://github.com/tomcw/Cybernoid/blob/master/Common/MB-Macros.a
- see macros SF_UpdateAY and MB_WriteAYRegs
Jerome Vernet
Apr 18, 2018, 1:09:07 PM4/18/18
to
Le 17/04/2018 à 23:04, TomCh a écrit :
> Hi Vince,
>
Wow. I missed this music disk ! I love it !
(original one). I need to test this disk on my IIe.
Some said that's because I have a ZIPChip (even running at 1Mhz, sound
is bad).
But anything else sound well on it.
JV
> Hi Vince,
>
Wow. I missed this music disk ! I love it !
>
> I was developing on AppleWin, but did this because I got reports from people with real Mockingboard h/w that the tunes were "noisy".
It's the same with French Touch Music Disk (NSCT, etc), with my MB
> I was developing on AppleWin, but did this because I got reports from people with real Mockingboard h/w that the tunes were "noisy".
(original one). I need to test this disk on my IIe.
Some said that's because I have a ZIPChip (even running at 1Mhz, sound
is bad).
But anything else sound well on it.
JV
Matthew Power
Apr 29, 2018, 2:32:24 PM4/29/18
to
This is awesome! My Apple II is rocking out! I play this disk when I'm cleaning the house. More, please!!...
vi...@pianoman.cluster.toy
Jun 13, 2018, 11:15:27 PM6/13/18
to
so you might recall I have been fighting an issue where my Mockingboard
hardware has really glitchy sound under some situations.
I spent some more time trying to narrow it down. I suspect it might
be the AY-3-8913 chips themselves.
The simplest test case that shows the problem is to enable only Channel C,
and then to repeatedly write $51,$3C to the register with a 20ms pause
in between. Often (and possibly always) after a power-of-two number of
repititions on the 51 to 3C transition a 30ms or so glitch occurs.
Other values will also trigger a glitch (or a more worrying similar one
where the volume drops, I've possibly seen this on my Pi chiptune player).
Sending a single tone, for example writing $51 repeatedly never triggers
the problem, only if different values are written.
Earlier in this batch of testing I thought it might be the 6522 chips.
Maybe the handshaking, as on the Mockingboard the PA1 line is pulled
high but PB1 is left floating. I tried tying PB1 to 5V, no change.
I also read out the interrupt registers to make sure they were set right.
Applewin reports IER wrong ($80 instead of $C0) for what it's worth.
I then thought maybe, despite my earlier logic probe readings, that the
AY-3-8913s were getting set wrong. So after writing I immediately read
out the values and compared them. The values always match the expected
ones.
(On real hardware at least, Applewin and MAME both don't seem to support
reading values out of the AY chips through the 6522).
Anyway I'm nearly about giving up on this. I ordered some AY-3-8913 chips
to try swapping out (I only have 8910 and 8912 spares).
Does anyone else see this issue on their Mockingboard?
You can try downloading the disk image from here:
http://www.deater.net/weave/vmwprod/chiptune/mock_problem/chiptune_debug.dsk
and BRUN CHIPTUNE_TINY and see. Maybe listen in an emulator first to
hear the expected noise, then listen (or even better, capture with
something like audacity) and see if it glitches.
Anyway a full rundown of the stuff I've tested is here:
http://www.deater.net/weave/vmwprod/chiptune/mock_problem/
Vince
hardware has really glitchy sound under some situations.
I spent some more time trying to narrow it down. I suspect it might
be the AY-3-8913 chips themselves.
The simplest test case that shows the problem is to enable only Channel C,
and then to repeatedly write $51,$3C to the register with a 20ms pause
in between. Often (and possibly always) after a power-of-two number of
repititions on the 51 to 3C transition a 30ms or so glitch occurs.
Other values will also trigger a glitch (or a more worrying similar one
where the volume drops, I've possibly seen this on my Pi chiptune player).
Sending a single tone, for example writing $51 repeatedly never triggers
the problem, only if different values are written.
Earlier in this batch of testing I thought it might be the 6522 chips.
Maybe the handshaking, as on the Mockingboard the PA1 line is pulled
high but PB1 is left floating. I tried tying PB1 to 5V, no change.
I also read out the interrupt registers to make sure they were set right.
Applewin reports IER wrong ($80 instead of $C0) for what it's worth.
I then thought maybe, despite my earlier logic probe readings, that the
AY-3-8913s were getting set wrong. So after writing I immediately read
out the values and compared them. The values always match the expected
ones.
(On real hardware at least, Applewin and MAME both don't seem to support
reading values out of the AY chips through the 6522).
Anyway I'm nearly about giving up on this. I ordered some AY-3-8913 chips
to try swapping out (I only have 8910 and 8912 spares).
Does anyone else see this issue on their Mockingboard?
You can try downloading the disk image from here:
http://www.deater.net/weave/vmwprod/chiptune/mock_problem/chiptune_debug.dsk
and BRUN CHIPTUNE_TINY and see. Maybe listen in an emulator first to
hear the expected noise, then listen (or even better, capture with
something like audacity) and see if it glitches.
Anyway a full rundown of the stuff I've tested is here:
http://www.deater.net/weave/vmwprod/chiptune/mock_problem/
Vince
Michael J. Mahon
Jun 14, 2018, 12:33:59 PM6/14/18
to
The registers need to be set in a proper sequence and, for multibyte
quantities, with little delay between writes if glitches are to be avoided.
TomCh
Jun 16, 2018, 11:21:52 AM6/16/18
to
Tom
TomCh
Jun 16, 2018, 11:29:54 AM6/16/18
to
On Thursday, June 14, 2018 at 4:15:27 AM UTC+1, vi...@pianoman.cluster.toy wrote:
> I also read out the interrupt registers to make sure they were set right.
> Applewin reports IER wrong ($80 instead of $C0) for what it's worth.
>
Yes, it's a bug - it always reads as 0x80. I've raised a GitHub issue for this:
> Applewin reports IER wrong ($80 instead of $C0) for what it's worth.
>
https://github.com/AppleWin/AppleWin/issues/567
>
> I then thought maybe, despite my earlier logic probe readings, that the
> AY-3-8913s were getting set wrong. So after writing I immediately read
> out the values and compared them. The values always match the expected
> ones.
> (On real hardware at least, Applewin and MAME both don't seem to support
> reading values out of the AY chips through the 6522).
>
Thanks,
Tom
vi...@pianoman.cluster.toy
Dec 21, 2019, 1:13:49 PM12/21/19
to
so I *finally* figured out the glitchy Mockingboard sound issue.
I've re-released many of my programs to fix things, in case you have
older versions (this includes the pt3 player, chiptune player, various
demos).
I kept overlooking this, but the AY-3-8910 datasheet says when you write
a value the maximum hold time of the write line is 10,000ns (10us).
With a 1MHz 6502 that's only roughly 10 clock cycles, which isn't
very long. My code was taking 12 cycles to do this (for various reasons).
I changed the code to only take 8 cycles and now everything sounds
much much better.
Vince
I've re-released many of my programs to fix things, in case you have
older versions (this includes the pt3 player, chiptune player, various
demos).
I kept overlooking this, but the AY-3-8910 datasheet says when you write
a value the maximum hold time of the write line is 10,000ns (10us).
With a 1MHz 6502 that's only roughly 10 clock cycles, which isn't
very long. My code was taking 12 cycles to do this (for various reasons).
I changed the code to only take 8 cycles and now everything sounds
much much better.
Vince
TomCh
Dec 22, 2019, 6:06:34 PM12/22/19
to
I checked your code fix, and I too made the same error (in 2006), but "blindly" fixed it in a later release that year. So this clears up a ~13 year mystery (for me at least).
It would be neat if emulators could trap and warn us about this kind of out-of-spec implementation :-)
Tom
0 new messages