Search options (Page 23 of 40)

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).

Whoa, that's very nicely done. Good find, thanks for sharing!

Been doing some thinking about vibratos. Here's an algo that is reasonably fast, has configurable parameters, and doesn't require a table lookup:

    ld hl,0
    ld de,note_divider
    
    ld c,1                    ;vibrato strength (max 0xf)
    ld b,2                    ;position init (must be ½ of vibrSpeed range - else detune)

loop
    add hl,de        ;11
    ld a,h            ;4
    out (#fe),a        ;11

    ld a,e            ;4
    jr nc,noVibrato        ;12/7

    ret nc            ;5        ;timing
vibrDir                    
    inc b            ;4        ;initial direction (probably needed as configurable parameter)
vibrSpeed equ $+1
    bit 2,b            ;8        ;speed (see above, bit 3 -> ld b,4 | bit 2 -> ld b,2...)
    jp z,vibrDown        ;10
                    
vibrUp
    add a,c            ;4        ;DE += C
    ld e,a            ;4
    adc a,d            ;4
    sub e            ;4
    ld d,a            ;4    
    
    jr loop            ;12
                ;96    

vibrDown
    sub c            ;4        ;DE -= C
    ld e,a            ;4
    sbc a,a            ;4    
    add a,d            ;4            
    ld d,a            ;4    
                    
    jr loop            ;12    
                    
    
noVibrato
    ;... waste some t's
    jr loop            ;12
                ;96

I have a feeling that this thing can be optimized further by using an sbc a,a fallthrough solution, but haven't managed to implement it for the downward slide yet. Let me know if you have any ideas for this.

Got a track in the pipes for this. Nothing great, just some simple PhaserX punk rock. Still need to polish it up a bit though.