And that is it for Retrochallenge 10/18

Or is it 18/10?
Anyway, writing a brief closing post seemed to make sense, so here it is.
To start, it was fun!
Yes, some things did not work as I expected, and others where hard, but overall, I had a lot of fun working and playing with my old computers – and emulators when needed.
It was also interesting to look at all the other projects going around, although I will admit that I did not have much time to see how the other participants were doing.
My goal of having 3 challenges may have been a bit too much. Not that I had to run to finish either, but I had to leave my other hobbies and projects on the sidelines for the whole month.
The First Challenge was to get my old Acer 486 laptop and “to install a full DOS and software package, including some games, utilities and productivity software in it”
Unfortunately, the poor thing is more dead than alive now. I’ll try to figure out what went wrong with it, and see if it can be recovered.

The Seconds Challenge was “to write a game that will run in any CoCo, using the low-res graphics mode (64×32) and no more than 16 KB RAM.”
“Hippo Teeth” was actually easy to write. Not having to create the gameplay mechanics helped a lot. I will try to write a version that runs in a 4 KB tape based CoCo, and another with some extra features, not caring too much if it will run or not in a 16 KB machine.

And the Third Challenge was “to look through my old programs, find some that could use some cleanup, and try to update them.”
And did I find some!
I have 10 disk images worth of old programs, and just by looking in 3 of them, I’ve already found 8 games that I wanted to update.
For the RetroChallenge, I did “Aliens”, “Russian Roulette”, and “Super-Catch-it”
It was fun – and a bit scary – to go over my +30 year old code. I really want to go over the rest of the programs, perhaps 20-30, and create a nice set of not-so-bad new-old games.

This slideshow requires JavaScript.

Perhaps for the next Retrochallenge? Because I will be there for sure!

RetroChallenge #1, part 4. Time to face reality.

Challenges #2 and #3 worked out quite smoothly. And so was challenge #1, that is, until I went to turn on my Acernote laptop.
The first thing that I noticed was that I could hardly see the text in the screen.
Something happened since the last time I used it, not that long ago. Looks like the lamp is almost dead, and there is an area at the bottom center of the screen where there is some kind of damage.
“OK” – I said to myself – “I can use an external monitor, and try to figure this out later.”
As the BIOS battery is long dead, I went to the usual steps to setup the time and date, and run the hard drive autodetect.
But… no joy. It just would not detect the disk.
Also, some of the keystrokes used to move around the BIOS menu did not want to work most of the time.
I opened it up, checked the mylar cable connectors for the keyboard, the one for the hard disk… all looked OK. But every time I booted it up, seemed to work even worst.
Well, today I could not even get to the BIOS. I press [Ctrl]+[Alt]+[Esc], it beeps, but nothing happens.
After trying to figure out what is going on for about an hour, it was evident that I had to face the facts. i have failed Challenge #1.
I really hope that I can – eventually – find out what is happening.
I´ll have disassembly it as much as I can, and work for some time that I don’t have right now.
If it happens to be a total loss… at least I have another 486 machine, a full tower, that I will try to eventually set up and use it to run the software that I planned to use in the Acernote.
Life happens…

RetroChallenge #3, part 9. Two for the price of one.

With just hours left in the Retrochallenge, I sat to add that 2nd “Chomper” to “Sup-Caz”.
Trying to keep the game as fast as possible, I thought that I could just draw the same “sprite” a second time, just switching the horizontal and vertical variables.
And it worked. I had to make a concession though.

The screen is 256×192. But, since I’m switching vertical and horizontal ones for the second Chomper, I can’t use the whole screen, since 240 can’t be used as a vertical coordinate. Therefore, I had to limit the screen to 192×192. This is not that bad, and leaves some empty space on the side if I ever want to have some kind of score display or whatever.

With this, the Remix was basically done.
I went ahead tweaking a few things. Like removing the timer used to end the game (it moved a single pixel, almost unnoticeable, across the screen) and just used the Chomper’s position as timer. Once it reaches the 14th line, the game is over.
Also made the show your score and pause whenever you catch a bug or are eaten, instead of only at the end of the game, and finally, if your score goes below 0 (you loose points when eaten by a Chomper), the game is over.
Of course, before calling it a day, I compacted the code the usual way, merging and renumbering lines, and removing spaces.
In the end, the game is not very challenging or fun the way it is. Just mildly entertaining, I would dare say.
But is probably the “ultimate” version of the original game.
If I ever decide to come back to this game, I will probably switch to the lower resolution (128×96), which will give me larger characters, and 4 screen pages. Then I could add some background with obstacles, some logic to the bug’s movement – like trying to stay away from the player or close to the Chompers, and an on-screen score display.
And again, I wonder why I didn’t do better back then. I guess I realized that the game was not that fun to play, and didn’t try too hard.
Here is the code for the original and Remix versions.
I guess this is it. I can say “Challenge #3, completed!”

RetroChallenge #3, part 8. I lied to myself.

So I sat to redo the graphics. The first thing I realized was that I still, after 30 years, don’t understand how the DRAW command really works when moving just one or 2 pixels. So I ended up using a lot of LINE and PSET, but that is all right. I also started using
DRAW” BM100,100;M110,110;BM70,100;M70,110″
instead of
LINE(100,100)-(110,110),PSET:LINE(70,100)-(70,110),PSET
since it is a lot shorter, not just to store, but also to type.
It was at that time that I noticed that my “bug” sprite was only 11 pixels high, and the player’s was 13…. No big deal, small redesign, with a little hat for the player.
Then, it was just a matter of using a “flag” variable – C in this case, to determine which of the 2 sprites for each character to PUT. If C=1 then C=0 and use one set of sprites, if not, then C=1 and use the other set.
IF C THEN PUT(X,Y)-(X+11,Y+11),P1,PSET:PUT(Y,X)-(Y+11,X+11),P1,PSET:C=0 ELSE PUT(X,Y)-(X+11,Y+11),P2,PSET:PUT(Y,X)-(Y+11,X+11),P2,PSET:C=1
And it looked quite good! But… the “Chomper”… the animation did not look good. Soooo I changed the movements to have the characters step 6 pixels at a time. Of course, that will make them take longer to go from one side of the screen to the other, but that is not a big deal.
But then, I discovered my lie.
The “reason” why I did the new graphics was so that all of them matched the movement grid size, 12×12, making collision detection a lot easier.
But now, the movement grid is 6×6!
Instead of the simple
IF H=X AND V=Y GOSUB 580
I had to go with
IF H>X-12 AND HY-12 AND V<Y+12 GOSUB 580

Well, the game was still reasonably fast. And since I noticed that the lone Chomper was not really much of a threat… why not add a second one?

RetroChallenge #3, part 7. Do I have time for another one?

I guess I shouldn’t…. After all, there are just 6 days left…
What the heck, I do consider challenge #3 achieved, with 2 Remixed games.
And my long term goal, beyond retrochallenge, is to remix over a dozen of games, so, the next one in the list is “Sup-Caza”. The name comes from “Super Cazalo”, translated roughly to “Super Catch-it”, with the original being a 32×16 resolution game with 1×1 blocks as characters.


After a quick look at the code, (1600 bytes), it was clear that I could use PCOPY to avoid screen flicker.
Here is the original routine to draw and clear the graphics.
250 PUT(X*12,Y*15+1)-(X*12+12,Y*15+13),P,PSET
260 PUT(H*12,V*15+1)-(H*12+8,V*15+13),J,PSET
270 PUT(X1*12,Y1*15+1)-(X1*12+9,Y1*15+16),C,PSET
274 FOR A=1 TO 100:NEXT A
275 COLOR 1
280 LINE(H*12,V*15+1)-(H*12+8,V*15+13),PSET,BF
290 LINE(X*12,Y*15+1)-(X*12+12,Y*15+13),PSET,BF
300 LINE(X1*12,Y1*15+1)-(X1*12+9,Y1*15+16),PSET,BF
The wait loop in 274 is to keep the characters visible in the screen for at least some time. I would have assumed that by that time I knew to put all the math between drawing and erasing, but I guess I did not.
Anyway, with page flipping, a simple PCLS is more than enough to clear the graphics, and faster than drawing 3 background colored boxes on top of the characters.
The next thought was to use the variables to store the actual character position in the screen, instead of the positions in the grid and doing math in all the loops.
From PUT(H*12,V*15+1)-(H*12+8,V*15+13),J,PSET
to PUT(H,V)-(H+8,V+13),J,PSET
Then, as the sprites are not the same size, I adjusted their positions so they looked centered in the grid squares, instead of “hanging from the corner”. That is, H starts at 2 instead of at 0 to center the 9 pixels sprite in the 12 pixel grid square.
But, that broke collision detection, since now the player’s H would never match the monster’s X
There are 3 ways to fix this. Doing additional math, with is kind of a waste, use a grid and array to store position – for example, X going from 0 to 20 and storing the screen coordinates for each position in X(19), or redo graphics to make them all the same size, which will affect the look of the game, and probably take more time. Also… who knows if I can get all the characters fit nicely in 12×12?
I guess I could do a mock-up to see… OK this looks good… Damn! I am doing the new graphics
Welllllll, I hope it rains next weekend.

 

 

RetroChallenge #1, part 3. Moving the bytes

As I expected, finding the software was not difficult at all.
Thanks to a USB card reader that is old enough to have Win98 drivers, moving the disk images and ZIP files to my internet impaired P-III was easy.

I was also able to find in some old backup CDs a copy of “HD-COPY”, the “Cardware” program that I used back in the day. It still worked flawlessly, and in a matter of minutes, the disks started to fill.

Some that were not new came out with some bad sectors, but HD-COPY does auto-verify and can low level format the disks if needed. It also auto-detects sequences in the source file names (if you read DOS6-1.IMG and there is a DOS6-2.IMG it will load it automatically), and starts writing to a disk as soon as one is inserted.
Well, not much of an update. All the good floppies I have are ready to be loaded into the Acer.
Using HD-COPY was a nice trip down memory lane. I used to work in a bootleg software store back in the 90’s and I would usually spend hours making disks out of IMG files with it. Again, a great piece of software with many, many options, including the DMF 21-sector, 1.68 MB format that Microsoft used to deploy Windows 95.

RetroChallenge #2, part 3. Challenge completed!

Yes! “Hippo Teeth” is completed!
well, there wasn’t that much left to do, mostly, get the “play again” option working.
The simplest way to do this is, of course, to run the program again, which would be fine since I’m not keeping a high score.
But, as I mentioned before, the background image is being loaded as a file. If you are running an emulator, or using any hard drive solution, this is probably fine, but for a floppy disk system, or even worst, a tape one, a better solution had to be used.
It was then that I remembered that the (C)LOADM command accepts an additional parameter, offset. Using this, I could LOADM the background to the memory range 1537 – 2049, normally used for the high-res modes. Then, at any time, it was just a matter of copying the memory content from there to the 1024-1536 range to have it “loaded” in the visible text screen.
As simple as FOR A=1537 TO 2049:POKE A-513,PEEK(A):NEXT
Then, I needed to restore the vertical position of the worm to the original one. As this is stored in a 3×3 array (3 possible horizontal positions, 3 lines in the graphic) with values that are READ from a DATA statement, RESTORE was clearly an option. I decided to use it, and basically reinitialize the game, going back to the first lines used to set the game variables.
This saved the space that would have been needed to reset the variables somewhere else in the code (I’m still thinking about eventually making a 4 KB version). A CLEAR was needed to make sure all was reset, but also keeps me from implementing a high score or something similar.
Eventually, by rearranging the order in which the variables are initialized, I will probably be able to have a high score list, and some other nice things. I wonder if the game is worth it?
The next step was to tweak the sounds a bit. I have been using the SOUND command, and for a while, I thought about replacing it with PLAY, since I could use just one PLAY to play multiple SOUNDs, saving some space.
I was surprised to find that SOUND can produce higher pitched sounds than PLAY, and PLAY goes lower than SOUND. After going around for a while trying to find the equivalent PLAY to the SOUNDs I was using, I realized that in a CoCo with Extended BASIC (the one that has PLAY), I would have 16 KB as minimum, so saving a few bytes by using a command that would not be available in the 4 KB machines did not make much sense.
Just in case anyone is curious, The closest PLAY equivalent I got to SOUND 150,1:SOUND 100,1:SOUND 50,1 was PLAY”O3L16GC+O2A-“.
Finally, I started compacting the code the usual way. Merging multiple lines in one, removing spaces and remarks, etc. I went from 70 lines with 3825 characters (according to Notepad++), to 37 lines with 3309 characters. Not bad at all.
I kept a copy of the “uncompacted” code, as it will make it easier to work with it in the future.
Well, that is it. The game is ready!
As the gameplay has not changed at all from what is seen in the previous video, I will leave you with the game’s code, the background code, and a DSK file, ready to play.

RetroChallenge #3, part 7. Another one done.

Looks like I could say “It is finished¨. Of course, anyone who ever wrote a computer program knows that you are never finished, but, at least I can say that “Russian Roulette” has been properly “Remixed”.
As I mentioned before, there were only 2 tasks left. I tackled the sound first, and even when the results are not great – there is no way to generate noise from BASIC in the CoCo – I think that they are at least acceptable.
For the “Bang” sound, I changed the original PLAY”V30O2L32CF”, just 2 notes in the 2nd low octave, to V30O1L254T254ACDEFAV20ACDBV10FACD. That is 14 notes in the lowest octave, as short as possible, arranged in a somewhat random fashion to simulate noise. There is also a slight “fade-out” effect by changing the volume from V30 to V20 and finally to V10 while playing.
The “Click” went from PLAY”O5L64;12″ – a single high pitched note – to O5L96T4BABB. Not a great deal, but at least a bit better.
In the original, the sounds will only be played in one place in the code. But as I added computer “players” that can also Click and Bang, I used an alphanumeric variable to store the PLAY string, to save me from typing the whole Bang sound twice.
For the ending, I wanted to do something a little bit fancy, but without going crazy.
I thought about changing the color assigned to the palette entry for the background to do a kind of “fade out” effect, but in the end I went for a kind of wipe-out.
Using 2 FOR/NEXT loops to print spaces with a different background color than the one already on the screen was very simple, and I went to use 2 PRINT statements. One would go from top left to halfway down, and the other from bottom right to halfway up.
But something was not working. For whatever reason, I’ve always ended up with a space in the original background color on the top left.
Eventually, I realized that, regardless of what was PRINTed on the screen, an extra character with the cursor would be placed right after it. Therefore, when I was printing in the bottom right corner (39,23), that extra character would print in the next line, causing the whole text screen to scroll up. This, in turn moved the 2nd top line up (still in the original background color), and caused that “leftover” character.
Since the computer was actually printing 2 characters for each PRINT command, and I should not print on the last position, I changed the loop that tracks the horizontal position to use STEP 2, and to go only up to 38, ending up with this:
510 FOR V=0 TO 11:FOR X=0 TO 38 STEP 2:LOCATE 39-X,23-V:ATTR 0,0:PRINT” “;:LOCATE X,V:PRINT” “;:NEXT X,V
And finally, the simple trick of printing one character at a time for the final message.
520 LOCATE 6,10:FORX=1 TO 25:PRINTMID$(“You are the last survivor”,X,1);:FORL=1 TO 30:NEXT L,X
The reason I did not use the palette fading effect was that I thought to use it for the “death” screen.
In the original, I switched one of the low res screens, set a blue background, and then painted it red from top to bottom by drawing lines.
1130 WIDTH 32:PMODE 1,1:SCREEN 1,0:PCLS 3
1135 COLOR 4
1140 FOR A=0 TO 192 STEP 2:LINE(0,A)-(256,A),PSET
1150 NEXT
I guess I was trying to do something like a veil of blood falling over the player’s eyes…
Looking for colors that would work for a fade from the magenta background to red, I realized that there were not really too many. By changing the default background to a darker shade, I was able to get another one, which is kind of enough for the effect to work.
340 FOR A=1 TO 5:READ P:PALETTE 6,P:FOR W=1 TO 100:NEXTW,A
350 DATA 9,8,7,6,5
Well, that’s it. A second game remixed. I leave you with some screenshots and the listings for both, the original and remixed versions.

This slideshow requires JavaScript.

Ooooppsss! I just figured something out. More than a few times, when it’s the player’s turn, the game will just react as if a key had been pressed, and move on. This seems to be because any key pressed after the INKEY$ is stored in a buffer, and goes is used later. Adding an extra, bogus INKEY$ seems to have taken care of this.
90 A$=INKEY$
95 A$=INKEY$:IF A$=”” GOTO 95

RetroChallenge #3, part 6. Roulette Recovered

As I went back to rewrite what I had lost, at least I remembered most of what I had done. And is not as if it was a great coding challenge. It is quite a simple program.
One of the first things I did was to include multiple computer players. They are quite dumb and will just pull the trigger when their turn is up.
When the game starts, you are asked “How many opponents” from 1 to 5 will play with you.

Then, after you go first, a simple routine takes care of your rivals.
2010 FOR R=1 TO O:CLS:C=C+1:IF C>6 THEN C=1:B=RND(6)
2020 LOCATE 5,5:PRINT”Rival #”;R;” aims and …”
2025 FOR W=1 TO 1000:NEXT:IF CB THEN LOCATE 15,8:ATTR 2,7,B:PRINT”!-CLICK-!”;:ATTR 3,6:FOR W=1 TO 1000:NEXT:NEXT R
2050 IF C=B THEN PLAY”V30O2L32CF”:LOCATE 15,8:ATTR 3,3,U:PRINT”!!!BANG!!!”;:ATTR 3,6:DP=DP+1:C=0:B=RND(6):FOR W=1 TO 1000:NEXT:NEXT R
2090 LOCATE 0,8:PRINT:O=O-DP:DP=0
2100 RETURN.
Having other players gives you the possibility of having a bit of strategy for the game. If the last 4 rivals “click” their shoots, you know that there is a good chance (2 in 6) that your chamber will have a bullet in it. Time to buy a spin, or aim for the floor.
I followed by modifying the “spin” and “aim” routines. Before, the program went back to wait for you to press any key. Now, after you decide to do either action, you shoot.

Finally, it was just a matter of translating and relocating the text.
After a few test runs to tweak and make sure all was OK in the game’s logic, I added a bit of flash when the gun fires. Nothing fancy, just
PALETTE 6,52:PLAY”P32″:PALETTECMP
That makes the background color a light yellow, plays a short pause (does the same as an empty loop, but is far shorter in code), and then restores the original color to the background.

The last two things I want to add are a congratulations screen if you are the only survivor, and better gunshot noises. Probably something like what I used in “Minecamp”
But is already almost midnight. That will have to wait for tomorrow.

RetroChallenge #3, part 5. Roulette

After finishing the “Aliens” Remix, the next game in my list of candidates for a remix may seem a bit odd.
It is probably quite clear, even without a translator at hand, that “Ruleta Rusa” is a simple text based “Russian Roulette” simulation – let’s not call it “game”.
When you run the program, you are told just “It is chamber #1”. When you press a key, it is either “!-CLICK-!” or…. “!!!BANG!!!”.
If you are still alive, then you are also told that you won an extra $10, and now have a total of $40.
But there are a few extra things that you should be told before starting.
You clearly start with $30, and besides making you… not rich, the money can be used to spin the gun’s cylinder – for a mere $40 -or to aim your shoot to the roof – for just $25.
Also, you can walk away at any time. But, if you do it too soon, the audience may feel cheated and shoot you in the back.
After playing the game a few times, the goals of the Remix were clear.

• Show you the available options!
• Change the colors (white text in light blue background, with a green-on-red “CLICK”)
• Add computer players who can get shoot too.
• Translate it to English.

I exported the code to a TXT file, and started editing in Notepad++.
After a while, I moved it to a disk image, and tested it in the “VCC” emulator. It was then that I noticed that text that was supposed to blink, did not blink at all!
Looks like it has been a defect in the emulator that I never noticed before.
So I moved to MAME, kept coding.
After a while, I decided to call it a night. I was, I guess, mostly done.
But when today I was about to start writing this entry, and loaded the disk image… the files had not been saved.
I’m 100% sure I told MAME to mount the disk as “Read – Write”, and even loaded and saved a few times while working. But all is gone now. Just the .BAS file that I wrote in Notepad++ remains.
I guess is back to the keyboard.