726

(65 replies, posted in Sinclair)

Good news, with Tufty's help I've finally sorted out my converter's issues with XMs created with OpenMPT. It should even work with OpenMPT's non-standard format hacks (no compatibility export required).

All converters at https://github.com/utz82/ZX-Spectrum-1-Bit-Routines have been updated. Just grab the master.zip if you want to update your local engine collection in one go. You'll get some extra crap you probably don't need, but deleting those still beats downloading all the packages seperately, I think.

727

(65 replies, posted in Sinclair)

Hmm, seems the bugs in the quattropic converter have finally vanished.

In the meantime, I've updated the nanobeep engine. The player has now been reduced to 77 bytes, and "light" (73B) and "ultra" (56B) versions have been added. "Light" has somewhat reduced sound quality, but otherwise still the full feature set. "Ultra", on the other hand, is cutting some corners, ie. no border masking, no click drum, and no looping. Also, there was a bug in the converter which has been fixed.

Uh, well, yeah, I think I promised to do a HT2 compilation for the HT2.10 release already yikes I'll put this on the to-do list for HT2.20, which I hope to be releasing some time this fall.

Regarding the bug, I faintly remember something about this. Think I may have fixed the issue in the latest beta builds, so grab that from github to be sure.

@Shiru: Well, Follin's engine is virtually unusable, and I've used ZX-10 excessively (and everybody else hates it). But, I see your point and agree. tBeepr and Beep Tracker would also fall under the "age limit", so yep, best use an "excluding" list.

@Tufty: Hehe, that'd be a pretty damn long list by now wink Think it's indeed best to do a list with disallowed engines, and for the rest direct users to http://randomflux.info/1bit/viewtopic.php?id=25. (I have to check if that one's actually up to date though).

@garvalf: There once was a -rather successful- Beeper BotB battle. But it was a one-time thing, quite sure I'd have a hard time convincing puke7 to host another one any time soon considering how packed the battle schedule is nowadays. Anyway BotB does a good job of drawing attention to 1-bit music either way, seeing how zxbeep is now one of the most popular formats on there aside from the "big ones" (nsf*, s3xmodit, wild).

Ok, I'll try to make a start on "the" list then.
The following engines would be disallowed:

- FuzzClick (Special FX/Orfeus)
- Huby
- Music Studio
- Octode (should that include the XL, 2k15 and PWM variants?)
- Qchan
- Phaser1
- ROMbeep
- Savage (should include newcore imo)
- Tritone
- Wham! The Music Box

Any others I forgot? What about ZX-7, -10, and -16? ZX-7 has been used quite a bit in the old days. For the rest we had the Tribute compilation, so those engines have had their spotlight already. I think we might also want to give a "recommended" list, which should include Phaser 2/3, fluidcore, and perhaps quattropic.

Edit: Squeeker and BT'man need more love, too, imo.

730

(2 replies, posted in Sinclair)

Yay, garvalf music topic ftw! Nice cover, mate wink

That's a very reasonable idea. However, for the time being my motivation to organize another compo is near 0. Perhaps we could collaborate with the Spanish folks from Culturachip, though. Like, handle the submissions through them, but use our more transparent approach to voting. I mean the main idea of the last forum compo was to attract more people to the forum, and it clearly flopped (not just) in that respect. And I don't think that would change with a different ruleset.

Regarding allowed engines, I think the easiest would be to draw the line at Phaser2, eg. all engines released prior to that would be prohibited. The only drawback would be that this would exclude Stocker. (I've got a -somewhat conceptual- Stocker project in the works, though wink) What do you think?

So the honour of submitting the first HT2 track to BotB goes to garvalf! *applause*
A very nice tune, congrats! And thanks for promoting wink

Seems I won't be submitting to Decadent Decade after all. I wanted to do a bunch of Channel F covers, but I just can't find the time to do them.

733

(135 replies, posted in Sinclair)

Cheers wink Hehe, maybe not to my creativity, but unfortunately there are quite some limits to my maths skills, which is providing some major stumbling blocks lately. Trying to read some stuff on DSP at the moment, mostly not understanding the slightest bit about the mathematical theory of it. Wish I could just go into recluse and just study that stuff for a few years.

734

(135 replies, posted in Sinclair)

Thanks mate!

Seems I omitted part of the formula for the low-pass. It should be

y[i] = y[i-1] + a(x[i] - y[i-1])

In any case it's a lovely algorithm, because with the multi-core digi synthesis I'm using lately it can be implemented without using any extra registers.

735

(135 replies, posted in Sinclair)

Cheers guys! Yes, I'm pretty sure there's more that can be done with the beeper. I'm just kind of running out of (feasible) ideas again.

Right now I'm doing some tests with dynamic duty cycles, but that seems to be surprisingly unuseful. I mean you can do some nice chords with it (Earth Shaker style), but other than that implementing an extra counter for the duty cycle seems to have little advantage over just incrementing the duty setting once per sound loop, like I do in Houstontracker. The extra registers needed for full duty cycle control can be put to better use elsewhere imo.

One thing I'm still pondering about is the Jan Deak's buffer based method. I mean it's blazingly fast, but what uses could it have besides generating a truckload of pin pulse channels?

Also, Shiru, did you get any further with your Fuzz Click/Music Box hybrid?

736

(7 replies, posted in Other Platforms)

Ah, didn't know April Fools revolves around fishes in France. Where does that tradition come from?

737

(135 replies, posted in Sinclair)

A new breakthrough! Just implemented a low-pass filter. Check out the attached .tap - first pattern is without the filter, second with low-pass enabled.

The low-pass is implemented with this simple algo:

y[i] = a(x[i] - y[i-1])

where y is the actual output volume level, x is the unfiltered output, and a is a (time-related) constant, in this case 0.25. Using a = 0.125 gives better results, but I'd need to implement more volume levels to use it.

I tried implementing a high-pass, too, but so far no luck on that, because the algo for that can produce negative values (unlike the low-pass one where the result will always be >=0). The high-pass algo I have is

y[i] = a(y[i-1] + x[i] - x[i-1]) 

Any idea how to modify it so it'll always produce positive results? I could probably invert the output but that'd be too slow I think.

EDIT: Nevermind, got it. The current implementation is ugly as hell, but hey, it works wink

Hellyeah, I'd love to be in a Metal band big_smile Maybe one day I'll drop by for a feature or something.

TI-89s are usually a bit easier to come by, though at this point I can't guarantee that qed68 will actually work on the 89. Also, I'm afraid the package isn't the most user-friendly, since it relies on GCC4TI/TIGCC, which is rather tricky to set up.

Last year a kind soul donated his TI-92 Plus to me. A nice machine, with a 68k CPU running at 12 MHz, and of course a classic analogue IO port. Needless to say, something needed to be done, no matter how useless it would be considering hardly anybody owns this monster of a calc.

So lo and behold: QED68, a 4 channel PCM WAV module player running at around 24 KHz, with a total of 24 volume levels + overdrive. (And also my first forray into 68k territory).

demo tune
download (XM converter included)
source

The demo tune doesn't show off the sound quality that well, as I crunched the samples more than necessary (they're nominally at ~2750 Hz or so). The player will most likely also run on TI-89 and V200, but I can't verify this since I don't own these calcs.

740

(1 replies, posted in Calculators & Pocket Computers)

Uff... never tried this particular setup, so I don't really have a clue.
Perhaps you need a specific USB2Serial driver? People are using this one to drive their GrayLinks: http://www.prolific.com.tw/US/ShowProdu … mp;pcid=41

In any case  I've sent the TiLP developer a mail, maybe he has a solution.

UPDATE:

Lionel Debroux wrote:

The general rule is that such a setup cannot be made to work for the purposes of communicating with a TI calculator through the legacy I/O port, because AFAWCT, most USB / RS232 DB9 adapters don't provide the direct wire access that TI's custom half-duplex protocol needs.

At some point, someone mentioned that his PL2303-based adapter could do it, so I requested more information about it, and bought that particular
model. However, I never actually tested a known working BlackLink / $4 cable against it, so I can't point anyone to a precise model of an USB / RS232 DB9 adapter which I know works with them.

Nowadays, libticables provides a way to define the device corresponding to a cable handle, so that e.g. /dev/ttyUSB0 can be used instead of
/dev/ttyS0 on Linux. TILP doesn't provide an UI for the user to enter an alternate device, though, so users still have to resort to symlinks on Linux.

So, this doesn't sound very promising, unfortunately. You could still try the driver I linked above though, provided your adapter is PL2303 based.

UPDATE 2: Disregard my last statement.

Lionel Debroux wrote:

The GrayLink is a different matter. Unlike the BlackLink / $4 cable, it speaks a standard RS232 protocol, and performs two-way adaptation with TI's half-duplex protocol on the calculator side, without the computer being aware of TI's protocol.

741

(7 replies, posted in Other Platforms)

Ok, so most of you have probably all seen this elsewhere already:

https://www.youtube.com/watch?v=FVGYi-46G2s
http://irrlichtproject.de/downloads/dmg5th.gb

Good old pulse interleaving on the 2nd DMG channel while resuming normal operation on the other channels. Been meaning to do this for a long time, and it was also clear early on that this would have to be some sort of an April Fool's prank - so thanks for inspiring me, garvalf big_smile

So, lessons learned? Well, 1-bit sound is possible on the Gameboy. But, as Shiru mentioned, the Gameboy CPU is... eh... not exactly great to work with if you want to do something out of the ordinary. Not only does it miss more than half the Z80 registers, but also a lot of useful opcodes aren't implemented, and the ones that are there are almost always slower than on a regular Z80. HRAM is a nice feature but doesn't make up for the drawbacks. So the possibilities for 1-bit  on Gameboy are very limited. One could probably pull off a third 1-bit channel with a lot of fiddeling and loop unrolling, but overall I have to conclude that this platform really isn't worth it as far as 1-bit music is concerned.

@garvalf Apple II version is in TOSEC.

@matalog uhh... in this case it'll be difficult to find. There were quite a few monophonic pc speaker music "demos" back in the day, and this stuff isn't exactly well preserved online either. Really sorry man, I'll keep an eye out for this but I'm afraid I can't help you further at the moment.

Hi mate,
Sorry, I don't know this particular program. Was it monophonic, or did it do multi-channel music?
In any case, there is some old PC Speaker stuff here: http://cd.textfiles.com/psl/pslmonthly2 … /mus_spkr/
Also, Will Harvey's Music Construction Set had the Entertainer as a demo tune, you can probably find that on some abandonware site.

744

(16 replies, posted in Atari)

Hmm, perhaps you'd be interested in putting together a Huby-PF music disk release? I've got a few Huby tunes laying around in any case. What format do you need, z80 .asm or raw binary maybe?

Also I was wondering... how does the sound work on PF? Can you use timers, like on PC?

Agreed, for some engines the IO contention adds some very pleasant overtones/harmonics to the sound.

746

(10 replies, posted in Sinclair)

garvalf wrote:

There is indeed an RGB / VGA output (the white thing close to the ear output), but I don't know how to connect it to a vga screen.

That'd be a Molex connector, the kind of plug used to connect power to drives in PCs. Damn, they are really cutting some corners there.

I do understand the reasoning behind using a jack for audio now, though. As it's stereo, I assume they're actually emulating stereo AY output. And considering how packed the board is, they probably couldn't have fitted two RCA sockets.

747

(10 replies, posted in Sinclair)

Yeah, composite only is a downer, but I can kind of understand why. HDMI is not feasible for this kind of projects, because of the insane licensing fees (5000 USD per year + 1 USD per unit). VGA on the other hand is pretty much as outdated as composite, so they were probably thinking "why add another legacy port". But I agree, would have been nice-to-have.

Not using RCA for audio on the other hand is indeed a bad choice, didn't realize they use jack.

Sounds good to my ears wink Yeah, it's normal that it'll play a bit faster/cleaner on +2A, because that machine doesn't have that I/O contention issue.
Btw you probably know this already, but just in case - in Beepola, you can enable IO contention emulation in the options, then the sound will be closer to 48K/128K.

749

(10 replies, posted in Sinclair)

Whoops, that sold out quickly! Well, good for them. I think it's an excellent project at a very fair price, made by some very experienced people.

750

(16 replies, posted in Atari)

Wow, it sounds excellent! Well done, mate.
Can't help with porting Portfolio Manager, unfortunately - my PC programming skills are extremely limited.