The Sinclair QL Forum

New topic

Can we do fancy music and sound? Is it possible to somehow define the sprites and backgrounds into a standard? That way some people who are rubbishing at coding (like me) can do some artwork or sound effects?

Thanks for moving the thread!

vanpeebles wrote:Can we do fancy music and sound? Is it possible to somehow define the sprites and backgrounds into a standard? That way some people who are rubbishing at coding (like me) can do some artwork or sound effects?

Sound effects are simple on Q68. Just two unsigned byte samples for left and right (joined into a 16-bit word) at 20 kHz rate. The Q68 has a large hardware buffer, so all one needs to to do is check for full buffer, and if not, feed in samples. It can also be done via SMSQ/E, a little more overhead, but makes it compatible to more platforms.

For me, the most simple way of conversion is using the Audacity effect "Change Tempo and Pitch" with the right factor and then save in "unsigned byte" format. (It also makes sense to use the "normalization" filter.) Q68 SMSQ/E has BASIC commands to play such files directly, also there is a "sound device" extension, where you can just COPY soundfile, SOUND2.

Zarchos wrote:Please start a new thread, as yes I am interested, in particular if it is a community project.

Only in contributing optimized graphics routines, or an arcade game itself?

Zarchos wrote:To me, incentive is the key to dev on retro systems.

But what kind of incentive, can a little money still motivate?

Zarchos wrote:I hope what I did is doable for a 68000 based system, but I believe so. I believe in 2 byte per pixel 'low res' screen mode, the QL68 should be faster than a 12 Mhz Archie in 1 byte per pixel 320 x 256 (just a belief as I haven't really checked the timings, I was just working with timings of a 68000 at 40 Mhz, here we have something different. I'll edit this post later).

In any case, the Q68 should never be slower than a 68000 at 40 MHz. If you plan for 68000, you should be on the save side. (Not even using the small "Fast RAM".)

Peter

Yes Peter, it is why I am very excited by your system, with its area of very fast RAM.

For the incentive, to me, it will not be money because of the small users base, but most certainly contributions (coding, or 'simply' optimising some source code, graphics, original tunes and so on).
Of course if some nice and willing people want to fund development, it will for sure help.
I believe in 'good will' in a friendly community.
For retro collectors, a final product could be edited, in a finite number (ex : 200 copies) at a relatively high price, with artworks etc ...
See what neo geo dev people do : it is very smart.

Again, I believe there is a lot possible.
If the spirit stays friendly, and people in the community do even small things, it can be good fun, and tools and routines can be made open source and serve as teaching to people who are interested by developping.
I very much believe in shared knowledge to keep retro dev alive.

See TerribleFire on YT or eab for example, with his accelerator boards, and free VHDL source, I mean, this is just beautiful and awesome.

[quote="Peter]It's a matter of speed! The Q68 has hardware SLUG [/quote]

I wrote SlowGold for my Gold Card to do a similar thing!

Cheers,
Norm.

Hehe... in how far was that better than the GoldCard SLUG?

How much better? I have no idea. As far as I remember, there was no SLUG command available which is why I ended up writing it. Dilwyn might have suggested it - but I can't remember. He certainly sold it through DJC though.

Cheers,
Norm.

Can you please explain what you are talking about ?
I am lost.

NormanDunbar wrote:How much better? I have no idea. As far as I remember, there was no SLUG command available which is why I ended up writing it. Dilwyn might have suggested it - but I can't remember. He certainly sold it through DJC though.

The GoldCard had a builtin SLUG command, that's why wondered.
Slowing down by software had some issues, so I added a hardware solution. Even that requires individual finetuning if the speed of the original game shall be met exactly.

Zarchos wrote:Can you please explain what you are talking about ?

It's about slowing down faster machines for old games.

NormanDunbar wrote:How much better? I have no idea. As far as I remember, there was no SLUG command available which is why I ended up writing it. Dilwyn might have suggested it - but I can't remember. He certainly sold it through DJC though.
Cheers,
Norm.

(not sure if this will make it due to intermittent and very slow broadband presumably due to local flooding)
Slowgold was written by Norman at my suggestion before the SLUG command was added to fast systems such as Gold Card. Both work in a different way and you tend to find one might work in situations where the other doesn't to slow down fast older games.

I think SLUG works by putting delays in keyboard read systems IIRC, whereas Slowgold is written to use interrupts or scheduler lists IIRC (haven't got the sources to hand to check), so it's quite possible that both might be of use in situations where some software needs to be slowed down.

dilwyn wrote:

NormanDunbar wrote:How much better? I have no idea. As far as I remember, there was no SLUG command available which is why I ended up writing it. Dilwyn might have suggested it - but I can't remember. He certainly sold it through DJC though.
Cheers,
Norm.

(not sure if this will make it due to intermittent and very slow broadband presumably due to local flooding)
Slowgold was written by Norman at my suggestion before the SLUG command was added to fast systems such as Gold Card. Both work in a different way and you tend to find one might work in situations where the other doesn't to slow down fast older games.

I think SLUG works by putting delays in keyboard read systems IIRC, whereas Slowgold is written to use interrupts or scheduler lists IIRC (haven't got the sources to hand to check), so it's quite possible that both might be of use in situations where some software needs to be slowed down.

No way on the QL to do some consuming time CPU operations, triggered by a timer interrupt, synced to whatever the screen mode sync is ?