| |
ChristopherJam
Registered: Aug 2004
Posts: 1409 |
SID read immediately after write?
Can anyone think of any way to read what ENV3 is doing less than four cycles after a write to the voice 3 gate register?
STA $D412
LDA $D41C
tells you the value 4 cycles later, and every experiment I've done so far indicates there's probably a four cycle lag before any visible response to gating/ungating anyway, but I'd like to confirm this.
If I could set appropriate inputs to hold POTX/POTY/OSC3 to the bytes for STA $D412 I could at least execute those to test whether ENV3 had become RTS or not, but I can't see the DAC being stable enough for that.
Any useful weird opcodes, defined or not? Or any way to fool VIC into reading from IO space? |
|
| |
Repose
Registered: Oct 2010
Posts: 225 |
I can think of 4 solutions;
1 Use a SuperCPU to read/write in ~1uS increments
2 Bend out pin6 (clk) and connect to userport; then you can clock the SID yourself
3 Take out SID or use SID Symphony cart to wire yourself; can connect to userport or PC printer port easily, can connect to breadboard and even clock it by hand
4 Use a C128 in 2MHz mode to write/read with a delay of ~2uS. The timing is as follows:
sta $d412
;1 R pc
;2 R pc+1
;3 R pc+2
;4 - clock stretch
;5 W $d412
;6 R pc
;7 R pc+1
;8 R pc+2
;9 R $d41c
The clock stretch could swap places depending when you run the code, but there should be constant delay between write and read to I/O in this case, as they hit even/odd cycles.
It could be tested on an emulator on a CIA timer at full speed.
|
| |
ChristopherJam
Registered: Aug 2004
Posts: 1409 |
I only just thought of using a C128 while I was trying to get to sleep last night! Unfortunately I don't think I know anyone local who has one anymore.
I do like your idea of using a SuperCPU though; I've been meaning to get hold of one so I can order/play Metal Dust.
Most practical suggestion for my current setup though is clocking by hand by breadboarding or pin bending. I'm a little wary of damaging the chip, but I also didn't realise it was that simple.
It would also make it a lot easier for reading the subsequent behaviour; at the moment I'm reading every cycle from the 4th to the 120th by running each experiment multiple times. I delay the first read by an extra cycle each run, before dropping into a loop that reads and saves a value every N cycles. |
| |
Repose
Registered: Oct 2010
Posts: 225 |
Too bad you don't have an REU; I've done exactly that experiment in 1986 or so and read out all the values of the envelope. There's 5 line segments that approximate a log shape.
Now that we have die shots, others have worked out exactly where this table comes from.
http://ploguechipsounds.blogspot.com/2010/03/sid-6581r3-adsr-ta..
http://ploguechipsounds.blogspot.com/2010/11/new-research-on-si..
Also the latest version of reSid incorporates this info. I'm not aware of anyone who's clocked it out with a custom hookup though; it's worth verifying.
An idea of how to interface the SID to the PC;
http://www.loper-os.org/vintage/parallelsid/parasid.html
|
| |
ChristopherJam
Registered: Aug 2004
Posts: 1409 |
Ah, thanks for those die links. I'd found kevtris' blog and the Yannes interview, but not the pics of the LUT for the piecewise linear approximation thresholds.
Yes, I've been using reSID as a reference as to how to avoid the better known envelope generation bugs, but I did some experiments in September last year that revealed some additional issues that reSID doesn't yet reproduce.
For example, for the first cycle after the gate is set, instead of using a rate_period determined by the Attack register, it uses the Decay rate instead. This explains why it's been safe to use ADSR of 0100 at note start under reSID, but not with a real SID, where you have a one in nine chance of the envelope jamming for a frame and a half.
I want to release a patch that's cycle exact, but my approach of logging on the c64 and displaying onscreen was making it hard to collect enough data on some odd behaviour when you ungate during attack, and I've only just got my test harness working with IP65 to send bigger test packets back to my laptop.
(also, nice work doing that research way back in '86!) |
| |
Hermit
Registered: May 2008
Posts: 208 |
Other interesting, not entirely off-topic thing is that after a fast checking with SID-Hacker in VICE it seems that the 1st SID-register at $d400 is readable in the emulator. (Tested when bank-selection register $1 has value $35).
Every other SID-register (except 'readable' ones) gives the same value as register 0....
Maybe this is not a new thing, but surprisingly I've never realized this fact...
|
| |
chatGPZ
Registered: Dec 2001
Posts: 11386 |
the emu implements bitfading as it happens on real hardware..... d400 shouldnt behave differently than other registers - if it does, file a bug :) |
