Sorry, I don't use Github, so unless some uploaded it there, it isn't there. And I doubt anyone did that.

I did it, some time ago, probably with a few modifications:

https://github.com/farvardin/garvuino/t … ino_octode

In that case, what should the licensing rules be?

[...] after some thoughts chose to start from the simplest thing possible - recreating the original Octode engine for Arudino Uno, in C. A very special kind of fun, should I say.[...]

I really appreciate the work

Can this source be found anywhere on Github?

I tried Googling but nothing obvious popped up...

I've added a knob and and I can slowdown the replay of the song:

  current_speed = constrain(map(knob_value,0,1023, 2, 20),2, 20);
/.../
  parser_sync=song_speed*(current_speed/2);

https://picosong.com/wekgx/

#define LED 8
/.../
if(!click_drum_len)
  {
     /.../
  }
  else
  {
    digitalWrite(LED,HIGH);
/.../
}

so now I have a led which pulses during the drum beats!

I'm still working on my AY+SID+1bit player PCB, I should send it soon to the maker!

Very interesting discussion guys.

Welcome to the forum chupo_cro , it's great to see new faces here

Thank you very much for the welcome! :-) I am looking forward to learn from the works presented by forum members and I hope I could add a bit here and there. Although my 'first' assember is Z80 I did write some 6502 code back in the 80s as well so I will be watching for those sound generation routines too.

Well, let's just say everybody has their own goals and methods, alright? For my part, I'm quite interested to hear about yours, chupo_cro (even though I'm personally more interested in coding AVR asm than C). Either way, probably best to continue this discussion in a new thread.

Yes, that would be great :-) I shall these days start a new thread where I'll write you an answer to this post (regarding data format and row transitions) and where we can discuss all kinds of possibilities that could be used for 1-bit sound generation using AVRs/Arduinos programmed in C, assembler or C + inline assembler.

Welcome to the forum chupo_cro , it's great to see new faces here

Now, while I see your reasoning behind it, I think this approach has some drawbacks. The main issue is that you will find few people who are willing to write music for your engine in a text-based format. While music markup languages have some fans (even around here ), the vast majority of users prefer trackers nowadays. And this kind of sheet-music oriented format does not lend itself well to a tracker implementation, since trackers don't care about note lengths. It might be worth considering to "inverse" the length format, so that t1 would be the smallest unit (ie. semi-quaver). This way, it'd be still relatively convenient for transcribing sheet music, while at the same time making tracker support a little easier. The other thing you have to worry about is row transition length. The more complex the data format, the more time you need to decode it - time that you can't spend on synthesis. It's normally not such a big issue with PFM-based synthesis, but once you get into pulse-interleaving/volume faking, you will notice a significant impact on the sound quality. Of course, with something like 10 channels, you have to start worrying about data size as well (so it would make sense to have patterns per channel instead of one pattern for all channels). But for 2 channels, I find split patterns aren't worth it in most cases.

For this particular application I didn't need to know exact cycle count or do assembly optimization. If I was to write AVR assembly code by hand, I sure would know how many cycles it takes - it is common practice to memorize opcode cycles (super easy on AVR), and count them in time critical parts when writing for 8/16 bit systems in assembler.

AVRs are like a 8 bit computer + peripherals, you might soon meet the situation where you would have to know the number of cycles between two events or between two conditions of the system.

I memorized a lot of Z80 opcode cycles and opcodes back in the 80s, I could write 20-30 byte long (or short? :-) ) routines directly in hex - without loading the assembler (Zeus or GENS). Now I still remember only #c9 and a few more opcodes.

Well... Could you notice the interrupt happening just in between loading or storing the 2-byte variable and ruining the result by just observing the code? ;-)

For this particular application I didn't need to know exact cycle count or do assembly optimization. If I was to write AVR assembly code by hand, I sure would know how many cycles it takes - it is common practice to memorize opcode cycles (super easy on AVR), and count them in time critical parts when writing for 8/16 bit systems in assembler.

What I needed was just to see compiler generated code, to check if particular changes in C code makes resulting code longer or shorter, which is totally enough to estimate efficiency of edits - another common practice when writing for 8/16 bit systems in C. It is super simple task, I don't see why it should be overcomplicated like that with all that porting to other environments, using simulators, debuggers, and stuff like that. All it really takes is just a quick glance at the compiler output, which is normally fully exposed to the user. It is just an Arduino IDE's quirk that it hides the intermediate assembly.

Thanks for explaination of the issue.

As for looking up to the generated code, I have my doubts about these ideas. First, I just need to see what compiler spits out, in order to see how efficiently certain C code compiles with certain C compiler. That's purely software issue, normally you don't even have to do anything to just get the intermediate assembly output. Using simulators, switching platforms, using JTAG or any extra HW is all total overkill for this. Also, I doubt that latest Arduino and AVR Studio 4.18 use the same exact C compiler with same exact options, and if this is not the case, it just won't help at all.

I have no doubts that a lot more can be pulled off with Arduino or plain AVR. Something along the lines of Casio CZ series or Korg Poly 800 (with external filter) should be totally doable. We here not trying to squeeze out all that is possible, we're just playing with concepts of porting over ZX beeper engines, with all their quirks and specifics, and maybe applying some of this experience to do like 'super' versions of those engines. And using Arduino over plain AVR is an important feature, because that's certainly more accessible platform for strangers and newcomers.

Yes, I am aware the primary goal is to port the Spectrum's sound engines to Arduino. I agree JTAG might be an overkill but when I saw $7 Chineese JTAG ICEs that connect to USB port I just had to buy one to see how/if it works - despite I most of the time use just five wires as a 'programmer'.

While code generated by Arduino IDE and old AVR Studio is not the same, the compiler is - in both cases avr-gcc is used to compile the code (although in Arduino you can use C++ in addition to C). One of the reasons why I said it is better to use an old AVR studio than new Atmel Studio is because old compiler produces smaller and mostly faster code. Despite Arduino beeing a target platform it is much easier to develop/debug the routines using old AVR Studio (good simulator, disassembler and cheap in circuit debugger) and to make just a few small modifications to move the code to Arduino IDE when everything works as expected. When I modified your Phaser1 code to work with bare metal ATmegax, I just had to remove loop() and move the code to main(), insert a call to setup(), get rid of boolean, insert a few #includes and make cast from pointer to int. The other way would be as easy too. Then, if you noticed that Arduino's compiler produced worse code than old avr-gcc, you could just insert a few lines of inline assembler. But 16 MHz AVR with just 1-5 cycle instructions is fast enough so I don't think there would be a need for assembly optimizations.

But still, fast and precise count of the cycles between two instructions is something that should be available at all the times. For that you might use a simulator which is part of the AVR Studio, or an oscilloscope (toggle the pin upon entering and before leaving the interrupt routine) or use Proteus vith virtual oscilloscope.

Although I don't have Arduino I do use Arduino IDE to write code for ESP8266 so I was examining the Arduino sources. That way I know Arduino is using Timer0 to do some things, the Timer0 is used by delay(), millis(), micros() etc. I might be wrong but I believe the sound generation routines might work better if Timer0 interrupt would be disabled (unless not used by the sound routine itself). In that case the delay() wouldn't work but you can #include <util/delay.h> and use _delay_ms() which does not use interrupts. Although I don't think the delay needs to be used in a sound generation routine.