Screen RAM Address and &bd question

[Bytebreaker]

Hello,

I would like to grab the visual content from the screen and save it to disk with the save command, option b.

Then I want to be able to read the saved screen data from disk and poke it back to screen ram. Is that possible? If yes, how?

In the cpc 464 manual there is a code example showing a smoothly moving text char with two "animation frames", respectively switching text chars. A code is used that begins with &bd19 or similar.

What is this about? I want to simulate smooth scrolling in Basic and I feel this might be the key to make it look better than the c64 basic text scroller I made. There, the characters move 8 pixels at once which makes the scroller look stuttering. On c64 I also see no way to use hardware scroll registers in Basic as my scroll text is a tweaked  print command solution. There is another one I did with only peek and poke into screen ram maybe hardware scrolling would work here but I feel on cpc it can be done in the most elegant way using basic and not machine language.

Edit :

I only know cpc basic until now. Can you recommend a good hardware book and z80 introduction?

[Fessor]

Screen Memory begins at &c000 and had a Size of &4000 bytes.
With save"screen.bin",b,&c000,&4000 you can save it. With load "screen.bin",&c000 you can load it direct into screenmemory.

Call &BD19 is used to synchronize output with Frame Flyback.


Die Bibel für den Z80
Programmierung des Z80 - CPCWiki

Und für den CPC
Das Schneider CPC Systembuch - CPCWiki

[Prodatron]

I want to simulate smooth scrolling in Basic and I feel this might be the key to make it look better than the c64 basic text scroller I made. [...] maybe hardware scrolling would work here but I feel on cpc it can be done in the most elegant way using basic and not machine language.

It's not possible to use smooth hardware scrolling in Basic without any assembler support routines. If you even want to use splitscreen techniques (one part of the screen is scrolling independant from the other part) then you have no chance with Basic.
A softscroller in Basic is only possible with a small text using the TAG methode, with which you can print text at any pixelposition (but this is really slow).

[SRS]

... SNIP ...
What is this about? I want to simulate smooth scrolling in Basic and I feel this might be the key to make it look better than the c64 basic text scroller I made. There, the characters move 8 pixels at once which makes the scroller look stuttering. ... SNIP ...

Hi,

first: no poking chars into screen as on other machines, CPC has a graphics screen
second: for "smother" movement consider printing in graphics mode not text mode. Hint: "TAG" - Command ...

Example (slooow):

Code Select Expand

5 DEFINT i
10 MODE 2
20 TAG
30 t$="I am scrolling, watch me ... the POWER of TAG                                   "
40 WINDOW 1,80,9,12
50 FOR i=630 TO 0 STEP -3
60  MOVE i,200:PRINT t$
70  CLS
80 NEXT
90 MODE 2:TAGOFF

[Bytebreaker]

Thanks guys for your help and expertise.
I will use your hints and continue to learn.

[Morri]

I have been looking at the same things as yourself @Bytebreaker and it becomes very obvious that there are a few holes in Locomotive Basic (Which is great by the way and I love!). Those are sprite handling and screen scrolling. Note that I too know next to zero machine code, all my games have been made in basic but I usually incorporate other tools and/or machine code routines to fill the required holes so I thought my experiences up to now may help you.

Firstly I want to deal with sprites...
When I came back to the CPC around 2008 I wanted to make a graphics intensive game in basic but quickly found that basic didn't have the ability on it's own. I was reading through some old Amstrad Action mags and found a review for the program "Sprites Alive". It is a package which loads into basic some machine code routines which are accessed through RSX commands, such as |scenery or |sprite. It includes a sprite design program and a very good manual on how to get started. Very worth checking out.
Here is a link to the dsk file for my first game "Eternal Light". Sprites Alive takes care of the sprites and collision detection, basic takes care of the rest. Feel free to *Break* into the code and check it out and copy anything you need.
Once I finished that game, I tried the compiler version of Sprites Alive which turns your basic code into machine code. Here I managed to make the game "Eternal Light 2". Major advantages here are speed increase. You can have more happening on screen with less slowdown. A bit more complicated to get working but worth it if you need the speed.
Lastly I tried a different program called "Easy Sprite Designer" made by Sean McManus. Again a machine code routine which helps put sprites on the screen. Using this tool and a windows based tool called CPC BASIC 3, I managed to make the game "Let's GO!", a basic game compiled into machine code.
As you can see, it was a slow learning curve of working out what works best and the type of game you're trying to make.

Now for scrolling in basic, I am currently making a game in basic that I wanted to have scrolling and sprites but I gave myself the challenge of no machine code routines like sprites alive or ESD. Instead I am using sprites made by using the SYMBOL command and control codes (CHR$(0) to CHR$(31)). I have also been using a scroll technique which scrolls the whole screen using the basic command OUT. Check out this post I did a few months back on the possibilities. I am making progress within the game itself but there are some limitations to what it can do.

Hopefully this helps you and I recommend reading all the posts I have linked to. Good luck and let me know if I can help any more.

[Bytebreaker]

Morri,


your work is just awesome.
I find it very appropriate to make use of the fantastic Amstrad Basic wherever possible, also in terms of a sportive challenge how far we get with acceptable speed.


On C64, you learn very soon that there is no alternative to machine code if you want to do more than printing text strings and formulas. Anything that deals with games or even demos in Basic can only be achieved with strange tricks, assembler function calls and often you need a Basic compiler aswell.


On Amstrad instead you can do so much more while still working with a high level interpreter language instead of machine language. These possibilities deserve acknowledgement, that's why I think it is good not to escape to machine language as fast as possible and leave Basic. This machine is worth doing both.


I'll get back at you when I have questions. Thanks for the valuable input.

[AMSDOS]

On Amstrad instead you can do so much more while still working with a high level interpreter language instead of machine language. These possibilities deserve acknowledgement, that's why I think it is good not to escape to machine language as fast as possible and leave Basic. This machine is worth doing both.

On an Amstrad, a good deal of the BASIC is accessed through the machines Firmware, though the Firmware is very extensive, so from time to time, some of the BASIC stuff will have Machine Code in it. On occasion BASIC doesn't need to rely on Machine Code, depending on the Firmware instruction, some need values loaded & other instructions hold values in them. An example of Firmware which requires no entry Parameters, nor return any is CALL &BD19, depending on which BASIC you've got, CALL &BD19 was tokenised in BASIC 1.1 to become FRAME, and that instruction in particular, is used to help reduce Flicker when moving Characters around the screen.