Oh yes it can.
I am currently working at a 3-voice synthesizer which should mimic and sound almost like a Commodore 64 SID chip, on a plain Coco 3. At the moment I haven’t finished coding the 3rd channel of a demo music, but it is going pretty well.
The final result will be a full 6-bit quality sound mixed in realtime, outputing at a high quality sample rate of 19456 Hz, featuring 3 completely independent channels that can play either a sine, sawtooth, triangle, pulse, or noise wave, at any frequency. It is not fully done yet but I am very confident it will sound like a C64.
(However the CPU is 100% used while playing so no chance of having stuff going on the screen simultaneously
)
This post was submitted by remz.
@sixxie
I don’t know if you would see much benefit from the faster “dead cycles” if your code is running from RAM. A typical instruction like LDA $xxxx takes five cycles, with only one of those being a dead cycle. The dead cycle falls between two live cycles. The SAM has to switch rates at certain point within the cycle when it sees the address presented by the CPU. The address bus is unstable during a portion of each cycle, so I’m not sure if a single fast cycle in between two slow cycles would have much affect at all.
It may be that you need to have a run of multiple fast cycles (where the SAM doesn’t have to switch rates on consecutive cycles) to see any real boost.
jdiffend: True, but also some other regions above the 32K line. SAM/CPU data sheets imply that during cycles lost to internal operation, CPU will output one of those addresses (and specifically claims it’ll speed things up!)
Robert: Ah but then there’d be nothing for me to do! Also, nice to imagine using this to play some title music. And while I’m sure the requisite addresses will be accessed during playback, there’s still that possibility of failing to refresh everything.
DarrenA: Sounds plausible, though in this case every last “half” cycle would help (and be noticeable). I always imagined that at the point the SAM latched the address, that determined the next whole cycle timing. Ah well, good to learn something new, even if it’s not what you hoped.
So, when will an General Instruments AY-3-891X emulation be done?
It should be easier.
I decided to test the VMA cycle usage under address-dependant mode to see if any gains could be had. It is possible, but does seem that you need to have a run of consecutive VMA cycles to see any difference. This implies that typical code sequences would likely not benefit much if at all.
I used the following code to perform the test. I loaded it into RAM at $4000 on an NTSC CoCo 2.
START PSHS Y,X,D,CC ; SAVE REGISTERS
ORCC #$50 ; MASK INTERRUPTS
* REPLACE IRQ SERVICE ROUTINE
LDX $10D ; GET CURRENT IRQ ROUTINE..
PSHS X ; ..AND SAVE ON STACK
LEAX MYSRVC,PCR ; GET MY IRQ ROUTINE..
STX $10D ; ..AND PUT IN VECTOR
* PREPARATION FOR TIMING LOOP
LDX #$FF02 ; POINT X TO PIA0B
LDY #0 ; INIT LOOP COUNTER
LDA ,X ; CLEAR IRQ FLAG IN PIA 0
SYNC ; WAIT FOR NEXT FIELD SYNC IRQ
LDA ,X ; CLEAR IRQ FLAG IN PIA 0
ANDCC #$EF ; CLEAR IRQ MASK IN CC
* TIMING LOOP
LOOP LEAY 1,Y ; 3 ACTIVE, 2 VMA
BRA LOOP ; 2 ACTIVE, 1 VMA
* IRQ SERVICE ROUTINE FOR LOOP TERMINATION
MYSRVC LDA ,X ; CLEAR IRQ FLAG IN PIA 0
STY $600 ; STORE COUNTER AT $600
LEAS 12,S ; POP MACHINE STATE
PULS X ; RESTORE ORIGINAL..
STX $10D ; ..IRQ SERVICE ROUTINE
PULS CC,D,X,Y,PC ; RESTORE REGS AND RETURN
Each iteration of the LOOP uses 8 cycles, with 3 of those being VMA cycles. The two VMA cycles in the LEAY instruction run consecutively. This loop runs 1866 times in both Normal and Address-Dependant mode, so there doesn’t appear to be any significant difference.
If an LEAU *+100,PCR instruction is inserted into the loop, this adds 9 additional cycles, with five of those being consecutive VMA cycles. Now the loop runs 878 times in Normal mode and 995 times in Address-Dependant mode, saving about 2 cycles for each iteration.
That’s good research! Needs more determinism for my liking, but further tests can get that, I’m sure. Looks like you’re right about needing some time for the rate to “kick in”, though that makes absolutely no sense in my head
The SAM datasheet you referenced shows a waveform diagram for the rate transitions. It lacks detail, but certainly gives the impression that a single fast cycle would have no benefit because it stretches the low portion of the Q clock during a transition from slow-to-fast.
G’Day Remz.
A fellow coconut called Torsten in Germany says he knows a great website that contains C-64 Sid files. Here is the link to it: http://www.hardsid.com
Here is 1 of the files you will find in the website.
http://www.hardsid.com/files/C64Music/MUSICIANS/H/Hubbard_Rob/Monty_on_the_Run.sid
laters
Briza
G’Day Briza
Thanks, I know a few SID tunes from this site and other like http://www.skytopia.com/games/c64/c64.html.
Monty On The Run was amongst my favorite C64 game back then. The music is awesome, as most of Rob Hubbard are.
I have just finished setting up a simple website for my CoCo 3 stuff if anyone’s interested:
http://sites.google.com/site/rveilleux/coco3home
G’Day Remz.
Thanks for the coco website. Hopefully we will see more stuff from you Remz.
Torsten also mentioned his favorite Sid tune was Monty on the Run.
Have fun exploring new stuff on the coco 3 Remz.
laters
Briza
DarrenA: I see what you mean. Looks like any transition basically leaves you with the first cycle still effectively “slow”. Boo!