Search options (Page 22 of 39)

Nice project, bummer about the sound emulation. Might be worth a try porting it to the C.H.I.P, though the timing issues on that machine will probably ruin the emulation.

Talkin' bout da tracker at Revision last weekend: https://www.youtube.com/watch?v=7UgSDAkXAJw
Rather technical, with a lot of uhhm and ehhm, and a failed demonstration of the QED68 sound routine at the end.

Well, generating a huge number of pin pulse channels is not a problem at least, thanks to Jan Deak's buffer method. I wonder though if it's possible to come up with an elegant algorithm that uses only one oscillator and derives the detuned copies from that, like the original SuperSaw supposedly does. For example, a simple 8-bit counter that increments once per loop iteration could already be enough to generate two derivatives (one added to main osc, one subtracted).

Well, trying to imitate the waveforms of the allophones is basically already a sort of proto-formant synthesis

Hybrid Qchan would be doable. Generally, almost any beeper engine can be combined with AY without too much trouble. The main problem is that adding AY would significantly increase row transition noise on most engines, because (re)loading the AY registers takes a lot of time. The other problem is volume balance. For example the classic Qchan is not a good candidate for combining with AY buzzer, because the buzzer is much, much louder. This is why I chose Squeeker-type synthesis for my hybrid experiment, because this type of synthesis produces very loud sound, and it also cloaks row transition clicks pretty well.

Well, as I said earlier, I've retired from writing beeper engines for the time being. So don't put your hopes on me. I do hope though that someone else will pick up these ideas, and I'm of course more than willing to help if somebody is to take up the challenge.

I think some MIDI solution would be preferable because of its potential impact. Would it be possible to ditch the Arduino MIDI shield and just decode the MIDI messages directly on the Arduino, using one of the digi ports? It would cause some additional load on the CPU of course, but on the other hand there's no need to load sequence/pattern data any more. As far as instruments go, yes, they could be pre-defined patches, but the engine should also make best use of the available standard Control Change messages, which could be linked to settings of duty, vibrato, etc.

Was just reading about this guy's troubles, so a software issue seems quite possible.

Perhaps it's easier to disable auto-reset until you've found the culprit?

Wow Shiru, looks like you're on a roll!

Since Arduino 1-bit seems all the rage now, I thought I'd give the avra+avrdude combo a try. Works like a charm, successfully produced a beep in asm!

Indeed, 16 MHz is a lot, especially considering the instructions are also super-fast. Guess I'll have to get used to writing purposefully slow asm code. Or just write complex enough routines, heh. Well, for now I'll leave things at "yay, my toolchain works" but next time I get bored with my other projects I might actually go and try writing a dedicated routine for this thing.

Edit: Wow, I just found out that ATmega has a fixed-length, 2-cycle MULtiply instruction. This should make it possible to implement stuff like 1-bit Phase distortion, perhaps even FM.

Awesome! Listening to the demo tune right now, and I can confirm there's no noticable artifact/carrier noise on my setup.

Well, would be great if this gets some exposition on the Arduino forums. If there's enough interest, we might even consider opening a special Arduino sub-board on here.

Alright, sucessfully uploaded garvalf's hex file with avrdude. The ELF doesn't run however, avrdude claims it's not valid. So I guess it's some intermediate thingy that's not meant to be uploaded. Well, no problem for now.

Good to see that the avr-gcc is reasonably efficient. Also, I still think it's very nice that you get annotated output with avr-objdump.

Still not sure if I want to install the latest IDE, especially not alongside the older install. If it were all contained in a standalone Java app then sure, but afaik it installs a ton of other stuff, namely all the avr tools. And I'm afraid checkinstall won't do the trick on this one.

I'm sorry but I don't have any octode demo tunes to offer. Have several snippets laying around but never managed to actually complete a song with it

So, guys, excuse my absolute electronics ignorance, but what would be the most reasonable approach to adding a line-out to this thing? Right now I have a PC speaker attached like garvalf, with some resistor thrown in for good measure.

Well, you have a point. I'll think about it more... perhaps write some simple tool that will convert AVRA source to Arduino syntax.

Anyway, I tried compiling arduino_octode, but I was getting some errors. I think it's because I have a very outdated version (1.0.5, thanks Debian) - it doesn't like PROGMEM and NULL. I got it to compile with defining NULL as 0 and PROGMEM as nothing, but that is not the correct way to do it afaik. I should probably replace the Debian version with a newer one, but given that the sources are like 90 MB I'm not too inclined to do it right now, as it would probably take half a day to compile them on my machine.

Anyway, I was able to extract the resulting ELF file and disassemble it. avr-objdump outputs a pretty nice, commented listing, so I'd say give it a try. Or, if you're having problems with it, send me the ELF files (ctrl-f arduino_octode.cpp.elf) and I'll send you back the asm listings.

Wow, I wouldn't have thought that it's possible to pull this off in C at all. I personally have no interest in programming this thing in C considering the beauty of the AVR m'code instruction set, but still, nice to see it works and is efficient enough.

Regarding the point you mentioned about the while loop, have you checked how the compiler implements this? It should be possible to get the resulting asm code somehow. Afaik the Arduino thing runs on AVR-GCC, so I suppose you could run the code directly through AVR-GCC with -S switch to get the asm output.

I think your stability issues will be related to your PC's USB port. Many PCs have their USB ports improperly configured and/or use crap controllers, which causes them to deliver unstable/out-of-spec current. Since you say that things are fine when running the board off external power, I'm pretty sure that's what's happening here.

I've actually done some AVR code before, it is indeed a very easy chip to code on. I also have a SeinSmart Uno (Chinese Arduino knock-off) laying around somewhere, and I have an asm programming toolchain installed (Arduino IDE is indeed useless for that), though I can't remember what the actual commands for it were.

In any case, I think Z80 emulation on a 16MHz AVR would be tricky, but possible, albeit not without cutting some corners. I think main challenges will be instruction decoding, and dealing with the AVR's big-endianness. I would suggest:

- Emulation of 4 MHz clock speed instead of 3.5, easier to emulate the correct cycle count like that
- Cut all interrupt-related stuff. This would break SpecialFX and Savage, but I think the benefits far outweigh this. Actual interrupts should be handled outside of the Z80 emulation.
- No R register auto-update.
- No emulation of 5,H,3,N flags and MEMPTR.
- DAA replaced with NOP (would break wtbeep, but oh well)

In any case, I would be willing to work on an AVR Z80 emulation. However, I currently have several other ongoing projects that I want to finish first (MDAL, mainly - made some good progress last month but there's still a few major features missing, such as multi-track sequences, "virtual" sequences, and sample support).