home.social

#pcbs — Public Fediverse posts

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

  1. Ireland @[email protected] ·

    europesays.com/ie/491119/ Mikroe Expands Click Board Portfolio with Ethernet IoT Solution #Communications #Éire #IE #IoT #Ireland #Networking/Wireless #PCBs #Processors&Controllers #Technology

    #technology #processors #pcbs #networking #ireland #iot
  2. 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
  3. 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
  4. 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
  5. 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
  6. 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
  7. Klaus Frank @[email protected] ·

    wtf is going on with this chip?

    #microcontroller #microcontroller #PCBs

    #microcontroller #pcbs
  8. Klaus Frank @[email protected] ·

    wtf is going on with this chip?

    #microcontroller #microcontroller #PCBs

    #microcontroller #pcbs
  9. Klaus Frank @[email protected] ·

    wtf is going on with this chip?

    #microcontroller #microcontroller #PCBs

    #microcontroller #pcbs
  10. Klaus Frank @[email protected] ·

    wtf is going on with this chip?

    #microcontroller #microcontroller #PCBs

    #microcontroller #pcbs
  11. Hacker News @[email protected] ·

    Open-Source KiCad PCBs for Common Arduino, ESP32, RP2040 Boards

    github.com/Hanqaqa/Easyduino

    #HackerNews #OpenSource #KiCad #PCBs #Arduino #ESP32 #RP2040

    #hackernews #opensource #kicad #pcbs #arduino #esp32
  12. Hacker News @[email protected] ·

    Open-Source KiCad PCBs for Common Arduino, ESP32, RP2040 Boards

    github.com/Hanqaqa/Easyduino

    #HackerNews #OpenSource #KiCad #PCBs #Arduino #ESP32 #RP2040

    #hackernews #opensource #kicad #pcbs #arduino #esp32
  13. Hacker News @[email protected] ·

    Open-Source KiCad PCBs for Common Arduino, ESP32, RP2040 Boards

    github.com/Hanqaqa/Easyduino

    #HackerNews #OpenSource #KiCad #PCBs #Arduino #ESP32 #RP2040

    #hackernews #opensource #kicad #pcbs #arduino #esp32
  14. Hacker News @[email protected] ·

    Open-Source KiCad PCBs for Common Arduino, ESP32, RP2040 Boards

    github.com/Hanqaqa/Easyduino

    #HackerNews #OpenSource #KiCad #PCBs #Arduino #ESP32 #RP2040

    #rp2040 #esp32 #arduino #pcbs #kicad #opensource
  15. Hacker News @[email protected] ·

    Open-Source KiCad PCBs for Common Arduino, ESP32, RP2040 Boards

    github.com/Hanqaqa/Easyduino

    #HackerNews #OpenSource #KiCad #PCBs #Arduino #ESP32 #RP2040

    #hackernews #opensource #kicad #pcbs #arduino #esp32
  16. Africa @[email protected] ·

    europesays.com/africa/183581/ FG approves 2026 Fiscal Policy Measures, cuts tariffs on cars, others #AFCFTA #ECOWAS #IATs #MinisterOfTheEconomy #news #Nigeria #PBBs #PCBs #PCTs #PremiumTimes #WaleEdun

    #waleedun #premiumtimes #pcts #pcbs #pbbs #nigeria
  17. merlin / alex glow @[email protected] ·

    New vid! #PCBs I made in 2025, part 1: LED charm ✨
    instagram.com/reel/DTH1NuelDig

    Finally pulled together a prototype with this little board – one of my new #Charmware set, reviving the series of modular tech #jewelry bits I started back in 2018. Been dreaming of assembling these with elytra and bike-leather, and the day finally came... The board still needs some tweaks (smaller switch etc.), but with my fixed-up #KiCad workflow, those will be a snap. 😸

    // #Maker #LEDs #WearableTech

    #pcbs #charmware #jewelry #kicad #maker #leds
  18. merlin / alex glow @[email protected] ·

    Tues #hardware update & #HackOClock coming up in ~30!

    Some gorgeous black #PCBs arrived; I’ll be testing & wrapping up a new Joule Thief design in #KiCad too... plus, #PenPlotter prep for holiday cards?? ✨

    ▶️ youtube.com/glowascii
    ▶️ twitch.tv/glowascii
    ▶️ linkedin.com/in/alexglow

    // #electronics #maker #MakersGonnaMake

    #hardware #hackoclock #pcbs #kicad #penplotter #electronics
  19. merlin / alex glow @[email protected] ·

    About to go live with a late-night Tuesday vlog; chill times if you wanna jump in. :)

    ▶️ youtube.com/glowascii
    ▶️ twitch.tv/glowascii
    ▶️ linkedin.com/in/alexglow

    // #electronics #hardware #maker #PCBs

    #electronics #hardware #maker #pcbs
  20. Emily @[email protected] ·

    #Introduction time 😊

    Long time maker/nerd girl who loves to learn... and can't get enough

    Designing my own #pcbs with #Kicad often around #IoT and #HomeAutomation, but you never know what 🤔 Huge fan of #HomeAssistant

    Been #3Dprinting for several years

    Started with DOS 3.3 but now run #Linux and #Ubuntu and #Debian . ❤️ Love #retrocomputing

    Very much enjoy my #HomeLab and learning

    In my "spare" time may be out hiking, fixing or fixing retro systems

    #3dprinting #linux #homeautomation #homeassistant #kicad #pcbs
  21. merlin / alex glow @[email protected] ·

    Hey, any of y'all #PCB nerds have a favorite type of UV-cure solder mask? 👀

    Just got my old Bantam mill back, and I'd like to level up my quick-prototyping game...

    // #PCBs

    #pcb #pcbs
  22. merlin / alex glow @[email protected] ·

    Ehehehe!! Finally, my #KiCad process is rolling again... here's a tiny, ornate blinky – the first entry in my updated #Charmware series of #PCBs, begun in 2018: hackster.io/glowascii/charmwar

    I'm working out some small kinks in the upload process – but hoping to have a small batch of prototypes this weekend! ✨

    (Left one is backwards bc I forgot to flip the KiCad screenshot before drawing on a ton of layers lol)

    #kicad #charmware #pcbs
  23. merlin / alex glow @[email protected] ·

    Tuesday evening update going live! Immersive audio testing, my discontinued faves, custom #KiCad components, (ham) #radio, and sticker designs (help me decide!) ✨

    Want to do these earlier, but I’m still a tad under the weather and finally found the energy 😅

    // #electronics #hardware #maker #PCBs

    ▶️ youtube.com/glowascii
    ▶️ twitch.tv/glowascii
    ▶️ linkedin.com/in/alexglow

    #kicad #radio #electronics #hardware #maker #pcbs
  24. merlin / alex glow @[email protected] ·

    Going live in ~60m with a special, cozy #Halloween livestream: my favorite spooky-style #PCBs, plus some live #hardware hacking! I've been brewing up some fun new stuff in #KiCad 🛠️✨

    ▶️ youtube.com/glowascii
    ▶️ twitch.tv/glowascii
    ▶️ linkedin.com/in/alexglow

    // #HackOClock #Electronics #Maker

    #halloween #pcbs #hardware #kicad #hackoclock #electronics
  25. Charles J Gervasi ⚡🛡️🥥 @cgervasi ·

    on change like the weather. My understanding is it's because the law allows the president to single-handed impose these in an emergency. There's no standard, so the president really wanting it counts as an "emergency". We need reforms so one person cannot raise taxes on a whim!

    #tariffs #pcbs #taxes
  26. DoomsdaysCW @[email protected] ·

    What good are #TreatyRights if the fish are poisoned?

    Monday, July 14, 2025
    By George Ochenski, Daily Montanan

    "By virtually any measure, the #ConfederatedSalishKootenai Tribal Nation is an incredible success story against all odds. Forcibly removed from their homeland in the Bitterroot Valley, despite not having waged war against the white settlers or army, their own '#TrailOfTears' brought them to the Flathead Valley to live within the boundaries of the vastly reduced lands they retained in the #HellgateTreatyOf1855.

    "Although the #HellgateTreaty is widely regarded as one of the best treaties signed by any of the nation’s #IndigenousPeople, even land supposedly reserved for the exclusive habitation of the #SalishKootenai was opened to purchase by non-tribal #settlers by the #DawesAct of 1887.

    "The act’s intentions were to allocate reservation lands the tribes already owned to individual families as private property and, as part of the 'civilization' of #NativeAmericans, it required tribal members to register with the federal government to receive their 'allotment.'

    "The entire debacle was part of the #AllotmentAndAssimilationEra from 1887 to 1934. Simply put, the federal government’s plan was to force Native Americans to be 'assimilated' into #EuropeanAmerican culture.

    "Importantly, any reservation lands not allocated to tribal members was deemed
    'surplus' land and opened to purchase by non-tribal settlers. This excursion into #ReservationLands was further exacerbated by the ability of tribal members to sell their allotment parcels to non-tribal members.

    "The fracturing of the Salish-Kootenai’s tribal lands through sales to non-tribal members continues to cause serious problems today, including the long and on-going battle to retain their #water, #hunting and #fishing #TreatyRights.

    "Article III of the Hellgate Treaty could not be more clear regarding the Tribe’s fishing rights: 'The exclusive right of taking fish in all the streams running through or bordering said reservation is further secured to said Indians; as also the right of taking fish at all usual and accustomed places…'

    "Yet, just last month the Confederated Salish-Kootenai Tribal Nation issued a very serious warning to tribal members regarding the fish they have treaty rights to catch because they are poisoned.

    CSKT Fish Consumption Advisory

    "The Confederated Salish and Kootenai Tribes issued a fish consumption advisory on June 24, 2025, warning tribal citizens not to eat fish due to the presence of Polychlorinated biphenyls (#PCBs), #dioxins and #furans at levels deemed unsafe for humans: Source: Confederated Salish and Kootenai Tribes

    "The #FishConsumptionAdvisory urges 'all tribal members to avoid consuming all species and sizes of fish harvested from the lower Clark Fork River from the Bitterroot River near Missoula to the Flathead River near Paradise. Recent testing has confirmed the presence of polychlorinated biphenyls, dioxins and furans in fish at levels that are unsafe for consumption by Tribal peoples. It is also advisable to avoid consuming rainbow trout and northern pike harvested from the Bitterroot River and the upper Clark Fork River above the Bitterroot River to Rock Creek, and, to avoid consuming rainbow trout from the Blackfoot River.

    "As the Advisory explains: 'These contaminants pose a health risk to all fish consumers, and an even greater health risk to the most sensitive members of the Tribal population including women of child bearing age, pregnant nursing women, and young children. These contaminants have been linked to negative health effects in the immune, and nervous systems and may be associated with birth defects…PCBs and dioxins are classified as probable and definite #HumanCarcinogens, respectively.'

    "So what good are treaty fishing rights if you can’t eat the fish because they’re poisoned? Are they really 'rights' — or is this just another in our nation’s long and shameful history of abrogating its treaties with Native Americans?

    "Moreover, #Montana’s poison fish affect us all. Just as our government has failed the Salish-Kootenai, they have likewise failed to uphold our rights to the 'swimmable/fishable waters' guaranteed by the #CleanWaterAct — because no one, tribal or non-tribal, is immune to poisoned fish."

    Source:
    indianz.com/News/2025/07/14/ge

    #WaterIsLife #TribalNations #NativeAmericanNews #WaterPollution #PoisonedFish #StolenLand #LandBack #EPAFail

    #treatyrights #confederatedsalishkootenai #trailoftears #hellgatetreatyof1855 #hellgatetreaty #indigenouspeople
  27. DoomsdaysCW @[email protected] ·

    What good are #TreatyRights if the fish are poisoned?

    Monday, July 14, 2025
    By George Ochenski, Daily Montanan

    "By virtually any measure, the #ConfederatedSalishKootenai Tribal Nation is an incredible success story against all odds. Forcibly removed from their homeland in the Bitterroot Valley, despite not having waged war against the white settlers or army, their own '#TrailOfTears' brought them to the Flathead Valley to live within the boundaries of the vastly reduced lands they retained in the #HellgateTreatyOf1855.

    "Although the #HellgateTreaty is widely regarded as one of the best treaties signed by any of the nation’s #IndigenousPeople, even land supposedly reserved for the exclusive habitation of the #SalishKootenai was opened to purchase by non-tribal #settlers by the #DawesAct of 1887.

    "The act’s intentions were to allocate reservation lands the tribes already owned to individual families as private property and, as part of the 'civilization' of #NativeAmericans, it required tribal members to register with the federal government to receive their 'allotment.'

    "The entire debacle was part of the #AllotmentAndAssimilationEra from 1887 to 1934. Simply put, the federal government’s plan was to force Native Americans to be 'assimilated' into #EuropeanAmerican culture.

    "Importantly, any reservation lands not allocated to tribal members was deemed
    'surplus' land and opened to purchase by non-tribal settlers. This excursion into #ReservationLands was further exacerbated by the ability of tribal members to sell their allotment parcels to non-tribal members.

    "The fracturing of the Salish-Kootenai’s tribal lands through sales to non-tribal members continues to cause serious problems today, including the long and on-going battle to retain their #water, #hunting and #fishing #TreatyRights.

    "Article III of the Hellgate Treaty could not be more clear regarding the Tribe’s fishing rights: 'The exclusive right of taking fish in all the streams running through or bordering said reservation is further secured to said Indians; as also the right of taking fish at all usual and accustomed places…'

    "Yet, just last month the Confederated Salish-Kootenai Tribal Nation issued a very serious warning to tribal members regarding the fish they have treaty rights to catch because they are poisoned.

    CSKT Fish Consumption Advisory

    "The Confederated Salish and Kootenai Tribes issued a fish consumption advisory on June 24, 2025, warning tribal citizens not to eat fish due to the presence of Polychlorinated biphenyls (#PCBs), #dioxins and #furans at levels deemed unsafe for humans: Source: Confederated Salish and Kootenai Tribes

    "The #FishConsumptionAdvisory urges 'all tribal members to avoid consuming all species and sizes of fish harvested from the lower Clark Fork River from the Bitterroot River near Missoula to the Flathead River near Paradise. Recent testing has confirmed the presence of polychlorinated biphenyls, dioxins and furans in fish at levels that are unsafe for consumption by Tribal peoples. It is also advisable to avoid consuming rainbow trout and northern pike harvested from the Bitterroot River and the upper Clark Fork River above the Bitterroot River to Rock Creek, and, to avoid consuming rainbow trout from the Blackfoot River.

    "As the Advisory explains: 'These contaminants pose a health risk to all fish consumers, and an even greater health risk to the most sensitive members of the Tribal population including women of child bearing age, pregnant nursing women, and young children. These contaminants have been linked to negative health effects in the immune, and nervous systems and may be associated with birth defects…PCBs and dioxins are classified as probable and definite #HumanCarcinogens, respectively.'

    "So what good are treaty fishing rights if you can’t eat the fish because they’re poisoned? Are they really 'rights' — or is this just another in our nation’s long and shameful history of abrogating its treaties with Native Americans?

    "Moreover, #Montana’s poison fish affect us all. Just as our government has failed the Salish-Kootenai, they have likewise failed to uphold our rights to the 'swimmable/fishable waters' guaranteed by the #CleanWaterAct — because no one, tribal or non-tribal, is immune to poisoned fish."

    Source:
    indianz.com/News/2025/07/14/ge

    #WaterIsLife #TribalNations #NativeAmericanNews #WaterPollution #PoisonedFish #StolenLand #LandBack #EPAFail

    #treatyrights #confederatedsalishkootenai #trailoftears #hellgatetreatyof1855 #hellgatetreaty #indigenouspeople
  28. DoomsdaysCW @[email protected] ·

    What good are #TreatyRights if the fish are poisoned?

    Monday, July 14, 2025
    By George Ochenski, Daily Montanan

    "By virtually any measure, the #ConfederatedSalishKootenai Tribal Nation is an incredible success story against all odds. Forcibly removed from their homeland in the Bitterroot Valley, despite not having waged war against the white settlers or army, their own '#TrailOfTears' brought them to the Flathead Valley to live within the boundaries of the vastly reduced lands they retained in the #HellgateTreatyOf1855.

    "Although the #HellgateTreaty is widely regarded as one of the best treaties signed by any of the nation’s #IndigenousPeople, even land supposedly reserved for the exclusive habitation of the #SalishKootenai was opened to purchase by non-tribal #settlers by the #DawesAct of 1887.

    "The act’s intentions were to allocate reservation lands the tribes already owned to individual families as private property and, as part of the 'civilization' of #NativeAmericans, it required tribal members to register with the federal government to receive their 'allotment.'

    "The entire debacle was part of the #AllotmentAndAssimilationEra from 1887 to 1934. Simply put, the federal government’s plan was to force Native Americans to be 'assimilated' into #EuropeanAmerican culture.

    "Importantly, any reservation lands not allocated to tribal members was deemed
    'surplus' land and opened to purchase by non-tribal settlers. This excursion into #ReservationLands was further exacerbated by the ability of tribal members to sell their allotment parcels to non-tribal members.

    "The fracturing of the Salish-Kootenai’s tribal lands through sales to non-tribal members continues to cause serious problems today, including the long and on-going battle to retain their #water, #hunting and #fishing #TreatyRights.

    "Article III of the Hellgate Treaty could not be more clear regarding the Tribe’s fishing rights: 'The exclusive right of taking fish in all the streams running through or bordering said reservation is further secured to said Indians; as also the right of taking fish at all usual and accustomed places…'

    "Yet, just last month the Confederated Salish-Kootenai Tribal Nation issued a very serious warning to tribal members regarding the fish they have treaty rights to catch because they are poisoned.

    CSKT Fish Consumption Advisory

    "The Confederated Salish and Kootenai Tribes issued a fish consumption advisory on June 24, 2025, warning tribal citizens not to eat fish due to the presence of Polychlorinated biphenyls (#PCBs), #dioxins and #furans at levels deemed unsafe for humans: Source: Confederated Salish and Kootenai Tribes

    "The #FishConsumptionAdvisory urges 'all tribal members to avoid consuming all species and sizes of fish harvested from the lower Clark Fork River from the Bitterroot River near Missoula to the Flathead River near Paradise. Recent testing has confirmed the presence of polychlorinated biphenyls, dioxins and furans in fish at levels that are unsafe for consumption by Tribal peoples. It is also advisable to avoid consuming rainbow trout and northern pike harvested from the Bitterroot River and the upper Clark Fork River above the Bitterroot River to Rock Creek, and, to avoid consuming rainbow trout from the Blackfoot River.

    "As the Advisory explains: 'These contaminants pose a health risk to all fish consumers, and an even greater health risk to the most sensitive members of the Tribal population including women of child bearing age, pregnant nursing women, and young children. These contaminants have been linked to negative health effects in the immune, and nervous systems and may be associated with birth defects…PCBs and dioxins are classified as probable and definite #HumanCarcinogens, respectively.'

    "So what good are treaty fishing rights if you can’t eat the fish because they’re poisoned? Are they really 'rights' — or is this just another in our nation’s long and shameful history of abrogating its treaties with Native Americans?

    "Moreover, #Montana’s poison fish affect us all. Just as our government has failed the Salish-Kootenai, they have likewise failed to uphold our rights to the 'swimmable/fishable waters' guaranteed by the #CleanWaterAct — because no one, tribal or non-tribal, is immune to poisoned fish."

    Source:
    indianz.com/News/2025/07/14/ge

    #WaterIsLife #TribalNations #NativeAmericanNews #WaterPollution #PoisonedFish #StolenLand #LandBack #EPAFail

    #epafail #landback #stolenland #poisonedfish #waterpollution #nativeamericannews
  29. DoomsdaysCW @[email protected] ·

    What good are #TreatyRights if the fish are poisoned?

    Monday, July 14, 2025
    By George Ochenski, Daily Montanan

    "By virtually any measure, the #ConfederatedSalishKootenai Tribal Nation is an incredible success story against all odds. Forcibly removed from their homeland in the Bitterroot Valley, despite not having waged war against the white settlers or army, their own '#TrailOfTears' brought them to the Flathead Valley to live within the boundaries of the vastly reduced lands they retained in the #HellgateTreatyOf1855.

    "Although the #HellgateTreaty is widely regarded as one of the best treaties signed by any of the nation’s #IndigenousPeople, even land supposedly reserved for the exclusive habitation of the #SalishKootenai was opened to purchase by non-tribal #settlers by the #DawesAct of 1887.

    "The act’s intentions were to allocate reservation lands the tribes already owned to individual families as private property and, as part of the 'civilization' of #NativeAmericans, it required tribal members to register with the federal government to receive their 'allotment.'

    "The entire debacle was part of the #AllotmentAndAssimilationEra from 1887 to 1934. Simply put, the federal government’s plan was to force Native Americans to be 'assimilated' into #EuropeanAmerican culture.

    "Importantly, any reservation lands not allocated to tribal members was deemed
    'surplus' land and opened to purchase by non-tribal settlers. This excursion into #ReservationLands was further exacerbated by the ability of tribal members to sell their allotment parcels to non-tribal members.

    "The fracturing of the Salish-Kootenai’s tribal lands through sales to non-tribal members continues to cause serious problems today, including the long and on-going battle to retain their #water, #hunting and #fishing #TreatyRights.

    "Article III of the Hellgate Treaty could not be more clear regarding the Tribe’s fishing rights: 'The exclusive right of taking fish in all the streams running through or bordering said reservation is further secured to said Indians; as also the right of taking fish at all usual and accustomed places…'

    "Yet, just last month the Confederated Salish-Kootenai Tribal Nation issued a very serious warning to tribal members regarding the fish they have treaty rights to catch because they are poisoned.

    CSKT Fish Consumption Advisory

    "The Confederated Salish and Kootenai Tribes issued a fish consumption advisory on June 24, 2025, warning tribal citizens not to eat fish due to the presence of Polychlorinated biphenyls (#PCBs), #dioxins and #furans at levels deemed unsafe for humans: Source: Confederated Salish and Kootenai Tribes

    "The #FishConsumptionAdvisory urges 'all tribal members to avoid consuming all species and sizes of fish harvested from the lower Clark Fork River from the Bitterroot River near Missoula to the Flathead River near Paradise. Recent testing has confirmed the presence of polychlorinated biphenyls, dioxins and furans in fish at levels that are unsafe for consumption by Tribal peoples. It is also advisable to avoid consuming rainbow trout and northern pike harvested from the Bitterroot River and the upper Clark Fork River above the Bitterroot River to Rock Creek, and, to avoid consuming rainbow trout from the Blackfoot River.

    "As the Advisory explains: 'These contaminants pose a health risk to all fish consumers, and an even greater health risk to the most sensitive members of the Tribal population including women of child bearing age, pregnant nursing women, and young children. These contaminants have been linked to negative health effects in the immune, and nervous systems and may be associated with birth defects…PCBs and dioxins are classified as probable and definite #HumanCarcinogens, respectively.'

    "So what good are treaty fishing rights if you can’t eat the fish because they’re poisoned? Are they really 'rights' — or is this just another in our nation’s long and shameful history of abrogating its treaties with Native Americans?

    "Moreover, #Montana’s poison fish affect us all. Just as our government has failed the Salish-Kootenai, they have likewise failed to uphold our rights to the 'swimmable/fishable waters' guaranteed by the #CleanWaterAct — because no one, tribal or non-tribal, is immune to poisoned fish."

    Source:
    indianz.com/News/2025/07/14/ge

    #WaterIsLife #TribalNations #NativeAmericanNews #WaterPollution #PoisonedFish #StolenLand #LandBack #EPAFail

    #treatyrights #confederatedsalishkootenai #trailoftears #hellgatetreatyof1855 #hellgatetreaty #indigenouspeople
  30. DoomsdaysCW @[email protected] ·

    What good are #TreatyRights if the fish are poisoned?

    Monday, July 14, 2025
    By George Ochenski, Daily Montanan

    "By virtually any measure, the #ConfederatedSalishKootenai Tribal Nation is an incredible success story against all odds. Forcibly removed from their homeland in the Bitterroot Valley, despite not having waged war against the white settlers or army, their own '#TrailOfTears' brought them to the Flathead Valley to live within the boundaries of the vastly reduced lands they retained in the #HellgateTreatyOf1855.

    "Although the #HellgateTreaty is widely regarded as one of the best treaties signed by any of the nation’s #IndigenousPeople, even land supposedly reserved for the exclusive habitation of the #SalishKootenai was opened to purchase by non-tribal #settlers by the #DawesAct of 1887.

    "The act’s intentions were to allocate reservation lands the tribes already owned to individual families as private property and, as part of the 'civilization' of #NativeAmericans, it required tribal members to register with the federal government to receive their 'allotment.'

    "The entire debacle was part of the #AllotmentAndAssimilationEra from 1887 to 1934. Simply put, the federal government’s plan was to force Native Americans to be 'assimilated' into #EuropeanAmerican culture.

    "Importantly, any reservation lands not allocated to tribal members was deemed
    'surplus' land and opened to purchase by non-tribal settlers. This excursion into #ReservationLands was further exacerbated by the ability of tribal members to sell their allotment parcels to non-tribal members.

    "The fracturing of the Salish-Kootenai’s tribal lands through sales to non-tribal members continues to cause serious problems today, including the long and on-going battle to retain their #water, #hunting and #fishing #TreatyRights.

    "Article III of the Hellgate Treaty could not be more clear regarding the Tribe’s fishing rights: 'The exclusive right of taking fish in all the streams running through or bordering said reservation is further secured to said Indians; as also the right of taking fish at all usual and accustomed places…'

    "Yet, just last month the Confederated Salish-Kootenai Tribal Nation issued a very serious warning to tribal members regarding the fish they have treaty rights to catch because they are poisoned.

    CSKT Fish Consumption Advisory

    "The Confederated Salish and Kootenai Tribes issued a fish consumption advisory on June 24, 2025, warning tribal citizens not to eat fish due to the presence of Polychlorinated biphenyls (#PCBs), #dioxins and #furans at levels deemed unsafe for humans: Source: Confederated Salish and Kootenai Tribes

    "The #FishConsumptionAdvisory urges 'all tribal members to avoid consuming all species and sizes of fish harvested from the lower Clark Fork River from the Bitterroot River near Missoula to the Flathead River near Paradise. Recent testing has confirmed the presence of polychlorinated biphenyls, dioxins and furans in fish at levels that are unsafe for consumption by Tribal peoples. It is also advisable to avoid consuming rainbow trout and northern pike harvested from the Bitterroot River and the upper Clark Fork River above the Bitterroot River to Rock Creek, and, to avoid consuming rainbow trout from the Blackfoot River.

    "As the Advisory explains: 'These contaminants pose a health risk to all fish consumers, and an even greater health risk to the most sensitive members of the Tribal population including women of child bearing age, pregnant nursing women, and young children. These contaminants have been linked to negative health effects in the immune, and nervous systems and may be associated with birth defects…PCBs and dioxins are classified as probable and definite #HumanCarcinogens, respectively.'

    "So what good are treaty fishing rights if you can’t eat the fish because they’re poisoned? Are they really 'rights' — or is this just another in our nation’s long and shameful history of abrogating its treaties with Native Americans?

    "Moreover, #Montana’s poison fish affect us all. Just as our government has failed the Salish-Kootenai, they have likewise failed to uphold our rights to the 'swimmable/fishable waters' guaranteed by the #CleanWaterAct — because no one, tribal or non-tribal, is immune to poisoned fish."

    Source:
    indianz.com/News/2025/07/14/ge

    #WaterIsLife #TribalNations #NativeAmericanNews #WaterPollution #PoisonedFish #StolenLand #LandBack #EPAFail

    #treatyrights #confederatedsalishkootenai #trailoftears #hellgatetreatyof1855 #hellgatetreaty #indigenouspeople
  31. Rommudoh @[email protected] ·

    My #BMS #PCBs arrived from @aislerhq and they look nice. I designed it because I couldn't find 3S BMS for #LiFePO4 cells and didn't like the voltage thresholds of the cheap #LiIon ones.
    It uses the #BQ77915 chip from #TexasInstruments. Size is 63x50mm.
    While fetching all components according to the BOM, I noticed the #diode had the #footprint SOT-323 assigned. I only have SOT-23 ones :blobcatgoogly:
    I'm glad that I can still make it fit, and the third leg isn't used at all (it's a single diode).
    Can't wait to find some time to finish soldering a few and try them out.
    It supports 3S up to 5S, and I added #silkscreen part to mark how it's configured.
    The back has detailed instructions, so I don't forget them.

    #bms #pcbs #lifepo4 #liion #bq77915 #texasinstruments
  32. Rommudoh @[email protected] ·

    My #BMS #PCBs arrived from @aislerhq and they look nice. I designed it because I couldn't find 3S BMS for #LiFePO4 cells and didn't like the voltage thresholds of the cheap #LiIon ones.
    It uses the #BQ77915 chip from #TexasInstruments. Size is 63x50mm.
    While fetching all components according to the BOM, I noticed the #diode had the #footprint SOT-323 assigned. I only have SOT-23 ones :blobcatgoogly:
    I'm glad that I can still make it fit, and the third leg isn't used at all (it's a single diode).
    Can't wait to find some time to finish soldering a few and try them out.
    It supports 3S up to 5S, and I added #silkscreen part to mark how it's configured.
    The back has detailed instructions, so I don't forget them.

    #bms #pcbs #lifepo4 #liion #bq77915 #texasinstruments
  33. rrmutt @[email protected] ·

    My first job out of college was at Teradyne, a company that makes PCB and semiconductor testers. Had a nostalgia jag and looked up pictures of the bonkers PCBs that went into their equipment. (I was writing test automation software: with hindsight I wish I had worked with the HW folks, I would have learned a lot!)
    #pcbs #retrocomputing

    #pcbs #retrocomputing
  34. Fiona Bianchi @[email protected] ·

    Can anyone recommend a UK based PCB manufacturer for simple home/hobby PCBs? Only looking for small run of some test boards #electronics #pcbs

    #electronics #pcbs
  35. Unofficial PetaPixel Bot @[email protected] ·

    Blackmagic Design Was Planning to Open a US Factory But Scrapped it Because of Trump’s Tariffs petapixel.com/2025/04/16/black #blackmagicpyxis12k #blackmagicdesign #semiconductors #trumpstariffs #Industry #imports #tariffs #News #pcbs

    #blackmagicpyxis12k #blackmagicdesign #semiconductors #trumpstariffs #industry #imports
  36. Unofficial PetaPixel Bot @[email protected] ·

    Blackmagic Design Was Planning to Open a US Factory But Scrapped it Because of Trump’s Tariffs petapixel.com/2025/04/16/black #blackmagicpyxis12k #blackmagicdesign #semiconductors #trumpstariffs #Industry #imports #tariffs #News #pcbs

    #blackmagicpyxis12k #blackmagicdesign #semiconductors #trumpstariffs #industry #imports
  37. Unofficial PetaPixel Bot @[email protected] ·

    Blackmagic Design Was Planning to Open a US Factory But Scrapped it Because of Trump’s Tariffs petapixel.com/2025/04/16/black #blackmagicpyxis12k #blackmagicdesign #semiconductors #trumpstariffs #Industry #imports #tariffs #News #pcbs

    #blackmagicpyxis12k #blackmagicdesign #semiconductors #trumpstariffs #industry #imports
  38. Unofficial PetaPixel Bot @[email protected] ·

    Blackmagic Design Was Planning to Open a US Factory But Scrapped it Because of Trump’s Tariffs petapixel.com/2025/04/16/black #blackmagicpyxis12k #blackmagicdesign #semiconductors #trumpstariffs #Industry #imports #tariffs #News #pcbs

    #pcbs #news #tariffs #imports #industry #trumpstariffs
  39. Unofficial PetaPixel Bot @[email protected] ·

    Blackmagic Design Was Planning to Open a US Factory But Scrapped it Because of Trump’s Tariffs petapixel.com/2025/04/16/black #blackmagicpyxis12k #blackmagicdesign #semiconductors #trumpstariffs #Industry #imports #tariffs #News #pcbs

    #blackmagicpyxis12k #blackmagicdesign #semiconductors #trumpstariffs #industry #imports
  40. Rommudoh @[email protected] ·

    Today my new #PCBs arrived. The first is an adaptation of Stefan Wagner's #C64 Power Guard: oshwlab.com/wagiminator/c64-po
    I changed some components to what I had available. Thanks @aislerhq for manufacturing them.
    Only I messed up two small details. The second #comparator is backwards, so the error #LED is practically the same as the power good LED. And I also put in the #MOSFET backwards. I'll try to mount it on its back and rotated tomorrow.
    #PCBfails #deadbug #diyelectronics #electronics #soldering

    #pcbs #c64 #comparator #led #mosfet #pcbfails
  41. Rommudoh @[email protected] ·

    Today my new #PCBs arrived. The first is an adaptation of Stefan Wagner's #C64 Power Guard: oshwlab.com/wagiminator/c64-po
    I changed some components to what I had available. Thanks @aislerhq for manufacturing them.
    Only I messed up two small details. The second #comparator is backwards, so the error #LED is practically the same as the power good LED. And I also put in the #MOSFET backwards. I'll try to mount it on its back and rotated tomorrow.
    #PCBfails #deadbug #diyelectronics #electronics #soldering

    #pcbs #c64 #comparator #led #mosfet #pcbfails
  42. Rommudoh @[email protected] ·

    Today my new #PCBs arrived. The first is an adaptation of Stefan Wagner's #C64 Power Guard: oshwlab.com/wagiminator/c64-po
    I changed some components to what I had available. Thanks @aislerhq for manufacturing them.
    Only I messed up two small details. The second #comparator is backwards, so the error #LED is practically the same as the power good LED. And I also put in the #MOSFET backwards. I'll try to mount it on its back and rotated tomorrow.
    #PCBfails #deadbug #diyelectronics #electronics #soldering

    #pcbs #c64 #comparator #led #mosfet #pcbfails
  43. Rommudoh @[email protected] ·

    Today my new #PCBs arrived. The first is an adaptation of Stefan Wagner's #C64 Power Guard: oshwlab.com/wagiminator/c64-po
    I changed some components to what I had available. Thanks @aislerhq for manufacturing them.
    Only I messed up two small details. The second #comparator is backwards, so the error #LED is practically the same as the power good LED. And I also put in the #MOSFET backwards. I'll try to mount it on its back and rotated tomorrow.
    #PCBfails #deadbug #diyelectronics #electronics #soldering

    #soldering #electronics #diyelectronics #deadbug #pcbfails #mosfet
  44. Rommudoh @[email protected] ·

    Today my new #PCBs arrived. The first is an adaptation of Stefan Wagner's #C64 Power Guard: oshwlab.com/wagiminator/c64-po
    I changed some components to what I had available. Thanks @aislerhq for manufacturing them.
    Only I messed up two small details. The second #comparator is backwards, so the error #LED is practically the same as the power good LED. And I also put in the #MOSFET backwards. I'll try to mount it on its back and rotated tomorrow.
    #PCBfails #deadbug #diyelectronics #electronics #soldering

    #pcbs #c64 #comparator #led #mosfet #pcbfails
  45. concretedog @[email protected] ·

    Been an age since I placed an @oshpark order for #pcbs ... they really do rock in terms of customer service and ffir certain projects they can't be beaten on price. #CreditWhereCreditIsDue

    #pcbs #creditwherecreditisdue
  46. concretedog @[email protected] ·

    Been an age since I placed an @oshpark order for #pcbs ... they really do rock in terms of customer service and ffir certain projects they can't be beaten on price. #CreditWhereCreditIsDue

    #pcbs #creditwherecreditisdue
  47. concretedog @[email protected] ·

    Been an age since I placed an @oshpark order for #pcbs ... they really do rock in terms of customer service and ffir certain projects they can't be beaten on price. #CreditWhereCreditIsDue

    #creditwherecreditisdue #pcbs
  48. concretedog @[email protected] ·

    Been an age since I placed an @oshpark order for #pcbs ... they really do rock in terms of customer service and ffir certain projects they can't be beaten on price. #CreditWhereCreditIsDue

    #pcbs #creditwherecreditisdue
  49. Christian Gudrian @[email protected] ·

    They don’t make #PCBs like they used to.

    #pcb #soldering #pcbrouting

    #pcbs #pcb #soldering #pcbrouting
  50. Gerd_Brodowski @[email protected] ·

    #israel #palestine : #war / #gaza / #civilianwarvictims / #statistics / #pcbs

    „The population of Gaza has fallen 6 per cent since the war with Israel began nearly 15 months ago as about 100,000 Palestinians left the enclave while more than 55,000 are presumed dead, according to the Palestinian Central Bureau of Statistics (PCBS).“

    straitstimes.com/world/middle-

    #israel #palestine #war #gaza #civilianwarvictims #statistics