BASIC Ten-Liners are back for 2018!

[AMSDOS]

Thank you for the compliments...

 

 

At least with my games, I'm not sure that they could be used for educartional purposes for many reasons:

 

• They seem to be 10 lines long, but they don't! Defensor actually has 220 statements packed to fit in those 10 lines. That's an average of 22 statements per phisical line!
• There are many, many, many optimizations to reduce the number of statements, so some things got mixed together, obfuscating the code.
• To fit the 10 lines, some statements are not placed in the "logical" order. Sometimes, part of the code has to be moved somewhere else to get the most from the max allowed length of a line.
• They are tied to the hardware. Without knowing the hardware, you cannot say which is the effect of a single POKE.

Anyway, all of my games have a description page with an explanation of what a statement or group of them does (*). Most of the times, it took me more time to write the docs than to code the corresponding program. Sometimes, I've found some bugs while I'm trying to explain the sources, and I had to update the game.

 

I've read some BASIC listings for C64, MSX and even 2600 for these contests, and sometimes I didn't understand the reason of the code or how something worked. There are many common statements in their syntax, but when graphics animations are the backbone of a game, it does not matter if the BASIC dialect has string functions or structured programming elements. Each machine has its own way to do things.

 

(*) The description pages for my 2018 entries won't have the source code listing until the end of the NOMAM event. Bunsen has the full docs anyway.

 

 

 

I'm currently been working on an Amstrad CPC version of "Alby, the albino bat" (not for a future compo), though am I to understand the collision test the Atari version has, is a convenient POKE?

I managed to write something on the Amstrad which involved array's, loops to test colour points around my floating frog in a pond It works, but I'll need to code in Assembly to ease time consuming calculations from Amstrad's BASIC.

 

Regarding the new FREI category which was added for this years Competition, I was a little confused that one of my Amstrad entries (Red Meets The Grumpy Grumbles) went into the EXTREM-256 category, despite it being that length, it also had a Machine Code sprite driver. Just wondered if the nature of my M/C Loader (which is quite an unusual one), didn't register with people?

Edited June 3, 2018 by AMSDOS

[vitoco]

The cave is drawn using playfield pixels and the bat is a so called "player", a single color sprite.

 

Atari has hardware registers to test collisions between sprites and playfield while the screen is refreshed. Different memory registers are used to store different combinations of players collisions, players against missiles, players against playfield and missiles against playfield. Every bit means a collision from some element to a specific other element of a given type. Those bits are persistent, so them have to be cleared with a POKE to a special register, the $D01E memory address.

 

You can take a look into Alby's listing at http://www.vitoco.cl/atari/10liner/ALBY/ and check that it checks for memory address $D007, the register that saves to which playfield the player P3 collided. Of course it only matters that the player does not collide with any playfield (all bits in zero).

 

About the FREI category, I was disappointed with it because although it was requested, that breaks the BASIC spirit, and then more when no games were submitted there. Now I see that at least one game was submitted. How is machine code called in Amstrad CPC? Or you just changed machine vectors to point to your custom routine?

[AMSDOS]

The cave is drawn using playfield pixels and the bat is a so called "player", a single color sprite.

 

Atari has hardware registers to test collisions between sprites and playfield while the screen is refreshed. Different memory registers are used to store different combinations of players collisions, players against missiles, players against playfield and missiles against playfield. Every bit means a collision from some element to a specific other element of a given type. Those bits are persistent, so them have to be cleared with a POKE to a special register, the $D01E memory address.

 

You can take a look into Alby's listing at http://www.vitoco.cl/atari/10liner/ALBY/ and check that it checks for memory address $D007, the register that saves to which playfield the player P3 collided. Of course it only matters that the player does not collide with any playfield (all bits in zero).

 

About the FREI category, I was disappointed with it because although it was requested, that breaks the BASIC spirit, and then more when no games were submitted there. Now I see that at least one game was submitted. How is machine code called in Amstrad CPC? Or you just changed machine vectors to point to your custom routine?

 

 

Wish I could appreciate the complexity of the Collision Detection the Atari uses, I wasn't aware there was anything like that within the Hardware, though I guess for a Game Based System, it's quite useful. Amstrad CPCs were made to cater for the Serious as well as the Game user, which means for things like Games, Sprite Drivers & Collision Detection routines have to be written.

Amstrad did revamp the CPC machines with the CPC Plus series, which has Cartridges, Hardware Sprites Driver, though my knowledge about them isn't great, but I think the irony about the Hardware Sprites on the Plus systems, is it needs an assembly routine to unlock those features for BASIC.

 

Unsure if it was my fault for submitting 5 games in the 2017 10-Liner Compo and asking Gunnar if an Assembly Sprite Driver could at least be used since the early CPC lack a hardware one. There are other means though of producing colourful graphics, the Colourful Trees in "Red Meets The Grumpy Grumbles" was all coded in BASIC by using Transparent Mode and User Defined Graphics (UDGs) in the appropriate PEN colour for the right effect, the other wild game I made "Aliens Attack" also uses the same kind of routine to draw Multicoloured graphics, I couldn't do Horizontal Scrolling in BASIC for this kind of game, so settled using an INK animation trick to alternate the edge of the play field, though because there was so much going on it was impossible to make it a 10-Liner despite it looking like a simple game. The Machine Code can simply be called with CALL <address>,<parameters> with <address> being where the Machine Code resides and <parameters> can be any number depending on how the routine is coded. This is usually done though Index Registers which have different offsets when Assembly routines are coded. Is also possible to write Resident System Extensions (RSXs), which are also accessible in BASIC though the use of the pipe command '|' followed by the name of the extension. Like the CALL it can also have a number of Parameters, when these things are coded they need to be CALLed to activate the RSXs, though they tend to be a little bit slower than a bunch of routines which can be called thought the use of CALL. As far as I know we can't change machine vectors to point to a custom routine, I guess if there was another way, it would have to be written as a ROM, which are also accessible though the pipe command, but would be against the rules.

[vitoco]

Wish I could appreciate the complexity of the Collision Detection the Atari uses, I wasn't aware there was anything like that within the Hardware, though I guess for a Game Based System, it's quite useful. Amstrad CPCs were made to cater for the Serious as well as the Game user, which means for things like Games, Sprite Drivers & Collision Detection routines have to be written.

As I said, the collision detection between Player/Missiles graphics and playfield in the Atari happens during the screen refresh, while the hardware computes which is the color for the next pixel to paint. This method is usefull in games where overlap of elements is allowed, like a bullet in the body of a cowboy to detect if it killed him, but if your hero can't walk through walls, you must compute by yourself if he can do the next step, and the hardware collision detection method becames useless...

 

The first time I used the hardware method was in my Invaders game. The block of aliens actually is a wall of blocks (fonts) like a BreakOut game, but the shape I assigned to the fonts left some space between the aliens, and allowed the missiles to go up between them. Only when I see that one of the hardware registers change to a non-zero value after I move the missile one step up, I can compute which is the block to remove. The other mini-games which also used this method are Don't Go!, Deep Canyon, Defensor and, of course, Alby, the albino bat.

 

Although Space Ranger also uses P/M graphics, collision detection could not be used because the playfield is completely drawn at game start, including the lasers that are initiallized as black, the same colour of the background just to hide them. This time, I must check if the coordinates of the enemy spaceship are in the range of the lasers when the trigger is pressed, changing the color register for the playfield pixels used for the lasers to display them.

 

 

Amstrad did revamp the CPC machines with the CPC Plus series, which has Cartridges, Hardware Sprites Driver, though my knowledge about them isn't great, but I think the irony about the Hardware Sprites on the Plus systems, is it needs an assembly routine to unlock those features for BASIC.

 

Unsure if it was my fault for submitting 5 games in the 2017 10-Liner Compo and asking Gunnar if an Assembly Sprite Driver could at least be used since the early CPC lack a hardware one.

Now I see why this exception in the use of assembly routines were required for the contest, and I understand it.

 

 

There are other means though of producing colourful graphics, the Colourful Trees in "Red Meets The Grumpy Grumbles" was all coded in BASIC by using Transparent Mode and User Defined Graphics (UDGs) in the appropriate PEN colour for the right effect, the other wild game I made "Aliens Attack" also uses the same kind of routine to draw Multicoloured graphics, I couldn't do Horizontal Scrolling in BASIC for this kind of game, so settled using an INK animation trick to alternate the edge of the play field, though because there was so much going on it was impossible to make it a 10-Liner despite it looking like a simple game. The Machine Code can simply be called with CALL <address>,<parameters> with <address> being where the Machine Code resides and <parameters> can be any number depending on how the routine is coded. This is usually done though Index Registers which have different offsets when Assembly routines are coded. Is also possible to write Resident System Extensions (RSXs), which are also accessible in BASIC though the use of the pipe command '|' followed by the name of the extension. Like the CALL it can also have a number of Parameters, when these things are coded they need to be CALLed to activate the RSXs, though they tend to be a little bit slower than a bunch of routines which can be called thought the use of CALL. As far as I know we can't change machine vectors to point to a custom routine, I guess if there was another way, it would have to be written as a ROM, which are also accessible though the pipe command, but would be against the rules.

Probably, your game was classified in the EXTREM-256 category instead of FREI category because the assembly routine was used only to enable a hardware feature you cannot get with other method like some POKEs, and to display sprites as we can do in the Atari just using MOVE to populate sprite buffers with bitmaps (well, some BASIC diallects in the Atari have special statements to perform that). Or, might be, Bunsen and his team didn't notice that the CALL statement worked like our USR function...

 

I'd like to try your games in an emulator. Could you give me some hints on which emulator to download for Win10 x64, and how to run your games?

 

[AMSDOS]

CPCBox is adequate enough for my simple games if you don't mind running it in your web browser and simple to setup. For the configuration any of the Boot configurations are fine, CPC 6128 is normally what other emulators default to or what people use, though I generally code on the CPC 464 for making the games compatible between BASIC 1.0 & BASIC 1.1. Unfortunately some of my games use the Joystick and others use Cursor Keys. In CPCBox the Joystick Icon defaults to enabled, which over-rides the Cursor Keys, it can easily be disabled to enable the Cursor Keys. In last years compo, all the games I made with the exception of Red's Exit use Cursor Keys, this for years compo Red Meets the Grumpy Grumbles uses Joystick, Red's Hurdles uses Enter (Return) key and I think Aliens Attack is also a Joystick. Once a system is selected, a Drive A: box appears below with an icon on the left to Insert a DSK image and an icon on the right to Ejecting the DSK image.

In BASIC you can use CAT to display the Disk Directory, but I've called all my programs DISC.BAS, so you can either run them with RUN"DISC.BAS to go straight into the program or LOAD"DISC.BAS which just loads the program without execution. LIST to list the program and RUN...

There's no case sensitivity in any of those commands or the filename.

 

Other popular Amstrad CPC emulators are Winape & Arnold for Windows if you prefer using a dedicated emulator program. I haven't used Arnold, though Winape is usually setup as a CPC Plus I think as default.

[vitoco]

Thanks for the info.

 

I've tried all 2018 and some 2017 entries of the contest so far. Some with success, but some were not playable. I don't know if it was a CPCBox problem with input devices (keyboard, joystick, ...). I had to LIST the programs to find the right way to play. I'll try again later using an emulator installed locally in my PC.

 

Amstrad CPC computers were unknown for me. The first time I heared about them was in this contest, and I wanted to play these games just now!!!

[AMSDOS]

I tried some of my programs, Reds Exit, Paddle Up! & Mini Ball Maze with CPCBox without any keyboard issues, some of the other Amstrad programs that were there maybe using other Key combinations.

 

I left instructions along with my programs for setting up the Winape Emulator, you may wish to pick a later version of it though if you're running a 64bit system. Unfortunately I can't remember what configuration that emulator defaults to once installed, my hunch is it would be a CPC Plus system, which comes up with the option of playing Burnin' Rubber or BASIC on boot-up. I've set mine up using the earlier computers because that's what I have or had when I was growing up and because Amstrad didn't launch the CPC Plus range in Australia and I'm just not as familiar with those computers despite them having fairly good compatibility with the original machines.

 

The Amstrad CPC range are fairly popular through the UK & Europe, as I mention they came to Australia and even New Zealand, I'm not sure if they ever sold in America, if they did, it was extremely limited. The power usage is somewhat usual in that the power for the Computer comes from the Monitor, switch off the Monitor and the Keyboard looses power, always remember that being different from a C64 or an Apple ][e. It's Z80 based so Disk based systems supported CP/M 2.2 (CP/M-80) and 128kb systems could run CP/M Plus (v3.1). Amstrad have their own specific kind of Disks as well that they called Discs, which are Double SIded, Single Density 3" Disks, which like 3.5" Disks are nice and solid. To use both sides of the Disks, you have to Flip each side manually (something you can't do with a 3.5"). The CPC664 is the rarer of all the Amstrads, this is because it came out at a time when other affordable machines were coming out with 128Kb, the 664 had Disk Drive as Standard with only 64kb, so a few months later the 6128 came out and units between the CPC464 and CPC6128 were sold between 1984-1989 and in 1990 the new Plus Range came out. The Plus range comprised of CPC464 Plus and CPC6128 Plus and a Console called the GX4000. I guess if Amstrad had decided to at least bring out the GX4000 to Australia, I might of had one, instead I've got an Atari 2600 and 7800. The Plus machines had their own Console built-in and Locomotive BASIC 1.1 was transferred to Cartridge. Unfortunately the success of those machines didn't eventuate and only a handful of Cartridge games came out, quite a few of the games were popular games when they originally came out on Disk & Cassette, though were criticised I think for lacking in features the new Plus range had to offer.

[carlsson]

Given that 8-bit computers were considered a dead end on the US market by 1984, at least releasing brand new models thereof, it doesn't surprise me if Amstrad CPC are nearly unheard of over there.

 

Wikipedia makes a mention that the CPC6128 had its debut in August 1985 through direct import by Indescomp Inc in Chicago, and that the 6128 arrived in Europe later in 1985. It supposedly cost $699 with green monitor or $799 with colour monitor. It can be compared with the Atari 520ST which was introduced in the USA in June 1985 at $799 with monochrome monitor or $999 with colour monitor. Thus the 128 kB Z80 based CPC6128 would be 100-200 dollars less than the 512 kB 68000 based Atari 520ST, both available simultaneously.

[AMSDOS]

Hmmm, unsure how accurate that Wikipedia article is, quite a bit of the information in it doesn't seem to be sourced apart from one article from Amstrad Computer User which has the Amstrad CPC6128 will be distributed in America. I have an Australian Edition of Personal Computer Games (PCG) dated Nov. 1985 which reviews the CPC6128, though it doesn't mention anything about availability, the other Australian magazine I have "The Amstrad User" reviewed the 6128s predecessor the 664 July 1985, though also reviewed the 6128 in Nov. 1985. Like Europe though Australia uses 220-240v, so it seems unusual it was initially sold in a 110v Country, though perhaps Amstrad were trying to get into the American market with a 128Kb machine. Indescomp Inc are the Spanish distributors which is interesting given that Amstrad are based in the UK.

[Savetz]

Play again?

 

Here's the contest thread for 2019.