The Sinclair QL Forum

popopo wrote:The Attiny takes more than 10 seconds (with my board Digispark or direct powered) to start the sound, not usable at all, in 10 seconds the microdrives has finished the reading, so led activity.

The Digisparks board has a bootloader built in. When programming it---using the Arduino IDE and a USB socket, which the little board plugs into---the bootloader waits to deter,mine if a new program is coming soon. If not, it starts running the code already programmed, and if it detects a new upload, it loads that over the USB connection.

For best results, use a plain old ATtiny85 and program it using an ICSP device and not any bootloaders. Even the full sized Arduino boards like the Uno R3, with bootloaders running in the ATmega328P chips, check at startup for incoming code and if not detected, run the current code in Flash RAM.

I suspect that your Digispark is being powered up when the microdrive is accessed, leading to a "wait for incoming code" every time.

HTH

Cheers,
Norm.

NormanDunbar wrote: Mon Jun 02, 2025 5:11 pm The Digisparks board has a bootloader built in. When programming it---using the Arduino IDE and a USB socket, which the little board plugs into---the bootloader waits to deter,mine if a new program is coming soon. If not, it starts running the code already programmed, and if it detects a new upload, it loads that over the USB connection.

For best results, use a plain old ATtiny85 and program it using an ICSP device and not any bootloaders. Even the full sized Arduino boards like the Uno R3, with bootloaders running in the ATmega328P chips, check at startup for incoming code and if not detected, run the current code in Flash RAM.

I suspect that your Digispark is being powered up when the microdrive is accessed, leading to a "wait for incoming code" every time.

Hi Norman,
very interesting,
I have done some tests programming it with different codes in order to check out if it were programming properly.

I am going to remove the Attiny from the Digispark board to do the same tests from outside.
You told me to use ICSP instead direct programming with ie. avrdude, right? What advantages has it?

About why the delay is produced, gotch it!, it makes a lot of sense.
I have not more Attiny85 but this SMD version into Digispark board, so after extract it from it and place it on a SMD-THT adapter, I'm going to perform same tests and registering them with the osc.

Could be very useful to have a screenshot of the signal when it is how expected to be to reproduce the sound (with and without speaker) between pb1 & pb2 (in order to get the whole signal).

I will share my results here ASAP.

Thanks

Popopo wrote: Mon Jun 02, 2025 5:40 pm You told me to use ICSP instead direct programming with ie. avrdude, right? What advantages has it?

If you program any Arduino or AVR (as was) microcontroller with an ICSP, the bootloader section of Flash RAM is overwritten by a chip erase. This means that there's no bootloader to delay startup, the device goes straight into the code for the application and not into a bootloader to check if there's data coming throiugh before running the current code in Flash.

Basically, you get "instant" startup, as opposed to a 10 second delay before startup.


HTH

Cheers,
Norm.

Hi,

l will get some PCBs made for Stephen's sound board and get one fitted to my vDrive.

Just out of interest, there was going to be an official vDrive sound addon called vSFX, but Charlie must of not got arou d to making it a product.

NormanDunbar wrote: Mon Jun 02, 2025 5:11 pm The Digisparks board has a bootloader built in. When programming it---using the Arduino IDE and a USB socket, which the little board plugs into---the bootloader waits to deter,mine if a new program is coming soon. If not, it starts running the code already programmed, and if it detects a new upload, it loads that over the USB connection.

Can the Digispark run the same code as the DIP Atmel ATTiny85? i.e. can I load Stephen's version which seems to have better sound? Also, can you grab the code that's on the Digispark, before overwriting it, and is it in a "compiled" state?

It would be nice to see if I could get better sound out of it.

NormanDunbar wrote: Mon Jun 02, 2025 5:11 pm I suspect that your Digispark is being powered up when the microdrive is accessed, leading to a "wait for incoming code" every time.

Yup, it gets its power from vDrive. I think the 10 second delay doesn't kick in since it stays powered the whole time so when you boot your QL it takes most of that 10 seconds away so the little device behaves instantly when you access a microdrive.

[Edit: one thing to improve on it is to disconnect the little speaker on the vDrive board since that beep doesn't go well with a proper whirring sound (if you watch my video you can see what I mean).]

You can disable the beep in software.

As for "powered continuously", on my board it's not. The ATTiny85 is powered on by the transistor which is controlled by the access LED voltage. The code would need to be highly modified to look at a pin on the ATTiny85 and then run the sound file, but probably check the status of the pin after every loop through the sound data.

Derek_Stewart wrote: Mon Jun 02, 2025 7:03 pm Hi,

l will get some PCBs made for Stephen's sound board and get one fitted to my vDrive.

Just out of interest, there was going to be an official vDrive sound addon called vSFX, but Charlie must of not got arou d to making it a product.

The last time I ordered 5 from PCBWay they sent 10 for the same price as they're such small boards.

bwinkel67 wrote: Mon Jun 02, 2025 8:26 pm Yup, it gets its power from vDrive. I think the 10 second delay doesn't kick in since it stays powered the whole time so when you boot your QL it takes most of that 10 seconds away so the little device behaves instantly when you access a microdrive.

[Edit: one thing to improve on it is to disconnect the little speaker on the vDrive board since that beep doesn't go well with a proper whirring sound (if you watch my video you can see what I mean).]

Hi!
It is not very helpful (for my idea of saving power), I mean, the code is design in order to be triggered by the transistor once the LED is activate. That way it always will reproduce the sound when needs.
In other words, you cannot let it powered all the time cause it will be playing all the time too.

But It is not the whole truth (what I have told). You may need one of the free GPIO pins free to detect when it is acceded, then play the sound.
In other words, your idea is not bad at all (very good idea) but you need to keep powered all the time the Attiny (be aware with the extra power that it needs) and the transistor will trigger the dedicated GPIO pin free (ie PB2) to detect when to start to play (in high) and stop (in low), and the base of that transistor this time connected to the LED signal.

For my project (I want to add this to the MicroDrivePico) is not a way, but your idea for vDrive seems really nice if you don't want to change fuses (bootleader).

Does it make sense?

Popopo wrote: Mon Jun 02, 2025 10:10 pm Hi!
It is not very helpful (for my idea of saving power), I mean, the code is design in order to be triggered by the transistor once the LED is activate. That way it always will reproduce the sound when needs.
In other words, you cannot let it powered all the time cause it will be playing all the time too.

I'm just assuming it is being continuously powered because it plays the sound immediately. Perhaps it doesn't have the 10 second delay that Norman was talking about...dunno.

You should go on the Sinclair QL For Everyone facebook page and ask Johan directly how it works.

bwinkel67 wrote: Mon Jun 02, 2025 8:26 pm Can the Digispark run the same code as the DIP Atmel ATTiny85? i.e. can I load Stephen's version which seems to have better sound? Also, can you grab the code that's on the Digispark, before overwriting it, and is it in a "compiled" state?

Yes. The Digispark board is just a pcb with an ATtiny85. The problem is that it has a bootloader resident on the chip to make it easy to program over USB from the Arduino IDE.

You can get the code off the chip fairly easily using AVRDude. Unless of course, the lock bits are configured, in which case no. The code that comes off will be a binary version of the C or C++ code that the source was written in, plus it will have been optimised for size by the compiler.

Somewhere on these forums is a post from me ages ago, discussing this noise generator and a version I wrote in assembly. Somewhere! I remember thinking that the speaker needed a resistor to limit current and blowing the chip.

HTH

Cheers,
Norm.