Reply 220 of 567, by LABS
- Rank
- Member
H1 header with GND and PB1 pins is made for debugging. The ATmega outputs all incoming/outgoing commands and parameters via this header in UART format with 1MHz baud rate. It is TX-only. I used FT232RL-based UART-to-USB adapter and RealTerm to read that data. It can be used to watch the communication between the software and the card. However the included firmware is UART-disabled. If anyone needs an UART-enabled firmware - just drop me a message.
I'm also working on a test-bb.exe diagnostic utility for the BlasterBoard right now, and it has software switching of UART mode without the need to reflash the MCU. But the utility is not ready yet.
One known issue is that the BlasterBoard do not pass the test-sbc.exe sample playback stage. This bothered me since the very beginning of development. Using UART mode I found out that it sends weird and undocumented 0xE2 command just before staring the playback. The problem is that this command should send its response back to the host in a DMA buffer(!). BlasterBoard's architecture does not support sample recording, so DMA transfer from the card to the host is not implemented in hardware and this single command cannot be done correctly. This command is so undocumented, that looks like test-sbc.exe is the only one using it, as all games and soft I tried work fine.
As there are lots of free cycles available in ATmega during PCM playback, some kind of upsampling algorithm could be implemented in firmware to increase 8-bit sample resolution and decrease quantization noise. The kit includes an 8-pin DIP socket for the DAC, so it could be changed to a better one (say 12-bit) if it is ever going to happen in future.