Help: Convert, display image, progressive loading (tape)?

[db6128]

akes me wonder why people ever bothered with loading screens 'back in the day'; I guess they used some form of compression, but even so - loading screens must have added valuable minutes to loading times.

It's a valid question in a lot of cases, especially when the screen starts to be longer, or even more enjoyable, than the game itself . . . However, the vast majority of screens that I've seen were not compressed. More clever loading routines might have employed some crunching, but I don't know how common it was.

Now I have the basics working using standard load/save commands from BASIC, I'd like to experiment with dumping the whole 16k block to tape/disk in one block. I see the CAS_READ and CAS_WRITE ROM routines seem to allow this; I'm guessing as I need to pass values via HL and DE registers I'll need to do this in assembly language - or can I 'poke' the HL and DE registers from BASIC?

You can't control registers from BASIC. You can pass parameters via the CALL command by using the stack, but the only register-mapping that occurs there is to inform the collecting subroutine of the number and address of the data being passed in.

Next I'll need to look at disabling CRCs... although I'm guessing this will need an entirely custom loader. I want to continue loading despite read errors...

I'm going to try hijacking the standard loading routines just to add the Spectrum-style border. :V That should be fairly easy as I've been practising writing and decoding ASM, including writing somewhat optimised pixel-plotting routines, and I imagine it'll be a fairly simple copy, paste, and addition of some basic I/O [good old confusingly named OUT (C),C].

Since I don't have a CPC with me at the moment, this all has to be done on WinAPE, and so I'll need to go and download tape images... not quite so nostalgic.

[Gryzor]

Wow.  I forgot how slow loading from tape was.  Dumping 16k of screen mem to tape takes ~3 minutes.

Makes me wonder why people ever bothered with loading screens 'back in the day';  I guess they used some form of compression, but even so - loading screens must have added valuable minutes to loading times.

I had asked the same thing a while back, I don't think there were any really convincing answers.

But, now that I think of it again, maybe it was a combination of both offering something to the user AND the user ignoring that nothing else happened while the screen was loaded. I'm sure most -if not all- of non-programmer users thought that the program loaded in parallel with the pic or something.

Ultimately, it was a powerful marketing tool - how many companies do you know these days that could have you staring at their logo for five or more minutes?

PS I love the loading sound...

[Nich]

Could be that CPCE plays the tape sounds and it conflicts with the actual music?

No, that's not the problem. CPCE plays both the tape loading noises and the music simultaneously, but the tape loading noises are much quieter. Music is played while the main game is loaded into memory (although you need to select "Tape compatibility" mode), so there's no issue with CPCE.

I think the reason why no 'music' is played while the screen is loading is simple; there is no music data embedded in the screen file!

Interestingly, the music on the disc version of Birdie is different to the cassette version. I don't understand why Ere Informatique would do that.

[Gryzor]

Interestingly, the music on the disc version of Birdie is different to the cassette version. I don't understand why Ere Informatique would do that.

Well, any number of reasons, the way things were running back then... maybe they didn't have the final version when the first edition went out and they got it later on?