3 ms·

> 4-level grayscale sprite editor (which worked by flickering the pixels of the 1-bit display which had a slow enough response time to create a static gray colo

by sampo 12y ago

> 4-level grayscale sprite editor (which worked by flickering the pixels of the 1-bit display which had a slow enough response time to create a static gray color if alternated quickly enough) I have heard of games (like Doom) on the TI calculators, that also had sound effects. The program was sending pulses to the linkport, and the user needed a 3.5 mm to 2.5 mm adapter to connect a headphone plug into it, but then you got sound.

vidarh 12y ago
Reminds me of sound-sampling on the C64 via the tape port: The C64 tape port is connected to the GPIO pins on the 6510 CPU. You get 1 bit amplitude data, at roughly whatever spedd you manage to sample the register. The problem there of course is that you're dealing with a 1MHz CPU, and 64K memory, and for real-time sampling you need to make tradeoffs between sacrificing sample rate for cycles to somewhat compress the data vs. running out of RAM in seconds. For playback, it's equally primitive: With some settings, flipping the volume to max and down creates a sufficient click that doing that for 1, and keeping it off for 0 gives you recognisable sampled music output. It's really quite amazing how low bitrate you can get to and still have recognisable music. If you do pre-processing you can get quite tolerable, substantially longer samples (if you do lots of pre-processing you can end up with this: https://www.youtube.com/watch?v=D6MSbdUMFZ4 https://www.youtube.com/watch?v=D6MSbdUMFZ4 )
adrusi 12y ago
Yeah you can do that. I've messed around with emitting square waves but not much else. There's also a problem with that where plugging something into the link port triggered an interrupt that diverted control back to the kernel which would then try to initiate communication with another calculator over the link. Not the desired behavior. In the best case this would cause serious lag. In the worst case, a crash and hard ram reset. You had to patch the kernel in order to output sound. Fun stuff.

by sampo 12y ago

vidarh 12y ago

Reminds me of sound-sampling on the C64 via the tape port: The C64 tape port is connected to the GPIO pins on the 6510 CPU. You get 1 bit amplitude data, at roughly whatever spedd you manage to sample the register. The problem there of course is that you're dealing with a 1MHz CPU, and 64K memory, and for real-time sampling you need to make tradeoffs between sacrificing sample rate for cycles to somewhat compress the data vs. running out of RAM in seconds. For playback, it's equally primitive: With some settings, flipping the volume to max and down creates a sufficient click that doing that for 1, and keeping it off for 0 gives you recognisable sampled music output. It's really quite amazing how low bitrate you can get to and still have recognisable music. If you do pre-processing you can get quite tolerable, substantially longer samples (if you do lots of pre-processing you can end up with this: https://www.youtube.com/watch?v=D6MSbdUMFZ4 https://www.youtube.com/watch?v=D6MSbdUMFZ4 )

adrusi 12y ago

Yeah you can do that. I've messed around with emitting square waves but not much else. There's also a problem with that where plugging something into the link port triggered an interrupt that diverted control back to the kernel which would then try to initiate communication with another calculator over the link. Not the desired behavior. In the best case this would cause serious lag. In the worst case, a crash and hard ram reset. You had to patch the kernel in order to output sound. Fun stuff.