In this chapter of ZX Spectrum Assembly, we will paint the play area.

Create the folder Step03 and copy the files const.asm, graph.asm, main.asm and var.asm from the folder Step02.

Before starting to draw the game area, it is necessary to know that the ZX Spectrum screen is divided into two zones, the upper one with twenty-two lines (from zero to twenty-one) and the lower one (the line where the commands are entered).

If you load the program resulting from the previous chapter, when it is executed, pressing the ENTER key will display the basic list of the loader. Executing line 40 should paint the graphics, but this does not seem to be the case. They do draw, but they do so on the command line; look and you will see them draw and then disappear.

After running our program, the active part of the screen is the command line, so we need a mechanism to activate the part of the screen where we want to paint.

The upper part of the screen is two, the lower part one. There is a routine in the ROM that activates one or the other channel depending on the value in register A.

Open the file const.asm and add the following lines:

Next, we open the main.asm file and just below the Main tag we add the following lines:

We load the channel we want to activate into A, LD A, $02, and then call the ROM routine to activate it, CALL OPENCHAN.

We compile, load into the emulator, press any key, execute line 40 and now our graphics are painted in the right place again.

When working with UDG, we could say that we are painting characters, and as such we will be painting the game screen.

We implement a routine that paints strings, giving the address where the string is and the length of the string.

We create the file print.asm and implement PrintString, which takes the address of the string in HL and the length in B. This routine changes the value of the AF, B and HL registers.

Loads the character to be drawn into A, LD A, (HL), draws it, RST $10, points HL to the next character, INC HL, and repeats the operation until B is 0, DJNZ PrintString. Finally, it exits, RET.

The final aspect of the routine, once commented, is as follows:

The next step is testing, so let’s edit the main.asm file. The first thing to do, so we don’t forget, is to include the print.asm file before END Main:

Just before the includes, we are going to define a string with two tags, the string itself and a second tag to mark the end of the string.

Just before the RET that takes us out of Basic, we add the call to the new routine.

We compile, load in the emulator and see the results.

As you can see, the string Hello World has been painted after the graphics.

We add codes before the string and leave it as it is:

We compile, load in the emulator and see the result.

As we can see, the Hello World string now appears more centred, which we have achieved by adding characters in front of the string, specifically $16, which is the control character of the Basic AT command, and the Y and X coordinates.

Below is a list of the control characters we can use when painting strings in this way, and the parameters to send.

Control codes must be accompanied by their parameters to avoid unwanted results. If a string is printed after TAB, a space must be added as the first character of the string.

As an exercise, try different combinations of control codes, try colour, blinking, etc.

The game screen is surrounded by a frame, but before we paint anything, let’s clean up main.asm, removing everything that’s left over; we delete from the two lines before the Loop tag to the line before the RET statement, we also delete the definition of String and String_End.

main.asm should now look like this:

Now we define the strings to paint the frame in var.asm and include them before udgsCommon.

In the first DB line we define the position of the top, $16, $00, $00 and the colour, $10, $01.

On the next line we define the top of the frame, first the top left corner, $96, then thirty top horizontal positions, $97, and finally the top right corner, $98; all these numbers are in the comments of the chart definition.

On the next line we define the position of the bottom, $16, $15, $00.

On the next line we define the bottom, first the lower left corner, $9b, then thirty lower horizontal positions, $9c, and finally the lower right corner, $9d.

Let’s see how it all looks. We go back to main.asm and add the following lines just above the RET:

We compile, load in the emulator and see the results.

We have painted the top and bottom of the frame, although the frame is not complete as the sides are missing.

We will implement a routine that prints the frame and we will do this in print.asm.

We load into HL the memory address of the top of the frame, LD HL, frameTopGraph, load into B the length by subtracting the start address of the top from the end address of the frame, LD B, frameEnd – frameTopGraph, and call the routine that prints the strings, CALL PrintString.

All that remains is to implement a loop to paint the sides.

We load into B the start line of the pages, LD B, $01, we load into A the AT control character, LD A, $16, and draw it, RST $10, we load the Y coordinate, LD A, B, and draw it, RST $10, we load the zero column, LD A, $00, and draw it, RST $10, and finally we load into A the left page character, LD A, $99, and draw it, RST $10.

We do the same with the right side, since the code is practically the same, we just mark the two lines that change.

And so we come to the last part of the routine.

We point B to the next line, INC B, load it into A, LD A, B, and check if B points to line twenty-one (the line where the bottom of the frame is), CP $15, and if not, repeat the loop until it reaches line twenty-one, JR NZ, printFrame_loop. As soon as B points to line twenty-one, we quit, RET.

The final aspect of the routine is as follows:

We will test if it paints the whole frame. Go back to main.asm and replace these lines:

For this one:

We compile, load in the emulator and see the result.

As you can see, we have already painted the frame of the screen, but there is still work to be done; we have not erased the screen and you can see things that should not be there.

Many of the Basic listings you see have a line similar to this:

This line sets the screen border to black, the ink to white and the background to black. Finally, the screen is cleaned by applying the ink and background attributes.

We will use the ZX Spectrum ROM to set the ink and background, clean the screen and implement the border colour change.

We start with the part where we clean the screen by opening the const.asm file and adding the following lines:

ATTR_P contains the permanent colour attributes in the format FBPPPIII, where F = FLASH (0/1), B = BRIGHT (0/1), PPP = PAPER (from 0 to 7) and III = INK (from 0 to 7). On the other hand, CLS clears the screen using the attributes in ATTR_P.

We go back to main.asm and add the following lines just before the PrintFrame call:

We load the memory address of the permanent attributes in HL, LD HL, ATTR_P; we set FLASH 0, BRIGHT 0, PAPER 0, INK 7, LD (HL), $07. Finally, we clear the screen, CALL CLS.

We compile, load into the emulator and see the results.

Now we want to change the colour of the border. We have already seen in ZX-Pong that the BEEPER routine of the ROM changes the colour of the border, so it is necessary to store the attributes in a system variable; the attributes have the same format as seen for ATTR_P.

We go back to the const.asm file and add the constant for the system variable where the border attributes are stored.

We go back to main.asm and set the border to black after CALL CLS.

We set A to zero, XOR A, and the border to black, OUT ($FE), A. We then load the value of BORDCR into A, LD A, (BORDCR), discard the border colour and so set it to black, AND $C7. We set the colour to white, OR $07, and load the value into BORDCR, LD (BORDCR), A.

The OR $07 command is only necessary while we are in Basic, remember that in BORDCR are the colour attributes of the command line, and if we don’t change the ink to white, it will stay as it was originally, in black, the same colour we gave to the background (border).

We compile, load into the emulator and see the results.

The only thing left to do is to paint the game information area, which we will do from the command line.

The first thing to do is to define the title line of the game information area, at the beginning of var.asm.

In the first line we set the colour to magenta and position the cursor at the coordinates 0,0. Next we define the titles of the information.

In print.asm we implement the routine that paints the titles of the information.

When painting the titles of the information on the command line, the first thing to do is to activate channel one. We load one in A, LD A, $01, and call the channel change, CALL OPENCHAN.

We load in HL the address of the title of the information, LD HL, infoGame, in B the length, LD B, infoGame_end – infoGame, and then we call to print the string, CALL PrintString.

Finally, we reactivate channel two (the top screen) and exit.

The final aspect of the routine is as follows:

We go back to main.asm and after CALL PrintFrame we add the call to paint the start information titles.

If we compile now, try it if you want, it seems that the last thing we implemented does not work, it does not paint the title information. Actually it does, but when we go back to Basic, the message 0 OK, 40:1 deletes it.

To avoid this, we’ll stay in an infinite loop; we’ll go to the RET statement that brings us back to Basic and change it to:

The final main.asm code is as follows:

We compile, load the emulator and see the result.

I don’t know about you, but I don’t like the fact that the titles are so close to the frame. Since we only have two lines in the command line without scrolling, and we need to draw the data below the title line, we have only one option left to remove a line from the play area.

In var.asm we find the frameBottomGraph tag, and one line down we see the DB that positions the cursor; we are going to change this line so that the Y coordinate is twenty instead of twenty-one.

In print.asm we now find the printFrame_loop tag. This loop runs until B is twenty-one; we need to change this condition so that it runs until it is twenty. Two lines above the RET of this routine we have CP $15, this is the line we need to modify, leaving it as follows:

We compile, load into the emulator and see the results. Now we have our play area.

In the next chapter of ZX Spectrum Assembly, we will implement the ship, its movement and therefore the controls.

Download the source code from here.

ZX Spectrum Assembly, Space Battle by Juan Antonio Rubio García.
Translation by Felipe Monge Corbalán.
This work is licensed to Creative Commons Attribution-NonCommercial-ShareAlike 4.0 International (CC BY-NC-SA 4.0).
Any comments are always welcome.

Ya hacía tiempo que no comentaba uno de estos maravillosos y útiles juegos educativos… y aquí me encuentro otra vez, con esta pequeña rareza de Mind Games España donde se pondrán a prueba nuestros conocimientos de vocabulario. Además, nos da la opción de competir contra otros tres jugadores y un número bastante elevado de opciones. Eso si, no le pidamos peras al olmo, que al ser un juego programado en BASIC, a veces las palabras se repiten con demasiada frecuencia. El mayor problema es que en cada partida, nos dan un tiempo de 20 minutos para responder y claro, la capacidad es demasiado limitada como para meter más.

Primero nos preguntará por el número de jugadores, después el nombre y ya pasamos a las opciones que nos dan para aprender y practicar. Podemos elegir miscelania, sinónimos, antónimos, numerales, gentilicios, singulares, plurales, masculinos, femeninos y abreviaturas.

Una vez seleccionado lo que queremos, el programa nos lanza la pregunta y nosotros tenemos que escribir la respuesta. Si acertamos, nos dará dos puntos. En cambio si fallamos, nos dará una segunda oportunidad enseñándonos 3 opciones. Si acertamos nos dará 1 solo punto y si una vez más erramos en la respuesta, nos dará la posibilidad de elegir otra de las 3 opciones. Eso si, en este punto si acertamos, ya no nos dará puntuación.

Clásico juego educativo digno de las épocas de EGB. Venga, a probarlo y a practicar ¿o tenéis miedo a tener oxidados vuestros conocimientos?

Descargas:

• Ortografía 1: Vocabulario (Mind Games España, 1986).cas

Ficha:

Juego: Ortografía 1
Genero: Educativo
Año: 1986
Programación: Pere Marqués / Sara Ranea
Distribución: Mind Games España
Dificultad: …
Mi Retropuntuación: 6

Raúl Portales acaba de publicar un nuevo juego bajo su sello Platty Soft, una mezcla de géneros con un aspecto muy bonito y bastante divertido.

Hablamos de Shyre, un videojuego que se inspira principalmente en los clásicos Eggerland Mystery y Sokoban con sus mecánicas de resolución de puzles a las que se les une la exploración de pantallas para conseguir objetos que nos serán de vital importancia en nuestra misión de salir con vida del planeta Shyre que da nombre al juego.

A mí me gustan los juegos de puzles, y si además tienen un acabado gráfico tan chulo como este Shyre, todavía más. Al jugarlo no puedo evitar recordar los videojuegos japoneses de los años ochenta, capaces de engancharme durante horas frente al televisor. Jugando con Shyre he vuelto a sentir lo mismo de antaño.

Me quito el sombrero ante el trabajo de Raúl en el aspecto gráfico y sobre todo por haber conseguido hacer que una idea clásica, sea tan fresca y divertida en pleno siglo XXI.

Según su autor, Shyre comenzó como un ejemplo de programación de un juego tipo dungeon crawler para su libro Modern MSX Basic Game Development. Y mirad en qué se ha convertido finalmente.

El juego está disponible para descargar, junto con su manual de instrucciones desde su página oficial. Además, se está preparando una tirada del juego en formato físico para los que estén interesados a un precio de 25 euros. En la propia página encontraréis el enlace para poder hacer una reserva.

Las copias estarán disponibles para final de año, coincidiendo con la celebración del evento MSX GOTO40 en Países Bajos.

Enlace relacionado: Shyre

Una nueva oportunidad de haceros con él.

leer más

In this chapter of ZX Spectrum Assembly, we will start drawing with UDG.

The ZX Spectrum character map consists of two hundred and fifty-six values, of which we can redefine twenty-one, namely those between $90 (144) and $A4 (164) inclusive.

Create a folder called Step02 and copy var.asm from Step01.

The value of memory address $5C7B contains the memory address where the user-defined graphics are located, so all we need to do is load the address where our graphics are defined into that memory address. Once this is done, drawing any character between $90 and $A4 with RST $10 will draw the graphics we have defined.

We create the file called const.asm and add the following:

In this constant we will have the address where we store the address where our graphics are located.

It’s time for our first test, we’re going to paint the UDGs. Create main.asm and add the following lines:

The first thing to do is to specify the address where we want to load the program, ORG $5DAD. We load the program at position $5DAD (23981) as it will be compatible with 16K models.

The next line is a label, Main, the entry point of the program.

Next we load one hundred and forty-four into A, LD A, $90, and twenty-one into B, LD B, $15, so we paint from character one hundred and forty-four to one hundred and sixty-four, for a total of twenty-one characters.

We make a loop of twenty-one iterations, starting with the loop label, Loop. We then keep the value of A, PUSH AF; the next instruction, RST $10, prints the character to which the code loaded into A belongs and modifies the register. We recover the value of A, POP AF.

We then increment A, INC A, so that it points to the next character, decrement B and jump to the loop if it has not reached zero, DJNZ Loop. Finally, we return to Basic, RET.

The last line tells PASMO to include the call to the address of the Main tag in the Basic loader.

Now it’s time to compile and see the results in the emulator.

But have we painted our graphics?

We have painted the capital letters A to U because we have not indicated where our graphics are.

Next, we go to the main.asm file, and under the Main tag we add the following lines:

We load into HL the address where the graphics are, LD HL, udgsCommon, and load that value into the address where the location of our graphics is, LD (UDG), HL.

As both udgsCommon and UDG are not defined in the main.asm file, we need to add the includes for the const.asm and var.asm files after the RET statement.

Now we can recompile the program, load it into the emulator and see our graphics on the screen.

Much better, right? But we painted twenty-one graphics: the ship, the shot, the explosion, the frame, the blank character, the graphics of enemy one and part of the graphics of enemy two. How are we going to paint the other two graphics of enemy two and the rest?

Looking at the graphics definition, the first tag is called udgsCommon, and this should give us a clue as to how we’re going to do this. We have defined fifteen common UDGs (ship, shot, explosion, frame and target), so we are going to define thirty-two bytes to be able to dump the enemy graphics into them; we do this because the enemies are one per level, and the dump is only done once, just at the level change.

In the var.asm file, above udgsEnemiesLeve1, let’s add the following lines:

In this block of memory we are going to dump the graphics of the enemies, depending on the level we are in.

Try compiling now and see how it looks. The enemy graphics are gone, aren’t they? It’s the udgsExtension painting.

We create the file graph.asm and implement in it the routine that loads into udgsExtension the graphics of the enemies of each of the levels, data that it receives in A.

To calculate the address where the graphics are, we multiply the level by thirty-two (bytes occupied by the graphics) and add the result to the address where the graphics of the first enemy are.

Since the levels range from one to thirty, we decrement A, DEC A, so that it does not add one level too many (level one adds zero to udgsEnemies, level two adds one, etc.).

The next step is to load the level into HL, for which we load zero into H, LD H, $00, and the level into L, LD L, A.

We multiply the level by thirty-two by adding HL to itself five times, ADD HL, HL. The first addition is like multiplying by two, the second by four, by eight, by sixteen and by thirty-two.

We load the address of the first enemy graphic into DE, LD DE, udgsEnemiesLevel1, and add it to HL, ADD HL, DE. We load the extension address DE, LD DE, udgsExtension, load the number of bytes we are going to load into udgsExtension, LD BC, $20, and load the thirty-two bytes of the level’s enemy graphics into udgsExtension, LDIR. Finally we exit, RET.

The final aspect of the routine is as follows:

Let’s test the new routine by editing the main.asm file, starting by changing the LD B, $15 instruction, above the Loop label, and leaving it as follows; it prints the first fifteen UDGs, the common ones:

The rest is implemented between the DJNZ Loop instruction and the RET instruction.

We load in A the first level, LD A, $01, in B the total number of levels (thirty), LD B, $1E, and implement a loop that draws the enemies of the thirty levels.

We keep AF, PUSH AF, and BC, PUSH BC, as we use A and B to control the enemies we paint and the loop iterations. Next, we call the routine that loads the level’s enemy graphics into udgsExtension, CALL LoadUdgsEnemies.

The characters corresponding to the enemy graphics are $9F, $A0, $A1 and $A2; we load them into A, LD A, $9F, and paint, RST $10. We repeat the process with $A0, $A1 and $A2.

Recover BC, POP BC, AF, POP AF, increment A to go to the next level, INC A, and repeat until B is zero, DJNZ Loop2.

Finally, at the end of the file and before END Main, we insert the file graph.asm.

The final main.asm code is as follows:

We compile, load into the emulator and see that we have painted all our graphics.

At this point we have defined all the graphics and learned how to paint them.

In the next chapter of ZX Spectrum Assembly, we will paint the play area.

Download the source code from here.

ZX Spectrum Assembly, Space Battle by Juan Antonio Rubio García.
Translation by Felipe Monge Corbalán.
This work is licensed to Creative Commons Attribution-NonCommercial-ShareAlike 4.0 International (CC BY-NC-SA 4.0).
Any comments are always welcome.

Durante el día de ayer sábado 16 y hoy domingo 17 se está celebrando una nueva edición de Retro Alacant 2023 en el Centro Cultural Las Cigarreras, de Alicante.

Esto es un festival de la cultura “retro”, un espacio de disfrute que gira en torno a los videojuegos, consolas, juegos de mesa, y todo aquel material que nos hace recordar mediante torneos solidarios, talleres, música, zona de expositores, batallas arcade, etc … la tecnología de los 80-90 y su evolución en el tiempo.

Una expedición de AUA se ha desplazado hasta el mismo para montar un stand con máquinas y hardware del Amstrad CPC.

Además, todo aquel que se acerque podrá disfrutar de diversos juegos, máquinas arcades, charlas, talleres, torneos, mercadillo, etc.

Quizás una de las principales atracciones en lo que se refiere al mundo del Amstrad, sea la presencia de Roland Perry, ya que fue el ingeniero encargado del diseño del Amstrad CPC, tenemos que dar las gracias la organización de Retro Alacant por hacer esto posible.

Retro Alacant 2023

Prototipo MOS del CPC

En una entrevista que se le ha hecho conoceremos de primera mano toda la historia de la creación de esta computadora y todas las curiosidades que llevo el proceso y las derivadas de su cargo de director de proyectos en Amstrad.

Gran afluencia de público como se puede observar en el video que os dejamos a continuación, junto con algunas fotografías del evento, esperemos que os guste.

Por favor, acepta las cookies de YouTube para poder ver este video. Aceptando, accederás al contenido de YouTube, un servicio externo y gestionado por terceros.

Leer la privacidad de Youtube.

Aceptando este aviso, tu selección será guardara y la página se refrescará.

Aceptar Cookies

Descarga

Descarga

Descarga

Descarga

Descarga

In this chapter of ZX Spectrum Assembly, we will define all the graphics used in Space Battle.

We will learn how to do the hexadecimal/binary conversion on the fly by doing our first exercise.

You can use ZX Paintbrush, or you can use the templates I created for GIMP, which you can download from these addresses:

• ZX Paintbrush
• GIMP
• Templates

The templates I have prepared are as follows:

• 8x8Template: for creating 8×8 pixel graphics.
• 256x192Template: the size of the ZX Spectrum’s screen.

For Space Battle we will use 8×8 templates. I will show you the image of the graphics, the hexadecimal codes, and your job will be to convert the codes into pixels, head first, to draw the graphics on the templates.

Although at first it may seem complicated to convert a hexadecimal number to binary, and vice versa, it is very simple and practically straightforward. We need to know the value of each bit (pixel) in blocks of four, which gives us a value between 0 and F, a value that can be represented by each hexadecimal digit.

In a byte, each bit to one has the following values:

When we convert from hexadecimal to binary, we divide the byte into two blocks of four bits (nibbles), resulting in a range of values between 0 and F (8 + 4 + 2 + 1 = 15 = F). To convert from binary to hexadecimal, we add the value of the bits to one of each nibble, which gives us the value in hexadecimal.

Suppose we have the following binary value:

0101 1001

If we add up the values of the nibbles, the result would be:

0 + 4 + 0 + 1 = 5       8 + 0 + 0 + 1 = 9

The result is that 01011001 is 59 in hexadecimal.

In hexadecimal a byte is represented by two digits. What if the value of some of the nibbles is greater than nine?

11011011 = 8 + 4 + 0 + 1 = 13 y 8 + 0 + 2 + 1 = 11

How do we represent thirteen and eleven with only one digit each? In hexadecimal, values from ten to fifteen are represented by letters.

In the example above, the hexadecimal value of 11011011 is DB.

Practising hexadecimal/binary conversion

A good way to learn is by doing, and this is what I propose to do below. Let’s look at the definition of all the UDGs we are going to use (the hexadecimal values) and draw them by doing the conversion from hexadecimal to binary.

If we work with nibbles (4 bits), the conversion table for a byte would be as follows:

We will create a folder called Step01 and inside it a file called var.asm. Having this table at hand, we are going to draw the ship, whose definition in hexadecimal (which we are going to copy into the created file) is the following:

We convert to binary.

If you transfer this conversion to ZX Paintbrush, or to the templates, the result should look like this:

We are going to continue practising, doing the conversions for the shot and the animation of the explosion of the ship. It is important that you try to translate it from hexadecimal to binary and from there to the graphics.

From here on, I will just give the hexadecimal definition and the image of the final appearance of each UDG.

If you are wondering what the number in the comments of each definition means, it is the code of the character we are redefining, i.e. the character code we are going to send to the printer to make the graphic. Don’t worry if you don’t understand it now, it will be much clearer later.

With this we have already defined the graphics we are going to use: the ship, the shot, the explosion, the frame of the screen and the enemies.

You may notice that all the enemies have the same character code, this is because there is a limited number of characters that can be used as UDGs. Don’t worry, we’ll see a way around this later on.

It’s really very important to practice the hexadecimal to binary conversion, so don’t leave it for another day, it’s a very simple exercise.

In the next chapter of ZX Spectrum Assembly, we will start drawing with UDG.

Download the source code from here.

ZX Spectrum Assembly, Space Battle by Juan Antonio Rubio García.
Translation by Felipe Monge Corbalán.
This work is licensed to Creative Commons Attribution-NonCommercial-ShareAlike 4.0 International (CC BY-NC-SA 4.0).
Any comments are always welcome.