home.social

#makerfail — Public Fediverse posts

Live and recent posts from across the Fediverse tagged #makerfail, aggregated by home.social.

  1. diyelectromusic @[email protected] ·

    So, annoyingly after thinking I might have had a bit of a breakthrough, it turns out I was chasing my tail and it seems like I'm back to square one...

    I'm going to have to have a break from this for a bit, as I'm running out of options at the moment.

    diyelectromusic.com/2026/05/24

    #Arduino #ATmega328 #AY38910 #MakerFail #Sigh

    #arduino #atmega328 #ay38910 #makerfail #sigh
  2. diyelectromusic @[email protected] ·

    So, annoyingly after thinking I might have had a bit of a breakthrough, it turns out I was chasing my tail and it seems like I'm back to square one...

    I'm going to have to have a break from this for a bit, as I'm running out of options at the moment.

    diyelectromusic.com/2026/05/24

    #Arduino #ATmega328 #AY38910 #MakerFail #Sigh

    #arduino #atmega328 #ay38910 #makerfail #sigh
  3. diyelectromusic @[email protected] ·

    So, annoyingly after thinking I might have had a bit of a breakthrough, it turns out I was chasing my tail and it seems like I'm back to square one...

    I'm going to have to have a break from this for a bit, as I'm running out of options at the moment.

    diyelectromusic.com/2026/05/24

    #Arduino #ATmega328 #AY38910 #MakerFail #Sigh

    #arduino #atmega328 #ay38910 #makerfail #sigh
  4. diyelectromusic @[email protected] ·

    So, annoyingly after thinking I might have had a bit of a breakthrough, it turns out I was chasing my tail and it seems like I'm back to square one...

    I'm going to have to have a break from this for a bit, as I'm running out of options at the moment.

    diyelectromusic.com/2026/05/24

    #Arduino #ATmega328 #AY38910 #MakerFail #Sigh

    #sigh #makerfail #ay38910 #atmega328 #arduino
  5. diyelectromusic @[email protected] ·

    So, annoyingly after thinking I might have had a bit of a breakthrough, it turns out I was chasing my tail and it seems like I'm back to square one...

    I'm going to have to have a break from this for a bit, as I'm running out of options at the moment.

    diyelectromusic.com/2026/05/24

    #Arduino #ATmega328 #AY38910 #MakerFail #Sigh

    #arduino #atmega328 #ay38910 #makerfail #sigh
  6. diyelectromusic @[email protected] ·

    Ok, so either I'm missing something (again) or some of my assumptions are wrong, but I've tried everything I can think of so far on this one and it still isn't working.

    Any experts on overclocking AVRs and the difference between ATMega48 and ATMega328P out there?

    This is on pause for a bit while I ponder some more :)

    diyelectromusic.com/2026/05/16

    #AY3910 #Arduino #MakerFail

    #ay3910 #arduino #makerfail
  7. diyelectromusic @[email protected] ·

    Ok, so either I'm missing something (again) or some of my assumptions are wrong, but I've tried everything I can think of so far on this one and it still isn't working.

    Any experts on overclocking AVRs and the difference between ATMega48 and ATMega328P out there?

    This is on pause for a bit while I ponder some more :)

    diyelectromusic.com/2026/05/16

    #AY3910 #Arduino #MakerFail

    #ay3910 #arduino #makerfail
  8. diyelectromusic @[email protected] ·

    Ok, so either I'm missing something (again) or some of my assumptions are wrong, but I've tried everything I can think of so far on this one and it still isn't working.

    Any experts on overclocking AVRs and the difference between ATMega48 and ATMega328P out there?

    This is on pause for a bit while I ponder some more :)

    diyelectromusic.com/2026/05/16

    #AY3910 #Arduino #MakerFail

    #ay3910 #arduino #makerfail
  9. diyelectromusic @[email protected] ·

    Ok, so either I'm missing something (again) or some of my assumptions are wrong, but I've tried everything I can think of so far on this one and it still isn't working.

    Any experts on overclocking AVRs and the difference between ATMega48 and ATMega328P out there?

    This is on pause for a bit while I ponder some more :)

    diyelectromusic.com/2026/05/16

    #AY3910 #Arduino #MakerFail

    #makerfail #arduino #ay3910
  10. diyelectromusic @[email protected] ·

    Ok, so either I'm missing something (again) or some of my assumptions are wrong, but I've tried everything I can think of so far on this one and it still isn't working.

    Any experts on overclocking AVRs and the difference between ATMega48 and ATMega328P out there?

    This is on pause for a bit while I ponder some more :)

    diyelectromusic.com/2026/05/16

    #AY3910 #Arduino #MakerFail

    #ay3910 #arduino #makerfail
  11. Simple DIY Electronic Music Projects @[email protected] ·

    AY-3-8912/8910 Hardware Emulation – Part 2

    Having explored how an AVR can be used to emulate the AY-3-8912/8910 in AY-3-8912/8910 Hardware Emulation I wanted to have a go at using the very common ATMega328P to do the same. But rather than wire things up on breadboard, I put together a quick PCB to allow me to do some experiments.

    Spoilers: This isn’t working yet!! Read on for where I’ve got to, but I’ll need to come back to this at some point.

    Warning! I strongly recommend using old or second hand equipment for your experiments.  I am not responsible for any damage to expensive instruments!

    If you are new to electronics and microcontrollers, see the Getting Started pages.

    The Circuit

    This is essentially the circuit from here: https://github.com/Yevgeniy-Olexandrenko/avr-ay-board

    But with an ATMega328P rather than the suggested ATMega48PA (more about that in part one here: AY-3-8912/8910 Hardware Emulation). I’ve included headers for both the AY-3-8910 and AY-3-8912.

    I’ve kept the same usage of ATMega ports, which map onto IO for the ATMega328P as follows:

    AY-3-8912SchematicATMega328P PORTATMega328P PinArduino EquivalentD0-D5DA0-DA5PC0-PC523-28A0-A5D6-D7DA6-DA7PD6-PD712-13D6-D7A8A8_CIPOPB418D12BC1BC1PD24D2BC2BC2_SCKPB519D13BDIRBDIRPD35D3CLOCKCLOCKPD46D4RESETRESETPC61RESETTESTN/CIOA7-IOA0N/CCPWM_CPB216D10BPWM_B_COPIPB317D11APWM_APB115D9A9_CFG0PB014D8CFG1PD56D5RXPD02D0TXPD13D1VCCVCCVCC7, 20VCCGNDGNDGND8GND

    The only change is I’m not connecting TEST to anything. I’ll have to see if this becomes an issue later…

    The circuit calls for overclocking the ATMega328P to 27MHz (again more discussion on this in the first part).

    I’ve included breakout headers for ICSP and a serial header.

    • Update: Turns out the header is back to front! See later…

    I have also swapped the oscillator to a crystal using a common configuration I’ve seen on many DIY Arduino-style boards using an ATMega328P.

    Rather than put together two boards, one for the 8912 and one for the 8910, I’ve also put together a simple adaptor circuit to allow one to plug into the socket for the other.

    The schematic essentially just maps the signals from one footprint onto the other.

    The only slight complication is that /A9 for the 8910 doesn’t exist on the 8912, so I’ve left in a jumper to provide the option of tying this to GND or VCC should the need arise. This should allow the larger 8910 to be used in the place where a 8912 is required whilst still enabling the 8910.

    PCB Design

    I did wonder quite how much of a 28 pin DIP could fit inside the footprint of a 28 pin WDIP and still keep through hole components, but I didn’t have to wonder for long to see it wasn’t really going to work.

    So as this is basically just for messing around I went with the format as shown. This way, round-profile pin headers can be used on the underside for the AY footprint if the board is to replace a genuine device. Alternatively normal pin headers or sockets can be used on the topside if jumper wires are going to be used to hook this board into another PCB.

    The two CFG jumpers are solder bridges (default not connected) on the underside of the board. I’ve also listed the Arduino versions of the AVR pins used on the underside too.

    For the converter board, I’ve left the /A9 jumper as standard pin headers. With hindsight I’m not sure when this would be wanted to be tied high, as presumably that would disable the chip. When plugging a 8912 into a 8910 socket, anything expecting an 8910 and using /A9 as part of the addressing scheme would require some additional logic before mapping it onto the smaller 8912.

    Errata

    The ICSP header is swapped to what is required. This will still work as long as the header is populated on the reverse of the board…

    From the top/silkscreen, the header has the following pinout (viewed from the top, ATMega328 on the left).

    RESETGNDCLKCOPICIPOVCC (square pad)

    Bill of Materials

    AVR-AY Emulator Board:

    • AVR-AY-Board PCB (GitHub link below).
    • ATMega329P (28 pin DIP version).
    • 1x 1K resistor
    • 3x 3K6 resistors
    • 1x 10K resistor
    • 1x 10uF electrolytic capacitor
    • 2x 100nF ceramic capacitors
    • 3x 2.2nF ceramic capacitors
    • 2x 18pF ceramic capacitors
    • 1x 3mm LED (colour to taste)
    • 1x 27 MHz crystal (2 pin, low-profile, HC-49 package – see footprints)
    • 1x 2-pin momentary push switch (see footprints)
    • Optional: 28-way narrow DIP socket
    • Optional: round-pin header pins (see photos and discussion)
    • Range of pin headers or sockets as required

    AY-3-8910 to 12 Converter:

    • AY-3-8910-12 Converter PCB (GitHub link below).
    • Either 40-pin WDIP socket or 28-pin WDIP socket.
    • Round-pin header pins.

    AY-3-8910 to 12 Converter Build

    This is a relatively straight forward build, but depending on the DIP sockets used it might be necessary to doctor the socket slightly to sit neatly over the soldered pins.

    Order of build:

    • Round pins for either the 28 pin or 40 pin part of the PCB.
    • The 40 pin or 28 pin DIP socket.

    If the converter is from a 8912 socket to a 8910 device, then the /A9 jumper or a solder link will have to be configured, presumably connecting it to GND to make it permanently active.

    One note of caution – the pins I was using are not particularly robust, so when removing the adaptor from its socket, I managed to break one and had to replace it, which wasn’t easy.

    But apart from that, it works!

    AVR AY Board

    As already mentioned there are a number of configuration options for the 28-pin AY-3-8910 emulation as illustrated below.

    The first two are designed for jumper wire connections. The third shows the use of pins which would allow the board, space permitting, to be inserted into a AY-3-8910 socket on an existing board.

    These headers will be soldered on last, but it is worth deciding in advance what configuration will be required.

    I’ve chosen not to populate the UART and ICSP headers, and am using round pins so that this can hopefully replace an AY-3-8912. But at the moment all my test boards are built for the AY-3-8910, so I’m also having to use the converter, which has led to the following stack of boards!

    ATMega328P Programming

    The stand-alone ATMega328P chip cannot be programmed directly from the Arduino IDE with this code as it stands. Instead the following are required:

    • AVRDude: https://github.com/avrdudes/avrdude
    • An AVR Programmer: I’m using a cheap USBasp clone, so one based on this: https://github.com/piit79/USBasp
    • Connection to the device via ICSP: I’m using a homemade link, but it should be possible to use the ICSP header on the PCB (however see previous warning about the pinout error!); plug it into a DIP-version of another Arduino Uno board; or possibly even a second Arduino Uno board in “Arduino as ISP” mode.

    The firmware should be downloaded from https://github.com/Yevgeniy-Olexandrenko/avr-ay-board.

    Update: I ended up using a slightly different firmware and configuration – see later…

    I’m using v1.0 of the firmware and have downloaded the binary firmware and the 1.75MHz configuration. I now have the following files:

    C:\Kevin\Temp> dir
    09/05/2026  15:49    <DIR>          .
    09/05/2026  15:49    <DIR>          ..
    09/05/2026  15:49             1,920 avr-psg.hex
    09/05/2026  15:40           909,660 avrdude.conf
    09/05/2026  15:40         9,604,608 avrdude.exe
    09/05/2026  15:40        13,316,096 avrdude.pdb
    09/05/2026  15:49                34 config-1.75mhz.hex
    C:\Kevin\Temp>

    To program the ATMega328P requires the following instructions to get the code into flash, the configuration into EEPROM and to set the fuses for the MCU:

    C:\Kevin\Temp>avrdude -c USBasp -p ATMega328P -U flash:w:avr-psg.hex:i
    Error: cannot set sck period; please check for usbasp firmware update
    Error: cannot set sck period; please check for usbasp firmware update
    Reading 682 bytes for flash from input file avr-psg.hex
    Writing 682 bytes to flash
    Writing | ################################################## | 100% 0.43 s
    Reading | ################################################## | 100% 0.23 s
    682 bytes of flash verified

    Avrdude done.  Thank you.


    C:\Kevin\Temp>avrdude -c USBasp -p ATMega328P -U eeprom:w:config-1.75mhz.hex:i
    Error: cannot set sck period; please check for usbasp firmware update
    Reading 5 bytes for eeprom from input file config-1.75mhz.hex
    Writing 5 bytes to eeprom
    Writing | ################################################## | 100% 0.09 s
    Reading | ################################################## | 100% 0.01 s
    5 bytes of eeprom verified

    Avrdude done.  Thank you.

    C:\Kevin\Test>avrdude -c USBasp -p ATMega328P -U lfuse:w:0xdf:m -U hfuse:w:0xdf:m -U efuse:w:0xfd:m
    Error: cannot set sck period; please check for usbasp firmware update

    Processing -U lfuse:w:0xdf:m
    Reading 1 byte for lfuse from input file 0xdf
    Writing 1 byte (0xDF) to lfuse, 1 byte written, 1 verified

    Processing -U hfuse:w:0xdf:m
    Reading 1 byte for hfuse from input file 0xdf
    Writing 1 byte (0xDF) to hfuse, 1 byte written, 1 verified

    Processing -U efuse:w:0xfd:m
    Reading 1 byte for efuse from input file 0xfd
    Writing 1 byte (0xFD) to efuse, 1 byte written, 1 verified

    Avrdude done.  Thank you.

    The error “cannot set sck period” is apparently pretty common especially with USBasp clones, and can be ignored.

    The three fuse settings come from the original AVR-AY firmware (here) in the readme as follows:

    ATMEGA328 ===================================================
    	avrdude -p m328p -c USBasp -U flash:w:AY_Emul_XXX_Nch_KK_MM.hex -U eeprom:w:Conf_XXX_YYMHz_ZZMhz.hex -U lfuse:w:0xee:m -U hfuse:w:0xdf:m -U efuse:w:0xfd:m
    Example:
    	avrdude -p m328p -c USBasp -U flash:w:AY_Emul_250_2ch_m328_ay.hex -U eeprom:w:Conf_standard_27MHz_1_75Mhz.hex -U lfuse:w:0xee:m -U hfuse:w:0xdf:m -U efuse:w:0xfd:m
    =============================================================

    But where the fuse settings for lfuse = 0xEE, when decoded from the ATMega328P datasheet and an online AVR fuse calculator here: https://eleccelerator.com/fusecalc/fusecalc.php?chip=atmega328p means the following:

    0xEE = b1110 1110
    CKDIV8 = 1 (unprogrammed)
    CLKOUT = 1 (unprogrammed)
    SUT    = 10
    CLKSEL = 1110

    Which from the AVR fusecalc site maps onto:

    • External crystal oscillator
    • Frequency 8MHz +
    • Start up time 1K
    • Powerdown/reset 16

    However, following through the settings in the datasheet, it is similar but slightly different, giving:

    • Low power crystal oscillator (CLKSEL3:0 = 1111 – 1000)
    • Low power operating mode 111 = 8.0-16.0 MHz (with recommended caps 12-22pF)
    • CLKSEL0+SUT = 0+10 = Ceramic Resonator BOD enabled, Start up time 1KCK, additional delay 14CK

    But I’m not using a ceramic resonator, I’m using a crystal oscillator, so I think I need the mode:

    • Crystal oscillator BOD enabled, startup time 16KCK, additional delay 14CK = CLKSEL0+SUT = 1+01

    There is no “1KCK” for the crystal oscillator settings, so I’ll have to use 16KCK I guess?

    This is what gives me the 0xDF value I’ve used:

    0xDF = b1101 1111
    CKDIV8 = 1 (unprogrammed)
    CLKOUT = 1 (unprogrammed)
    SUT    = 01
    CLKSEL = 1111

    Actually, this wasn’t working with either 0xEE or 0xDF, so I decide to try to turn off BOD and went with “slow rising power” (CLKSEL0+SUT = 1+11) which gave me the fuses:

    lfuse = b1111 1111 = 0xFF
    hfuse = 0xDF (as before)
    efuse = 0xFF (no brown-out detection)

    But that isn’t working either…

    The AY891x Library and BCn/BCDIR control

    Eventually, I remembered reading about the control signals with the library that was designed for use with that test board. It states the following (here):

    “While the PSG has tight timing requirements, it is possible to use digitalWrite() by using all three bus control signals (BDIR, BC1, BC2) and cycling through an extra state when reading and writing the chip registers.”

    But the emulation is ignoring BC2 (more here), relying instead on the ATMega’s two IO interrupt pins INT0 and INT1 on D2 and D3, to trigger on BDIR and BC1. This means I had to ditch the library and instead switched over to my own PORT IO driver as described here: Arduino and AY-3-8910 – Part 3.

    Resetting the fuses as before, unfortunately it still isn’t working.

    At this point I loaded on a simple tone() function on one of the IO pins using the Arduino IDE then set the fuses again as above. I can definitely see that the frequency for the tone() output is almost twice as high as when the ATMega328P is plugged into the Arduino, so the 27MHz crystal is certainly having an effect compared to the Uno’s original 16MHz.

    I can also see the 105kHz PWM carrier frequency on all three PWM output pins, but the peaks are so narrow, these must be responding to a level 0 output which implies all code is working, but there are simply no register writes getting through.

    So, in summary, I think the code on the emulator is running fine – so why isn’t it responding to register writes?

    An Epiphany?

    At this point I left things for a bit and came back to it all a few days later.

    I was chewing over why the register writes didn’t seem to be getting through, so at this point I think the handling of BC1 and BDIR are key. The next things that I tried:

    • Getting it all on a breadboard and showing it working with a real AY-3-8910.
    • Check I can see BC1 and BDIR and the data lines doing something.
    • Replace the real chip with the emulator.
    • Repeat the tests for BC1, BDIR and data – all appear ok.

    At this point I’m suspecting the interrupts aren’t getting through (remember BC1 and BDIR are triggered off the external interrupts), so I’m contemplating two things:

    • Some test code that lights an LED on an external interrupt.
    • Porting the whole code across to the Arduino environment to let me build and run it all from there.

    But this has got me wondering about build differences for the two devices – what might be different between the ATMega48 and ATMega328P. Would rebuilding from source for the ATMega328P sort it out?

    Looking at the original code, I can see there are many different binaries for the different chips. For the repository I’m using there is just one.

    Looking in the two chip datasheets, I can see that the INT0 interrupt vector is different – it is 2 (address 0x001) for the 48 and whist it is still 2 for the 328P, the address is 0x0002. From the 48 datasheet:

    “Each interrupt vector occupies two instruction words in ATmega168, and one instruction word in ATmega48 and
    ATmega88.”

    From the 328P datasheet:

    “Each interrupt vector occupies two instruction words in Atmel ATmega328P.”

    Looking at the suggested implementations of the vector tables, they are shown as follows:

    // ATMega48 vector table
    0x000 rjmp RESET      ; Reset Handler
    0x001 rjmp EXT_INT0   ; IRQ0 Handler
    0x002 rjmp EXT_INT1   ; IRQ1 Handler

    // ATMega328P vector table
    0x0000 jmp RESET      ; Reset Handler
    0x0002 jmp EXT_INT0   ; IRQ0 Handler
    0x0004 jmp EXT_INT1   ; IRQ1 Handler

    So presumably one is a relative jump (rjmp) which is a single word (16-bit) instruction, vs an absolute jump which is a two-word (32-bit) instruction.

    With hindsight is seems obvious I’d need to rebuild for the ATMega328P, but the initial talk of compatibility lulled me into a false sense of security!

    There is no build for the 328P in the listed repository, but going back to the original avr-ay source, there are builds for all supported MCUs, each with variants covering:

    • 2 or 3 channel sound.
    • AY or YM volume tables.
    • Additional speaker output on PD1.

    There are configuration options for:

    • Serial, parallel, or both (“standard”).
    • 1.75MHz, 1.78MHz, or 2.0MHz operation.
    • 20MHz to 40MHz (including my required 27MHz).

    I’ve now downloaded:

    avrdude -c USBasp -p ATMega328P -U flash:w:AY_Emul_260_3ch_m328_ay.hex:i
    avrdude -c USBasp -p ATMega328P -U eeprom:w:Conf_parallel_27MHz_1_78Mhz.hex:i
    avrdude -c USBasp -p ATMega328P -U lfuse:w:0xee:m -Uhfuse:w:0xdf:m -U efuse:w:0xfd:m

    But unfortunately it still isn’t working…

    I did notice in the original source, a number of conditional assembler code, based on the initial configuration of MCU_TYPE. But most of it is of the form “if MCU_TYPE==0” which is giving alternative code for the ATMega8. There is one piece of code that implies something different for the ATMega48:

    	; get byte 0 from EEPROM, check value > 0 or skip USART initialization if value = 0
    #if MCU_TYPE == 0 ||  MCU_TYPE > 1
    	out		EEARH,C00		; is absent in Atmega48
    #endif
    	out		EEARL,C00

    I also note that the vector table is all relative jumps:

    	.cseg
    ;------------------------------------------------------
    ; INTERRUPT VECTORS TABLE
    ;------------------------------------------------------
    	.org	0x0000
    	rjmp	_RESET

    	.org	INT0addr
    	rjmp	_INT0_Handler

    	.org	INT1addr
     	rjmp	_INT1_Handler

    	.org	URXCaddr
    	rjmp	_USART_RX_COMPLETE

    But as each entry has its own origin statement, one presumes that these are correct for the MCU type.

    Double checking the hex records for my chosen firmware, and adding some expansions and annotations, I can see:

    // Format:
    // :ll aaaa tt dd..dd cc
    //                    ++-- CRC
    //             +----+----- Data
    //          ++------------ Record type
    //     +--+--------------- Address
    //  ++-------------------- Data length

    :02 0000 02 0000 FC  // tt=02: Extended (Upper) Segment Base Address

    // Vector Table tt=00: Data
    :02 0000 00 88C0 B6
    :02 0004 00 4AC0 F0
    :02 0008 00 56C0 E0

    // Start of code/data tt=00; Data
    :10 0048 00 50C0000101010202030506090D11161D 29
    :10 0058 00 242D0000010101010101020202020303 33
    :10 0068 00 0505060607090B0D0F111316191D2024 87
    ...
    :10 02F8 00 0092880010928A0092CF05910D932A95 5A
    :04 0308 00 E1F70895 7C
    :00 0000 01 FF       // tt=01: End of File

    So yes, it would appear that the vectors in the vector table are indeed on the expected 32-bit boundaries which matches and it has values for vectors 2 and 3, so INT0 and INT1. Vector 1 is RESET.

    One oddity, each record is only 2 bytes long, so I guess it is assuming that the missing bytes will be zero? Really, the full records should perhaps be:

    :04 0000 00 88C00000 B4 // Needed to recalc CRC
    :04 0004 00 4AC00000 EE
    :04 0008 00 56C00000 DE

    I don’t know the algorithm for calculating the CRC, but I don’t need to. When attempting to download via avrdude any CRC mismatch is reported, detailing what value was expected which allows me to set the correct value for each line at a time!

    But as these are instructions rather than addresses themselves, maybe it would be fine. If the PC hits this address, then the instruction will be (presumably) a rjmp which is only two bytes and all would be fine.

    But regardless, unfortunately this still isn’t working. I’m now at quite a loss as to what to try next.

    I did go back and look at the original firmware I was using and it has the following:

    :06 0000 00 70C039C045C0 CC

    So I don’t see how this would work on an ATMega328P at all as each vector is only half the expected size.

    The reset vector is probably ok, as the first two bytes will be read as a “rjmp” instruction and presumably the next two bytes ignored. But INT0 and INT1 will be jumping off into who-knows-where.

    This would match the evidence that the board seems to get initialised but no register writes are processed.

    So this at least does confirm that the original firmware was no good for me.

    Conclusion

    I’ve got to draw a line under this for now. I’m going to hit publish on this post as is, and put this aside for a bit.

    Some possible future directions:

    • Solder on the ICSP header to make uploading code a bit easier.
    • Load up some simple Arduino firmware that will indicate if INT0/INT1 are actually getting through.
    • Create a ATMega48 breakout to see if the board would work with the original MCU ok.
    • I’m still not convinced with that clock – it seems a very low amplitude – I wonder if those capacitors are the right values.
    • Port the whole lot to the Arduino environment. This is going to be a fair bit of work as you can’t use assembler directly, but only via asm(“nop”) style directives…

    But for now, this one is on pause.

    And I’m still annoyed about the error in the ICSP pinout…

    Kevin

    #arduino #atmega328 #ay38910 #ay38912 #emulation #MakerFail #pcbs
    #arduino #atmega328 #ay38910 #ay38912 #emulation #makerfail
  12. Simple DIY Electronic Music Projects @[email protected] ·

    AY-3-8912/8910 Hardware Emulation – Part 2

    Having explored how an AVR can be used to emulate the AY-3-8912/8910 in AY-3-8912/8910 Hardware Emulation I wanted to have a go at using the very common ATMega328P to do the same. But rather than wire things up on breadboard, I put together a quick PCB to allow me to do some experiments.

    Spoilers: This isn’t working yet!! Read on for where I’ve got to, but I’ll need to come back to this at some point.

    Warning! I strongly recommend using old or second hand equipment for your experiments.  I am not responsible for any damage to expensive instruments!

    If you are new to electronics and microcontrollers, see the Getting Started pages.

    The Circuit

    This is essentially the circuit from here: https://github.com/Yevgeniy-Olexandrenko/avr-ay-board

    But with an ATMega328P rather than the suggested ATMega48PA (more about that in part one here: AY-3-8912/8910 Hardware Emulation). I’ve included headers for both the AY-3-8910 and AY-3-8912.

    I’ve kept the same usage of ATMega ports, which map onto IO for the ATMega328P as follows:

    AY-3-8912SchematicATMega328P PORTATMega328P PinArduino EquivalentD0-D5DA0-DA5PC0-PC523-28A0-A5D6-D7DA6-DA7PD6-PD712-13D6-D7A8A8_CIPOPB418D12BC1BC1PD24D2BC2BC2_SCKPB519D13BDIRBDIRPD35D3CLOCKCLOCKPD46D4RESETRESETPC61RESETTESTN/CIOA7-IOA0N/CCPWM_CPB216D10BPWM_B_COPIPB317D11APWM_APB115D9A9_CFG0PB014D8CFG1PD56D5RXPD02D0TXPD13D1VCCVCCVCC7, 20VCCGNDGNDGND8GND

    The only change is I’m not connecting TEST to anything. I’ll have to see if this becomes an issue later…

    The circuit calls for overclocking the ATMega328P to 27MHz (again more discussion on this in the first part).

    I’ve included breakout headers for ICSP and a serial header.

    • Update: Turns out the header is back to front! See later…

    I have also swapped the oscillator to a crystal using a common configuration I’ve seen on many DIY Arduino-style boards using an ATMega328P.

    Rather than put together two boards, one for the 8912 and one for the 8910, I’ve also put together a simple adaptor circuit to allow one to plug into the socket for the other.

    The schematic essentially just maps the signals from one footprint onto the other.

    The only slight complication is that /A9 for the 8910 doesn’t exist on the 8912, so I’ve left in a jumper to provide the option of tying this to GND or VCC should the need arise. This should allow the larger 8910 to be used in the place where a 8912 is required whilst still enabling the 8910.

    PCB Design

    I did wonder quite how much of a 28 pin DIP could fit inside the footprint of a 28 pin WDIP and still keep through hole components, but I didn’t have to wonder for long to see it wasn’t really going to work.

    So as this is basically just for messing around I went with the format as shown. This way, round-profile pin headers can be used on the underside for the AY footprint if the board is to replace a genuine device. Alternatively normal pin headers or sockets can be used on the topside if jumper wires are going to be used to hook this board into another PCB.

    The two CFG jumpers are solder bridges (default not connected) on the underside of the board. I’ve also listed the Arduino versions of the AVR pins used on the underside too.

    For the converter board, I’ve left the /A9 jumper as standard pin headers. With hindsight I’m not sure when this would be wanted to be tied high, as presumably that would disable the chip. When plugging a 8912 into a 8910 socket, anything expecting an 8910 and using /A9 as part of the addressing scheme would require some additional logic before mapping it onto the smaller 8912.

    Errata

    The ICSP header is swapped to what is required. This will still work as long as the header is populated on the reverse of the board…

    From the top/silkscreen, the header has the following pinout (viewed from the top, ATMega328 on the left).

    RESETGNDCLKCOPICIPOVCC (square pad)

    Bill of Materials

    AVR-AY Emulator Board:

    • AVR-AY-Board PCB (GitHub link below).
    • ATMega329P (28 pin DIP version).
    • 1x 1K resistor
    • 3x 3K6 resistors
    • 1x 10K resistor
    • 1x 10uF electrolytic capacitor
    • 2x 100nF ceramic capacitors
    • 3x 2.2nF ceramic capacitors
    • 2x 18pF ceramic capacitors
    • 1x 3mm LED (colour to taste)
    • 1x 27 MHz crystal (2 pin, low-profile, HC-49 package – see footprints)
    • 1x 2-pin momentary push switch (see footprints)
    • Optional: 28-way narrow DIP socket
    • Optional: round-pin header pins (see photos and discussion)
    • Range of pin headers or sockets as required

    AY-3-8910 to 12 Converter:

    • AY-3-8910-12 Converter PCB (GitHub link below).
    • Either 40-pin WDIP socket or 28-pin WDIP socket.
    • Round-pin header pins.

    AY-3-8910 to 12 Converter Build

    This is a relatively straight forward build, but depending on the DIP sockets used it might be necessary to doctor the socket slightly to sit neatly over the soldered pins.

    Order of build:

    • Round pins for either the 28 pin or 40 pin part of the PCB.
    • The 40 pin or 28 pin DIP socket.

    If the converter is from a 8912 socket to a 8910 device, then the /A9 jumper or a solder link will have to be configured, presumably connecting it to GND to make it permanently active.

    One note of caution – the pins I was using are not particularly robust, so when removing the adaptor from its socket, I managed to break one and had to replace it, which wasn’t easy.

    But apart from that, it works!

    AVR AY Board

    As already mentioned there are a number of configuration options for the 28-pin AY-3-8910 emulation as illustrated below.

    The first two are designed for jumper wire connections. The third shows the use of pins which would allow the board, space permitting, to be inserted into a AY-3-8910 socket on an existing board.

    These headers will be soldered on last, but it is worth deciding in advance what configuration will be required.

    I’ve chosen not to populate the UART and ICSP headers, and am using round pins so that this can hopefully replace an AY-3-8912. But at the moment all my test boards are built for the AY-3-8910, so I’m also having to use the converter, which has led to the following stack of boards!

    ATMega328P Programming

    The stand-alone ATMega328P chip cannot be programmed directly from the Arduino IDE with this code as it stands. Instead the following are required:

    • AVRDude: https://github.com/avrdudes/avrdude
    • An AVR Programmer: I’m using a cheap USBasp clone, so one based on this: https://github.com/piit79/USBasp
    • Connection to the device via ICSP: I’m using a homemade link, but it should be possible to use the ICSP header on the PCB (however see previous warning about the pinout error!); plug it into a DIP-version of another Arduino Uno board; or possibly even a second Arduino Uno board in “Arduino as ISP” mode.

    The firmware should be downloaded from https://github.com/Yevgeniy-Olexandrenko/avr-ay-board.

    Update: I ended up using a slightly different firmware and configuration – see later…

    I’m using v1.0 of the firmware and have downloaded the binary firmware and the 1.75MHz configuration. I now have the following files:

    C:\Kevin\Temp> dir
    09/05/2026  15:49    <DIR>          .
    09/05/2026  15:49    <DIR>          ..
    09/05/2026  15:49             1,920 avr-psg.hex
    09/05/2026  15:40           909,660 avrdude.conf
    09/05/2026  15:40         9,604,608 avrdude.exe
    09/05/2026  15:40        13,316,096 avrdude.pdb
    09/05/2026  15:49                34 config-1.75mhz.hex
    C:\Kevin\Temp>

    To program the ATMega328P requires the following instructions to get the code into flash, the configuration into EEPROM and to set the fuses for the MCU:

    C:\Kevin\Temp>avrdude -c USBasp -p ATMega328P -U flash:w:avr-psg.hex:i
    Error: cannot set sck period; please check for usbasp firmware update
    Error: cannot set sck period; please check for usbasp firmware update
    Reading 682 bytes for flash from input file avr-psg.hex
    Writing 682 bytes to flash
    Writing | ################################################## | 100% 0.43 s
    Reading | ################################################## | 100% 0.23 s
    682 bytes of flash verified

    Avrdude done.  Thank you.


    C:\Kevin\Temp>avrdude -c USBasp -p ATMega328P -U eeprom:w:config-1.75mhz.hex:i
    Error: cannot set sck period; please check for usbasp firmware update
    Reading 5 bytes for eeprom from input file config-1.75mhz.hex
    Writing 5 bytes to eeprom
    Writing | ################################################## | 100% 0.09 s
    Reading | ################################################## | 100% 0.01 s
    5 bytes of eeprom verified

    Avrdude done.  Thank you.

    C:\Kevin\Test>avrdude -c USBasp -p ATMega328P -U lfuse:w:0xdf:m -U hfuse:w:0xdf:m -U efuse:w:0xfd:m
    Error: cannot set sck period; please check for usbasp firmware update

    Processing -U lfuse:w:0xdf:m
    Reading 1 byte for lfuse from input file 0xdf
    Writing 1 byte (0xDF) to lfuse, 1 byte written, 1 verified

    Processing -U hfuse:w:0xdf:m
    Reading 1 byte for hfuse from input file 0xdf
    Writing 1 byte (0xDF) to hfuse, 1 byte written, 1 verified

    Processing -U efuse:w:0xfd:m
    Reading 1 byte for efuse from input file 0xfd
    Writing 1 byte (0xFD) to efuse, 1 byte written, 1 verified

    Avrdude done.  Thank you.

    The error “cannot set sck period” is apparently pretty common especially with USBasp clones, and can be ignored.

    The three fuse settings come from the original AVR-AY firmware (here) in the readme as follows:

    ATMEGA328 ===================================================
    	avrdude -p m328p -c USBasp -U flash:w:AY_Emul_XXX_Nch_KK_MM.hex -U eeprom:w:Conf_XXX_YYMHz_ZZMhz.hex -U lfuse:w:0xee:m -U hfuse:w:0xdf:m -U efuse:w:0xfd:m
    Example:
    	avrdude -p m328p -c USBasp -U flash:w:AY_Emul_250_2ch_m328_ay.hex -U eeprom:w:Conf_standard_27MHz_1_75Mhz.hex -U lfuse:w:0xee:m -U hfuse:w:0xdf:m -U efuse:w:0xfd:m
    =============================================================

    But where the fuse settings for lfuse = 0xEE, when decoded from the ATMega328P datasheet and an online AVR fuse calculator here: https://eleccelerator.com/fusecalc/fusecalc.php?chip=atmega328p means the following:

    0xEE = b1110 1110
    CKDIV8 = 1 (unprogrammed)
    CLKOUT = 1 (unprogrammed)
    SUT    = 10
    CLKSEL = 1110

    Which from the AVR fusecalc site maps onto:

    • External crystal oscillator
    • Frequency 8MHz +
    • Start up time 1K
    • Powerdown/reset 16

    However, following through the settings in the datasheet, it is similar but slightly different, giving:

    • Low power crystal oscillator (CLKSEL3:0 = 1111 – 1000)
    • Low power operating mode 111 = 8.0-16.0 MHz (with recommended caps 12-22pF)
    • CLKSEL0+SUT = 0+10 = Ceramic Resonator BOD enabled, Start up time 1KCK, additional delay 14CK

    But I’m not using a ceramic resonator, I’m using a crystal oscillator, so I think I need the mode:

    • Crystal oscillator BOD enabled, startup time 16KCK, additional delay 14CK = CLKSEL0+SUT = 1+01

    There is no “1KCK” for the crystal oscillator settings, so I’ll have to use 16KCK I guess?

    This is what gives me the 0xDF value I’ve used:

    0xDF = b1101 1111
    CKDIV8 = 1 (unprogrammed)
    CLKOUT = 1 (unprogrammed)
    SUT    = 01
    CLKSEL = 1111

    Actually, this wasn’t working with either 0xEE or 0xDF, so I decide to try to turn off BOD and went with “slow rising power” (CLKSEL0+SUT = 1+11) which gave me the fuses:

    lfuse = b1111 1111 = 0xFF
    hfuse = 0xDF (as before)
    efuse = 0xFF (no brown-out detection)

    But that isn’t working either…

    The AY891x Library and BCn/BCDIR control

    Eventually, I remembered reading about the control signals with the library that was designed for use with that test board. It states the following (here):

    “While the PSG has tight timing requirements, it is possible to use digitalWrite() by using all three bus control signals (BDIR, BC1, BC2) and cycling through an extra state when reading and writing the chip registers.”

    But the emulation is ignoring BC2 (more here), relying instead on the ATMega’s two IO interrupt pins INT0 and INT1 on D2 and D3, to trigger on BDIR and BC1. This means I had to ditch the library and instead switched over to my own PORT IO driver as described here: Arduino and AY-3-8910 – Part 3.

    Resetting the fuses as before, unfortunately it still isn’t working.

    At this point I loaded on a simple tone() function on one of the IO pins using the Arduino IDE then set the fuses again as above. I can definitely see that the frequency for the tone() output is almost twice as high as when the ATMega328P is plugged into the Arduino, so the 27MHz crystal is certainly having an effect compared to the Uno’s original 16MHz.

    I can also see the 105kHz PWM carrier frequency on all three PWM output pins, but the peaks are so narrow, these must be responding to a level 0 output which implies all code is working, but there are simply no register writes getting through.

    So, in summary, I think the code on the emulator is running fine – so why isn’t it responding to register writes?

    An Epiphany?

    At this point I left things for a bit and came back to it all a few days later.

    I was chewing over why the register writes didn’t seem to be getting through, so at this point I think the handling of BC1 and BDIR are key. The next things that I tried:

    • Getting it all on a breadboard and showing it working with a real AY-3-8910.
    • Check I can see BC1 and BDIR and the data lines doing something.
    • Replace the real chip with the emulator.
    • Repeat the tests for BC1, BDIR and data – all appear ok.

    At this point I’m suspecting the interrupts aren’t getting through (remember BC1 and BDIR are triggered off the external interrupts), so I’m contemplating two things:

    • Some test code that lights an LED on an external interrupt.
    • Porting the whole code across to the Arduino environment to let me build and run it all from there.

    But this has got me wondering about build differences for the two devices – what might be different between the ATMega48 and ATMega328P. Would rebuilding from source for the ATMega328P sort it out?

    Looking at the original code, I can see there are many different binaries for the different chips. For the repository I’m using there is just one.

    Looking in the two chip datasheets, I can see that the INT0 interrupt vector is different – it is 2 (address 0x001) for the 48 and whist it is still 2 for the 328P, the address is 0x0002. From the 48 datasheet:

    “Each interrupt vector occupies two instruction words in ATmega168, and one instruction word in ATmega48 and
    ATmega88.”

    From the 328P datasheet:

    “Each interrupt vector occupies two instruction words in Atmel ATmega328P.”

    Looking at the suggested implementations of the vector tables, they are shown as follows:

    // ATMega48 vector table
    0x000 rjmp RESET      ; Reset Handler
    0x001 rjmp EXT_INT0   ; IRQ0 Handler
    0x002 rjmp EXT_INT1   ; IRQ1 Handler

    // ATMega328P vector table
    0x0000 jmp RESET      ; Reset Handler
    0x0002 jmp EXT_INT0   ; IRQ0 Handler
    0x0004 jmp EXT_INT1   ; IRQ1 Handler

    So presumably one is a relative jump (rjmp) which is a single word (16-bit) instruction, vs an absolute jump which is a two-word (32-bit) instruction.

    With hindsight is seems obvious I’d need to rebuild for the ATMega328P, but the initial talk of compatibility lulled me into a false sense of security!

    There is no build for the 328P in the listed repository, but going back to the original avr-ay source, there are builds for all supported MCUs, each with variants covering:

    • 2 or 3 channel sound.
    • AY or YM volume tables.
    • Additional speaker output on PD1.

    There are configuration options for:

    • Serial, parallel, or both (“standard”).
    • 1.75MHz, 1.78MHz, or 2.0MHz operation.
    • 20MHz to 40MHz (including my required 27MHz).

    I’ve now downloaded:

    avrdude -c USBasp -p ATMega328P -U flash:w:AY_Emul_260_3ch_m328_ay.hex:i
    avrdude -c USBasp -p ATMega328P -U eeprom:w:Conf_parallel_27MHz_1_78Mhz.hex:i
    avrdude -c USBasp -p ATMega328P -U lfuse:w:0xee:m -Uhfuse:w:0xdf:m -U efuse:w:0xfd:m

    But unfortunately it still isn’t working…

    I did notice in the original source, a number of conditional assembler code, based on the initial configuration of MCU_TYPE. But most of it is of the form “if MCU_TYPE==0” which is giving alternative code for the ATMega8. There is one piece of code that implies something different for the ATMega48:

    	; get byte 0 from EEPROM, check value > 0 or skip USART initialization if value = 0
    #if MCU_TYPE == 0 ||  MCU_TYPE > 1
    	out		EEARH,C00		; is absent in Atmega48
    #endif
    	out		EEARL,C00

    I also note that the vector table is all relative jumps:

    	.cseg
    ;------------------------------------------------------
    ; INTERRUPT VECTORS TABLE
    ;------------------------------------------------------
    	.org	0x0000
    	rjmp	_RESET

    	.org	INT0addr
    	rjmp	_INT0_Handler

    	.org	INT1addr
     	rjmp	_INT1_Handler

    	.org	URXCaddr
    	rjmp	_USART_RX_COMPLETE

    But as each entry has its own origin statement, one presumes that these are correct for the MCU type.

    Double checking the hex records for my chosen firmware, and adding some expansions and annotations, I can see:

    // Format:
    // :ll aaaa tt dd..dd cc
    //                    ++-- CRC
    //             +----+----- Data
    //          ++------------ Record type
    //     +--+--------------- Address
    //  ++-------------------- Data length

    :02 0000 02 0000 FC  // tt=02: Extended (Upper) Segment Base Address

    // Vector Table tt=00: Data
    :02 0000 00 88C0 B6
    :02 0004 00 4AC0 F0
    :02 0008 00 56C0 E0

    // Start of code/data tt=00; Data
    :10 0048 00 50C0000101010202030506090D11161D 29
    :10 0058 00 242D0000010101010101020202020303 33
    :10 0068 00 0505060607090B0D0F111316191D2024 87
    ...
    :10 02F8 00 0092880010928A0092CF05910D932A95 5A
    :04 0308 00 E1F70895 7C
    :00 0000 01 FF       // tt=01: End of File

    So yes, it would appear that the vectors in the vector table are indeed on the expected 32-bit boundaries which matches and it has values for vectors 2 and 3, so INT0 and INT1. Vector 1 is RESET.

    One oddity, each record is only 2 bytes long, so I guess it is assuming that the missing bytes will be zero? Really, the full records should perhaps be:

    :04 0000 00 88C00000 B4 // Needed to recalc CRC
    :04 0004 00 4AC00000 EE
    :04 0008 00 56C00000 DE

    I don’t know the algorithm for calculating the CRC, but I don’t need to. When attempting to download via avrdude any CRC mismatch is reported, detailing what value was expected which allows me to set the correct value for each line at a time!

    But as these are instructions rather than addresses themselves, maybe it would be fine. If the PC hits this address, then the instruction will be (presumably) a rjmp which is only two bytes and all would be fine.

    But regardless, unfortunately this still isn’t working. I’m now at quite a loss as to what to try next.

    I did go back and look at the original firmware I was using and it has the following:

    :06 0000 00 70C039C045C0 CC

    So I don’t see how this would work on an ATMega328P at all as each vector is only half the expected size.

    The reset vector is probably ok, as the first two bytes will be read as a “rjmp” instruction and presumably the next two bytes ignored. But INT0 and INT1 will be jumping off into who-knows-where.

    This would match the evidence that the board seems to get initialised but no register writes are processed.

    So this at least does confirm that the original firmware was no good for me.

    Conclusion

    I’ve got to draw a line under this for now. I’m going to hit publish on this post as is, and put this aside for a bit.

    Some possible future directions:

    • Solder on the ICSP header to make uploading code a bit easier.
    • Load up some simple Arduino firmware that will indicate if INT0/INT1 are actually getting through.
    • Create a ATMega48 breakout to see if the board would work with the original MCU ok.
    • I’m still not convinced with that clock – it seems a very low amplitude – I wonder if those capacitors are the right values.
    • Port the whole lot to the Arduino environment. This is going to be a fair bit of work as you can’t use assembler directly, but only via asm(“nop”) style directives…

    But for now, this one is on pause.

    And I’m still annoyed about the error in the ICSP pinout…

    Kevin

    #arduino #atmega328 #ay38910 #ay38912 #emulation #MakerFail #pcbs
    #arduino #atmega328 #ay38910 #ay38912 #emulation #makerfail
  13. Simple DIY Electronic Music Projects @[email protected] ·

    AY-3-8912/8910 Hardware Emulation – Part 2

    Having explored how an AVR can be used to emulate the AY-3-8912/8910 in AY-3-8912/8910 Hardware Emulation I wanted to have a go at using the very common ATMega328P to do the same. But rather than wire things up on breadboard, I put together a quick PCB to allow me to do some experiments.

    Spoilers: This isn’t working yet!! Read on for where I’ve got to, but I’ll need to come back to this at some point.

    Warning! I strongly recommend using old or second hand equipment for your experiments.  I am not responsible for any damage to expensive instruments!

    If you are new to electronics and microcontrollers, see the Getting Started pages.

    The Circuit

    This is essentially the circuit from here: https://github.com/Yevgeniy-Olexandrenko/avr-ay-board

    But with an ATMega328P rather than the suggested ATMega48PA (more about that in part one here: AY-3-8912/8910 Hardware Emulation). I’ve included headers for both the AY-3-8910 and AY-3-8912.

    I’ve kept the same usage of ATMega ports, which map onto IO for the ATMega328P as follows:

    AY-3-8912SchematicATMega328P PORTATMega328P PinArduino EquivalentD0-D5DA0-DA5PC0-PC523-28A0-A5D6-D7DA6-DA7PD6-PD712-13D6-D7A8A8_CIPOPB418D12BC1BC1PD24D2BC2BC2_SCKPB519D13BDIRBDIRPD35D3CLOCKCLOCKPD46D4RESETRESETPC61RESETTESTN/CIOA7-IOA0N/CCPWM_CPB216D10BPWM_B_COPIPB317D11APWM_APB115D9A9_CFG0PB014D8CFG1PD56D5RXPD02D0TXPD13D1VCCVCCVCC7, 20VCCGNDGNDGND8GND

    The only change is I’m not connecting TEST to anything. I’ll have to see if this becomes an issue later…

    The circuit calls for overclocking the ATMega328P to 27MHz (again more discussion on this in the first part).

    I’ve included breakout headers for ICSP and a serial header.

    • Update: Turns out the header is back to front! See later…

    I have also swapped the oscillator to a crystal using a common configuration I’ve seen on many DIY Arduino-style boards using an ATMega328P.

    Rather than put together two boards, one for the 8912 and one for the 8910, I’ve also put together a simple adaptor circuit to allow one to plug into the socket for the other.

    The schematic essentially just maps the signals from one footprint onto the other.

    The only slight complication is that /A9 for the 8910 doesn’t exist on the 8912, so I’ve left in a jumper to provide the option of tying this to GND or VCC should the need arise. This should allow the larger 8910 to be used in the place where a 8912 is required whilst still enabling the 8910.

    PCB Design

    I did wonder quite how much of a 28 pin DIP could fit inside the footprint of a 28 pin WDIP and still keep through hole components, but I didn’t have to wonder for long to see it wasn’t really going to work.

    So as this is basically just for messing around I went with the format as shown. This way, round-profile pin headers can be used on the underside for the AY footprint if the board is to replace a genuine device. Alternatively normal pin headers or sockets can be used on the topside if jumper wires are going to be used to hook this board into another PCB.

    The two CFG jumpers are solder bridges (default not connected) on the underside of the board. I’ve also listed the Arduino versions of the AVR pins used on the underside too.

    For the converter board, I’ve left the /A9 jumper as standard pin headers. With hindsight I’m not sure when this would be wanted to be tied high, as presumably that would disable the chip. When plugging a 8912 into a 8910 socket, anything expecting an 8910 and using /A9 as part of the addressing scheme would require some additional logic before mapping it onto the smaller 8912.

    Errata

    The ICSP header is swapped to what is required. This will still work as long as the header is populated on the reverse of the board…

    From the top/silkscreen, the header has the following pinout (viewed from the top, ATMega328 on the left).

    RESETGNDCLKCOPICIPOVCC (square pad)

    Bill of Materials

    AVR-AY Emulator Board:

    • AVR-AY-Board PCB (GitHub link below).
    • ATMega329P (28 pin DIP version).
    • 1x 1K resistor
    • 3x 3K6 resistors
    • 1x 10K resistor
    • 1x 10uF electrolytic capacitor
    • 2x 100nF ceramic capacitors
    • 3x 2.2nF ceramic capacitors
    • 2x 18pF ceramic capacitors
    • 1x 3mm LED (colour to taste)
    • 1x 27 MHz crystal (2 pin, low-profile, HC-49 package – see footprints)
    • 1x 2-pin momentary push switch (see footprints)
    • Optional: 28-way narrow DIP socket
    • Optional: round-pin header pins (see photos and discussion)
    • Range of pin headers or sockets as required

    AY-3-8910 to 12 Converter:

    • AY-3-8910-12 Converter PCB (GitHub link below).
    • Either 40-pin WDIP socket or 28-pin WDIP socket.
    • Round-pin header pins.

    AY-3-8910 to 12 Converter Build

    This is a relatively straight forward build, but depending on the DIP sockets used it might be necessary to doctor the socket slightly to sit neatly over the soldered pins.

    Order of build:

    • Round pins for either the 28 pin or 40 pin part of the PCB.
    • The 40 pin or 28 pin DIP socket.

    If the converter is from a 8912 socket to a 8910 device, then the /A9 jumper or a solder link will have to be configured, presumably connecting it to GND to make it permanently active.

    One note of caution – the pins I was using are not particularly robust, so when removing the adaptor from its socket, I managed to break one and had to replace it, which wasn’t easy.

    But apart from that, it works!

    AVR AY Board

    As already mentioned there are a number of configuration options for the 28-pin AY-3-8910 emulation as illustrated below.

    The first two are designed for jumper wire connections. The third shows the use of pins which would allow the board, space permitting, to be inserted into a AY-3-8910 socket on an existing board.

    These headers will be soldered on last, but it is worth deciding in advance what configuration will be required.

    I’ve chosen not to populate the UART and ICSP headers, and am using round pins so that this can hopefully replace an AY-3-8912. But at the moment all my test boards are built for the AY-3-8910, so I’m also having to use the converter, which has led to the following stack of boards!

    ATMega328P Programming

    The stand-alone ATMega328P chip cannot be programmed directly from the Arduino IDE with this code as it stands. Instead the following are required:

    • AVRDude: https://github.com/avrdudes/avrdude
    • An AVR Programmer: I’m using a cheap USBasp clone, so one based on this: https://github.com/piit79/USBasp
    • Connection to the device via ICSP: I’m using a homemade link, but it should be possible to use the ICSP header on the PCB (however see previous warning about the pinout error!); plug it into a DIP-version of another Arduino Uno board; or possibly even a second Arduino Uno board in “Arduino as ISP” mode.

    The firmware should be downloaded from https://github.com/Yevgeniy-Olexandrenko/avr-ay-board.

    Update: I ended up using a slightly different firmware and configuration – see later…

    I’m using v1.0 of the firmware and have downloaded the binary firmware and the 1.75MHz configuration. I now have the following files:

    C:\Kevin\Temp> dir
    09/05/2026  15:49    <DIR>          .
    09/05/2026  15:49    <DIR>          ..
    09/05/2026  15:49             1,920 avr-psg.hex
    09/05/2026  15:40           909,660 avrdude.conf
    09/05/2026  15:40         9,604,608 avrdude.exe
    09/05/2026  15:40        13,316,096 avrdude.pdb
    09/05/2026  15:49                34 config-1.75mhz.hex
    C:\Kevin\Temp>

    To program the ATMega328P requires the following instructions to get the code into flash, the configuration into EEPROM and to set the fuses for the MCU:

    C:\Kevin\Temp>avrdude -c USBasp -p ATMega328P -U flash:w:avr-psg.hex:i
    Error: cannot set sck period; please check for usbasp firmware update
    Error: cannot set sck period; please check for usbasp firmware update
    Reading 682 bytes for flash from input file avr-psg.hex
    Writing 682 bytes to flash
    Writing | ################################################## | 100% 0.43 s
    Reading | ################################################## | 100% 0.23 s
    682 bytes of flash verified

    Avrdude done.  Thank you.


    C:\Kevin\Temp>avrdude -c USBasp -p ATMega328P -U eeprom:w:config-1.75mhz.hex:i
    Error: cannot set sck period; please check for usbasp firmware update
    Reading 5 bytes for eeprom from input file config-1.75mhz.hex
    Writing 5 bytes to eeprom
    Writing | ################################################## | 100% 0.09 s
    Reading | ################################################## | 100% 0.01 s
    5 bytes of eeprom verified

    Avrdude done.  Thank you.

    C:\Kevin\Test>avrdude -c USBasp -p ATMega328P -U lfuse:w:0xdf:m -U hfuse:w:0xdf:m -U efuse:w:0xfd:m
    Error: cannot set sck period; please check for usbasp firmware update

    Processing -U lfuse:w:0xdf:m
    Reading 1 byte for lfuse from input file 0xdf
    Writing 1 byte (0xDF) to lfuse, 1 byte written, 1 verified

    Processing -U hfuse:w:0xdf:m
    Reading 1 byte for hfuse from input file 0xdf
    Writing 1 byte (0xDF) to hfuse, 1 byte written, 1 verified

    Processing -U efuse:w:0xfd:m
    Reading 1 byte for efuse from input file 0xfd
    Writing 1 byte (0xFD) to efuse, 1 byte written, 1 verified

    Avrdude done.  Thank you.

    The error “cannot set sck period” is apparently pretty common especially with USBasp clones, and can be ignored.

    The three fuse settings come from the original AVR-AY firmware (here) in the readme as follows:

    ATMEGA328 ===================================================
    	avrdude -p m328p -c USBasp -U flash:w:AY_Emul_XXX_Nch_KK_MM.hex -U eeprom:w:Conf_XXX_YYMHz_ZZMhz.hex -U lfuse:w:0xee:m -U hfuse:w:0xdf:m -U efuse:w:0xfd:m
    Example:
    	avrdude -p m328p -c USBasp -U flash:w:AY_Emul_250_2ch_m328_ay.hex -U eeprom:w:Conf_standard_27MHz_1_75Mhz.hex -U lfuse:w:0xee:m -U hfuse:w:0xdf:m -U efuse:w:0xfd:m
    =============================================================

    But where the fuse settings for lfuse = 0xEE, when decoded from the ATMega328P datasheet and an online AVR fuse calculator here: https://eleccelerator.com/fusecalc/fusecalc.php?chip=atmega328p means the following:

    0xEE = b1110 1110
    CKDIV8 = 1 (unprogrammed)
    CLKOUT = 1 (unprogrammed)
    SUT    = 10
    CLKSEL = 1110

    Which from the AVR fusecalc site maps onto:

    • External crystal oscillator
    • Frequency 8MHz +
    • Start up time 1K
    • Powerdown/reset 16

    However, following through the settings in the datasheet, it is similar but slightly different, giving:

    • Low power crystal oscillator (CLKSEL3:0 = 1111 – 1000)
    • Low power operating mode 111 = 8.0-16.0 MHz (with recommended caps 12-22pF)
    • CLKSEL0+SUT = 0+10 = Ceramic Resonator BOD enabled, Start up time 1KCK, additional delay 14CK

    But I’m not using a ceramic resonator, I’m using a crystal oscillator, so I think I need the mode:

    • Crystal oscillator BOD enabled, startup time 16KCK, additional delay 14CK = CLKSEL0+SUT = 1+01

    There is no “1KCK” for the crystal oscillator settings, so I’ll have to use 16KCK I guess?

    This is what gives me the 0xDF value I’ve used:

    0xDF = b1101 1111
    CKDIV8 = 1 (unprogrammed)
    CLKOUT = 1 (unprogrammed)
    SUT    = 01
    CLKSEL = 1111

    Actually, this wasn’t working with either 0xEE or 0xDF, so I decide to try to turn off BOD and went with “slow rising power” (CLKSEL0+SUT = 1+11) which gave me the fuses:

    lfuse = b1111 1111 = 0xFF
    hfuse = 0xDF (as before)
    efuse = 0xFF (no brown-out detection)

    But that isn’t working either…

    The AY891x Library and BCn/BCDIR control

    Eventually, I remembered reading about the control signals with the library that was designed for use with that test board. It states the following (here):

    “While the PSG has tight timing requirements, it is possible to use digitalWrite() by using all three bus control signals (BDIR, BC1, BC2) and cycling through an extra state when reading and writing the chip registers.”

    But the emulation is ignoring BC2 (more here), relying instead on the ATMega’s two IO interrupt pins INT0 and INT1 on D2 and D3, to trigger on BDIR and BC1. This means I had to ditch the library and instead switched over to my own PORT IO driver as described here: Arduino and AY-3-8910 – Part 3.

    Resetting the fuses as before, unfortunately it still isn’t working.

    At this point I loaded on a simple tone() function on one of the IO pins using the Arduino IDE then set the fuses again as above. I can definitely see that the frequency for the tone() output is almost twice as high as when the ATMega328P is plugged into the Arduino, so the 27MHz crystal is certainly having an effect compared to the Uno’s original 16MHz.

    I can also see the 105kHz PWM carrier frequency on all three PWM output pins, but the peaks are so narrow, these must be responding to a level 0 output which implies all code is working, but there are simply no register writes getting through.

    So, in summary, I think the code on the emulator is running fine – so why isn’t it responding to register writes?

    An Epiphany?

    At this point I left things for a bit and came back to it all a few days later.

    I was chewing over why the register writes didn’t seem to be getting through, so at this point I think the handling of BC1 and BDIR are key. The next things that I tried:

    • Getting it all on a breadboard and showing it working with a real AY-3-8910.
    • Check I can see BC1 and BDIR and the data lines doing something.
    • Replace the real chip with the emulator.
    • Repeat the tests for BC1, BDIR and data – all appear ok.

    At this point I’m suspecting the interrupts aren’t getting through (remember BC1 and BDIR are triggered off the external interrupts), so I’m contemplating two things:

    • Some test code that lights an LED on an external interrupt.
    • Porting the whole code across to the Arduino environment to let me build and run it all from there.

    But this has got me wondering about build differences for the two devices – what might be different between the ATMega48 and ATMega328P. Would rebuilding from source for the ATMega328P sort it out?

    Looking at the original code, I can see there are many different binaries for the different chips. For the repository I’m using there is just one.

    Looking in the two chip datasheets, I can see that the INT0 interrupt vector is different – it is 2 (address 0x001) for the 48 and whist it is still 2 for the 328P, the address is 0x0002. From the 48 datasheet:

    “Each interrupt vector occupies two instruction words in ATmega168, and one instruction word in ATmega48 and
    ATmega88.”

    From the 328P datasheet:

    “Each interrupt vector occupies two instruction words in Atmel ATmega328P.”

    Looking at the suggested implementations of the vector tables, they are shown as follows:

    // ATMega48 vector table
    0x000 rjmp RESET      ; Reset Handler
    0x001 rjmp EXT_INT0   ; IRQ0 Handler
    0x002 rjmp EXT_INT1   ; IRQ1 Handler

    // ATMega328P vector table
    0x0000 jmp RESET      ; Reset Handler
    0x0002 jmp EXT_INT0   ; IRQ0 Handler
    0x0004 jmp EXT_INT1   ; IRQ1 Handler

    So presumably one is a relative jump (rjmp) which is a single word (16-bit) instruction, vs an absolute jump which is a two-word (32-bit) instruction.

    With hindsight is seems obvious I’d need to rebuild for the ATMega328P, but the initial talk of compatibility lulled me into a false sense of security!

    There is no build for the 328P in the listed repository, but going back to the original avr-ay source, there are builds for all supported MCUs, each with variants covering:

    • 2 or 3 channel sound.
    • AY or YM volume tables.
    • Additional speaker output on PD1.

    There are configuration options for:

    • Serial, parallel, or both (“standard”).
    • 1.75MHz, 1.78MHz, or 2.0MHz operation.
    • 20MHz to 40MHz (including my required 27MHz).

    I’ve now downloaded:

    avrdude -c USBasp -p ATMega328P -U flash:w:AY_Emul_260_3ch_m328_ay.hex:i
    avrdude -c USBasp -p ATMega328P -U eeprom:w:Conf_parallel_27MHz_1_78Mhz.hex:i
    avrdude -c USBasp -p ATMega328P -U lfuse:w:0xee:m -Uhfuse:w:0xdf:m -U efuse:w:0xfd:m

    But unfortunately it still isn’t working…

    I did notice in the original source, a number of conditional assembler code, based on the initial configuration of MCU_TYPE. But most of it is of the form “if MCU_TYPE==0” which is giving alternative code for the ATMega8. There is one piece of code that implies something different for the ATMega48:

    	; get byte 0 from EEPROM, check value > 0 or skip USART initialization if value = 0
    #if MCU_TYPE == 0 ||  MCU_TYPE > 1
    	out		EEARH,C00		; is absent in Atmega48
    #endif
    	out		EEARL,C00

    I also note that the vector table is all relative jumps:

    	.cseg
    ;------------------------------------------------------
    ; INTERRUPT VECTORS TABLE
    ;------------------------------------------------------
    	.org	0x0000
    	rjmp	_RESET

    	.org	INT0addr
    	rjmp	_INT0_Handler

    	.org	INT1addr
     	rjmp	_INT1_Handler

    	.org	URXCaddr
    	rjmp	_USART_RX_COMPLETE

    But as each entry has its own origin statement, one presumes that these are correct for the MCU type.

    Double checking the hex records for my chosen firmware, and adding some expansions and annotations, I can see:

    // Format:
    // :ll aaaa tt dd..dd cc
    //                    ++-- CRC
    //             +----+----- Data
    //          ++------------ Record type
    //     +--+--------------- Address
    //  ++-------------------- Data length

    :02 0000 02 0000 FC  // tt=02: Extended (Upper) Segment Base Address

    // Vector Table tt=00: Data
    :02 0000 00 88C0 B6
    :02 0004 00 4AC0 F0
    :02 0008 00 56C0 E0

    // Start of code/data tt=00; Data
    :10 0048 00 50C0000101010202030506090D11161D 29
    :10 0058 00 242D0000010101010101020202020303 33
    :10 0068 00 0505060607090B0D0F111316191D2024 87
    ...
    :10 02F8 00 0092880010928A0092CF05910D932A95 5A
    :04 0308 00 E1F70895 7C
    :00 0000 01 FF       // tt=01: End of File

    So yes, it would appear that the vectors in the vector table are indeed on the expected 32-bit boundaries which matches and it has values for vectors 2 and 3, so INT0 and INT1. Vector 1 is RESET.

    One oddity, each record is only 2 bytes long, so I guess it is assuming that the missing bytes will be zero? Really, the full records should perhaps be:

    :04 0000 00 88C00000 B4 // Needed to recalc CRC
    :04 0004 00 4AC00000 EE
    :04 0008 00 56C00000 DE

    I don’t know the algorithm for calculating the CRC, but I don’t need to. When attempting to download via avrdude any CRC mismatch is reported, detailing what value was expected which allows me to set the correct value for each line at a time!

    But as these are instructions rather than addresses themselves, maybe it would be fine. If the PC hits this address, then the instruction will be (presumably) a rjmp which is only two bytes and all would be fine.

    But regardless, unfortunately this still isn’t working. I’m now at quite a loss as to what to try next.

    I did go back and look at the original firmware I was using and it has the following:

    :06 0000 00 70C039C045C0 CC

    So I don’t see how this would work on an ATMega328P at all as each vector is only half the expected size.

    The reset vector is probably ok, as the first two bytes will be read as a “rjmp” instruction and presumably the next two bytes ignored. But INT0 and INT1 will be jumping off into who-knows-where.

    This would match the evidence that the board seems to get initialised but no register writes are processed.

    So this at least does confirm that the original firmware was no good for me.

    Conclusion

    I’ve got to draw a line under this for now. I’m going to hit publish on this post as is, and put this aside for a bit.

    Some possible future directions:

    • Solder on the ICSP header to make uploading code a bit easier.
    • Load up some simple Arduino firmware that will indicate if INT0/INT1 are actually getting through.
    • Create a ATMega48 breakout to see if the board would work with the original MCU ok.
    • I’m still not convinced with that clock – it seems a very low amplitude – I wonder if those capacitors are the right values.
    • Port the whole lot to the Arduino environment. This is going to be a fair bit of work as you can’t use assembler directly, but only via asm(“nop”) style directives…

    But for now, this one is on pause.

    And I’m still annoyed about the error in the ICSP pinout…

    Kevin

    #arduino #atmega328 #ay38910 #ay38912 #emulation #MakerFail #pcbs
    #arduino #atmega328 #ay38910 #ay38912 #emulation #makerfail
  14. Simple DIY Electronic Music Projects @[email protected] ·

    AY-3-8912/8910 Hardware Emulation – Part 2

    Having explored how an AVR can be used to emulate the AY-3-8912/8910 in AY-3-8912/8910 Hardware Emulation I wanted to have a go at using the very common ATMega328P to do the same. But rather than wire things up on breadboard, I put together a quick PCB to allow me to do some experiments.

    Spoilers: This isn’t working yet!! Read on for where I’ve got to, but I’ll need to come back to this at some point.

    Warning! I strongly recommend using old or second hand equipment for your experiments.  I am not responsible for any damage to expensive instruments!

    If you are new to electronics and microcontrollers, see the Getting Started pages.

    The Circuit

    This is essentially the circuit from here: https://github.com/Yevgeniy-Olexandrenko/avr-ay-board

    But with an ATMega328P rather than the suggested ATMega48PA (more about that in part one here: AY-3-8912/8910 Hardware Emulation). I’ve included headers for both the AY-3-8910 and AY-3-8912.

    I’ve kept the same usage of ATMega ports, which map onto IO for the ATMega328P as follows:

    AY-3-8912SchematicATMega328P PORTATMega328P PinArduino EquivalentD0-D5DA0-DA5PC0-PC523-28A0-A5D6-D7DA6-DA7PD6-PD712-13D6-D7A8A8_CIPOPB418D12BC1BC1PD24D2BC2BC2_SCKPB519D13BDIRBDIRPD35D3CLOCKCLOCKPD46D4RESETRESETPC61RESETTESTN/CIOA7-IOA0N/CCPWM_CPB216D10BPWM_B_COPIPB317D11APWM_APB115D9A9_CFG0PB014D8CFG1PD56D5RXPD02D0TXPD13D1VCCVCCVCC7, 20VCCGNDGNDGND8GND

    The only change is I’m not connecting TEST to anything. I’ll have to see if this becomes an issue later…

    The circuit calls for overclocking the ATMega328P to 27MHz (again more discussion on this in the first part).

    I’ve included breakout headers for ICSP and a serial header.

    • Update: Turns out the header is back to front! See later…

    I have also swapped the oscillator to a crystal using a common configuration I’ve seen on many DIY Arduino-style boards using an ATMega328P.

    Rather than put together two boards, one for the 8912 and one for the 8910, I’ve also put together a simple adaptor circuit to allow one to plug into the socket for the other.

    The schematic essentially just maps the signals from one footprint onto the other.

    The only slight complication is that /A9 for the 8910 doesn’t exist on the 8912, so I’ve left in a jumper to provide the option of tying this to GND or VCC should the need arise. This should allow the larger 8910 to be used in the place where a 8912 is required whilst still enabling the 8910.

    PCB Design

    I did wonder quite how much of a 28 pin DIP could fit inside the footprint of a 28 pin WDIP and still keep through hole components, but I didn’t have to wonder for long to see it wasn’t really going to work.

    So as this is basically just for messing around I went with the format as shown. This way, round-profile pin headers can be used on the underside for the AY footprint if the board is to replace a genuine device. Alternatively normal pin headers or sockets can be used on the topside if jumper wires are going to be used to hook this board into another PCB.

    The two CFG jumpers are solder bridges (default not connected) on the underside of the board. I’ve also listed the Arduino versions of the AVR pins used on the underside too.

    For the converter board, I’ve left the /A9 jumper as standard pin headers. With hindsight I’m not sure when this would be wanted to be tied high, as presumably that would disable the chip. When plugging a 8912 into a 8910 socket, anything expecting an 8910 and using /A9 as part of the addressing scheme would require some additional logic before mapping it onto the smaller 8912.

    Errata

    The ICSP header is swapped to what is required. This will still work as long as the header is populated on the reverse of the board…

    From the top/silkscreen, the header has the following pinout (viewed from the top, ATMega328 on the left).

    RESETGNDCLKCOPICIPOVCC (square pad)

    Bill of Materials

    AVR-AY Emulator Board:

    • AVR-AY-Board PCB (GitHub link below).
    • ATMega329P (28 pin DIP version).
    • 1x 1K resistor
    • 3x 3K6 resistors
    • 1x 10K resistor
    • 1x 10uF electrolytic capacitor
    • 2x 100nF ceramic capacitors
    • 3x 2.2nF ceramic capacitors
    • 2x 18pF ceramic capacitors
    • 1x 3mm LED (colour to taste)
    • 1x 27 MHz crystal (2 pin, low-profile, HC-49 package – see footprints)
    • 1x 2-pin momentary push switch (see footprints)
    • Optional: 28-way narrow DIP socket
    • Optional: round-pin header pins (see photos and discussion)
    • Range of pin headers or sockets as required

    AY-3-8910 to 12 Converter:

    • AY-3-8910-12 Converter PCB (GitHub link below).
    • Either 40-pin WDIP socket or 28-pin WDIP socket.
    • Round-pin header pins.

    AY-3-8910 to 12 Converter Build

    This is a relatively straight forward build, but depending on the DIP sockets used it might be necessary to doctor the socket slightly to sit neatly over the soldered pins.

    Order of build:

    • Round pins for either the 28 pin or 40 pin part of the PCB.
    • The 40 pin or 28 pin DIP socket.

    If the converter is from a 8912 socket to a 8910 device, then the /A9 jumper or a solder link will have to be configured, presumably connecting it to GND to make it permanently active.

    One note of caution – the pins I was using are not particularly robust, so when removing the adaptor from its socket, I managed to break one and had to replace it, which wasn’t easy.

    But apart from that, it works!

    AVR AY Board

    As already mentioned there are a number of configuration options for the 28-pin AY-3-8910 emulation as illustrated below.

    The first two are designed for jumper wire connections. The third shows the use of pins which would allow the board, space permitting, to be inserted into a AY-3-8910 socket on an existing board.

    These headers will be soldered on last, but it is worth deciding in advance what configuration will be required.

    I’ve chosen not to populate the UART and ICSP headers, and am using round pins so that this can hopefully replace an AY-3-8912. But at the moment all my test boards are built for the AY-3-8910, so I’m also having to use the converter, which has led to the following stack of boards!

    ATMega328P Programming

    The stand-alone ATMega328P chip cannot be programmed directly from the Arduino IDE with this code as it stands. Instead the following are required:

    • AVRDude: https://github.com/avrdudes/avrdude
    • An AVR Programmer: I’m using a cheap USBasp clone, so one based on this: https://github.com/piit79/USBasp
    • Connection to the device via ICSP: I’m using a homemade link, but it should be possible to use the ICSP header on the PCB (however see previous warning about the pinout error!); plug it into a DIP-version of another Arduino Uno board; or possibly even a second Arduino Uno board in “Arduino as ISP” mode.

    The firmware should be downloaded from https://github.com/Yevgeniy-Olexandrenko/avr-ay-board.

    Update: I ended up using a slightly different firmware and configuration – see later…

    I’m using v1.0 of the firmware and have downloaded the binary firmware and the 1.75MHz configuration. I now have the following files:

    C:\Kevin\Temp> dir
    09/05/2026  15:49    <DIR>          .
    09/05/2026  15:49    <DIR>          ..
    09/05/2026  15:49             1,920 avr-psg.hex
    09/05/2026  15:40           909,660 avrdude.conf
    09/05/2026  15:40         9,604,608 avrdude.exe
    09/05/2026  15:40        13,316,096 avrdude.pdb
    09/05/2026  15:49                34 config-1.75mhz.hex
    C:\Kevin\Temp>

    To program the ATMega328P requires the following instructions to get the code into flash, the configuration into EEPROM and to set the fuses for the MCU:

    C:\Kevin\Temp>avrdude -c USBasp -p ATMega328P -U flash:w:avr-psg.hex:i
    Error: cannot set sck period; please check for usbasp firmware update
    Error: cannot set sck period; please check for usbasp firmware update
    Reading 682 bytes for flash from input file avr-psg.hex
    Writing 682 bytes to flash
    Writing | ################################################## | 100% 0.43 s
    Reading | ################################################## | 100% 0.23 s
    682 bytes of flash verified

    Avrdude done.  Thank you.


    C:\Kevin\Temp>avrdude -c USBasp -p ATMega328P -U eeprom:w:config-1.75mhz.hex:i
    Error: cannot set sck period; please check for usbasp firmware update
    Reading 5 bytes for eeprom from input file config-1.75mhz.hex
    Writing 5 bytes to eeprom
    Writing | ################################################## | 100% 0.09 s
    Reading | ################################################## | 100% 0.01 s
    5 bytes of eeprom verified

    Avrdude done.  Thank you.

    C:\Kevin\Test>avrdude -c USBasp -p ATMega328P -U lfuse:w:0xdf:m -U hfuse:w:0xdf:m -U efuse:w:0xfd:m
    Error: cannot set sck period; please check for usbasp firmware update

    Processing -U lfuse:w:0xdf:m
    Reading 1 byte for lfuse from input file 0xdf
    Writing 1 byte (0xDF) to lfuse, 1 byte written, 1 verified

    Processing -U hfuse:w:0xdf:m
    Reading 1 byte for hfuse from input file 0xdf
    Writing 1 byte (0xDF) to hfuse, 1 byte written, 1 verified

    Processing -U efuse:w:0xfd:m
    Reading 1 byte for efuse from input file 0xfd
    Writing 1 byte (0xFD) to efuse, 1 byte written, 1 verified

    Avrdude done.  Thank you.

    The error “cannot set sck period” is apparently pretty common especially with USBasp clones, and can be ignored.

    The three fuse settings come from the original AVR-AY firmware (here) in the readme as follows:

    ATMEGA328 ===================================================
    	avrdude -p m328p -c USBasp -U flash:w:AY_Emul_XXX_Nch_KK_MM.hex -U eeprom:w:Conf_XXX_YYMHz_ZZMhz.hex -U lfuse:w:0xee:m -U hfuse:w:0xdf:m -U efuse:w:0xfd:m
    Example:
    	avrdude -p m328p -c USBasp -U flash:w:AY_Emul_250_2ch_m328_ay.hex -U eeprom:w:Conf_standard_27MHz_1_75Mhz.hex -U lfuse:w:0xee:m -U hfuse:w:0xdf:m -U efuse:w:0xfd:m
    =============================================================

    But where the fuse settings for lfuse = 0xEE, when decoded from the ATMega328P datasheet and an online AVR fuse calculator here: https://eleccelerator.com/fusecalc/fusecalc.php?chip=atmega328p means the following:

    0xEE = b1110 1110
    CKDIV8 = 1 (unprogrammed)
    CLKOUT = 1 (unprogrammed)
    SUT    = 10
    CLKSEL = 1110

    Which from the AVR fusecalc site maps onto:

    • External crystal oscillator
    • Frequency 8MHz +
    • Start up time 1K
    • Powerdown/reset 16

    However, following through the settings in the datasheet, it is similar but slightly different, giving:

    • Low power crystal oscillator (CLKSEL3:0 = 1111 – 1000)
    • Low power operating mode 111 = 8.0-16.0 MHz (with recommended caps 12-22pF)
    • CLKSEL0+SUT = 0+10 = Ceramic Resonator BOD enabled, Start up time 1KCK, additional delay 14CK

    But I’m not using a ceramic resonator, I’m using a crystal oscillator, so I think I need the mode:

    • Crystal oscillator BOD enabled, startup time 16KCK, additional delay 14CK = CLKSEL0+SUT = 1+01

    There is no “1KCK” for the crystal oscillator settings, so I’ll have to use 16KCK I guess?

    This is what gives me the 0xDF value I’ve used:

    0xDF = b1101 1111
    CKDIV8 = 1 (unprogrammed)
    CLKOUT = 1 (unprogrammed)
    SUT    = 01
    CLKSEL = 1111

    Actually, this wasn’t working with either 0xEE or 0xDF, so I decide to try to turn off BOD and went with “slow rising power” (CLKSEL0+SUT = 1+11) which gave me the fuses:

    lfuse = b1111 1111 = 0xFF
    hfuse = 0xDF (as before)
    efuse = 0xFF (no brown-out detection)

    But that isn’t working either…

    The AY891x Library and BCn/BCDIR control

    Eventually, I remembered reading about the control signals with the library that was designed for use with that test board. It states the following (here):

    “While the PSG has tight timing requirements, it is possible to use digitalWrite() by using all three bus control signals (BDIR, BC1, BC2) and cycling through an extra state when reading and writing the chip registers.”

    But the emulation is ignoring BC2 (more here), relying instead on the ATMega’s two IO interrupt pins INT0 and INT1 on D2 and D3, to trigger on BDIR and BC1. This means I had to ditch the library and instead switched over to my own PORT IO driver as described here: Arduino and AY-3-8910 – Part 3.

    Resetting the fuses as before, unfortunately it still isn’t working.

    At this point I loaded on a simple tone() function on one of the IO pins using the Arduino IDE then set the fuses again as above. I can definitely see that the frequency for the tone() output is almost twice as high as when the ATMega328P is plugged into the Arduino, so the 27MHz crystal is certainly having an effect compared to the Uno’s original 16MHz.

    I can also see the 105kHz PWM carrier frequency on all three PWM output pins, but the peaks are so narrow, these must be responding to a level 0 output which implies all code is working, but there are simply no register writes getting through.

    So, in summary, I think the code on the emulator is running fine – so why isn’t it responding to register writes?

    An Epiphany?

    At this point I left things for a bit and came back to it all a few days later.

    I was chewing over why the register writes didn’t seem to be getting through, so at this point I think the handling of BC1 and BDIR are key. The next things that I tried:

    • Getting it all on a breadboard and showing it working with a real AY-3-8910.
    • Check I can see BC1 and BDIR and the data lines doing something.
    • Replace the real chip with the emulator.
    • Repeat the tests for BC1, BDIR and data – all appear ok.

    At this point I’m suspecting the interrupts aren’t getting through (remember BC1 and BDIR are triggered off the external interrupts), so I’m contemplating two things:

    • Some test code that lights an LED on an external interrupt.
    • Porting the whole code across to the Arduino environment to let me build and run it all from there.

    But this has got me wondering about build differences for the two devices – what might be different between the ATMega48 and ATMega328P. Would rebuilding from source for the ATMega328P sort it out?

    Looking at the original code, I can see there are many different binaries for the different chips. For the repository I’m using there is just one.

    Looking in the two chip datasheets, I can see that the INT0 interrupt vector is different – it is 2 (address 0x001) for the 48 and whist it is still 2 for the 328P, the address is 0x0002. From the 48 datasheet:

    “Each interrupt vector occupies two instruction words in ATmega168, and one instruction word in ATmega48 and
    ATmega88.”

    From the 328P datasheet:

    “Each interrupt vector occupies two instruction words in Atmel ATmega328P.”

    Looking at the suggested implementations of the vector tables, they are shown as follows:

    // ATMega48 vector table
    0x000 rjmp RESET      ; Reset Handler
    0x001 rjmp EXT_INT0   ; IRQ0 Handler
    0x002 rjmp EXT_INT1   ; IRQ1 Handler

    // ATMega328P vector table
    0x0000 jmp RESET      ; Reset Handler
    0x0002 jmp EXT_INT0   ; IRQ0 Handler
    0x0004 jmp EXT_INT1   ; IRQ1 Handler

    So presumably one is a relative jump (rjmp) which is a single word (16-bit) instruction, vs an absolute jump which is a two-word (32-bit) instruction.

    With hindsight is seems obvious I’d need to rebuild for the ATMega328P, but the initial talk of compatibility lulled me into a false sense of security!

    There is no build for the 328P in the listed repository, but going back to the original avr-ay source, there are builds for all supported MCUs, each with variants covering:

    • 2 or 3 channel sound.
    • AY or YM volume tables.
    • Additional speaker output on PD1.

    There are configuration options for:

    • Serial, parallel, or both (“standard”).
    • 1.75MHz, 1.78MHz, or 2.0MHz operation.
    • 20MHz to 40MHz (including my required 27MHz).

    I’ve now downloaded:

    avrdude -c USBasp -p ATMega328P -U flash:w:AY_Emul_260_3ch_m328_ay.hex:i
    avrdude -c USBasp -p ATMega328P -U eeprom:w:Conf_parallel_27MHz_1_78Mhz.hex:i
    avrdude -c USBasp -p ATMega328P -U lfuse:w:0xee:m -Uhfuse:w:0xdf:m -U efuse:w:0xfd:m

    But unfortunately it still isn’t working…

    I did notice in the original source, a number of conditional assembler code, based on the initial configuration of MCU_TYPE. But most of it is of the form “if MCU_TYPE==0” which is giving alternative code for the ATMega8. There is one piece of code that implies something different for the ATMega48:

    	; get byte 0 from EEPROM, check value > 0 or skip USART initialization if value = 0
    #if MCU_TYPE == 0 ||  MCU_TYPE > 1
    	out		EEARH,C00		; is absent in Atmega48
    #endif
    	out		EEARL,C00

    I also note that the vector table is all relative jumps:

    	.cseg
    ;------------------------------------------------------
    ; INTERRUPT VECTORS TABLE
    ;------------------------------------------------------
    	.org	0x0000
    	rjmp	_RESET

    	.org	INT0addr
    	rjmp	_INT0_Handler

    	.org	INT1addr
     	rjmp	_INT1_Handler

    	.org	URXCaddr
    	rjmp	_USART_RX_COMPLETE

    But as each entry has its own origin statement, one presumes that these are correct for the MCU type.

    Double checking the hex records for my chosen firmware, and adding some expansions and annotations, I can see:

    // Format:
    // :ll aaaa tt dd..dd cc
    //                    ++-- CRC
    //             +----+----- Data
    //          ++------------ Record type
    //     +--+--------------- Address
    //  ++-------------------- Data length

    :02 0000 02 0000 FC  // tt=02: Extended (Upper) Segment Base Address

    // Vector Table tt=00: Data
    :02 0000 00 88C0 B6
    :02 0004 00 4AC0 F0
    :02 0008 00 56C0 E0

    // Start of code/data tt=00; Data
    :10 0048 00 50C0000101010202030506090D11161D 29
    :10 0058 00 242D0000010101010101020202020303 33
    :10 0068 00 0505060607090B0D0F111316191D2024 87
    ...
    :10 02F8 00 0092880010928A0092CF05910D932A95 5A
    :04 0308 00 E1F70895 7C
    :00 0000 01 FF       // tt=01: End of File

    So yes, it would appear that the vectors in the vector table are indeed on the expected 32-bit boundaries which matches and it has values for vectors 2 and 3, so INT0 and INT1. Vector 1 is RESET.

    One oddity, each record is only 2 bytes long, so I guess it is assuming that the missing bytes will be zero? Really, the full records should perhaps be:

    :04 0000 00 88C00000 B4 // Needed to recalc CRC
    :04 0004 00 4AC00000 EE
    :04 0008 00 56C00000 DE

    I don’t know the algorithm for calculating the CRC, but I don’t need to. When attempting to download via avrdude any CRC mismatch is reported, detailing what value was expected which allows me to set the correct value for each line at a time!

    But as these are instructions rather than addresses themselves, maybe it would be fine. If the PC hits this address, then the instruction will be (presumably) a rjmp which is only two bytes and all would be fine.

    But regardless, unfortunately this still isn’t working. I’m now at quite a loss as to what to try next.

    I did go back and look at the original firmware I was using and it has the following:

    :06 0000 00 70C039C045C0 CC

    So I don’t see how this would work on an ATMega328P at all as each vector is only half the expected size.

    The reset vector is probably ok, as the first two bytes will be read as a “rjmp” instruction and presumably the next two bytes ignored. But INT0 and INT1 will be jumping off into who-knows-where.

    This would match the evidence that the board seems to get initialised but no register writes are processed.

    So this at least does confirm that the original firmware was no good for me.

    Conclusion

    I’ve got to draw a line under this for now. I’m going to hit publish on this post as is, and put this aside for a bit.

    Some possible future directions:

    • Solder on the ICSP header to make uploading code a bit easier.
    • Load up some simple Arduino firmware that will indicate if INT0/INT1 are actually getting through.
    • Create a ATMega48 breakout to see if the board would work with the original MCU ok.
    • I’m still not convinced with that clock – it seems a very low amplitude – I wonder if those capacitors are the right values.
    • Port the whole lot to the Arduino environment. This is going to be a fair bit of work as you can’t use assembler directly, but only via asm(“nop”) style directives…

    But for now, this one is on pause.

    And I’m still annoyed about the error in the ICSP pinout…

    Kevin

    #arduino #atmega328 #ay38910 #ay38912 #emulation #MakerFail #pcbs
    #pcbs #makerfail #emulation #ay38912 #ay38910 #atmega328
  15. Simple DIY Electronic Music Projects @[email protected] ·

    AY-3-8912/8910 Hardware Emulation – Part 2

    Having explored how an AVR can be used to emulate the AY-3-8912/8910 in AY-3-8912/8910 Hardware Emulation I wanted to have a go at using the very common ATMega328P to do the same. But rather than wire things up on breadboard, I put together a quick PCB to allow me to do some experiments.

    Spoilers: This isn’t working yet!! Read on for where I’ve got to, but I’ll need to come back to this at some point.

    Warning! I strongly recommend using old or second hand equipment for your experiments.  I am not responsible for any damage to expensive instruments!

    If you are new to electronics and microcontrollers, see the Getting Started pages.

    The Circuit

    This is essentially the circuit from here: https://github.com/Yevgeniy-Olexandrenko/avr-ay-board

    But with an ATMega328P rather than the suggested ATMega48PA (more about that in part one here: AY-3-8912/8910 Hardware Emulation). I’ve included headers for both the AY-3-8910 and AY-3-8912.

    I’ve kept the same usage of ATMega ports, which map onto IO for the ATMega328P as follows:

    AY-3-8912SchematicATMega328P PORTATMega328P PinArduino EquivalentD0-D5DA0-DA5PC0-PC523-28A0-A5D6-D7DA6-DA7PD6-PD712-13D6-D7A8A8_CIPOPB418D12BC1BC1PD24D2BC2BC2_SCKPB519D13BDIRBDIRPD35D3CLOCKCLOCKPD46D4RESETRESETPC61RESETTESTN/CIOA7-IOA0N/CCPWM_CPB216D10BPWM_B_COPIPB317D11APWM_APB115D9A9_CFG0PB014D8CFG1PD56D5RXPD02D0TXPD13D1VCCVCCVCC7, 20VCCGNDGNDGND8GND

    The only change is I’m not connecting TEST to anything. I’ll have to see if this becomes an issue later…

    The circuit calls for overclocking the ATMega328P to 27MHz (again more discussion on this in the first part).

    I’ve included breakout headers for ICSP and a serial header.

    • Update: Turns out the header is back to front! See later…

    I have also swapped the oscillator to a crystal using a common configuration I’ve seen on many DIY Arduino-style boards using an ATMega328P.

    Rather than put together two boards, one for the 8912 and one for the 8910, I’ve also put together a simple adaptor circuit to allow one to plug into the socket for the other.

    The schematic essentially just maps the signals from one footprint onto the other.

    The only slight complication is that /A9 for the 8910 doesn’t exist on the 8912, so I’ve left in a jumper to provide the option of tying this to GND or VCC should the need arise. This should allow the larger 8910 to be used in the place where a 8912 is required whilst still enabling the 8910.

    PCB Design

    I did wonder quite how much of a 28 pin DIP could fit inside the footprint of a 28 pin WDIP and still keep through hole components, but I didn’t have to wonder for long to see it wasn’t really going to work.

    So as this is basically just for messing around I went with the format as shown. This way, round-profile pin headers can be used on the underside for the AY footprint if the board is to replace a genuine device. Alternatively normal pin headers or sockets can be used on the topside if jumper wires are going to be used to hook this board into another PCB.

    The two CFG jumpers are solder bridges (default not connected) on the underside of the board. I’ve also listed the Arduino versions of the AVR pins used on the underside too.

    For the converter board, I’ve left the /A9 jumper as standard pin headers. With hindsight I’m not sure when this would be wanted to be tied high, as presumably that would disable the chip. When plugging a 8912 into a 8910 socket, anything expecting an 8910 and using /A9 as part of the addressing scheme would require some additional logic before mapping it onto the smaller 8912.

    Errata

    The ICSP header is swapped to what is required. This will still work as long as the header is populated on the reverse of the board…

    From the top/silkscreen, the header has the following pinout (viewed from the top, ATMega328 on the left).

    RESETGNDCLKCOPICIPOVCC (square pad)

    Bill of Materials

    AVR-AY Emulator Board:

    • AVR-AY-Board PCB (GitHub link below).
    • ATMega329P (28 pin DIP version).
    • 1x 1K resistor
    • 3x 3K6 resistors
    • 1x 10K resistor
    • 1x 10uF electrolytic capacitor
    • 2x 100nF ceramic capacitors
    • 3x 2.2nF ceramic capacitors
    • 2x 18pF ceramic capacitors
    • 1x 3mm LED (colour to taste)
    • 1x 27 MHz crystal (2 pin, low-profile, HC-49 package – see footprints)
    • 1x 2-pin momentary push switch (see footprints)
    • Optional: 28-way narrow DIP socket
    • Optional: round-pin header pins (see photos and discussion)
    • Range of pin headers or sockets as required

    AY-3-8910 to 12 Converter:

    • AY-3-8910-12 Converter PCB (GitHub link below).
    • Either 40-pin WDIP socket or 28-pin WDIP socket.
    • Round-pin header pins.

    AY-3-8910 to 12 Converter Build

    This is a relatively straight forward build, but depending on the DIP sockets used it might be necessary to doctor the socket slightly to sit neatly over the soldered pins.

    Order of build:

    • Round pins for either the 28 pin or 40 pin part of the PCB.
    • The 40 pin or 28 pin DIP socket.

    If the converter is from a 8912 socket to a 8910 device, then the /A9 jumper or a solder link will have to be configured, presumably connecting it to GND to make it permanently active.

    One note of caution – the pins I was using are not particularly robust, so when removing the adaptor from its socket, I managed to break one and had to replace it, which wasn’t easy.

    But apart from that, it works!

    AVR AY Board

    As already mentioned there are a number of configuration options for the 28-pin AY-3-8910 emulation as illustrated below.

    The first two are designed for jumper wire connections. The third shows the use of pins which would allow the board, space permitting, to be inserted into a AY-3-8910 socket on an existing board.

    These headers will be soldered on last, but it is worth deciding in advance what configuration will be required.

    I’ve chosen not to populate the UART and ICSP headers, and am using round pins so that this can hopefully replace an AY-3-8912. But at the moment all my test boards are built for the AY-3-8910, so I’m also having to use the converter, which has led to the following stack of boards!

    ATMega328P Programming

    The stand-alone ATMega328P chip cannot be programmed directly from the Arduino IDE with this code as it stands. Instead the following are required:

    • AVRDude: https://github.com/avrdudes/avrdude
    • An AVR Programmer: I’m using a cheap USBasp clone, so one based on this: https://github.com/piit79/USBasp
    • Connection to the device via ICSP: I’m using a homemade link, but it should be possible to use the ICSP header on the PCB (however see previous warning about the pinout error!); plug it into a DIP-version of another Arduino Uno board; or possibly even a second Arduino Uno board in “Arduino as ISP” mode.

    The firmware should be downloaded from https://github.com/Yevgeniy-Olexandrenko/avr-ay-board.

    Update: I ended up using a slightly different firmware and configuration – see later…

    I’m using v1.0 of the firmware and have downloaded the binary firmware and the 1.75MHz configuration. I now have the following files:

    C:\Kevin\Temp> dir
    09/05/2026  15:49    <DIR>          .
    09/05/2026  15:49    <DIR>          ..
    09/05/2026  15:49             1,920 avr-psg.hex
    09/05/2026  15:40           909,660 avrdude.conf
    09/05/2026  15:40         9,604,608 avrdude.exe
    09/05/2026  15:40        13,316,096 avrdude.pdb
    09/05/2026  15:49                34 config-1.75mhz.hex
    C:\Kevin\Temp>

    To program the ATMega328P requires the following instructions to get the code into flash, the configuration into EEPROM and to set the fuses for the MCU:

    C:\Kevin\Temp>avrdude -c USBasp -p ATMega328P -U flash:w:avr-psg.hex:i
    Error: cannot set sck period; please check for usbasp firmware update
    Error: cannot set sck period; please check for usbasp firmware update
    Reading 682 bytes for flash from input file avr-psg.hex
    Writing 682 bytes to flash
    Writing | ################################################## | 100% 0.43 s
    Reading | ################################################## | 100% 0.23 s
    682 bytes of flash verified

    Avrdude done.  Thank you.


    C:\Kevin\Temp>avrdude -c USBasp -p ATMega328P -U eeprom:w:config-1.75mhz.hex:i
    Error: cannot set sck period; please check for usbasp firmware update
    Reading 5 bytes for eeprom from input file config-1.75mhz.hex
    Writing 5 bytes to eeprom
    Writing | ################################################## | 100% 0.09 s
    Reading | ################################################## | 100% 0.01 s
    5 bytes of eeprom verified

    Avrdude done.  Thank you.

    C:\Kevin\Test>avrdude -c USBasp -p ATMega328P -U lfuse:w:0xdf:m -U hfuse:w:0xdf:m -U efuse:w:0xfd:m
    Error: cannot set sck period; please check for usbasp firmware update

    Processing -U lfuse:w:0xdf:m
    Reading 1 byte for lfuse from input file 0xdf
    Writing 1 byte (0xDF) to lfuse, 1 byte written, 1 verified

    Processing -U hfuse:w:0xdf:m
    Reading 1 byte for hfuse from input file 0xdf
    Writing 1 byte (0xDF) to hfuse, 1 byte written, 1 verified

    Processing -U efuse:w:0xfd:m
    Reading 1 byte for efuse from input file 0xfd
    Writing 1 byte (0xFD) to efuse, 1 byte written, 1 verified

    Avrdude done.  Thank you.

    The error “cannot set sck period” is apparently pretty common especially with USBasp clones, and can be ignored.

    The three fuse settings come from the original AVR-AY firmware (here) in the readme as follows:

    ATMEGA328 ===================================================
    	avrdude -p m328p -c USBasp -U flash:w:AY_Emul_XXX_Nch_KK_MM.hex -U eeprom:w:Conf_XXX_YYMHz_ZZMhz.hex -U lfuse:w:0xee:m -U hfuse:w:0xdf:m -U efuse:w:0xfd:m
    Example:
    	avrdude -p m328p -c USBasp -U flash:w:AY_Emul_250_2ch_m328_ay.hex -U eeprom:w:Conf_standard_27MHz_1_75Mhz.hex -U lfuse:w:0xee:m -U hfuse:w:0xdf:m -U efuse:w:0xfd:m
    =============================================================

    But where the fuse settings for lfuse = 0xEE, when decoded from the ATMega328P datasheet and an online AVR fuse calculator here: https://eleccelerator.com/fusecalc/fusecalc.php?chip=atmega328p means the following:

    0xEE = b1110 1110
    CKDIV8 = 1 (unprogrammed)
    CLKOUT = 1 (unprogrammed)
    SUT    = 10
    CLKSEL = 1110

    Which from the AVR fusecalc site maps onto:

    • External crystal oscillator
    • Frequency 8MHz +
    • Start up time 1K
    • Powerdown/reset 16

    However, following through the settings in the datasheet, it is similar but slightly different, giving:

    • Low power crystal oscillator (CLKSEL3:0 = 1111 – 1000)
    • Low power operating mode 111 = 8.0-16.0 MHz (with recommended caps 12-22pF)
    • CLKSEL0+SUT = 0+10 = Ceramic Resonator BOD enabled, Start up time 1KCK, additional delay 14CK

    But I’m not using a ceramic resonator, I’m using a crystal oscillator, so I think I need the mode:

    • Crystal oscillator BOD enabled, startup time 16KCK, additional delay 14CK = CLKSEL0+SUT = 1+01

    There is no “1KCK” for the crystal oscillator settings, so I’ll have to use 16KCK I guess?

    This is what gives me the 0xDF value I’ve used:

    0xDF = b1101 1111
    CKDIV8 = 1 (unprogrammed)
    CLKOUT = 1 (unprogrammed)
    SUT    = 01
    CLKSEL = 1111

    Actually, this wasn’t working with either 0xEE or 0xDF, so I decide to try to turn off BOD and went with “slow rising power” (CLKSEL0+SUT = 1+11) which gave me the fuses:

    lfuse = b1111 1111 = 0xFF
    hfuse = 0xDF (as before)
    efuse = 0xFF (no brown-out detection)

    But that isn’t working either…

    The AY891x Library and BCn/BCDIR control

    Eventually, I remembered reading about the control signals with the library that was designed for use with that test board. It states the following (here):

    “While the PSG has tight timing requirements, it is possible to use digitalWrite() by using all three bus control signals (BDIR, BC1, BC2) and cycling through an extra state when reading and writing the chip registers.”

    But the emulation is ignoring BC2 (more here), relying instead on the ATMega’s two IO interrupt pins INT0 and INT1 on D2 and D3, to trigger on BDIR and BC1. This means I had to ditch the library and instead switched over to my own PORT IO driver as described here: Arduino and AY-3-8910 – Part 3.

    Resetting the fuses as before, unfortunately it still isn’t working.

    At this point I loaded on a simple tone() function on one of the IO pins using the Arduino IDE then set the fuses again as above. I can definitely see that the frequency for the tone() output is almost twice as high as when the ATMega328P is plugged into the Arduino, so the 27MHz crystal is certainly having an effect compared to the Uno’s original 16MHz.

    I can also see the 105kHz PWM carrier frequency on all three PWM output pins, but the peaks are so narrow, these must be responding to a level 0 output which implies all code is working, but there are simply no register writes getting through.

    So, in summary, I think the code on the emulator is running fine – so why isn’t it responding to register writes?

    An Epiphany?

    At this point I left things for a bit and came back to it all a few days later.

    I was chewing over why the register writes didn’t seem to be getting through, so at this point I think the handling of BC1 and BDIR are key. The next things that I tried:

    • Getting it all on a breadboard and showing it working with a real AY-3-8910.
    • Check I can see BC1 and BDIR and the data lines doing something.
    • Replace the real chip with the emulator.
    • Repeat the tests for BC1, BDIR and data – all appear ok.

    At this point I’m suspecting the interrupts aren’t getting through (remember BC1 and BDIR are triggered off the external interrupts), so I’m contemplating two things:

    • Some test code that lights an LED on an external interrupt.
    • Porting the whole code across to the Arduino environment to let me build and run it all from there.

    But this has got me wondering about build differences for the two devices – what might be different between the ATMega48 and ATMega328P. Would rebuilding from source for the ATMega328P sort it out?

    Looking at the original code, I can see there are many different binaries for the different chips. For the repository I’m using there is just one.

    Looking in the two chip datasheets, I can see that the INT0 interrupt vector is different – it is 2 (address 0x001) for the 48 and whist it is still 2 for the 328P, the address is 0x0002. From the 48 datasheet:

    “Each interrupt vector occupies two instruction words in ATmega168, and one instruction word in ATmega48 and
    ATmega88.”

    From the 328P datasheet:

    “Each interrupt vector occupies two instruction words in Atmel ATmega328P.”

    Looking at the suggested implementations of the vector tables, they are shown as follows:

    // ATMega48 vector table
    0x000 rjmp RESET      ; Reset Handler
    0x001 rjmp EXT_INT0   ; IRQ0 Handler
    0x002 rjmp EXT_INT1   ; IRQ1 Handler

    // ATMega328P vector table
    0x0000 jmp RESET      ; Reset Handler
    0x0002 jmp EXT_INT0   ; IRQ0 Handler
    0x0004 jmp EXT_INT1   ; IRQ1 Handler

    So presumably one is a relative jump (rjmp) which is a single word (16-bit) instruction, vs an absolute jump which is a two-word (32-bit) instruction.

    With hindsight is seems obvious I’d need to rebuild for the ATMega328P, but the initial talk of compatibility lulled me into a false sense of security!

    There is no build for the 328P in the listed repository, but going back to the original avr-ay source, there are builds for all supported MCUs, each with variants covering:

    • 2 or 3 channel sound.
    • AY or YM volume tables.
    • Additional speaker output on PD1.

    There are configuration options for:

    • Serial, parallel, or both (“standard”).
    • 1.75MHz, 1.78MHz, or 2.0MHz operation.
    • 20MHz to 40MHz (including my required 27MHz).

    I’ve now downloaded:

    avrdude -c USBasp -p ATMega328P -U flash:w:AY_Emul_260_3ch_m328_ay.hex:i
    avrdude -c USBasp -p ATMega328P -U eeprom:w:Conf_parallel_27MHz_1_78Mhz.hex:i
    avrdude -c USBasp -p ATMega328P -U lfuse:w:0xee:m -Uhfuse:w:0xdf:m -U efuse:w:0xfd:m

    But unfortunately it still isn’t working…

    I did notice in the original source, a number of conditional assembler code, based on the initial configuration of MCU_TYPE. But most of it is of the form “if MCU_TYPE==0” which is giving alternative code for the ATMega8. There is one piece of code that implies something different for the ATMega48:

    	; get byte 0 from EEPROM, check value > 0 or skip USART initialization if value = 0
    #if MCU_TYPE == 0 ||  MCU_TYPE > 1
    	out		EEARH,C00		; is absent in Atmega48
    #endif
    	out		EEARL,C00

    I also note that the vector table is all relative jumps:

    	.cseg
    ;------------------------------------------------------
    ; INTERRUPT VECTORS TABLE
    ;------------------------------------------------------
    	.org	0x0000
    	rjmp	_RESET

    	.org	INT0addr
    	rjmp	_INT0_Handler

    	.org	INT1addr
     	rjmp	_INT1_Handler

    	.org	URXCaddr
    	rjmp	_USART_RX_COMPLETE

    But as each entry has its own origin statement, one presumes that these are correct for the MCU type.

    Double checking the hex records for my chosen firmware, and adding some expansions and annotations, I can see:

    // Format:
    // :ll aaaa tt dd..dd cc
    //                    ++-- CRC
    //             +----+----- Data
    //          ++------------ Record type
    //     +--+--------------- Address
    //  ++-------------------- Data length

    :02 0000 02 0000 FC  // tt=02: Extended (Upper) Segment Base Address

    // Vector Table tt=00: Data
    :02 0000 00 88C0 B6
    :02 0004 00 4AC0 F0
    :02 0008 00 56C0 E0

    // Start of code/data tt=00; Data
    :10 0048 00 50C0000101010202030506090D11161D 29
    :10 0058 00 242D0000010101010101020202020303 33
    :10 0068 00 0505060607090B0D0F111316191D2024 87
    ...
    :10 02F8 00 0092880010928A0092CF05910D932A95 5A
    :04 0308 00 E1F70895 7C
    :00 0000 01 FF       // tt=01: End of File

    So yes, it would appear that the vectors in the vector table are indeed on the expected 32-bit boundaries which matches and it has values for vectors 2 and 3, so INT0 and INT1. Vector 1 is RESET.

    One oddity, each record is only 2 bytes long, so I guess it is assuming that the missing bytes will be zero? Really, the full records should perhaps be:

    :04 0000 00 88C00000 B4 // Needed to recalc CRC
    :04 0004 00 4AC00000 EE
    :04 0008 00 56C00000 DE

    I don’t know the algorithm for calculating the CRC, but I don’t need to. When attempting to download via avrdude any CRC mismatch is reported, detailing what value was expected which allows me to set the correct value for each line at a time!

    But as these are instructions rather than addresses themselves, maybe it would be fine. If the PC hits this address, then the instruction will be (presumably) a rjmp which is only two bytes and all would be fine.

    But regardless, unfortunately this still isn’t working. I’m now at quite a loss as to what to try next.

    I did go back and look at the original firmware I was using and it has the following:

    :06 0000 00 70C039C045C0 CC

    So I don’t see how this would work on an ATMega328P at all as each vector is only half the expected size.

    The reset vector is probably ok, as the first two bytes will be read as a “rjmp” instruction and presumably the next two bytes ignored. But INT0 and INT1 will be jumping off into who-knows-where.

    This would match the evidence that the board seems to get initialised but no register writes are processed.

    So this at least does confirm that the original firmware was no good for me.

    Conclusion

    I’ve got to draw a line under this for now. I’m going to hit publish on this post as is, and put this aside for a bit.

    Some possible future directions:

    • Solder on the ICSP header to make uploading code a bit easier.
    • Load up some simple Arduino firmware that will indicate if INT0/INT1 are actually getting through.
    • Create a ATMega48 breakout to see if the board would work with the original MCU ok.
    • I’m still not convinced with that clock – it seems a very low amplitude – I wonder if those capacitors are the right values.
    • Port the whole lot to the Arduino environment. This is going to be a fair bit of work as you can’t use assembler directly, but only via asm(“nop”) style directives…

    But for now, this one is on pause.

    And I’m still annoyed about the error in the ICSP pinout…

    Kevin

    #arduino #atmega328 #ay38910 #ay38912 #emulation #MakerFail #pcbs
    #arduino #atmega328 #ay38910 #ay38912 #emulation #makerfail
  16. laen 🌿 @[email protected] ·

    watch the lid (right at the top of the frame) ...

    #MakerFail

    #makerfail
  17. diyelectromusic @[email protected] ·

    @iris @MakersHour @MLE_online @potterybyosa @moonrabbit Oh absolutely. And fails. We don't see enough things that didn't work in my vew. One reason I was trying to get #MakerFail used a bit more :)

    #makerfail
  18. diyelectromusic @[email protected] ·

    Ah, I think I've found why one of my boards isn't presenting a USB device on boot. This sits between the USB connector and the RP2350...

    I don't have anything fine enough to try to fix that by hand, which is a shame.

    Anyway registered a quality issue, so will see what happens.

    #MakerFail

    #makerfail
  19. diyelectromusic @[email protected] ·

    @quixoticgeek @MakersHour Oh, do start using the #MakerFail tag then! I'd really like more people to document their fails - I think sometimes everything can seem too perfect! :)

    #makerfail
  20. diyelectromusic @[email protected] ·

    @Unixbigot @andypiper Haha! We've all been there! :)

    #MakerFail

    #makerfail
  21. diyelectromusic @[email protected] ·

    @mike @[email protected] @[email protected] I think we learn as much from each others #MakerFail s as we do from the successes!

    It's good that you've written it up :)

    #makerfail
  22. diyelectromusic @[email protected] ·

    Damn, for a brief hour or two this evening, I thought I'd made a breakthrough with the DX100.

    But it turns out I get a really neat and crips data signal when I plug in a blank ROM by mistake :)

    Still I think I've ruled out the ROM, RAM, sound generator, and probably the ADC...

    So that really is pointing back to the display I think...

    I've written up the latest minor increment forward here.

    But fundamentally it still isn't working :)

    diyelectromusic.com/2025/07/08

    #DX100 #MakerFail

    #dx100 #makerfail
  23. diyelectromusic @[email protected] ·

    I've just tried to program a new ROM for my DX100 to rule that out and as far as I can see that has had no effect.

    I've updated my last post on the topic anyway, but I might have to admit defeat with this one as I'm not sure I've got it in me to be desoldering RAM chips or the Yamaha sound generator...

    I'm still wondering if there is a simpler explanation I'm just not seeing at the moment.

    diyelectromusic.com/2025/04/16

    #MakerFail

    #makerfail
  24. diyelectromusic @[email protected] ·

    And immediately followed by a simpler version, thanks to the observation by @bytex64 that the originals wouldn't have used ADCs at all! :)

    diyelectromusic.com/2025/06/22

    Just goes to show that sometimes we can't "see the wood for the trees" in some of these things! And we are spoiled by our modern tools.

    #Atari #Arduino

    Was this a #MakerFail ? Not sure. Certainly some learning going on there though :)

    #atari #arduino #makerfail
  25. diyelectromusic @[email protected] ·

    Haha. Whilst messing around with this for its proper purpose this morning, I've realised I've used values in the PWM filter much more suited to audio frequencies than a CV!

    That will teach me to properly think about my requirement for a circuit rather than paste in a previous one :)

    #MakerFail

    #makerfail
  26. AxWax @[email protected] ·

    Why does adding one of those 0.96" #OLED screens to my project cause terrible noise to my PCM5102 i2s output board whenever the screen updates 😩

    And why did I not check this before permanently attaching it to my project case? 😭

    #MakerFail #electronics

    #oled #makerfail #electronics
  27. AxWax @[email protected] ·

    Who's got two thumbs and not only found out how not to connect two batteries in series, but also learned how to arc weld in the process?

    As a bonus he's still got two functioning thumbs...

    PSA: Double-check your polarities when playing with 12V batteries and misleadingly marked cables...

    #TIL #MakerFail

    #til #makerfail
  28. diyelectromusic @[email protected] ·

    So turns out I've used the footprint for the socket version of a 9-pin d-type connector on my PCB when I needed the pins version, so the pins are wired up the wrong way round...

    Oh well, v2 now sent off...

    #MakerFail

    #makerfail
  29. diyelectromusic @[email protected] ·

    I thought this would be an easy fix - using a Pi Zero-format RP2040 board in my MiniDexed EuroRack module...

    ... but it ended up an afternoon of frustration and unfortunately I still can't get it making sound or booting reliably.

    It does look cool though :)

    Anyone else have any experience of these Stacky-Pi "RP2040 on a Pi Zero shaped PCB" boards?

    diyelectromusic.com/2025/04/12

    #PicoDexed #MIDI #StackyPi #MakerFail

    #picodexed #midi #stackypi #makerfail
  30. diyelectromusic @[email protected] ·

    I thought this would be an easy fix - using a Pi Zero-format RP2040 board in my MiniDexed EuroRack module...

    ... but it ended up an afternoon of frustration and unfortunately I still can't get it making sound or booting reliably.

    It does look cool though :)

    Anyone else have any experience of these Stacky-Pi "RP2040 on a Pi Zero shaped PCB" boards?

    diyelectromusic.com/2025/04/12

    #PicoDexed #MIDI #StackyPi #MakerFail

    #picodexed #midi #stackypi #makerfail
  31. diyelectromusic @[email protected] ·

    I thought this would be an easy fix - using a Pi Zero-format RP2040 board in my MiniDexed EuroRack module...

    ... but it ended up an afternoon of frustration and unfortunately I still can't get it making sound or booting reliably.

    It does look cool though :)

    Anyone else have any experience of these Stacky-Pi "RP2040 on a Pi Zero shaped PCB" boards?

    diyelectromusic.com/2025/04/12

    #PicoDexed #MIDI #StackyPi #MakerFail

    #picodexed #midi #stackypi #makerfail
  32. diyelectromusic @[email protected] ·

    I thought this would be an easy fix - using a Pi Zero-format RP2040 board in my MiniDexed EuroRack module...

    ... but it ended up an afternoon of frustration and unfortunately I still can't get it making sound or booting reliably.

    It does look cool though :)

    Anyone else have any experience of these Stacky-Pi "RP2040 on a Pi Zero shaped PCB" boards?

    diyelectromusic.com/2025/04/12

    #PicoDexed #MIDI #StackyPi #MakerFail

    #makerfail #stackypi #midi #picodexed
  33. diyelectromusic @[email protected] ·

    I thought this would be an easy fix - using a Pi Zero-format RP2040 board in my MiniDexed EuroRack module...

    ... but it ended up an afternoon of frustration and unfortunately I still can't get it making sound or booting reliably.

    It does look cool though :)

    Anyone else have any experience of these Stacky-Pi "RP2040 on a Pi Zero shaped PCB" boards?

    diyelectromusic.com/2025/04/12

    #PicoDexed #MIDI #StackyPi #MakerFail

    #picodexed #midi #stackypi #makerfail
  34. diyelectromusic @[email protected] ·

    Yeah, what of it? I'm not proud. May as well see if the rest works anyway :)

    #MakerFail

    #makerfail
  35. diyelectromusic @[email protected] ·

    Hmm. That's mildly annoying. Wish I'd tried that before soldering the other bits on... oh well.

    #MakerFail

    #makerfail
  36. diyelectromusic @[email protected] ·

    So, looks like a razor blade, applied carefully, has largely removed the erroneous Ref** that slipped into the silkscreen on my new panel...

    That is what happens when you change the size of a hole fairly last minute and don't notice a layer change for a reference when previewing the Gerber files before sending it off...

    #MakerFail

    #makerfail
  37. diyelectromusic @[email protected] ·

    Apart from the fact I totally miss-guessed the locations for the text(!) I'm pretty pleased with this result.

    This panel is following the process suggested by @doctroid
    in the attached video.

    Now I know I can do the process and it works fine for me, I can make a new panel fairly easily and fix the text.

    youtube.com/watch?v=-8sNB2UjLAo

    #MakerFail #NotReallyAFailALearningOpportunity
    #SynthDIY

    #makerfail #notreallyafailalearningopportunity #synthdiy
  38. AxWax @[email protected] ·

    I should not be allowed near a Dremel until I know where is up and where is down! 😩

    There, that's the Toot!

    #MakerFail

    #makerfail
  39. diyelectromusic @[email protected] ·

    @jayemar And in a fun twist, sometimes I use #MakerFails, so even using #MakerFail is sometimes a #MakerFail :)

    #makerfails #makerfail
  40. diyelectromusic @[email protected] ·

    @jayemar I love the idea that #MakerFail could be my legacy!

    Does that make me an influencer!?

    cc #MakersHour - we need more fails :)

    #makerfail #makershour
  41. diyelectromusic @[email protected] ·

    Had an odd voltage reading in a circuit and finally realised I'd used 10K resistors instead of 100K.

    Then went to replace them and pulled out two more from my 100K drawer... and turns out I'd managed to drop a single ribbon of 10K resistors into my 100K drawer by mistake!

    Oh well - at least I spotted they had the same bands as the ones I was replacing...

    #MakerFail

    #makerfail
  42. diyelectromusic @[email protected] ·

    Whoops. But I think I can fix my soldering iron. I have a spare element, I just need to solder it onto the pcb...

    err...

    I just need to... solder it onto...

    err...

    #MakerFail #HangOnLadsIveGotAnIdea

    #makerfail #hangonladsivegotanidea
  43. diyelectromusic @[email protected] ·

    That moment when you think your PCB is finished being routed up and you realise your microcontroller is on the wrong side of the board :/

    Mind you, better to spot it now than when I'm admiring the returned PCBs in a few weeks time!

    I'm now wondering if it might be easier just to swap all the other components, as there aren't very many. But that would really annoy me forever more if I do that...

    #MakerFail

    #makerfail
  44. diyelectromusic @[email protected] ·

    Finally got something that worked, but wasn't confident it would last.

    Realised today what the issue was.

    I'd forgotten that the Adafruit_SSD1306 library has to malloc a display buffer on startup and if it fails, the display won't work.

    All the fiddling about kept moving my free memory either side of what the library needed...

    Swapping some int arrays to uint8_t seems to free up enough that it now all works properly!

    I hate dynamic memory on embedded systems! Esp on an Uno :)

    #MakerFail

    #makerfail
  45. diyelectromusic @[email protected] ·

    @Maker_of_Things @makershour A4 I don't think I do big fails... a general background of continual #MakerFail s is probably more my thing :)

    As such I'd like to think I've learned something from all of them!

    (even if it is just "no matter how many times I do it, I'll never remember to check RX vs TX; MIDI pin 4 or 5; or which way round to wire a potentiometer" and just accept I'll keep making the same mistakes!!)

    #MakersHour

    #makerfail #makershour
  46. diyelectromusic @[email protected] ·

    Ah. Just had my first 3D printing spaghetti moment.

    Turns it out is always a good idea when printing two things at the same time to make sure they both actually reach down to the build plate... :)

    Thankfully I hadn't left it for too long to go completely wild!

    #MakerFail

    #makerfail