| |
Frantic
Registered: Mar 2003
Posts: 1661 |
Configurable addresses in multi sid tunes please
Hi guys!
If you want to make a fellow scener a tiny bit happier than he already is:
In multi sid tunes (2 sid chips or more) it would be super nice if more people started to add the possibility to configure the adress of the extra sid chips before the tune starts playing. After all, if you play multi sid tunes on a real machine it may not be easy to change the addressing of the extra sids you have. Sometimes there are jumpers which allow a bit of configuration (such as switching between de00 and df00, or between d4xx/d5xx or something). However, in many cases the configuration options are limited. For example, in my 3sid-machine, the sid chips are located at $d400, $d420 and $d500 and that's that. I can't change it. No jumpers or stuff like that. :)
I understand that most people use VICE or various cross platform music editors, or emulated+configurable "sid chips" like the ones in the 1541U2, when they deal with multi sid stuff, but still.. the real machine with real hardware sid chips is always the main target, right? ;)
Thanks in advance! ;) |
|
... 36 posts hidden. Click here to view all posts....
|
| |
FunFun
Registered: Dec 2018
Posts: 5 |
So you want to able to change the second SID address in in the cheescutter player and goattracker player.
Looking at the goattracker the second sid is hardcoded in the player, you could scan for known sequences and patch the .sid file.
It should be possible to identify the player and modify SIDplay64 to be able to patch the .sid file. |
| |
ChristopherJam
Registered: Aug 2004
Posts: 1424 |
The idea is to modify all of the multi sid players to get them to auto-detect at runtime where the sid chips are. |
| |
iAN CooG
Registered: May 2002
Posts: 3238 |
<Post edited by iAN CooG on 4/9-2019 10:08>
Even by identifying the player one should scan for patterns and not patch specific offsets because very few players have a fixed structure, for example GoatTracker and Cheese cutter tunes are dynamically created depending on the features selected in the tracker, and the version of the tracker of course.
Each release should have a selector and its own patcher with an array of offsets manually found in the tune, like in Icony [2sid] or Ramdrive [2sid] |
| |
ChristopherJam
Registered: Aug 2004
Posts: 1424 |
…of course, patching might not even be a matter of changing a few addresses in the source.
I could well understand a player author just using an index register to access six or nine voices within the d4xx range; modifying such code to support chips that have addresses outside that would be nontrivial. |
| |
Frantic
Registered: Mar 2003
Posts: 1661 |
Yep, it can be non-trivial in some cases, at least in principle. Also, it would be cool if the players supported such autodetection out of the box (I'm thinking about implementing this myself in defMON or its currently developed successor), but..
My main point was actually something like this:
If you're skilled enough to code a quite nice player screen (which seems to be common for those multi sid tunes), it wouldn't typically be so hard to implement some custom patching of relevant addresses in the player code. Either to allow the user to select adress(es) manually, or through some auto-detection routine. That's all. :) |
| |
4mat
Registered: May 2010
Posts: 66 |
Haven't tried this on hardware yet but I needed an auto-detect for dual SIDs so wrote this recently:
https://4matprojects.blogspot.com/2020/12/2nd-sid-chip-auto-det..
When I was trying things out it seems like the $d400-$d7ff and $de00-$dfff areas needed different detection setups, does that sound correct? |
| |
Krill
Registered: Apr 2002
Posts: 3098 |
I wonder if the burden of support should really be on the software in this case. The hardware in question is optional add-on stuff, after all, pretty much a moving target.
Having the register layout be configurable seems more sensible, and should not be all that difficult with today's hardware.
Even nicer if we could agree on some standard to tell hardware about required/optional number of SIDs, register layout, panning etc. =) |
| |
chatGPZ
Registered: Dec 2001
Posts: 11523 |
check https://sourceforge.net/p/vice-emu/code/HEAD/tree/testprogs/SID.. and https://sourceforge.net/p/vice-emu/code/HEAD/tree/testprogs/SID.. |
| |
Frantic
Registered: Mar 2003
Posts: 1661 |
In my experience, TLR's routine (the first of the two links posted by Gpz above) works really well to detect the location of multiple SID chips and whether they are 6581 or 8580. Of course it is optional if someone wants to bear the burden of implementing this in their SID player code, to facilitate life for those of us who do have hardware for additional SID chips that does not allow configuration of base addresses, or that only allows limited configuration of base addresses. |
| |
Krill
Registered: Apr 2002
Posts: 3098 |
Semi-off topic, so bear with me for a moment. =)
With 32 (29) register slots per SID, more than 8 SIDs become somewhat cumbersome to address from software.
With configurable register layouts in mind, how feasible would be an addressing scheme that would, e.g., group all SIDs' registers together like so:$d400..$d41f: voice 1 frequency lo
$d420..$d43f: voice 1 frequency hi
[...]
$d780..$d79f: voice 3 envelope state (register 28=$1c) Never mind how sensible having 32 SIDs actually is, but black MIDI and the Furby organ exist, so... =) |
| Previous - 1 | 2 | 3 | 4 | 5 - Next |
