Sound Driver note/frequency mapping about romwbw

[b1ackmai1er]

Hi Dean, Some of those commits may have been my lousy usage of git desktop and the nightmare I have had (created) trying to keep everything in sync! Sorry about that. I've done a git reset so hopefully it will be better. I think I see the mistake I have made ... I am using the AY_CLK = 3579545 (for my EBC-SCG) which is twice what it should be. Working on a fix now. If you have duration code, I think you should submit it. From previous discussion I interpreted it as a decision not to implement a queued sound system like on MSX computer. I'll report back as soon as I think I have a fix. Regards Phil.

…

On Mon, May 25, 2020 at 8:18 PM Dean Netherton ***@***.***> wrote: Hi guys, I just pull the latest code - wow 68 commits - gee - i was only away about a week! Have observed some issues (used my test scripts - and tested on my rig) - not had a chance to fully investigate. I notice there has been some changes for the AY driver's implemention of NOTE. I am not sure i understand, and dont know what configuration i need to adjust to align with my configuration - because now I am out an octave... - it plays an octave lower, than the stated value in the docs. What would be the recommend approach to adjust this? I see the code for AY note configuration has been inlined. If the two drivers need to be different - perhaps the code in audio.inc (which is only used by the SN driver now) needs to be also inlined? I see there is a new function being built - SND_DURATION - a little confused, as I had built code for hanlding a duration model - got quite a ways with it. I didnt raise a PR with this change, as I thought it was decieded that this level of functionality didnt belong in the bios. Perhaps i misunderstood. If you would like me to do any more testing - happy to, but I probably wont have time to do any more testing until the weekend Cheers Dean — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#135>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AJM7HV4CB3AY4XSKGZFIVLLRTJO2BANCNFSM4NJPMG7Q> .

[vipoo]

Hi,

git branch management can be a challenge. I am not sure your process, and apologies if this is of no interest (and the long post) - but If it helps, this is how I do it.

First I only use the cli -- no gui interfaces - but the concept is the same.

After forking a repo on github, and cloning it locally. I setup the upstream remotes on the repo. (github have excellent cli help pages)

https://help.github.com/en/github/collaborating-with-issues-and-pull-requests/configuring-a-remote-for-a-fork

git remote add upstream [email protected]:wwarthen/RomWBW.git
git remote -v # to see your remote urls - typicaly have 2 - origin (my repo) and upstream (Wayne's repo)

These are my remotes:

origin  [email protected]:vipoo/RomWBW.git (fetch)
origin  [email protected]:vipoo/RomWBW.git (push)
upstream        [email protected]:wwarthen/RomWBW.git (fetch)
upstream        [email protected]:wwarthen/RomWBW.git (push)

Then i make sure i have the same branches in my repo - and i never commit to these branches. They are just used to track the official commits.

To get Waynes latest commits - i do (https://help.github.com/en/github/collaborating-with-issues-and-pull-requests/syncing-a-fork)

git fetch upstream
git checkout dev
git merge upstream/dev
git push

This gives me a dev branch reference. As i said, never commit to this branch.

For opensource stuff a feature/PR branch can be very helpful in keeping it simple. When i start a new feature, i do this:

git checkout dev
git checkout -b my-new-feature # create a new brach for my work
git push # push this branch to my repo

Then i work on this branch. When i am ready to do a PR - and this is important, i rebase to the latest dev (I dont merge in changes and create confusing merge commits)

git fetch upstream
git checkout dev
git merge upstream/dev
git push

git checkout feature/my-new-feature
git checkout -b pr/my-new-feature
git rebase master # merge in all upstream changes - fix conflict

ensure my stuff still works!
git push

Now i make a PR from this new branch (pr/my-new-feature).

Cleanup
git checkout dev
git branch -D feature/my-new-feature
git push origin --delete feature/my-new-feature

And when the PR is merged - i can then delete the PR branch.

It helps a lot that these PR branches dont need to live very long - as Wayne seem to very quickly get them merged - I might change my approach if the PR had to sit for a few weeks.

[vipoo]

In regards to the duration stuff - I am not sure I still have the code - i transformed it and applied it directly in the bbcbasic fork i am working on - it works by polling the timer value - there is no HBIOS interrupt signal for just the timer.

Yes my duration code did have a que logic in there - but that could have been removed - (this is kind of a que of just 1 item). The que logic was not complicated - just a little round buffer thing.

I am not sure how you are planning to go with the duration implementation - so maybe i am missing something or making more complicated than need (this happen more often that i would like to admit!)

For a duration, that is a set and forget - that would imply the application would not be able to know when the duration is completed - so would not be able to do anything at the completion of the duration - it would not be able to schedule another command for example - polling might work - but it be complicated i would think.

Also, have to manage the overlapping calls (eg: Schedule started on 1 channel, then application starts note on another channel - with or without duration value) - need to track current schedule channel. Would duration get reset on call to play? -- the vol and period do not get reset on PLAY at the moment?

So for the simple 'beep for 1 second' scenarios this could be handy. But application could also just start a note - wait a second - and stop the note.

When i was building the duration logic, this all starting making me wonder of the boundary between (BIOS, OS and application) - I appreciate its very blurry on these platforms)

I am very new to all this... so i know i need to get more wiser about designing bios/os level stuff.

These are just my ramblings - so feel free to correct me - or just ignore me!

Cheers
Dean

[vipoo]

Given i have less time to work on this - and to avoid creating more merge challenges - I can focus on other coding. But i am happy to help test if you want.

Cheers
Dean

[wwarthen]

That's a pretty slick GitHub management process Dean. It looks a little complicated at first, but I bet it becomes pretty intuitive after getting used to it. My situation is not the same as you guys deal with, but I think I may adopt some of this for certain scenarios of mine.

[wwarthen]

With respect to the duration stuff, I had the impression that there would conceptually be two ways to "play" a sound.

1. Play the sound for the specified duration, stop the sound, then return to the caller. Essentially, a "blocking" call.
2. Start playing the sound and return immediately to the caller. The sound would continue to play until the caller made another call to either stop the sound or switch to a different sound.

A potential variation of #1 would be allowing the caller to specify that the sound is not stopped after the duration elapses. This would allow the caller to make sequential calls with a duration specified without micro gaps in the playback.

The DURATION function call can do all this. I assume a duration of zero would mean return immediately to caller. The only thing I am not sure about is how to specify whether to stop the sound or not after playing for the specified duration.

I think this represents a nice balance between complexity and capability.

Thanks,

Wayne

[b1ackmai1er]

Hi Dean, Thanks for the time and effort to describe your process. I have been using github desktop and only revert to the command line when I get stuck. I have a fork of romwbw on github (master and dev) and then have a copy of that on my pc which I think is called the remote? I do my development on my pc then push the changes to my github fork and then PR that to waynes when I get to a milestone that I am happy with. I have really struggled with the git learning curve and am a bit afraid to experiment in case I screw things up. I commit often because I often find I have coded myself into a mess and want to revert back to an earlier version - it's a good thing coding isn't my day job :) Recently I have found myself in a mess when I PR from Wayne to my github fork while I have unfinished commits on my remote I think I neeed to get my head around rebasing and merge commits. Regards Phil

…

On Tue, May 26, 2020 at 9:58 AM Dean Netherton ***@***.***> wrote: Hi, git branch management can be a challenge. I am not sure your process, and apologies if this is of no interest (and the long post) - but If it helps, this is how I do it. First I only use the cli -- no gui interfaces - but the concept is the same. After forking a repo on github, and cloning it locally. I setup the upstream remotes on the repo. (github have excellent cli help pages) https://help.github.com/en/github/collaborating-with-issues-and-pull-requests/configuring-a-remote-for-a-fork git remote add upstream ***@***.***:wwarthen/RomWBW.git git remote -v # to see your remote urls - typicaly have 2 - origin (my repo) and upstream (Wayne's repo) These are my remotes: origin ***@***.***:vipoo/RomWBW.git (fetch) origin ***@***.***:vipoo/RomWBW.git (push) upstream ***@***.***:wwarthen/RomWBW.git (fetch) upstream ***@***.***:wwarthen/RomWBW.git (push) Then i make sure i have the same branches in my repo - and i *never commit* to these branches. They are just used to track the official commits. To get Waynes latest commits - i do ( https://help.github.com/en/github/collaborating-with-issues-and-pull-requests/syncing-a-fork ) git fetch upstream git checkout dev git merge upstream/dev git push This gives me a dev branch reference. As i said, never commit to this branch. For opensource stuff a feature/PR branch can be very helpful in keeping it simple. When i start a new feature, i do this: git checkout dev git checkout -b my-new-feature # create a new brach for my work git push # push this branch to my repo Then i work on this branch. When i am ready to do a PR - and this is important, i *rebase* to the latest dev (I dont merge in changes and create confusing merge commits) git fetch upstream git checkout dev git merge upstream/dev git push git checkout feature/my-new-feature git checkout -b pr/my-new-feature git rebase master # merge in all upstream changes - fix conflict ensure my stuff still works! git push Now i make a PR from this new branch (pr/my-new-feature). Cleanup git checkout dev git branch -D feature/my-new-feature git push origin --delete feature/my-new-feature And when the PR is merged - i can then delete the PR branch. It helps a lot that these PR branches dont need to live very long - as Wayne seem to very quickly get them merged - I might change my approach if the PR had to sit for a few weeks. — You are receiving this because you were assigned. Reply to this email directly, view it on GitHub <#135 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AJM7HV3GLIBKEPH4BRSWHDDRTMO3XANCNFSM4NJPMG7Q> .

[b1ackmai1er]

Yes this is how I imagined it working as well - I'll have a play and see how it goes.

…

On Tue, May 26, 2020 at 10:43 AM Wayne Warthen ***@***.***> wrote: With respect to the duration stuff, I had the impression that there would conceptually be two ways to "play" a sound. 1. Play the sound for the specified duration, stop the sound, then return to the caller. Essentially, a "blocking" call. 2. Start playing the sound and return immediately to the caller. The sound would continue to play until the caller made another call to either stop the sound or switch to a different sound. A potential variation of #1 <#1> would be allowing the caller to specify that the sound is not stopped after the duration elapses. This would allow the caller to make sequential calls with a duration specified without micro gaps in the playback. The DURATION function call can do all this. I assume a duration of zero would mean return immediately to caller. The only thing I am not sure about is how to specify whether to stop the sound or not after playing for the specified duration. I think this represents a nice balance between complexity and capability. Thanks, Wayne — You are receiving this because you were assigned. Reply to this email directly, view it on GitHub <#135 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AJM7HVZU5ZG3F7UPY2JKWYLRTMUDVANCNFSM4NJPMG7Q> .

[wwarthen]

Some of those commits may have been my lousy usage of git desktop and the nightmare I have had (created) trying to keep everything in sync! Sorry about that. I've done a git reset so hopefully it will be better. I think I see the mistake I have made ... I am using the AY_CLK = 3579545 (for my EBC-SCG) which is twice what it should be. Working on a fix now.

Hi @b1ackmai1er ,

I am trying to close out some long outstanding issues in the GitHub repostory. It sounds like you were working on a fix for this, but I am not clear if it was ever completed. Do you remember?

Thanks,

Wayne

[b1ackmai1er]

HI Wayne, No I broke something but cannot remember what. I will order an RC2014 sound module and work to close this.

Best Wishes Phil

[wwarthen]

No worries. Since it appears to still be an outstanding issue, I will leave the issue open here.

There is no rush to resolve this. In fact, I don't know that it is worth having you order hardware just to work on it. I may try to recreate the issue myself since I do have the appropriate hardware. I'm just not sure I know enough to identify the issue.

Thanks,

Wayne

[b1ackmai1er]

I think in an effort to maintain as much resolution in the fequency table i broke something that resulted in different frequencies between the two platforms. I'll have a look at the last changes I did. Best Wishes Phil

…

On Sun, 24 Oct 2021, 9:08 am Wayne Warthen, ***@***.***> wrote: No worries. Since it appears to still be an outstanding issue, I will leave the issue open here. There is no rush to resolve this. In fact, I don't know that it is worth having you order hardware just to work on it. I may try to recreate the issue myself since I do have the appropriate hardware. I'm just not sure I know enough to identify the issue. Thanks, Wayne — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#135 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AJM7HV4BD3PU3NREH2UCUITUINMBJANCNFSM4NJPMG7Q> . Triage notifications on the go with GitHub Mobile for iOS <https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675> or Android <https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub>.

[lynchaj]

Hi Phillip With these mods is the Z80 MBC able to play simple tunes and/or multiple tones on start up? Like a start up sound more than the start up beep we now have? That would be a nice modification. Play "Daisy" from 2001 when HAL was being deactivated... :-) Thanks, Andrew Lynch On Sunday, October 24, 2021, 04:17:46 AM EDT, b1ackmai1er ***@***.***> wrote: I think in an effort to maintain as much resolution in the fequency table i broke something that resulted in different frequencies between the two platforms. I'll have a look at the last changes I did. Best Wishes Phil

On Sun, 24 Oct 2021, 9:08 am Wayne Warthen, ***@***.***> wrote: No worries. Since it appears to still be an outstanding issue, I will leave the issue open here. There is no rush to resolve this. In fact, I don't know that it is worth having you order hardware just to work on it. I may try to recreate the issue myself since I do have the appropriate hardware. I'm just not sure I know enough to identify the issue. Thanks, Wayne — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#135 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AJM7HV4BD3PU3NREH2UCUITUINMBJANCNFSM4NJPMG7Q> . Triage notifications on the go with GitHub Mobile for iOS <https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675> or Android <https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub>.

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub, or unsubscribe. Triage notifications on the go with GitHub Mobile for iOS or Android.

[wwarthen]

Hi Phillip With these mods is the Z80 MBC able to play simple tunes and/or multiple tones on start up? Like a start up sound more than the start up beep we now have? That would be a nice modification. Play "Daisy" from 2001 when HAL was being deactivated... :-) Thanks, Andrew Lynch

Phil can correct me, but I think that the current speaker driver is able to play a single note for one second. I think you can select the note, but the one second duration is fixed. Since the duration is fixed at one second, I don't think there is any reasonable way to play a "tune".

Thanks, Wayne

[b1ackmai1er]

dun dun dahhhhhh ... Yes Wayne is correct. There is code in Nascom BASIC that has the same code base which could be transplanted into the HBIOS. Regards Phil

…

On Mon, 25 Oct 2021, 4:05 am Wayne Warthen, ***@***.***> wrote: Hi Phillip With these mods is the Z80 MBC able to play simple tunes and/or multiple tones on start up? Like a start up sound more than the start up beep we now have? That would be a nice modification. Play "Daisy" from 2001 when HAL was being deactivated... :-) Thanks, Andrew Lynch Phil can correct me, but I think that the current speaker driver is able to play a single note for one second. I think you can select the note, but the one second duration is fixed. Since the duration is fixed at one second, I don't think there is any reasonable way to play a "tune". Thanks, Wayne — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#135 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AJM7HV5UMDHZ7Q5RHFCECGDUIRRHDANCNFSM4NJPMG7Q> . Triage notifications on the go with GitHub Mobile for iOS <https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675> or Android <https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub>.

[lynchaj]

Hi Phillip & Wayne OK, I must have gotten confused about what you were discussing Thanks, Andrew Lynch On Monday, October 25, 2021, 12:17:25 AM EDT, b1ackmai1er ***@***.***> wrote: dun dun dahhhhhh ... Yes Wayne is correct. There is code in Nascom BASIC that has the same code base which could be transplanted into the HBIOS. Regards Phil

On Mon, 25 Oct 2021, 4:05 am Wayne Warthen, ***@***.***> wrote: Hi Phillip With these mods is the Z80 MBC able to play simple tunes and/or multiple tones on start up? Like a start up sound more than the start up beep we now have? That would be a nice modification. Play "Daisy" from 2001 when HAL was being deactivated... :-) Thanks, Andrew Lynch Phil can correct me, but I think that the current speaker driver is able to play a single note for one second. I think you can select the note, but the one second duration is fixed. Since the duration is fixed at one second, I don't think there is any reasonable way to play a "tune". Thanks, Wayne — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#135 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AJM7HV5UMDHZ7Q5RHFCECGDUIRRHDANCNFSM4NJPMG7Q> . Triage notifications on the go with GitHub Mobile for iOS <https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675> or Android <https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub>.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub, or unsubscribe. Triage notifications on the go with GitHub Mobile for iOS or Android.

[wwarthen]

Ths

[wwarthen]

Have observed some issues (used my test scripts - and tested on my rig) - not had a chance to fully investigate.

I notice there has been some changes for the AY driver's implemention of NOTE.

I am not sure i understand, and dont know what configuration i need to adjust to align with my configuration - because now I am out an octave... - it plays an octave lower, than the stated value in the docs. What would be the recommend approach to adjust this?

I think the off-by-one octave issue with the AY driver has been corrected in commit b2e1294.

-Wayne