Load while you play...

[sigh]

I was reading this interview on one of the programmers on SWIV on the Amiga:

Whose idea was the load-while-you-play system? How long did that take to perfect?

I believe it was my idea. I first developed the technique for Silkworm. The final boss encounter followed the last level immediately, but used a different set of graphics. The boss graphics did not fit in memory with the rest of the level, so I decided to load them from disk, as you approach the final screen. Then I used the idea extensively for The Ninja Warriors. By the time I used it for SWIV, I had done it twice before, and it was almost routine.

How does it work? (I am guessing the game is running mostly from the vertical blank interrupt and there is a main loop doing nothing but waiting for specific points, loading data from the disk and decompressing it over a safe area of memory for the next batch of baddies and tiles?)

That is exactly right.

(Edit: Here is the full article:)
http://www.codetapper.com/amiga/interviews/ronald-pieket-weeserik/


Now, I have already been told that this is not possible on the CPC as it takes a lot of the CPU time, but I'm wondering if this is possible using the DMA features of the PLUS machines?

[McKlain]

Well, something as complex as that, I don't know, but Dinamic included a mastermind game on some of their cassette releases so that you could play while the game was loading. Even with something that simple the keyboard input was slow.

[AMSDOS]

I dare say something like this cannot be rigged up using an Event Block to make it seem that the computer is doing two things at once.

But I recall the Mastermind game you could play while Rescue from Atlantics was loading.

[arnoldemu]

Now, I have already been told that this is not possible on the CPC as it takes a lot of the CPU time, but I'm wondering if this is possible using the DMA features of the PLUS machines?

Sadly it's the same on the Plus as it is on the CPC.

For both disc and cassette loading the cpu is involved throughout, so it's intensive on the cpu, and timing is very important.

The DMA in the plus is not the same kind of dma as found in other systems. Yes it is *D*irect *M*emory *A*addressing without the cpu's work, but it's not for loading chunks into ram.

it works different: each line, the plus fetches 3 instructions from base ram (base 64k). It then executes these. These instructions can be used for generating interrupts, looping over dma instructions and writing to ay ONLY. That is it, it is a much nicer way to access the AY only.

Now using interrupts during loading on either disc/tape is hard work and it affects the timing.

So the good news:

*IF* you pre-setup a DMA list, and it fit into RAM, then the Plus *CAN* play this while disc or tape operations are going on.
So in theory the plus can play samples while loading from disc or tape.
But this hasn't been tried yet.

[arnoldemu]

The only thing that would make it all possible, would be a hardware patch.
linking the fdc's interrupt pin to nmi or interrupts. that *may* work.

[sigh]

The DMA in the plus is not the same kind of dma as found in other systems. Yes it is *D*irect *M*emory *A*addressing without the cpu's work, but it's not for loading chunks into ram.

Darn

So the good news:

*IF* you pre-setup a DMA list, and it fit into RAM, then the Plus *CAN* play this while disc or tape operations are going on.
So in theory the plus can play samples while loading from disc or tape.
But this hasn't been tried yet.

So it can play samples while loading but not while playing an actual game. That's interesting in a similar way that the C64 use to play music while the game was loading. This could be useful for cutscenes of still pictures or maybe animated ones as it's just a sequence of pictures running through?

The only thing that would make it all possible, would be a hardware patch.
linking the fdc's interrupt pin to nmi or interrupts. that *may* work.

[redbox]

That's interesting in a similar way that the C64 use to play music while the game was loading.

Don't need a Plus or DMA to do this - arnoldemu wrote the routines to do it on a classic CPC for the Batman Forever demo 

[sigh]

Don't need a Plus or DMA to do this - arnoldemu wrote the routines to do it on a classic CPC for the Batman Forever demo 

Okay. It does makes me wonder how far you can push this technique on a PLUS machine....

[arnoldemu]

Okay. It does makes me wonder how far you can push this technique on a PLUS machine....

I haven't tried this, so it's speculation.

But I think playing a sample while loading is possible on plus.
Doing the same on cpc is almost impossible.

[OCT]

playing a sample while loading is possible on plus.
Doing the same on cpc is almost impossible.

At a minimum, there was one game that could do it while loading from tape (better on a 664/6128 where the speaker wasn't tied to the recorder as well IIRC). Not sure about the title and whether it would even work from a CDT/TZX tape image, but I'll have a look next time I get near the old cassettes (worlds away these days).

Some unusual sector size&interleave had also been figured out (not sure if it was by Face Hugger, possibly following similar work by Rubi in an early incarnation of The Demo) to allow music even from a disk loader, but I never saw or rather heard this in operation.

[Executioner]

Kev, you recently did a musical loader for BF didn't you? I did one back in 1993 for something, can't quite remember what it was.

The secret to doing this successfully would be to have interrupts enabled and use small sectors and a special interrupt routine that's very small except for one interrupt per frame, then retry the same sector read if the large interrupt causes an overrun. I think the version I did way back then actually did disable interrupts while reading the FDC.

By my calculations, a 128 byte sector should take 4096 microseconds to read (128 * 32) but the interrupts occur 3328 (52 * 64) microseconds apart, so the smaller interrupt routines would have to be quite a bit less than 32 microseconds to prevent buffer overruns.

Another way to do this would be to test the current interrupt number after the first byte of the sector is read, and only disable interrupts if it's between certain frame positions, so that only non flyback interrupts are missed.

[AMSDOS]

At a minimum, there was one game that could do it while loading from tape (better on a 664/6128 where the speaker wasn't tied to the recorder as well IIRC). Not sure about the title and whether it would even work from a CDT/TZX tape image, but I'll have a look next time I get near the old cassettes (worlds away these days).

Rescue from Atlantis - which consisted of a Mastermind game while the main game was loading!

[AMSDOS]

I remember on my 464 that if you had some flashing inks, they would flash away just in between loading blocks with the standard loader, just having a little animated sprite blinking away between blocks would be pretty cool! 

[arnoldemu]

I remember on my 464 that if you had some flashing inks, they would flash away just in between loading blocks with the standard loader, just having a little animated sprite blinking away between blocks would be pretty cool! 

Brian Bloodaxe!

[arnoldemu]

Kev, you recently did a musical loader for BF didn't you? I did one back in 1993 for something, can't quite remember what it was.

Yes I did. It uses 512 byte sectors, and relied on the time between the command and the data for the sector.
It had interrupts on, so any failure was retried. I did also use a special gap value to increase the chance that it would succeed, but that only worked 99% of the time on 3.5" drives, 3" drives are not very good for timing.

I've seen a musical loader on soundhakker, but I think Rob Scott did that one?

The secret to doing this successfully would be to have interrupts enabled and use small sectors and a special interrupt routine that's very small except for one interrupt per frame, then retry the same sector read if the large interrupt causes an overrun. I think the version I did way back then actually did disable interrupts while reading the FDC.

By my calculations, a 128 byte sector should take 4096 microseconds to read (128 * 32) but the interrupts occur 3328 (52 * 64) microseconds apart, so the smaller interrupt routines would have to be quite a bit less than 32 microseconds to prevent buffer overruns.

Well it is possible to interleave writes to the AY within the sector reading, and midline process does just this.
I've implemented one like that too, but it was more complex than the method I settled for.
I ran loads of timing tests, and found that 3" drives are not so good at running at 300rpm, they have a lot of variance.

Another way to do this would be to test the current interrupt number after the first byte of the sector is read, and only disable interrupts if it's between certain frame positions, so that only non flyback interrupts are missed.

Yes that could work.

[AMSDOS]

Brian Bloodaxe!

Yes indeed it does - what a strange game complete with false reset when it's loaded!
I couldn't find a tape image of it, though you can still see it at work in the Disk version! 

[sigh]

With samples being able to be played while loading, would a motion comic be possible? This example is obviously impossible, but think of it as only being 10 seconds long with no animation or effects but just cutting from one picture to another with a voice over:

http://www.cpcwiki.eu/forum/index.php?action=post;topic=2312.15;last_msg=24623

[Executioner]

I've seen a musical loader on soundhakker, but I think Rob Scott did that one?

Yes, that's the one. I actually wrote most of it for Rob.

[dlfrsilver]

I was reading this interview on one of the programmers on SWIV on the Amiga:

Whose idea was the load-while-you-play system? How long did that take to perfect?

I believe it was my idea. I first developed the technique for Silkworm. The final boss encounter followed the last level immediately, but used a different set of graphics. The boss graphics did not fit in memory with the rest of the level, so I decided to load them from disk, as you approach the final screen. Then I used the idea extensively for The Ninja Warriors. By the time I used it for SWIV, I had done it twice before, and it was almost routine.

How does it work? (I am guessing the game is running mostly from the vertical blank interrupt and there is a main loop doing nothing but waiting for specific points, loading data from the disk and decompressing it over a safe area of memory for the next batch of baddies and tiles?)

That is exactly right.

The D.L.S. (Dynamic Loading System) loading system is to ROM arcade machine data reading what loading data from a disk is from a computer like the amiga.

* It just renders the RAM limit an old souvenir. You can convert with it a coin-op that would require 8mb of RAM on a computer, that will only need 512kb of RAM. This is exactly what happened with saint dragon or SWIV. The computer is permanently loading graphics in RAM, dynamically, this allows too to keep ALL the sprites frames of a monster from the arcade. you just need to keep the disk in the drive