| Mockingboard plays 30+ minutes of music from one floppy [message #364422] |
Mon, 26 February 2018 16:23  |
Vince Weaver
Messages: 136
Registered: April 2013
Karma: 0
|
Senior Member |
|
|
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
|
|
|
|
|
|
|
|
| Re: Mockingboard plays 30+ minutes of music from one floppy [message #364490 is a reply to message #364462] |
Tue, 27 February 2018 10:43  |
Vince Weaver
Messages: 136
Registered: April 2013
Karma: 0
|
Senior Member |
|
|
On 2018-02-27, STYNX <Jonas.Groenhagen@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
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
|
|
|
|
| Re: Mockingboard plays 30+ minutes of music from one floppy [message #364491 is a reply to message #364422] |
Tue, 27 February 2018 10:47 |
Vince Weaver
Messages: 136
Registered: April 2013
Karma: 0
|
Senior Member |
|
|
On 2018-02-26, vince@pianoman.cluster.toy <vince@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,
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
|
|
|
|
|
|
| Re: Mockingboard plays 30+ minutes of music from one floppy [message #364532 is a reply to message #364517] |
Tue, 27 February 2018 19:38 |
Vince Weaver
Messages: 136
Registered: April 2013
Karma: 0
|
Senior Member |
|
|
On 2018-02-27, qkumba <peter.ferrie@gmail.com> wrote:
> 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.
I was thinking about inlining the various sub-functions to see if that
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
|
|
|
|
| Re: Mockingboard plays 30+ minutes of music from one floppy [message #365604 is a reply to message #364422] |
Sat, 24 March 2018 08:27 |
|
|
Originally posted by: Tom Porter
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,
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.
|
|
|
|
| Re: Mockingboard plays 30+ minutes of music from one floppy [message #365660 is a reply to message #365604] |
Sun, 25 March 2018 01:03 |
Vince Weaver
Messages: 136
Registered: April 2013
Karma: 0
|
Senior Member |
|
|
On 2018-03-24, Tom Porter <laseractiveguy@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.
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
|
|
|
|
| Re: Mockingboard plays 30+ minutes of music from one floppy [message #365678 is a reply to message #365660] |
Sun, 25 March 2018 10:38 |
Michael J. Mahon
Messages: 1767
Registered: October 2012
Karma: 0
|
Senior Member |
|
|
<vince@pianoman.cluster.toy> wrote:
> On 2018-03-24, Tom Porter <laseractiveguy@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.
>
> 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
>
390 cycles may seem slow, but that’s actually less than 0.4 milliseconds,
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
|
|
|
|
| Re: Mockingboard plays 30+ minutes of music from one floppy [message #365692 is a reply to message #365678] |
Sun, 25 March 2018 23:05 |
dagz
Messages: 108
Registered: December 2012
Karma: 0
|
Senior Member |
|
|
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..
|
|
|
|
| Re: Mockingboard plays 30+ minutes of music from one floppy [message #365697 is a reply to message #365692] |
Mon, 26 March 2018 00:11 |
Michael J. Mahon
Messages: 1767
Registered: October 2012
Karma: 0
|
Senior Member |
|
|
Dagen Brock <dagenbrock@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
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.
Exactly.
> 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’m glad you found it useful. I first used the analogy to ease my mind
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. ;-)
--
-michael - NadaNet 3.1 and AppleCrate II: http://michaeljmahon.com
|
|
|
|
| Re: Mockingboard plays 30+ minutes of music from one floppy [message #366223 is a reply to message #365660] |
Tue, 10 April 2018 23:15 |
Vince Weaver
Messages: 136
Registered: April 2013
Karma: 0
|
Senior Member |
|
|
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
|
|
|
|
| Re: Mockingboard plays 30+ minutes of music from one floppy [message #366228 is a reply to message #366223] |
Wed, 11 April 2018 02:08 |
|
|
Originally posted by: frank_o_rama
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
|
|
|
|
| Re: Mockingboard plays 30+ minutes of music from one floppy [message #366313 is a reply to message #366228] |
Sat, 14 April 2018 14:51 |
Vince Weaver
Messages: 136
Registered: April 2013
Karma: 0
|
Senior Member |
|
|
On 2018-04-11, frank_o_rama@hotmail.com <frank_o_rama@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
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?
Tried that, I still get the glitch if I manually wait 20ms with WAIT rather
than using the 6522 interrupt.
> Still a problem under slower/half speed playback using interrupts?
I should try that. I have verified that making the writes twice as long
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?
not using video blank at all.
> Does the base audio engine play properly if you disable the video bars
> or extra components?
I've cut things to the bare minimum (no graphics, text, compression, or
disk at all in the program) and still see the glitches.
> bad chips in the mockingboard?
maybe, though both 8913s show the glitch (left/right).
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
|
|
|
|
|
|
|
|
|
|
| Re: Mockingboard plays 30+ minutes of music from one floppy [message #366372 is a reply to message #366324] |
Mon, 16 April 2018 22:11 |
Vince Weaver
Messages: 136
Registered: April 2013
Karma: 0
|
Senior Member |
|
|
On 2018-04-15, frank_o_rama@hotmail.com <frank_o_rama@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
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.
I'm pretty sure there are two 6522s, one for each AY-3-8913.
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
|
|
|
|
| Re: Mockingboard plays 30+ minutes of music from one floppy [message #366420 is a reply to message #366372] |
Tue, 17 April 2018 17:04 |
TomCh
Messages: 242
Registered: November 2012
Karma: 0
|
Senior Member |
|
|
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-Mac ros.a
- see macros SF_UpdateAY and MB_WriteAYRegs
|
|
|
|
| Re: Mockingboard plays 30+ minutes of music from one floppy [message #366451 is a reply to message #366420] |
Wed, 18 April 2018 13:09 |
Jerome Vernet
Messages: 64
Registered: November 2012
Karma: 0
|
Member |
|
|
Le 17/04/2018 à 23:04, TomCh a écrit :
> 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
(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
|
|
|
|
|
|
| Re: Mockingboard with glitchy output [message #368993 is a reply to message #366372] |
Wed, 13 June 2018 23:15 |
Vince Weaver
Messages: 136
Registered: April 2013
Karma: 0
|
Senior Member |
|
|
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/ch iptune_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
|
|
|
|
| Re: Mockingboard with glitchy output [message #369001 is a reply to message #368993] |
Thu, 14 June 2018 12:33 |
Michael J. Mahon
Messages: 1767
Registered: October 2012
Karma: 0
|
Senior Member |
|
|
<vince@pianoman.cluster.toy> wrote:
> 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/ch iptune_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
>
Have you read the 8910 data sheet?
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.
--
-michael - NadaNet 3.1 and AppleCrate II: http://michaeljmahon.com
|
|
|
|
| Re: Mockingboard with glitchy output [message #369044 is a reply to message #368993] |
Sat, 16 June 2018 11:21 |
TomCh
Messages: 242
Registered: November 2012
Karma: 0
|
Senior Member |
|
|
On Thursday, June 14, 2018 at 4:15:27 AM UTC+1, vi...@pianoman.cluster.toy wrote:
> 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/ch iptune_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
Did you try my suggestion? (see comment on 17th April)
Tom
|
|
|
|
| Re: Mockingboard with glitchy output [message #369045 is a reply to message #368993] |
Sat, 16 June 2018 11:29 |
TomCh
Messages: 242
Registered: November 2012
Karma: 0
|
Senior Member |
|
|
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:
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).
>
Correct - there's no AY register read support in AppleWin. I don't plan to support this in AppleWin, unless there's a good use-case for it.
Thanks,
Tom
|
|
|
|
| Re: Mockingboard with glitchy output [message #389401 is a reply to message #368993] |
Sat, 21 December 2019 13:13 |
Vince Weaver
Messages: 136
Registered: April 2013
Karma: 0
|
Senior Member |
|
|
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
|
|
|
|
| Re: Mockingboard with glitchy output [message #389419 is a reply to message #389401] |
Sun, 22 December 2019 18:06 |
TomCh
Messages: 242
Registered: November 2012
Karma: 0
|
Senior Member |
|
|
On Saturday, 21 December 2019 18:13:49 UTC, vi...@pianoman.cluster.toy wrote:
> 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
Thanks for sharing this info.
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
|
|
|
|
Members
Search
Help
Register
Login
Home
