Thanks pullmoll. I saw your interface is 1K1 series, 470R to ground, and 1uF series to output. I shall give that a try with some headphones and also my TV.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔ Links to other interesting threads:
Cluso99 said...
Thanks pullmoll. I saw your interface is 1K1 series, 470R to ground, and 1uF series to output. I shall give that a try with some headphones and also my TV.
That was just a wild guess to have ~ 1V output at 500Ohms, which is the standard AUX input parameters IIRC. It should work with headphones. The capacitor value is just a guess taken from some amplifier's input circuitry.
Is is possible to use this object (AY-3-8910) in conjunction with another sound object? (say, Chip's speech object?)
It would be extremely handy for a couple projects I'm working on.
Thanks!
OBC
Yes it would, but not on the same output.
AYcog/SIDcog to the left and the speech object to the right.
I do not have an SD card but I really want to try this driver so I included a ym file in the build and modified the code to copy data from the included file instead of from the SD card. I am not able to make it work no matter what I do!!
Here is the code I modified
i:=14+16+16+16 '' the starting pointer
repeat until (i>4000)'this is just an estomate for now
waitcnt(cnt+playRate)
'if( sd.pread(@buffer, 16) ) => 0
bytemove( @buffer, @data+i, 16 )' instead of read from SD I read from file I added
i +=16'increment the pointer by 16
bytemove( @AYregs, @buffer, 13 )
ifnot buffer[noparse][[/noparse]13] == 255
byte[noparse][[/noparse]@AYregs + 13] := buffer[noparse][[/noparse]13]&15
.................
............
..............
DAT
data file "jess2.ym"
edit: haha!! I found the error. The code reads the first 14+16+16+16 bytes (the header) but the header is not necessary to be this size! I kinda kept messing with numbers until I had it to work.
Does anyone know where I can find the spec fro the ym files?
Whoever made this....very nice work
Post Edited (fezmonkey) : 6/27/2010 4:52:45 AM GMT
fezmonkey said...
Whoever made this....very nice work
That would be me. Thanks!
I'm sorry about the header thing.
All my initial test dumps had the same header size and I was eager to get it to play as soon as possible.
I just took a short cut and kind of forgot about it.
pullmoll made a player that handles the header correctly, you can find it somewhere in this thread.
(BTW, I hope you use the latest version of AYcog since it is improved a lot)
Here is a video of what we have so far. This is far from done but very good progress
Ahle2 said...
I may be interested in one of those. [noparse]:)[/noparse]
I maybe able to get you one for free if you are willing to help out [noparse];)[/noparse]
SIDcog, I looked it up on this forum but I do not understand anything about SID or audio so I am going to stick with the current driver for now. The important part is to make a complete project that is all open so the anyone (you) can take ti and make it better anyway they like.
fez, why would you say in your video that programming in spin is very hard and also for someone who knows c or c++ would find spin very very difficult?
I've been writing with C for years, and found my spin very easy to get to grips with.
It's comments like yours that keep other people away from the propeller [noparse]:([/noparse] please try and by more positive about spin in your videos [noparse];)[/noparse] we need more people coming to the prop, so they too can find out what a great little chip it is, and easy to program, and very easy and very quick to prototype with. ( it even has a C compiler and PropBASIC ).
Sorry for my little rant, but the prop deserves good press, and to me, that video says, get a gameo, it's very difficult to program with, so you're going to frighten away anyone who would want to get a gameo.
fezmonkey: I have to wonder about these statements from the video:
"Spin ...very very difficult", "Some what OK[noparse][[/noparse]for familiar users]", "Any programmer out there that knows C or C++ would find this very difficult to understand".
That is so far from the truth. Any programmer out there who has been working with anything since the dawn of structured programming from ALGOL through C to Z will pick get the idea of Spin in a one hour scan of the manual and be up to speed in no time. There are no new concepts in there.
OK PASM is harder but still about the easiest assembly language going.
Admittedly all that audio/video code maybe beyond what a lot of people are used to or want to get into. But that's in the nature of the task rather than the languages or IDE used to do it.
Lets look at this the other way round. In Spin/PASM on the Prop it is possible to do those audio/video things. In C++/C# on the Fez or other platform it is very HARD.
With that out of the way the whole Gameo idea is quite interesting. Moving all the high level "management" or game logic out of the Propeller which is memory constrained. I have often though a marriage of a Prop and an ARM on a single PCB would be great.
The FEZ Domino card has a very attractive price (60 Euros) so it fits the plan perfectly.
Can I program this setup from Linux?
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
I do embedded programming for living (over 15 years) and have always use C/C++. Moving to program FEZ Domino in C# was very easy for me. Now, programming in SPIN, not easy at all, at least for me. I am now on my forth week trying to learn spin and I still get stuck in many places where I get very frustrated.
I guess if you know SPIN only and wanted to program in C then you will have the same problem, C will be very difficult!
Either way, the propeller chip is amazing at generating signals (that is why it was chosen for the project) and SPIN is not bad but I wish it was closer to C so it is easier to learn.
Maybe by next video I will be less frustrated with spin (learned more) and have more positive attitude toward spin [noparse]:)[/noparse]
Sorry guys if I upset anyone
About Linux, theoretically, this is a .NET interpreter so it can run any .NET assembly...coming from windows or Linux ....if ti was programmed in C# or VB....all should work. That is in theory. In reality, C# is fully supported and VB has been proven to run but no one had tried to make it work on linux.
Fezmonkey, you are right about that. The hardest thing is when you find yourself programming in C and Spin at the same time. Things are similar enough that you keep finding yourself using one syntax in the other. Which mostly just produces a compiler error but sometimes compiles fine and then does unexpected things. For example when you think you are commenting out a block of code with {} in C. Syntax highlighting normally alerts one to these things but sometimes they slip through.
It's better to have time in each language to get into the correct habits.
So is it possible to compile C# with Mono under Linux that would run on that board? What libs might it need? How would the executable get downloaded?
Any links to any clues about this?
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
exactly, there are differences between spin and C, the problem is you want to stick with something you know.
people should try the prop, and realise how easy it is, here's an example, your video to show people how to use the FEZ-Domino to flash a single LED
create a new project, add a few using lines, for the thread instructions, and for the pin defines, then you can write your code.
prop is just, open the proptool then type
pub main
dira[noparse][[/noparse] 0 ]:=1
repeat
!outa[noparse][[/noparse]0]
repeat 5000
surely that's a lot more Freaking Easy than the FEZ-Domino is? [noparse]:)[/noparse]
How long did it take for you to get use to classes etc in C? when they brought out C++? and again, when you moved to C# from C++?
And like heater said, would it be easy for you to write a TV display driver on the FEZ?
I know arm, inside out, been programming on it for 9 years (in both C and ASM), which is 3 times longer than I've had a prop for ( about 3 years ) and I know, that I would rather write a TV driver for the prop than do one on an arm chip.
sometimes to advance you need to step outside of your comfort zone and just jump into the water, either the deep end or the shallow end, but at least get your feet wet before totally dismissing it, or using words like "very very hard"
What about people who program other microcontrollers, pic, avr or sx chips, it's like you're telling them spin is very very hard, compared to C#, whereas I'd say it would be a lot easier to learn spin than it would to learn C# for someone who doesn't know C.
btw, you haven't upset me, I just think it a bit unfair you dissed the prop without even realising it, not to mention possibly frightened away potential prop newbies.
Heater, like I said before, using linux/mono is possible in theory but no one has done it before
Baggers, blinking an LED is easier on prop because prop is made to handle low level things very well. Now try to do a real life application, like a data logger, then FEZ would be much easier. Now, FEZ can't do timing at all so generating audio or video would be impossible on FEZ. Each device has its strengths and weaknesses.
Yeah, fez, I know things have strengths and weaknesses, and sorry if my replies seem harsh, I guess I like the prop too much, maybe because, like their advert "remember when programming was fun" I really enjoy programming on the prop, it's fun, and very easy to program on, and I guess I like spin more as a language than any of the C variants [noparse]:)[/noparse]
btw, the prop can be a data logger, and a very good one too, and it would be very easy to write one for the prop, taking measurements from the pins ( either I2C to a device, or SPI, or ADC on the pins, then store to eeprom or serial to PC or to SD, or even to a TV display, the prop can do it easily, and it would be very quick to prototype, so maybe your example wasn't the best to use, but I agree, they are separate chips, with separate target customers.
and like your gameo you use them both to their strengths, the prop for displaying an image on the tv, and the arm chip for writing the game logic, and using the usb ability of the arm for loading from SD or USBkey and sending to the prop.
Yes with combining both, prop and FEZ, I see soooo many possibilities! The only down side now is the resolution I have. 128x96 is not really a lot of pixels! If I could have 256x192 then that would be just terrific. The problem is I need double buffering to eliminate flickering.
you can have a higher res than 128x96, that is just for the 256 colour bitmap, or 16colour bitmap with room for double buffering.
the beauty of the prop, is you can work the display driver to your needs, since you're using it for a gameo, then why don't you do a 256x192 or 320x200 but have a character mapped display with sprites on?
Just testing out my audio circuit with this simple bit of spin (and the latest AYcog object)
CON _clkmode = xtal1 + pll16x
_xinfreq = 5_000_000
SDPins = 0
audioR = 0
audioL = 24
' playRate = 80_000_000/50
VAR
byte buffer[noparse][[/noparse]25]
byte filename[noparse][[/noparse]18]
long fileNumber
long nrOfTunes
OBJ
AY : "AYcog_V0-16"
' SD : "fsrw"
PUB Main | AYregisters, i, j, value, playRate
AYregisters := AY.start( audioR, audioL )
playRate := 5
repeat
waitcnt(cnt + 80_000_000/playrate)
repeat i from 0 to 15
value := (?j)&255
if i>9 and i<13
value &= 31
byte[noparse][[/noparse]AYregisters + i] := value
All working great. My little LM386 is working fine. Not even getting warm and it is quite loud into a 4" speaker.
I haven't been able to do the ym files yet as I'm using fat32 sd cards so I need to port the fsrw part to KyeDOS. Maybe add the audio files to a menu somehow as well.
This is so nifty!
All retro emulations are going to really benefit from this audio.
FSRW 2.6 does handle FAT32 (support for FAT32 was added almost a year ago [noparse][[/noparse]8^). Kye's code does as well, with the added benefit of subdirectories.
Jonathan
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
lonesock
Piranha are people too.
(geek humor escalation => "There are 100 types of people: those who understand binary, and those who understand bit masks")
I was reading through your AY-3-891X emulator code in the OBEX and was thinking it might be possible to customize it to get some simple 8 bit PCM capabilities out of it as well as the AY-3-891X audio. This could be achieved by repurposing the currently unused 8 bit I/O port A and port B registers to conveniently pass in the 8 bit PCM values for each channel. They could then mixed with the existing (mono) AY-3-891X source separately for each channel. If this really is possible I think it would be a pretty cool extra feature because it then lets you do AY-3-891X music/sound fx AND PCM simultaneously on the same output pin without needing additional hardware resources. That is exactly the type of capability I am looking for in my application right now.
Below is a further description of what I am contemplating. Please understand that I haven't tried it out yet so I am not sure if this overall idea even fits in with your current duty cycle modulation scheme or not. But I am thinking of trying it once I get time with a proper test setup in place. You might also be interested in attempting this too, or shoot it down as being fundamentally incompatible or identify other problems with PCM data formats etc. I'm still hoping it's achievable.
Description of PCM extensions:
When reading all the AY registers, you would read and save off the last two I/O port values in the 16 byte register block as the initial DAC values for each channel. You would need to shift up these two 8 bit PCM values into the MSBs of two 32 bit words (which I called dacA and dacB) to be mixed later. If there is no PCM value needed to be added, the caller would simply leave a zero in these AY registers and it would have no effect.
In the register reading code block, here is the new code in red for example. Further rearranging could optimize hub op timing of later wrByte. This is just to show the idea.
rdbyte envelopePeriod, tempValue ' reg 11
add tempValue, #1
shl noisePeriod, #20
rdbyte temp1, tempValue ' reg 12
shl temp1, #8
or envelopePeriod, temp1 wz
if_z mov envelopePeriod, half_period ' 0 == half the period of 1
if_nz shl envelopePeriod, #16
add tempValue, [COLOR="#FF0000"]#2
rdword dacA, tempValue ' regs 14 and 15 hold DAC A and DAC B samples
sub tempValue, #1
mov dacB, dacA
[/COLOR] rdbyte envelopeShape, tempValue ' reg 13
movd oscValues, enableRegister
[COLOR="#FF0000"] shl dacA, #24 ' align data to MSBs
shr dacB, #8
shl dacB, #24 ' align data to MSBs
[/COLOR]
At the mixer stage you would add the existing (mono) AY sample output separately to the two DAC output value accumulators and then write these to the FRQ register used for that channel.
In the sample mixing code block, here is the new code in red for example
mixer mov r1, val31bit ' DC offset
add r1, out1
add r1, out2
add r1, out3
[COLOR="#FF0000"] add dacA, r1
add dacB, r1
[/COLOR] waitcnt waitCounter, sampleRate ' Wait until the right time to update
mov FRQA, [COLOR="#FF0000"]dacA [/COLOR] ' the PWM values in FRQA/FRQB
mov FRQB, [COLOR="#FF0000"]dacB [/COLOR] '
jmp #mainLoop
Conveniently it seems the code has already accounted for up to 4 channels in the MAX_AMPLITUDE constant even though there are only 3 channels used today, so no overdriving should happen with the extra PCM component summed in as I understand it.
MAX_AMPLITUDE = float(POSX / 4) ' maxInt32value / numberOfChannels (this makes room for maximum "swing" on all channels)
Also the two new DAC values are also required to be stored in the COG's memory
noiseMSB long 1 << NOISE_MSB
noiseTap long NOISE_TAP
sampleRate long 0
[COLOR="#FF0000"]dacA long 0
dacB long 0
[/COLOR]freqRef long 10<<20
I counted up the instructions in your existing code (v0.8) and it is getting tight at 125kHz (there's not a lot of free cycles left perhaps ~32-40 worth or so if I counted right) but I think at least 6 more instructions can also be gained by inlining the getAmplitude subroutine that is called 3 times when determining the amplitude of each channel which then removes the 6 call/return instruction operation overheads. With that there are maybe 56 clock cycles overall to play with. Probably good to leave a few spare for slight hub op timing variation each iteration.
I think I added about 36 clock cycles with the above code if the read operation is strategically placed so it might still be possible to squeeze it in and keep it clocking at 125kHz. :thumb:
DAC Synchronization issues:
Now one could always choose to write the two PCM register bytes asynchronously if you had to (it probably would not sound too exceptional) but in order to properly synchronize the PCM source with the output I was thinking about toggling another pin once per sample or writing to another memory location which can be read/cleared by some other COG which feeds it PCM data at some convenient sub-multiple of the sampling rate. In my particular application for example I would like to try to run this code at 88200 Hz instead of 125kHz and probably toggle a pin every iteration to create a simple square wave interrupt signal at a rate of 44.1kHz. This would then be used for triggering an external microcontroller and/or COG to update the PCM registers in time for the next sample and consequently keeping it fed with 44.1kHz 8 bit stereo audio source data. A simple XOR of an outA port register bit would suffice for driving such an interrupt signal so only one additional instruction would be required there. Simple. Otherwise another memory address write for another COG to poll is required which would burn a few more cycles. But if sampled at 88.2kHz the cycle count would no longer be an issue when compared to operating at 125kHz.
I'm still figuring out which exact parameters in your code to change for achieving the 88.2kHz sample rate - it's quite hard for me to determine what parameters are affected by this and that is a separate question for you.
I would be very interested in hearing your thoughts on this overall idea Johannes, as well as any other people who are interested in it.
Regards,
Roger.
P.s. Separate crazy idea....there are two other bits that were related to the original I/O port direction in AY register 7. Perhaps they could also be repurposed to enable/disable AY output on each channel in the mixer stage for even finer audio output control on each channel. Also, if they are modulated at a high enough rate, it might be able to give some weird panning or tremelo effect perhaps...I will have to try that too. Could sound a bit harsh I imagine. It burns 2 more instructions in the mixer to extract the two control bits eg.
mixer mov r1, val31bit ' DC offset
add r1, out1
add r1, out2
add r1, out3
[COLOR="#FF0000"] test enableRegister, #$80 wc
test enableRegister, #$40 wz
if_nz[/COLOR] add dacA, r1
[COLOR="#FF0000"]if_c [/COLOR] add dacB, r1
waitcnt waitCounter, sampleRate ' Wait until the right time to update
mov FRQA, dacA ' the PWM values in FRQA/FRQB
mov FRQB, dacB '
jmp #mainLoop
Comments
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Pullmoll's Propeller Projects
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Links to other interesting threads:
· Home of the MultiBladeProps: TriBlade,·RamBlade,·SixBlade, website
· Single Board Computer:·3 Propeller ICs·and a·TriBladeProp board (ZiCog Z80 Emulator)
· Prop Tools under Development or Completed (Index)
· Emulators: CPUs Z80 etc; Micros Altair etc;· Terminals·VT100 etc; (Index) ZiCog (Z80) , MoCog (6809)·
· Prop OS: SphinxOS·, PropDos , PropCmd··· Search the Propeller forums·(uses advanced Google search)
My cruising website is: ·www.bluemagic.biz·· MultiBlade Props: www.cluso.bluemagic.biz
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Pullmoll's Propeller Projects
AYcog/SIDcog to the left and the speech object to the right.
OBC
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Propeller Feature Projects: PropellerPowered.com
Visit the: PROPELLERPOWERED SIG forum kindly hosted by Savage Circuits.
Here is the code I modified
i:=14+16+16+16 '' the starting pointer
repeat until (i>4000)'this is just an estomate for now
waitcnt(cnt+playRate)
'if( sd.pread(@buffer, 16) ) => 0
bytemove( @buffer, @data+i, 16 )' instead of read from SD I read from file I added
i +=16'increment the pointer by 16
bytemove( @AYregs, @buffer, 13 )
ifnot buffer[noparse][[/noparse]13] == 255
byte[noparse][[/noparse]@AYregs + 13] := buffer[noparse][[/noparse]13]&15
.................
............
..............
DAT
data file "jess2.ym"
edit: haha!! I found the error. The code reads the first 14+16+16+16 bytes (the header) but the header is not necessary to be this size! I kinda kept messing with numbers until I had it to work.
Does anyone know where I can find the spec fro the ym files?
Whoever made this....very nice work
Post Edited (fezmonkey) : 6/27/2010 4:52:45 AM GMT
I'm sorry about the header thing.
All my initial test dumps had the same header size and I was eager to get it to play as soon as possible.
I just took a short cut and kind of forgot about it.
pullmoll made a player that handles the header correctly, you can find it somewhere in this thread.
(BTW, I hope you use the latest version of AYcog since it is improved a lot)
/Ahle2
I can't remember the website where I have this from, but here it is:
HTH
Juergen
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Pullmoll's Propeller Projects
leonard.oxg.free.fr/ymformat.html
I am using version 22 as this is the latest I could find. Files are playing just fine.
Thanks to your driver and Andy's video driver, I have now somewhat complete system for the FEZ Gameo project.http://www.microframeworkprojects.com/index.php?title=FEZ_Gameo
I should be able to show some cool demo in couple days
I may be interested in one of those. [noparse]:)[/noparse]
BTW, you may be interested in SIDcog as well. It's an emulation of the much more powerful SID chip in the C64.
Post Edited (Ahle2) : 6/27/2010 8:21:24 PM GMT
I maybe able to get you one for free if you are willing to help out [noparse];)[/noparse]
SIDcog, I looked it up on this forum but I do not understand anything about SID or audio so I am going to stick with the current driver for now. The important part is to make a complete project that is all open so the anyone (you) can take ti and make it better anyway they like.
I've been writing with C for years, and found my spin very easy to get to grips with.
It's comments like yours that keep other people away from the propeller [noparse]:([/noparse] please try and by more positive about spin in your videos [noparse];)[/noparse] we need more people coming to the prop, so they too can find out what a great little chip it is, and easy to program, and very easy and very quick to prototype with. ( it even has a C compiler and PropBASIC ).
Sorry for my little rant, but the prop deserves good press, and to me, that video says, get a gameo, it's very difficult to program with, so you're going to frighten away anyone who would want to get a gameo.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
http://www.propgfx.co.uk/forum/·home of the PropGFX Lite
·
"Spin ...very very difficult", "Some what OK[noparse][[/noparse]for familiar users]", "Any programmer out there that knows C or C++ would find this very difficult to understand".
That is so far from the truth. Any programmer out there who has been working with anything since the dawn of structured programming from ALGOL through C to Z will pick get the idea of Spin in a one hour scan of the manual and be up to speed in no time. There are no new concepts in there.
OK PASM is harder but still about the easiest assembly language going.
Admittedly all that audio/video code maybe beyond what a lot of people are used to or want to get into. But that's in the nature of the task rather than the languages or IDE used to do it.
Lets look at this the other way round. In Spin/PASM on the Prop it is possible to do those audio/video things. In C++/C# on the Fez or other platform it is very HARD.
With that out of the way the whole Gameo idea is quite interesting. Moving all the high level "management" or game logic out of the Propeller which is memory constrained. I have often though a marriage of a Prop and an ARM on a single PCB would be great.
The FEZ Domino card has a very attractive price (60 Euros) so it fits the plan perfectly.
Can I program this setup from Linux?
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
I guess if you know SPIN only and wanted to program in C then you will have the same problem, C will be very difficult!
Either way, the propeller chip is amazing at generating signals (that is why it was chosen for the project) and SPIN is not bad but I wish it was closer to C so it is easier to learn.
Maybe by next video I will be less frustrated with spin (learned more) and have more positive attitude toward spin [noparse]:)[/noparse]
Sorry guys if I upset anyone
About Linux, theoretically, this is a .NET interpreter so it can run any .NET assembly...coming from windows or Linux ....if ti was programmed in C# or VB....all should work. That is in theory. In reality, C# is fully supported and VB has been proven to run but no one had tried to make it work on linux.
It's better to have time in each language to get into the correct habits.
So is it possible to compile C# with Mono under Linux that would run on that board? What libs might it need? How would the executable get downloaded?
Any links to any clues about this?
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
people should try the prop, and realise how easy it is, here's an example, your video to show people how to use the FEZ-Domino to flash a single LED
create a new project, add a few using lines, for the thread instructions, and for the pin defines, then you can write your code.
prop is just, open the proptool then type
pub main dira[noparse][[/noparse] 0 ]:=1 repeat !outa[noparse][[/noparse]0] repeat 5000surely that's a lot more Freaking Easy than the FEZ-Domino is? [noparse]:)[/noparse]
How long did it take for you to get use to classes etc in C? when they brought out C++? and again, when you moved to C# from C++?
And like heater said, would it be easy for you to write a TV display driver on the FEZ?
I know arm, inside out, been programming on it for 9 years (in both C and ASM), which is 3 times longer than I've had a prop for ( about 3 years ) and I know, that I would rather write a TV driver for the prop than do one on an arm chip.
sometimes to advance you need to step outside of your comfort zone and just jump into the water, either the deep end or the shallow end, but at least get your feet wet before totally dismissing it, or using words like "very very hard"
What about people who program other microcontrollers, pic, avr or sx chips, it's like you're telling them spin is very very hard, compared to C#, whereas I'd say it would be a lot easier to learn spin than it would to learn C# for someone who doesn't know C.
btw, you haven't upset me, I just think it a bit unfair you dissed the prop without even realising it, not to mention possibly frightened away potential prop newbies.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
http://www.propgfx.co.uk/forum/·home of the PropGFX Lite
·
Baggers, blinking an LED is easier on prop because prop is made to handle low level things very well. Now try to do a real life application, like a data logger, then FEZ would be much easier. Now, FEZ can't do timing at all so generating audio or video would be impossible on FEZ. Each device has its strengths and weaknesses.
I was programming in Pascal and Delphi for years. And from that startingpoint it was a breeze to learn spin
best regards
Stefan
btw, the prop can be a data logger, and a very good one too, and it would be very easy to write one for the prop, taking measurements from the pins ( either I2C to a device, or SPI, or ADC on the pins, then store to eeprom or serial to PC or to SD, or even to a TV display, the prop can do it easily, and it would be very quick to prototype, so maybe your example wasn't the best to use, but I agree, they are separate chips, with separate target customers.
and like your gameo you use them both to their strengths, the prop for displaying an image on the tv, and the arm chip for writing the game logic, and using the usb ability of the arm for loading from SD or USBkey and sending to the prop.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
http://www.propgfx.co.uk/forum/·home of the PropGFX Lite
·
Maybe a future prop will have 64K of ram?
Adding external RAM is not an option here.
the beauty of the prop, is you can work the display driver to your needs, since you're using it for a gameo, then why don't you do a 256x192 or 320x200 but have a character mapped display with sprites on?
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
http://www.propgfx.co.uk/forum/·home of the PropGFX Lite
·
I want to see a game running with USB joystick and loading levels/resources from SD card or USB thumb drive.....very soon now!
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
http://www.propgfx.co.uk/forum/·home of the PropGFX Lite
·
CON _clkmode = xtal1 + pll16x _xinfreq = 5_000_000 SDPins = 0 audioR = 0 audioL = 24 ' playRate = 80_000_000/50 VAR byte buffer[noparse][[/noparse]25] byte filename[noparse][[/noparse]18] long fileNumber long nrOfTunes OBJ AY : "AYcog_V0-16" ' SD : "fsrw" PUB Main | AYregisters, i, j, value, playRate AYregisters := AY.start( audioR, audioL ) playRate := 5 repeat waitcnt(cnt + 80_000_000/playrate) repeat i from 0 to 15 value := (?j)&255 if i>9 and i<13 value &= 31 byte[noparse][[/noparse]AYregisters + i] := valueAll working great. My little LM386 is working fine. Not even getting warm and it is quite loud into a 4" speaker.
I haven't been able to do the ym files yet as I'm using fat32 sd cards so I need to port the fsrw part to KyeDOS. Maybe add the audio files to a menu somehow as well.
This is so nifty!
All retro emulations are going to really benefit from this audio.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
www.smarthome.viviti.com/propeller
Jonathan
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
lonesock
Piranha are people too.
(geek humor escalation => "There are 100 types of people: those who understand binary, and those who understand bit masks")
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
www.smarthome.viviti.com/propeller
Changes:
- Increased volume table accuracy
- Increased noise accuracy
- Opmtimized code a little bit
I was reading through your AY-3-891X emulator code in the OBEX and was thinking it might be possible to customize it to get some simple 8 bit PCM capabilities out of it as well as the AY-3-891X audio. This could be achieved by repurposing the currently unused 8 bit I/O port A and port B registers to conveniently pass in the 8 bit PCM values for each channel. They could then mixed with the existing (mono) AY-3-891X source separately for each channel. If this really is possible I think it would be a pretty cool extra feature because it then lets you do AY-3-891X music/sound fx AND PCM simultaneously on the same output pin without needing additional hardware resources. That is exactly the type of capability I am looking for in my application right now.
Below is a further description of what I am contemplating. Please understand that I haven't tried it out yet so I am not sure if this overall idea even fits in with your current duty cycle modulation scheme or not. But I am thinking of trying it once I get time with a proper test setup in place. You might also be interested in attempting this too, or shoot it down as being fundamentally incompatible or identify other problems with PCM data formats etc. I'm still hoping it's achievable.
Description of PCM extensions:
When reading all the AY registers, you would read and save off the last two I/O port values in the 16 byte register block as the initial DAC values for each channel. You would need to shift up these two 8 bit PCM values into the MSBs of two 32 bit words (which I called dacA and dacB) to be mixed later. If there is no PCM value needed to be added, the caller would simply leave a zero in these AY registers and it would have no effect.
In the register reading code block, here is the new code in red for example. Further rearranging could optimize hub op timing of later wrByte. This is just to show the idea.
rdbyte envelopePeriod, tempValue ' reg 11 add tempValue, #1 shl noisePeriod, #20 rdbyte temp1, tempValue ' reg 12 shl temp1, #8 or envelopePeriod, temp1 wz if_z mov envelopePeriod, half_period ' 0 == half the period of 1 if_nz shl envelopePeriod, #16 add tempValue, [COLOR="#FF0000"]#2 rdword dacA, tempValue ' regs 14 and 15 hold DAC A and DAC B samples sub tempValue, #1 mov dacB, dacA [/COLOR] rdbyte envelopeShape, tempValue ' reg 13 movd oscValues, enableRegister [COLOR="#FF0000"] shl dacA, #24 ' align data to MSBs shr dacB, #8 shl dacB, #24 ' align data to MSBs [/COLOR]At the mixer stage you would add the existing (mono) AY sample output separately to the two DAC output value accumulators and then write these to the FRQ register used for that channel.
In the sample mixing code block, here is the new code in red for example
mixer mov r1, val31bit ' DC offset add r1, out1 add r1, out2 add r1, out3 [COLOR="#FF0000"] add dacA, r1 add dacB, r1 [/COLOR] waitcnt waitCounter, sampleRate ' Wait until the right time to update mov FRQA, [COLOR="#FF0000"]dacA [/COLOR] ' the PWM values in FRQA/FRQB mov FRQB, [COLOR="#FF0000"]dacB [/COLOR] ' jmp #mainLoopConveniently it seems the code has already accounted for up to 4 channels in the MAX_AMPLITUDE constant even though there are only 3 channels used today, so no overdriving should happen with the extra PCM component summed in as I understand it.
Also the two new DAC values are also required to be stored in the COG's memory
I counted up the instructions in your existing code (v0.8) and it is getting tight at 125kHz (there's not a lot of free cycles left perhaps ~32-40 worth or so if I counted right) but I think at least 6 more instructions can also be gained by inlining the getAmplitude subroutine that is called 3 times when determining the amplitude of each channel which then removes the 6 call/return instruction operation overheads. With that there are maybe 56 clock cycles overall to play with. Probably good to leave a few spare for slight hub op timing variation each iteration.
I think I added about 36 clock cycles with the above code if the read operation is strategically placed so it might still be possible to squeeze it in and keep it clocking at 125kHz. :thumb:
DAC Synchronization issues:
Now one could always choose to write the two PCM register bytes asynchronously if you had to (it probably would not sound too exceptional) but in order to properly synchronize the PCM source with the output I was thinking about toggling another pin once per sample or writing to another memory location which can be read/cleared by some other COG which feeds it PCM data at some convenient sub-multiple of the sampling rate. In my particular application for example I would like to try to run this code at 88200 Hz instead of 125kHz and probably toggle a pin every iteration to create a simple square wave interrupt signal at a rate of 44.1kHz. This would then be used for triggering an external microcontroller and/or COG to update the PCM registers in time for the next sample and consequently keeping it fed with 44.1kHz 8 bit stereo audio source data. A simple XOR of an outA port register bit would suffice for driving such an interrupt signal so only one additional instruction would be required there. Simple. Otherwise another memory address write for another COG to poll is required which would burn a few more cycles. But if sampled at 88.2kHz the cycle count would no longer be an issue when compared to operating at 125kHz.
I'm still figuring out which exact parameters in your code to change for achieving the 88.2kHz sample rate - it's quite hard for me to determine what parameters are affected by this and that is a separate question for you.
I would be very interested in hearing your thoughts on this overall idea Johannes, as well as any other people who are interested in it.
Regards,
Roger.
P.s. Separate crazy idea....there are two other bits that were related to the original I/O port direction in AY register 7. Perhaps they could also be repurposed to enable/disable AY output on each channel in the mixer stage for even finer audio output control on each channel. Also, if they are modulated at a high enough rate, it might be able to give some weird panning or tremelo effect perhaps...I will have to try that too. Could sound a bit harsh I imagine. It burns 2 more instructions in the mixer to extract the two control bits eg.
mixer mov r1, val31bit ' DC offset add r1, out1 add r1, out2 add r1, out3 [COLOR="#FF0000"] test enableRegister, #$80 wc test enableRegister, #$40 wz if_nz[/COLOR] add dacA, r1 [COLOR="#FF0000"]if_c [/COLOR] add dacB, r1 waitcnt waitCounter, sampleRate ' Wait until the right time to update mov FRQA, dacA ' the PWM values in FRQA/FRQB mov FRQB, dacB ' jmp #mainLoop