Un nuevo remake de un juego clásico se encuentra en preparación para nuestro Amstrad CPC de la mano del equipo de PlayonRetro, se trata de Booty The Remake.

Allá cuando corría el año 1984, Firebird lanzó el juego de rompecabezas arcade estilo pirata ‘Booty’ para Amstrad CPC, C64, Commodore Plus/4 y ZX Spectrum.

En ese juego jugabas como un grumete que tenía que robar tesoros de sus amos piratas, lo que significaba evitar a otros piratas, loros y tesoros atrapados.

Booty The Remake para Amstrad CPC

Si recuerdas este clásico juego de temática pirata de antaño, te complacerá saber que en algún momento en un futuro cercano podrás jugar Booty The Remake.

El equipo de PlayonRetro nos enseña algunas imágenes y algún video del juego en movimiento, y nos comentan que podrás verlo en directo, en el próximo evento de Amstrad Eterno 2023, que se celebra el día 30 de este mes en la ciudad de Málaga.

Quieres probar el nuevo "Booty, The Remake" para #amstrad CPC ?
Con las colaboraciones de Beyker, Brundij y @blackmores_ .
Te lo mostramos en exclusiva en @AmstradEterno. Ven a visitar nuestro stand de @PlayOnRetro.#gamedev #retrodev #indiedev #8bit #homebrew #programming pic.twitter.com/NlewSYos3H

— Salvador Cantero (@salvakantero) September 18, 2023

Así se mueve ahora Jim en el #amstrad CPC 464 .
Es un juego más rápido pero más fácil que las versiones de 1984-86.
[El sonido del video no es el definitivo]@PlayOnRetro @AmstradEterno @Indie_RetroNEWS @VintageNewOld #cpctelera #GameDev #RetroDev #8bit #indiedev #homebrew pic.twitter.com/I5cMFK1dGy

— Salvador Cantero (@salvakantero) September 20, 2023

In this chapter of ZX Spectrum Assembly, we will implement interrupts; if you want to know more about them, read the chapter dedicated to them in the Compiler Software course, and how to implement them in 16K.

The ZX Spectrum generates a total of fifty interrupts per second on PAL systems, sixty on NTSC systems.

Create the folder Step05 and copy the files const.asm, ctrl.asm, game.asm, graph.asm, main.asm, print.asm and var.asm from the folder Step04.

Before we continue, let’s look at the size of the program, which is about 1600 bytes.

The routine that is executed when an interrupt is generated is implemented in the int.asm file, so we create it.

Following the Compiler Software course, we will load $28 (40) into register I and our routine at address $7e5c (32348), giving us four hundred and nineteen bytes for the routine. Since the program loads at $5dad (23981), we have eight thousand three hundred and sixty-seven bytes for our game.

We open main.asm and before Main_loop we add the lines that prepare the interrupts.

We disable interrupts, DI, load $28 (40) into register A, LD A, $28, and load I, LD I, A. We change the interrupt mode to mode two, IM 2, and enable interrupts, EI.

We are going to implement the routine in the int.asm file, so open it and add the following lines:

We load the Isr routine at address $7E5C (32348), ORG $7E5C and preserve HL, DE, BC and AF, PUSH HL, PUSH DE, PUSH BC, PUSH AF.

We do nothing more for the moment and leave.

Get AF, BC, DE and HL, POP AF, POP BC, POP DE, POP HL, enable interrupts, EI, and exit, RETI.

Now we go to main.asm and just before END Main we include the file int.asm.

Compile, load into the emulator and test. Nothing seems to happen, but look at how much space our program now occupies. It takes up a whopping nine thousand bytes. Because we’ve loaded the routine at address $7E5C, PASMO fills all the space from where the program ended before to where it ends now with zeros, that’s why it takes up so much space. Normally this doesn’t matter when loading on an emulator, we can load it immediately, but on a ZX Spectrum we are adding unnecessary loading time.

To prevent our program from growing like this, we will compile the int.asm file separately from the rest. We will also dispense with the loader generated by PASMO and make our own.

Creation of the loader

From the emulator we will generate a BASIC loader and save it as loader.tap. The code of the loader looks like this:

We save our loader with the following instruction:

When the program is loaded, line ten is auto-executed.

Compilation in several files

We will compile the int.asm file separately, which will generate the int.tap file, and the rest of the program will generate martian.tap. Then we will concatenate the loader.tap, martian.tap and int.tap files into SpaceBattle.tap.

Since it is tedious to do this every time we want to compile and see the results, we will create a script. For those of you using Windows, create the file make.bat in the Paso05 folder, for those of you using Linux, run it from the command line:

Then grant permissions to run.

Before we continue, open the main.asm file and delete the include of the int.asm file near the end.

We can now edit make or make.bat. On Windows and Linux, the first two lines are the same.

First we compile the programme, then we compile the Int.asm file and generate the int.tap file. Note that instead of –tapbas we put –tap because we did the BASIC loader by hand.

Finally, we combine loader.tap, martian.tap and int.tap into SpaceBattle.tap.

For Linux users, add this line to the end of your make file:

For those of you using Windows, the line is as follows:

From here, the way to compile will be to run make or make.bat, and in the emulator we will load the file SpaceBattle.tap.

We compile, load in the emulator and see that everything is the same, but the size of SpaceBattle.tap is less than two thousand bytes.

We saw in the previous chapter that the ship was moving too fast. To solve this, we will use the interrupts to move the ship a maximum of fifty times per second (on PAL systems, sixty on NTSC), i.e. we will move the ship when the interruption is triggered. We open var.asm and add the following at the top:

In int.asm, add the following lines after PUSH AF:

We load the flags memory address into HL, LD HL, flags, and set the zero bit to one, SET $00, (HL).

Now go to the game.asm file and add the following lines just below the MoveShip tag:

We load the flags memory address into HL, LD HL, flags, we check if we need to move the ship, BIT $00, (HL), and if not we exit, RET Z. If we do need to move the ship we set the bit to zero, SET $00, (HL), this way we will not move the ship again until an interrupt occurs and we set the zero bit of flags back to one.

This will make our ship move fifty times per second (or sixty, depending on the system). We compile and…

Actually, we have a compilation error.

ERROR on line N of file Int.asm
ERROR: Symbol ‘flags’ is not defined

So far we have included all the .asm files we have in main.asm, but we have removed the include from int.asm to compile it separately, so the flags tag is not known in int.asm. The solution is simple, in int.asm we need to replace LD HL, flags with LD HL, memoryaddress.

Let’s have a look at the line we used to compile.

The last parameter, martian.log, creates a file of that name in which we can see what memory address the tags are at. In this case, flags is at memory address $5EB5, so just go to int.asm and replace LD HL, flags with LD HL, $5EB5.

Now yes, we compile, load in the emulator and see that the ship moves slower, but we still have a problem; put a NOP at the beginning of main.asm, just before the Main tag.

Compile and you will see that it works fine. Load it into the emulator and it stopped working. If you go to martian.log, you will see that the flags tag is at address $5EB6, but in the int.asm file the value loaded in HL is $5EB5. Every time we change some code, it is very likely that the flags address will change, so we need to make sure that we change it in int.asm as well.

To prevent the flags address from changing, we open var.asm, cut the flags declaration and paste it at the top of main.asm, below ORG $5DAD. This ensures that flags is always located at $5DAD. Don’t forget to replace $5EB5 with $5DAD in int.asm.

We compile, load it into the emulator and everything works, but this is because we initialised flags to zero, which is equivalent to NOP, which takes four clock cycles to execute, nothing more. If we had started it with a different value, say $C9, it would return to BASIC on execution because $C9 is RET. Try it and see.

This has an easy solution, before the flags tag we add JR Main, but as we only need the flags tag and it is zero, there is no problem, but be careful with this.

It is not necessary to add JR Main, but if you do, note that the flags address changes.

As with the ship, we include the constants needed for the shot in const.asm.

Also in var.asm we add the tag to store the shot position.

In print.asm we will implement the routine that paints the shot.

We load red ink in A, LD A, $02, and call change, CALL Ink.

We load into BC the position of the shot, LD BC, (firePos), and call to position the cursor, CALL At.

We load the shot character in A, LD A, FIRE_GRAPH, paints it, RST $10, and exit, RET.

The final aspect of the routine is as follows:

We implement the routine that moves the shot in game.asm.

We load the flag address into HL, LD HL, flags, then check if bit one (shot) is set, BIT $01, (HL), and if so we jump, JR NZ, moveFire_try. If bit one is not set, we check if the trigger control has been pressed, BIT $02, D, and if not we exit, RET Z. If it has, we set the trigger bit in flags, SET $01, (HL), load the ship position in BC, LD BC, (shipPos), point it to the top line, INC B, and jump to paints it, JR moveFire_print.

If the fire was active, we load its position in BC, LD BC, (firePos), delete the fire, CALL DeleteChar, point B to the top line, INC B, load the top stop of the fire in A, LD A, FIRE_TOP_T, and subtract B, SUB B. If the result is not zero, the top stop has not been reached and we jump, JR NZ, moveFire_print. If we have reached the top, we deactivate the shot, RES $01, (HL), and exit, RET.

If we have not reached the top or have just activated the shot, we update the position of the shot, LD (firePos), BC, paint it, CALL PrintFire, and exit, RET.

The final aspect of the routine is as follows:

It’s time to test the shot, so we open main.asm and at the beginning, in the flags declaration, we add the comment for bit one.

We locate Main_loop, and between the lines CALL CheckCtrl and CALL MoveShip we add the call to the shot movement.

We compile, load the emulator and see the results.

You can’t see it in the picture, but in the emulator you can see that it looks like it’s firing in bursts, and if you leave it pressed it looks like it doesn’t stop firing. This is an optical effect caused by the camera moving faster than the ULA refreshes the screen. We leave it like that to make it look like we are shooting several times at once.

We started working with interrupts, timed the ship’s movement and implemented triggering, as well as compiling the program into several files and customising the loader.

In the next chapter of ZX Spectrum Assembly, we will add the enemies.

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.

Pampas & Selene – The Maze of Demons y Westen House EX son dos de los títulos que más éxito han tenido en los últimos meses debido a su excelente calidad.

Ambos han agotado todas sus existencias en su salida a la venta. Pampas & Selene después de un lanzamiento retrasado respecto a su fecha inicial de publicación debido a problemas con el hardware ha colocado en todo el mundo (hasta en Japón) 500 copias. Por su parte, Westen House fue publicado en formato digital en el año 2021 de manera gratuita y llamó mucho la atención por su novedosa puesta en escena en perspectiva isométrica y por su atmósfera de misterio y terror. Este 2023 hizo su debut en formato físico vendiendo todas las unidades que habían disponibles.

Llegados a este punto en el que ya no hay más copias y cuando parecía que no habrían más para siempre, muy cerca en el tiempo han anunciado sendas remesas:

En el caso de Pampas & Selene, simplemente tenéis que poneros en contacto con Fran Téllez, su autor, enviando un correo electrónico para apuntaros a la lista de reservas:

Para Westen House EX, Ramón Ribas es quien está llevando el proceso. Y en este caso hay posibilidad de conseguir la caja de cartón grueso de la primera edición completamente ilustrada tanto por fuera como por dentro si se alcanza un mínimo de 100 unidades, a un precio de 35€. En cambio, si no se alcanzara esa cifra entonces existen dos posibilidades: pagar un poco más (alrededor de 40€) y mantener la caja de cartón o bajar a 30€ y sustituir la caja por una tipo estuche SEGA Megadrive. La campaña de reservas tiene una duración de quince días para tomar una decisión y la distribución de esta segunda remesa de cartuchos se haría coincidir con la celebración del evento MSX GOTO40 la primera semana de diciembre.

Para reservar, escribid al correo electrónico que aparece en la siguiente imagen:

¿A qué se debe este éxito? En primer lugar a la calidad de ambos juegos, eso es indiscutible. Pero además aquí entra en juego la manera que han escogido sus desarrolladores para dar forma a un cuidado lanzamiento en formato físico que no tiene nada que envidiar a los de la época comercial del MSX. Esto último es, en mi opinión un aliciente extra para comprar software homebrew. No me importa pagar más si el producto es de mejor calidad, en cambio me fastidia pagar dinero sin obtener como comprador la satisfacción de obtener un producto bien acabado.

Ya sé que el envoltorio no lo es todo, pero qué duda cabe que es un aspecto importante a tener en cuenta a la hora de vender un producto.

¡Corred a por ellos, insensatos!

8bits4ever ha anunciado que dispone de nuevo de unidades de SX2. Esta es una FPGA que se comporta como un MSX2+ (a día de hoy con los firmwares disponibles) pero que nace con vocación de futuro pues admite nuevas actualizaciones del firmware. Este hardware consta de unas características superiores a las del veterano OneChipMSX, empezando por la propia FPGA que tiene 22.000 elementos lógicos (el doble que el OCM) y complementándose con características como las siguientes:

• 2 ranuras para cartuchos MSX.
• Soporte interno de PSG, SCC+, OPLL (YM2413), OPL (YM3526), OPL2 (YM3812) y OPL3 (YMF262). 
• Conector de salida de audio de 3.5mm.
• Conector de entrada/salida para reproductores de casetes.
• Puerto PS/2 para teclado.
• Puerto PS/2 para ratón (emula a un ratón MSX conectado al puerto 1 de joystick).
• 2 conectores de joysticks tipo DB9 con norma MSX (dos botones funcionales).
• Conector de alimentación doble: mini USB y tipo clavija.
• Módulo interno WiFi (necesita configuración de la SDBIOS).
• Salida MIDI (a través del puerto 2 de joystick).
• Mapper seleccionable de 2/4 MB de memoria RAM.
• MEGASCC+/MegaRAM interno de 1MB.
• 2 modos Turbo CPU: 5.37 ó 8.06 MHz.
• BIOS dual opcional (requiere “reflasheo”).
• Carcasa de plástico impreso en 3D.

Su precio es de 250 euros y el tiempo de fabricación, montaje y pruebas es unas seis semanas aproximadamente.

Enlace relacionado: 8bits4ever

¡No os lo perdáis... otra vez!

leer más

La competición revela al jurado.

leer más

Un juego basado en texto transformado en una delicia bitmap.

leer más

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

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

So far we have been using the AT control character and coordinates to position ourselves on the screen, but this is slow.

We will open graph.asm and at the top of the file we will implement a routine that does the same thing, but is faster.

In this routine we use the ROM routine that positions the cursor. We store the value of DE, PUSH DE, and the value of HL, PUSH HL. Once this is done, we call the ROM routine, CALL $0A23, and retrieve the value of HL, POP HL, and also the value of DE, POP DE. Finally we exit, RET.

In the comments you can see that the routine also changes the value of AF and BC, but we don’t keep them; we won’t be affected by that, and so we save two PUSH and two POP.

Another thing to note, a hint is given in the comments, is that for the ROM routine the upper left corner is at coordinates Y=24 and X=32, so we will work with the coordinates inverted with respect to the AT instruction.

Open the file const.asm and add the coordinate constants.

The EQU directive does not compile, it does not expand the binary; it replaces the tag with its value wherever it is found.

The first thing we’re going to do is place the ship in our game area; it will move from left to right at the bottom of the game area.

Since the ship is a mobile element, we need to know its current and initial position, as we saw with the paddles in ZX-Pong.

We open the var.asm file and add the following lines after the game information title declarations:

In the case of the ship, we only define the position, DW $0511, a two-byte value, first the Y-coordinate and then the X-coordinate, which we will load into BC during the game to position the ship. The position $0511 is the result of subtracting 19 ($13) and 15 ($0f) from the upper left corner used by the ROM routine ($1820).

We open const.asm and add constants for the ship character, the start position and the left and right stops.

To paint the correct colours, and to avoid repeating the code, we implement a routine to change the ink colour in the graph.asm file. This routine receives the value of the colour in A.

Before implementing the routine, we add the constant memory location where the current colour attributes are stored. These attributes are those used by RST $10 to assign the colour to the character it is drawing.

We open the graph.asm file and implement the Ink routine.

If we need to rely on the B register, the first thing we do is to preserve its value with the EXX instruction, which exchanges the value of the BC, DE and HL registers with the alternative registers ‘BC, ‘DE and ‘HL, with only one byte and four clock cycles, which is faster and occupies less than if we used the stack.

We load the value of the colour into B, LD B, A, load the current attributes into A, LD A, (ATTR_T), discard the colour, AND $F8, add the colour, OR B, and load it into the current attributes, LD (ATTR_T), A. Finally, we retrieve the value of the BC, DE and HL registers, EXX, and exit, RET.

We need a routine to paint the ship, which we implement in the file print.asm.

We load the white ink, LD A, $07, into A and call CALL INK to change it.

We load the position of the ship into BC, LD BC, (shipPos), and position the cursor, CALL At.

We load the ship character in A, LD A, SHIP_GRAPH, paint it, RST $10, and exit, RET.

We already have the routine that paints the ship, which looks like this:

Before we leave the Print.asm file, we return to the routine that draws the frame, specifically the part where we create the loop that draws the sides.

We see that the six lines following printFrame_loop position the cursor to paint on the left side, then six lines following printFrame_loop do the same for the right side.

I’m using Visual Studio Code with the Z80 Assembly meter extension, so I know that this routine, from printFrame_loop to JR NZ, printFrame_loop, consumes one hundred and sixty-five clock cycles and twenty-eight bytes.

Since we’ve already implemented a routine that positions the cursor, we’ve just implemented At, so let’s replace these lines with calls to that routine.

Above printFrame_loop we modify the LD B line, $01, and leave it as follows:

Remember that the ROM routine works with inverted coordinates. We point B to line one, LD B, COR_Y – $01.

We delete the first six lines below printFrame_loop and replace them with the following:

A few lines down, we delete from LD A, $16 to RST $10 just above LD A, $9A, and replace these lines with the following:

Replacement from INC B to JR NZ, printFrame_loop.

The final appearance of the modified part is as follows:

At first glance, the routine is shorter, consuming twenty-two bytes and one hundred and eleven clock cycles, but beware, all that glitters is not gold, to these clock cycles must be added the clock cycles of the At routine, which are sixty-nine (the bytes are not added because we are going to use the routine from more places).

When all the values are added up, the routine takes twenty-two bytes and each iteration of the loop consumes one hundred and eighty clock cycles, fifteen more than the previous implementation, although we have saved six bytes. In addition, the ROM routine takes less time than positioning using the AT control code.

What do we do now? How do we leave it?

Since the routine that paints the border is not critical, as we only paint it at the beginning of each level, and four clock cycles will not be noticed, we decided to keep the six-byte saving and stick with the new implementation.

We just need to paint the ship, we go to main.asm and just below CALL PrintInfoGame we add the call to paint the ship.

We compile, load the emulator and see the results.

The ship must move in response to some action by the player, in our case by pressing three keys: Z to move the ship left, X to move the ship right and V to shoot.

We create the ctrl.asm file and implement the routine that reads the keyboard and returns the control keys pressed.

The routine we are going to implement returns the pressed keys in register D, similar to what was done in ZX-Pong; it sets bit zero to one if the Z key was pressed, bit one if the X key was pressed and bit two if the V key was pressed.

We set D to zero, LD D, $00, load the Cs-V half-stack into A, LD A, $FE, and read the keyboard, IN A, ($FE).

We check if the V key has been pressed, BIT $04, A. If it has not, we move on to check if the X key has been pressed, JR NZ, checkCtrl_left. If it was pressed, we set bit two of register D to one to indicate that the trigger was pressed, SET $02, D.

When we read from the keyboard, the status of the keys of the half stack read is in register A, with one for the keys that have not been pressed and zero for the keys that have been pressed (bit zero refers to the key furthest from the centre of the keyboard and four to the nearest).

The BIT instruction evaluates the status of the specified bit, $04, of the specified register, A, and, depending on whether it is set to zero or one, activates or deactivates the Z flag. The SET instruction sets the specified bit, $02, of the specified register, D, to one. The RES instruction is the opposite of SET, it sets the bit to zero. RES and SET do not affect the F register.

We check if the Z key has been pressed, BIT $01, A. If it has not, we move on to check if the X key has been pressed, JR NZ, checkCtrl_right. If it was pressed, we set the zero bit of the D register to one to indicate that the left key was pressed, SET $00, D.

We check if the X key has been pressed, BIT $02, A. If it has not been pressed, we exit, RET NZ. If it was pressed, we set bit one of register D to one to indicate that it was pressed correctly, SET $01, D.

Finally, we check if left and right are pressed at the same time, in which case we disable both.

We load A with the value of D, LD A, D, we leave the value of the bits zero and one, AND $03, and we subtract three, SUB $03. If the result is not zero, we exit, RET NZ, because the two bits weren’t set to one and we don’t have to do anything.

If we have not exited, we load the value of D back into A, LD A, D, keeping only the value of bit two (trigger), AND $04, and load the value into D, LD D, A, thus disabling the simultaneous left and right keystrokes. Finally we exit, RET.

The last tag, checkCtrl_end, is not necessary, although we include it to make it clear where the routine ends.

The final aspect of the routine is as follows:

We open main.asm and in each iteration of the Main_loop we will call the routine we have just implemented. Just below the Main_loop tag, we add the following line:

Below, in the part where we have the includes, we add the include for the ctrl.asm file.

We compile and check that it compiles well; there are no errors.

When the ship is moved, we first erase it from the current position and repaint it at the new position. In const.asm, we add the following constant to the constants we defined for the ship:

We open print.asm and at the top we implement the routine that deletes the ship. As this routine will also be used to delete the enemies and the shot, it will be given the coordinates of the character we want to delete in BC.

As DeleteChar receives the coordinates of the character to be deleted in BC, the first step is to position the cursor, CALL At.

We load the character in bank A, LD A, WHITE_GRAPH, and paint it, RST $10, erasing the painted character at these coordinates.

The final aspect of the routine is as follows:

Open main.asm and add the following lines just below CALL CheckCtrl to see if it works:

With these lines we erase and paint the ship in each iteration of Main_loop. If we compile and load in the emulator, we will see that the ship is blinking constantly, a sign that the erasing is working.

Let’s move the ship. We create a new file, game.asm, and implement the routine that changes the position of the ship and paints it. The routine gets the state of the controls in the D register (first we add the include from game.asm to main.asm).

We load the ship’s position into BC, LD BC, (shipPos), check if the right-hand control is pressed, BIT $01, D, and if so we jump to the part that controls the right movement, JR NZ, moveShip_right.

We check that the left-hand control has been pressed, BIT $00, D, and if it has not, we quit, RET Z.

If the left-hand control was pressed, we check if we can move the ship. We load into A the stop at which the ship can move to the left, LD A, SHIP_TOP_L + $01, and subtract the current column from the ship’s position, SUB C. If the result is zero, the ship is already at the stop and cannot move to the right, so we exit, RET Z.

If we don’t exit, we delete the ship, CALL DeleteChar, point C to the column just to the left, INC C, update the new position of the ship in memory, LD (shipPos), BC, and jump to the end of the routine, JR moveShip_print.

The routine that controls the movement of the ship to the right is almost the same as the one that controls the movement to the left, so we will only highlight and explain the changes.

In A we load the stop to which the ship can move to the right, LD A, SHIP_TOP_R + 01. In C we load the column to the right of the current position, DEC C. Finally, we paint the ship, CALL PrintShip.

The final aspect of the routine is as follows:

Before continuing, remember that I commented earlier that At changed the value of the BC and AF registers, but did not affect us. Now that At is called from multiple locations, the change to BC does affect us. The solution is as simple as adding PUSH BC and POP BC to At to preserve and restore the value of BC.

However, we will do another implementation that saves bytes and clock cycles.

We keep the value of BC where the coordinates are, PUSH BC, keep the value of BC, DE and HL by swapping them with the alternative registers, EXX, retrieve BC (coordinates), POP BC, and call the ROM routine that positions the cursor, CALL $0A23.

At this point the values of BC, DE and HL have changed, we retrieve them from the alternate registers, EXX, and exit, RET.

The routine now occupies eight bytes and takes fifty-six clock cycles to execute, compared to ten bytes and ninety clock cycles if we use the stack for the three registers.

It’s time to see if the ship is moving. We go back to main.asm and replace the lines we added earlier:

by:

We compile, load the emulator and see the results.

The ship already moves left and right, but we have the same problem we had in ZX-Pong, it moves very fast, faster than the ZX-Pong paddles, because they moved pixel by pixel and the ship moves character by character.

We could solve it in the same way as we did then, by not moving the ship in each iteration of the loop, but since we are going to use the interrupts for other things, we are going to do it through them, and so we see something we didn’t see in ZX-Pong.

In the next chapter of ZX Spectrum Assembly, we will implement interrupts; if you want to know more about them, read the chapter dedicated to them in the Compiler Software course, and how to implement them in 16K.

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.

Publicamos el manual con los esquemas de la máquina de casino Costa Brava de Interflip, escaneado y facilitado por Grull Oslo. Las máquinas Sevilla, Costa Brava y Toledo han sido recientemente volcadas, y como comentamos en la noticia relacionada en su momento, fueron además las tres primeras máquinas de casino en ser homologadas para España.

Leer más en: https://www.recreativas.org/noticias/2023/09/19/publicados-los-esquemas-de-la-maquina-costa-brava-de-interflip-por-grull-oslo-605
Recreativas.org - Base de datos de máquinas recreativas españolas.
Web: www.recreativas.org

Hace ya casi 7 años, un 5 de noviembre de 2016, nuestro compañero Azicuetano sufrió el síndrome de Stendhal al curiosear por el evento Retroconsolas Alicante y ver las creaciones tan maravillosas que muchos equipos homebrew habían desarrollado para sistemas de 8 bits que ya creía olvidados. Este shock provocó que durante la siguiente semana se pusiera a buscar información de cómo podría él desarrollar un juego para Amstrad, su querido ordenador de la infancia.

El síndrome de Stendhal puede catalogarse como una enfermedad psicosomática que causa un elevado ritmo cardíaco, felicidad, palpitaciones, sentimientos incomparables y emoción cuando el individuo es expuesto a obras de arte, especialmente cuando estas son consideradas extremadamente bellas.

Un año después nació Baba’s Palace, ganador del certamen CPCRetroDev 2017, a tan solo un puñado de puntos del inigualable Profanation 2, y con rivales tan duros como Basquet Cases, Cris Odd Prelude, Bitume, Laser Boy o Phantis Legacy entre otros.

Baba’s Palace es fruto del fabuloso arte musical de McKlain y de un año de trabajo a ratos libres de Azicuetano. Detrás de esto, muchos días viendo vídeos de Fran Gallego y leyendo con detalle el manual de CPCTelera. Horas y horas destinadas a búsquedas de inpiración, creatividad, pixel art, diseño de niveles, pruebas y mucho darle al coco. Si tenéis curiosidad, en la propia documentación entregada junto al juego para la CPCRetroDev tenéis un documento sobre el «making-of», así como el código fuente. También hay una entrevista muy amena de Fran Gallego a Azicuetano donde se explican muchos de los entresijos técnicos del juego y su proceso de desarrollo.

JGNavarro programó una magnífica versión para Android, compatible con el sistema de códigos de Amstrad para poder continuar la partida en uno u otro dispositivo.

Este pasado fin de semana se ha celebrado la 7ª edición de Retroalacant (aquí la genial crónica de Manuel Sagra), un gran evento sobre retroinformática en Alicante, y en el stand de 4MHz hemos expuesto un equipo Amstrad CPC con Baba’s Palace para ser usado por el público que acude al evento. Como concepto, un juego de puzzles que te obliga a estrujarte las neuronas para poder superar cada nivel, tiene todas las papeletas para pasar totalmente desapercibido en un entorno con tantos juegos atractivos al alcance del público. Pues bien, era un poema ver como todo aquel que se acercaba a mirar y tímidamente exploraba para averiguar qué tenía entre manos, acababa pasándose una hora atrapado entre bichos, escaleras y piedras. Y lo más sorprendente, el variado espectro demográfico que se enganchaba: parejas jóvenes, adolescentes, niños, y ¡hasta una madre con su hija de tres años en brazos que se llegó hasta el nivel 28 en una sentada! De verdad, ver para creer : )

Has sido muchísimas las muestras de cariño y las historias compartidas con nosotros sobre Baba’s Palace. Historias tan variopintas como que la hija de uno miembro de AUA, de 19 años, juega de forma asidua en una consola Amstrad GX4000 e incluso, en ocasiones, se la lleva en la mochila a casa de amigas para jugar allí. O la de una familia que llegó a poner el Amstrad en el comedor de su casa durante una temporada porque solian jugar todos juntos largas partidas.

Precisamente, esta edición de Baba’s Palace es fruto de una de esas anécdotas tiernas e inesperadas. Juan Antonio Rubio, reciente autor del libro «Ensamblador para ZX Spectrum ¿Hacemos un juego?«, fue uno de tantos que le echó horas a este juego en compañía de su hija, alternando intentos, y consiguieron juntos llegar hasta el nivel sesentaipico. Siempre tuvo clavada la espinita de que Baba’s Palace no contara con una edición cassette en físico y fue el principal promotor de la idea que desembocó en esta fantástica edición de PlayOnRetro, a cargo de Felipe Monge.

Si sois de los que os gusta coleccionar y poder tocar vuestros juegos favoritos, no os perdáis esta oportunidad, puede que no haya más…

Y es que no deja de sorprendernos ver la repercusión que el juego ha logrado. Al margen de premios, buenas puntuaciones y atractivas reviews en prensa especializada, es asombroso ver cómo en cada vídeo de YouTube sobre Baba’s Palace hay gran cantidad de comentarios amables y desinteresados destacando diferenes aspectos del juego. Algo similar ocurre con post en Twitter o foros sobre videojuegos retro. ¡Eso sí que es un verdadero premio para nosotros! Nunca imaginamos llegar a recibir una recompensa tan grande como el cariño recibido.

Junto a Baba’s Palace, PlayOnRetro tiene a la venta una maravillosa colección de juegos de Amstrad: Castaway, Jax the Dog, Space Panic + Spaceman Kerl, Shadow Hunter y Transylvanian Castle DX2. Echadles un ojo y aprovechad la oferta para llevaros los 6 juegos por el precio de 5!

La entrada Baba’s Palace ya a la venta en una edición física espectacular! se publicó primero en 4MHz.

Una solución sencilla para una gestión sencilla de los slots.

leer más

No hay banco seguro para Hopper Boy.

leer más

El sábado 23 de septiembre tendrá lugar nuestra reunión mensual, en el Centro Ciudadano de San Bartolomé de Geneto, en La Laguna. En esta ocasión tendrá lugar en la planta alta, que se encuentra después del bar.

La localización de centro ciudadano es:

Cam. San Bartolomé de Geneto, 206
38108 La Laguna, Santa Cruz de Tenerife

Google Maps

El horario será de 10 de la mañana a 8 de la tarde.

El lugar cuenta con amplio aparcamiento.

Como siempre nuestras reuniones son abiertas a cualquier aficionado, así que no dudes en venir a vernos.