RMT during SIO?

[ilmenit]

Hi,

 

There was an old topic about playing music during SIO

but proposed solution required custom SIO routine. Do you think it could be done just with changing the RMT player? If yes, has anyone did it?

As I'm aiming with the current project for wide range of users ideally, if this could work with standard OS calls, without custom SIO procedure.

Edited February 19, 2020 by ilmenit

[Rybags]

I think yes.  RMT lets you choose what voices are in use and in what mode.

You'd probably want to modify the source code it can produce, to use shadow registers instead of storing to the AUDxx registers.

 

Regardless of music or fx generation technique, you need a custom SIO routine to allow that so that it doesn't mess with the voices you're using.

Then just compose your tune to either only use the non SIO voices or to use them for the main melody and still sound OK when the SIO used voices are cut out.

 

Reason you need custom SIO - the OS routines zero out all the AUDF/C and AUDCTL at regular intervals.  Possibly you might get away with leaving the stock SIO in place and do your shadow store in immediate VBlank but you'd get unwanted clicking where your notes are cut off and reinstated.

[emkay]

Interesting that such a thread has to be re opened on and on.

There are many custom loaders available. The question is, why no one already cared of joining the depending routines?

The RMT runtime is defined clearly, stripping the loader from the HARD demos has also been done.

And then there is the question , who will make the tunes that really fit to such a loader.

There is a possible max time for loading, if a 1050 is used. Loading via an SIO -USB will be faster.

So tunes should be created to have a max. of 2 voices while loading, and mixed into 4 channel tunes while unpacking the data from a very high compression rate.

Well, I always have some example

 

28 Seconds for loading, 80 seconds for unpacking.

 

 

 

https://www.youtube.com/watch?v=uMjEJ2ZwQLc

 

 

 

[emkay]

Interesting that such a thread has to be re opened on and on.

There are many custom loaders available. The question is, why no one already cared of joining the depending routines?

The RMT runtime is defined clearly, stripping the loader from the HARD demos has also been done.

And then there is the question , who will make the tunes that really fit to such a loader.

There is a possible max time for loading, if a 1050 is used. Loading via an SIO -USB will be faster.

So tunes should be created to have a max. of 2 voices while loading, and mixed into 4 channel tunes while unpacking the data from a very high compression rate.

Well, I always have some example

 

28 Seconds for loading, 80 seconds for unpacking.

 

 

 

 

 

 

Not to forget that digitizing is possible during SIO ....

 

 

 

[Rybags]

Game/level loads are just a couple of things.

A game with constant disk access like 7 Cities of Gold becomes feasible if there's published info and code for it.

[ilmenit]

14 minutes ago, Rybags said:

Game/level loads are just a couple of things.

A game with constant disk access like 7 Cities of Gold becomes feasible if there's published info and code for it.

My case is exactly related to cover loading game levels. Other option would be to use extended memory end preload everything there, but I'm also aiming for the best user experience for users of non-extended memory.

 

Reseting AUDF/C and AUDCTL indeed seems to be a problem ? Considering custom SIO - is there any open source one? I don't want to use xBios for multiple reasons.

[Rybags]

I've seen bits of source around but can't specifically remember where.

For stock SIO speeds it'd not be too hard to implement.  You could just copy the OS one, though the routines and IRQs are spread around a bit.  Then about all you need to do is stop it clearing all the registers you want to use.

Unsure if you could just stick to using the standard IRQ routines to save space.  I think some of the flags and workspace might be different depending on OS version.

[Rybags]

I think Heaven might have done some stuff - possibly a demo with digital sounds and SIO?  And I think the source was made available, this is going back probably over 6 years ago.

 

[Heaven/TQA]

Sorry.... me in Nintendo land since 9 months... 

 

well... My experience in custom loaders....

 

RMT is too heavy on CPU load i have to admit and you need to alter the layer code not to touch the sound channels... maybe the simple player... we tried it in Arsantica 3 but failed...

 

so Miker used the MPT player or CMC if my memories are tight as in energy zine #1 there was an explanation of the used player with Digi...

 

Tamas of hard basicly rebuild the the SIO protocol with a CPU loop so your effect must run in VBL... I used his custom loader in Arsantica 3.

 

i was aware of that it will fail with non 1050 disk solutions but well it was intended.

 

XBIOS has the feature of loading music but you need here as well a custom music tracker. But XXL can tell more about it.

 

on Gnork my VIC20 demo i used a standard irq fast loader which basicly uploads faster coder to the 1541 disk drive but that’s not an option here...

 

i always tell the C64 guys why Atari lacks in such possibilities and that’s most reason why demos use extended memory basicly for memory cache loading system and not for the need of memory for the effects.

 

Eidolon, rescue on Fractalus and 7 cities use custom loaders... 7 cities and Eidolon must be interesting to look into as they are running on a 800 so you can not patch the OS routines...

[+Stephen]

Phantasie 2 also played music while loading.  I remember when I installed a US Doubler in my 1050, I converted it from 4 disks to 2 double density ones and it still played the music.

[emkay]

The RMT runtime can be set to use music FX or not. It is nonsense to tell that the RMT Runtime is too heavy on  CPU load.

Have a slight look at Atari Blast, that is doing about 10 times more than any other comparable game. But it can run even STEREO using the RMT runtime.

We had the decision to use base features of the replay, or to use the automated frequency slide. 

It would have been more problematic to set all instruments to more RAM usage, instead of using less RAM with more CPU usage.

If particular this missing development for the Atari was more advanced (if it even was developed) , the music, the enabled features of the RMT runtime could be loaded and adjusted on the fly.

 

[Heaven/TQA]

23 minutes ago, Stephen said:

Phantasie 2 also played music while loading.  I remember when I installed a US Doubler in my 1050, I converted it from 4 disks to 2 double density ones and it still played the music.

Ah ok... wasn’t aware... thx

[Heaven/TQA]

25 minutes ago, emkay said:

The RMT runtime can be set to use music FX or not. It is nonsense to tell that the RMT Runtime is too heavy on  CPU load.

Have a slight look at Atari Blast, that is doing about 10 times more than any other comparable game. But it can run even STEREO using the RMT runtime.

We had the decision to use base features of the replay, or to use the automated frequency slide. 

It would have been more problematic to set all instruments to more RAM usage, instead of using less RAM with more CPU usage.

If particular this missing development for the Atari was more advanced (if it even was developed) , the music, the enabled features of the RMT runtime could be loaded and adjusted on the fly.

 

Why nonsense? That’s what I have experienced while tinkering with Arsantica 3 hard loader plus RMT... 

 

never checked Atari Blast... does it load and play music from 5,25 disk? 
 

Ps. Be careful with the word nonsense... I told RMT runtime cpu load was too heavy in combination with the tight SIO timing master Jedi.

Edited February 19, 2020 by Heaven/TQA

[emkay]

8 minutes ago, Heaven/TQA said:

Why nonsense? That’s what I have experienced while tinkering with Arsantica 3 hard loader plus RMT... 

 

never checked Atari Blast... does it load and play music from 5,25 disk? 
 

Ps. Be careful with the word nonsense... I told RMT runtime cpu load was too heavy in combination with the tight SIO timing master Jedi.

 

Funny.

 

You could set the RMT Runtime to drop progress, if things were too CPU consuming. The priority has to be set to the SIO and then to change the needed registers for music playback.  So how can a runtime be too CPU consuming, if you can handle the resources at all?

 

 

 

 

[Heaven/TQA]

5 minutes ago, emkay said:

 

Funny.

 

You could set the RMT Runtime to drop progress, if things were too CPU consuming. The priority has to be set to the SIO and then to change the needed registers for music playback.  So how can a runtime be too CPU consuming, if you can handle the resources at all?

 

 

 

 

Then show me a working example of a SIO based disk loader with RMT music and I am happy.

[ilmenit]

3 minutes ago, Heaven/TQA said:

Then show me a working example of a SIO based disk loader with RMT music and I am happy.

Yes, please.

[Rybags]

The problem you'd have regardless of tracker - you can't run during stage 2 VBlank since it'll be disabled a good deal of the time during SIO.

With immediate VBlank you can run it but it'll cause input overrun since it goes for too long.

With stock SIO you can't run it in mainline code as the SIO routine sits in a wait loop.

 

The solution - with custom SIO you can return to your mainline code.  Then all you need to do is once in a while check if the operation has completed.

Calling RMT in mainline - you just keep an eye on low byte of RTCLOCK, when it changes do the RMT play call.

[Heaven/TQA]

7 hours ago, Rybags said:

The problem you'd have regardless of tracker - you can't run during stage 2 VBlank since it'll be disabled a good deal of the time during SIO.

With immediate VBlank you can run it but it'll cause input overrun since it goes for too long.

With stock SIO you can't run it in mainline code as the SIO routine sits in a wait loop.

 

The solution - with custom SIO you can return to your mainline code.  Then all you need to do is once in a while check if the operation has completed.

Calling RMT in mainline - you just keep an eye on low byte of RTCLOCK, when it changes do the RMT play call.

Yes. That’s the way...

 

in a demo scenario where you want to have something nice on screen it gives you more headache. But as you said not impossible.

 

that’s why I am fan of carts now... since Wratchild told me how simple it is to use those bank switched ones...

[ilmenit]

Thanks guys. Therefore seems that without custom SIO it's hardly doable and custom SIO will have the same (and more issues than using xBios).

[Heaven/TQA]

1 hour ago, ilmenit said:

Thanks guys. Therefore seems that without custom SIO it's hardly doable and custom SIO will have the same (and more issues than using xBios).

Custom SIO in a modern way would need to run from all kind of modern media... 

 

xbios is not bad and can do what you want...

 

but it’s MPT here:

 

 

[emkay]

 

 

Btw. Not sure, where the real problems are, if RMT doesn't work with an SIO loader.  

But, if you have a look at this, you should start to rethink

There are a lot color changes , and they are stable, so WSYNC is used, which is a real timing breaker. But the loader works...

 

 

 

[Rybags]

WSync isn't a particular problem - at worst if might cause a delay of a little over a scanline considering screen DMA as well.

The problem is when an incoming byte isn't read before the next arrives = serial input overrun.

 

At 19.2 kbps stock rate (though it's a little different to that) a serial byte arrives about every 8 scanlines - the OS immediate VBlank and a short running DLI like for simple colour change is no problem there.  But something like an RMT playback routine with IRQs masked will easily cause problems.

[emkay]

3 hours ago, Rybags said:

WSync isn't a particular problem - at worst if might cause a delay of a little over a scanline considering screen DMA as well.

The problem is when an incoming byte isn't read before the next arrives = serial input overrun.

 

At 19.2 kbps stock rate (though it's a little different to that) a serial byte arrives about every 8 scanlines - the OS immediate VBlank and a short running DLI like for simple colour change is no problem there.  But something like an RMT playback routine with IRQs masked will easily cause problems.

 

If you now could explain what Heaven was writing:

On ‎2‎/‎19‎/‎2020 at 6:45 PM, Heaven/TQA said:

 

 

RMT is too heavy on CPU load i have to admit and you need to alter the layer code not to touch the sound channels... maybe the simple player... we tried it in Arsantica 3 but failed...

 

 

 

RMT has no problem with the CPU load. I wonder what the problems were.

[xxl]

RMT during SIO:

 

 

 

DLT during SIO:

 

?

 

 

[Rybags]

Like I said before - the bottom line is if IRQs are masked for too long, and you may as well say about 6.5 scanlines to be safe, serial input overrun can occur which will invalidate the current operation.

The typical scenario of RMT use is during VBlank.  If you're doing SIO by custom routine and using the OS VBlank code then you'd be wanting to do your RMT call during Stage 1, and IRQs are masked at that time, and a typical RMT music call + the OS code will pretty easily exceed the safe time limit.