newcoleco: HELP!

[Aswald]

Now that I've finally figured out how to run emulators here (more or less...), which emulator should I use to actually program a ColecoVision game? I assume the emulator acts like a "ColecoVision" computer.

[Aswald]

By the by, I managed to dig up some more notes and such from that game, way back when.

For example, each Temple Ruin required you to go through a randomly-generated maze. It was made up of 4 big 8X8 "tiles" that looked like this:

Hmmm...it doesn't work with keyboard characters.
Each tile was 8X8, and a mini-maze, but done in such a way that no matter how you put them together (in a 2X2 fashion), they would properly form one big 16X16 maze. Since which of the 4 tiles to be used in each of the 4 positions was random, there were dozens, if not hundreds, of possible maze configurations. As a result, you never knew what you were in for. Finding the graph paper with those tiles was a real bonus. The globe you were looking for was in any of the 15 border positions (you entered from the 16th), along with life-sucking barriers and a mobile "Monster Guardian." It was still all-text; the maze was placed in a clear area of the Commodore-64's memory used for such things.

[newcoleco]

Sorry .. I don't understand this time.
Please! do a drawing of your idea!

[newcoleco]

About programming ColecoVision :

But before programming, you need to know in which language you will program your game. There is actually two ways to program a ColecoVision game : using the ASM (machine language) or using the ansi C language with a good C compiler for the Z80 processor.

I personnaly use the Hitech-C compiler for the CP/M computer. But I don't use a CP/M computer... no problem, I use a CP/M emulator for DOS named 22NICE.

For the ASM way, there is a problem : choosing a good ASM compiler for the Z80 processor. Each Z80 ASM compiler use a little different mnemonic syntax and/or variation. Norman Nithman used TASM for Tables ASM (not Turbo ASM) and I keep a few source made by him in my Coleco web page.

If you choose the C language solution and you are using a computer PC with DOS or Windows, you simply have to unzip "z80.zip" (this file is in the help page in my Coleco web site) in a folder named z80 (like I said in the help page). This simple step avoid the little compilcated step to adapt the Hitech-C compiler ".com" files to be used with 22NICE. To run the Hitech-C compiler you must start the 22nice emulator first. Open a DOS window and start 22nice emulator. Keep this window open to keep running the emulator in this window. Then, use the compiler in the correct way to compile your project. Test the binary result with any Coleco emulator.

You must test the C (or ASM) compiler before starting programming your Coleco projects.

For the ASM solution, read the information texte file of the ASM compiler to know how to test it.

For the C solution, In the help page, I suggest to compile one of the Marcel de Kogel Coleco projects. By doing this, read the "coleco.txt" (in the Coleco library archive) and do a batch file to use the compiler with the correct parameters. Ok, for the test, I do the batch file for you but you will do your own batch file for your own projects. If you have a problem to use a simple command line env., you may find this a little hard.

There is no easy way to do a ColecoVision game... until someone find one.

[opcode]

Hi,

I think choosing a programming language will depend on the kind of task you are hoping to accomplish. Some games can be done just using plain C language, more understandable, while others will ask for ASM language, more optimizable and controllable. I didn't understand your game idea as well, but I guess it could very well be done using C.
About ASM compilers, I like to use ZASM, the "official" Zilog assembler, since it uses the Zilog documented syntax. I think you can find both (the compilers and docs) on Zilog web site. If you don't, let me know and I send them to you.
Finally, I suggest you using MESS, which I think does have the best emulation of ColecoVision (but never perfect. Beware the VDP access timing issues!)

[newcoleco]

Choosing a good Coleco emulator...

MESS emulator is a good choice!


For PC (DOS/WINDOWS) :

ADAMEM is a very good ColecoVision and Adam emulator for DOS

Meka - I heard there was a bug fixed in the newest version of this multi-emulator (Sega and Coleco emulator for DOS with GUI)

ColemDOS is a good one too but stopped

VirtualColeco is for Windows and also a not very good one. bad sounds! bad graphics rendering! many games unsupported! but I heard there was a TwinGalaxy version a little bit better than the original one.


For Mac (MacOS 7+) :

ColemMac is a good Coleco emulator


.. in fact, try a few emulators and keep the best one for you.

[Aswald]

Well, I'm thinking of an emulator that let's you program a game, more than simply running one- or do they do both?

The maze set-up is a bit hard to explain here, but, once I figure out how to program for the ColecoVision, I can (maybe?) figure it out. Essentially, it's a sub-game in which you look for something in a maze, but instead of seeing the maze, you see text. I put the maze in a clear area of the Commodore-64's memory.

Please remember that I've only just gotten any sort of emulator running, and this is still very confusing to me...

[newcoleco]

The only Coleco computer emulator I know is ADAMEM.

BTW, compiling with a Penitum computer is more faster than on the original Coleco computer or emulator. And beleive me, hitech-C compiler for CP/M is slower than any other C compiler I currently use.

[ManekiNeko]

I'm not talking about the Dilbert guy, either. Twenty years ago a man named Scott Adams created a series of popular text adventure games, each with different themes. The entry level game, Adventure Land, was based on fairy tales and medievel fantasies, while the toughest of the lot, Mission Impossible, was a spy adventure based on the old television series.
I designed one of these games in high school, just for fun, so I might be able to help you out a little. I might be a little rusty, though, considering that I made this game a decade ago.
All right, let's see... the first thing you're going to want to do is create a grid that will hold each of your rooms. If you want to create a maze, what you'll want to do is flag portions of the grid the player can't enter. All this can be done with by dimensioning variables. I don't recall how this is done in C++ but in BASIC you'd do something like this:

DIM RoomStatus (5,5)
Here's what the above statement means. You're dimensioning a variable called RoomStatus to be five spaces tall and five spaces wide, giving you a total of twenty five rooms to use. RoomStatus can be used to determine whether or not the player can actually enter a particular room, using X/Y coordinates. You'll have to define the status of all twenty five rooms to make this work, however. READ and DATA statements make this easy in BASIC, but again, I'm not sure how you'd do this in C++.

FOR Y=1 TO 5
FOR X=1 TO 5
READ RoomStatus (X,Y)
NEXT X
NEXT Y
...
DATA 0,0,1,0,0
DATA 0,1,1,1,0
DATA 1,1,0,1,1
DATA 0,1,0,1,0
DATA 1,1,1,1,1

Basically what the code above does is programs in the information available for every room in the grid, counting from left to right and working down. The numbers in the DATA statements describe sections of the grid... you'll be able to walk in a room marked with a 1 but a room with a 0 is inaccessible. You can make alterations to this if you wanted... let's say keys grant access to other portions of the maze. If there are rooms you shouldn't access without a key, label them 2 instead of 0. That way, the player CAN enter that room once the key is found, rather than being permanently denied access.

More to come!
JR

[ManekiNeko]

All right, where was I...? Oh yes. You can use DIM statements to define other room characteristics, too. You said you wanted a nice, picturesque description of each room instead of actual graphics, and the DIM statement can handle that, too. One of Scott Adam's adventures had a series of rooms without adequate lighting... if you didn't bring a lit torch with you, you couldn't see anything (the descriptions were replaced with "TOO DARK TO SEE"), and one wrong step (typing in a command directing you to a room that didn't exist) spelled your doom. This and other features can be accessed with more dimensioned variables.
Now items inside these rooms, on the other hand, should be given coordinates so they can be moved from place to place. That includes yourself and any enemies you may encounter along the way. Let's give your party of foxes the variables FoxesX and FoxesY. If you wanted to start them at the top of the maze created in the last example, you'd enter this at the beginning of the program:

FoxesX=3
FoxesY=1

And let's say that orb of light could be found at the lower right hand corner of the screen. You'd put this in the program too:

OrbX=5
OrbY=5

Every time you moved from room to room, the foxes' coordinates would change accordingly. If you wanted to head east, you'd add 1 to the value of FoxesX, and if you wanted to move west, you'd subtract 1 to the value of FoxesY. Of course, you'll need to have safeguards to ensure the band of foxes won't step into a room that doesn't exist, or worse, outside the boundaries of the maze. That's where IF statements come in.

IF JOYSTICK=LEFT AND FoxesX>1 AND RoomStatus (FoxesX-1, FoxesY)=1 THEN FoxesX=FoxesX-1

Joystick is a fake command just to give you an idea of what I'm talking about (no two computers seem to use the same BASIC commands for joysticks, graphics, or sound). Everything else should be valid, though. What the above line is basically telling you is this:

[ManekiNeko]

(sorry, lost my keyboard input for a second there)

If:

* the player presses left on the joystick
* the band of foxes will not move outside the playfield
* and the band of foxes will not walk into a solid wall

The foxes may proceed to the room to the left.

The other bonus of having X/Y coordinates for the foxes is that these coordinates can be used to describe the characteristics of a room quickly and without much trouble. Let's say you dimensioned a string containing descriptions of every room. Instead of having to test twenty five times to determine where the foxes are, you can just do this:

PRINT RoomDescription$ (FoxesX, FoxesY)

That should give you an idea of what you'll need to do to design your program, if you didn't know all this stuff already.

JR

[Aswald]

Thanks for the advice, but...I already did program this game for the Commodore 64, about 15 years ago. I've only just dug up the graphs and maps, as well as probabilities and such, recently.

Maybe I'm going about this the wrong way. Maybe I should just re-program the game on a Commodore 64.

The problem I'm having is not how to program the game itself, but how to do it on the completely different ColecoVision. Commodore 64 know-how seems to be largely useless.

At the beginning of each game, the main Island map was PRINTed onscreen, in black, so you couldn't see it. A subroutine then scanned it, and placed it into a "blank" area of the C-64, out of the way.

You then moved about, using...well, it involved PEEK commands, but essentially it let you move in the eight directions. Whether or not you could move somewhere, or what you found, was based directly on what was in that space: for example, "character 232" simply meant that there was a meadow there, so the computer would PEEK, "see" character 232, and then go to the subroutine that scanned it all, and then tell you that you were in a meadow (that was it). No matter where the "characters 232" were, this would happen every time. If, on the other (paw), character 233 was there, that meant it was a meadow with an Elolypa; the computer would tell you you were in a meadow, and that you had encountered an Elolypa. It would then go to the combat subroutine, dealing with Elolypas. Your actual coordinates had nothing to do with it; they only moved you about.

The mazes were similar once they were set up.

[newcoleco]

For caracter graphics (tiles), the video chip fix a color for the caracter so you can't do a red "A" and a blue "A" by using the same caracter.

So, for your example of a hidden maze, you have to reserve a set of caracters to be invisible (or the same color as the one for the background). The other solution is to set an array of memory space to be the maze but there is not enough RAM for a big maze. The other solution is to use a basic graphic mode to let you use the unused video memory space like extra RAM space for your maze.

I think Eduardo can explain these solutions much better than me.

[Aswald]

In the Commodore 64, there were actually large portions of memory that were blank.
When you look at the screen on any computer, you are actually "seeing" a portion of the memory. PEEK commands simply allowed you to find out what was in a particular memory location. In the case of the Commodore 64, there was more than one such area, consisting of 1000 memory locations (on screen, it was shown as 25X40). There was actually a command that allowed you to shift your view from one portion to the other, sort of like moving a camera from one room in a house to another room. Thus, you could set up 2 full screen mazes at once, and by using that command shift your view from one to the other.

So, at the beginning of my game, I "drew" the maze using PRINT commands- an old trick- and then scanned the entire screen using a subroutine that copied the maze onto that other portion of the memory- The "second screen"- it was just as big. Once this was done, the text could be displayed normally.

For Island of Foxes to work on a CV, I would need a completely unused block of memory 768 Bytes ("spaces") long, other than the portion you "see," to hold the main map. I would also require an area large enough to hold the lesser mazes, one at a time- an area 18X18 or 324 Bytes long. As long as 2 such areas are available, in a place that will not be messed up in any way, then the game can be done. I would have to know what the CV equivalent of a PEEK command is; clearly, Amazing Snake uses such a thing- in fact, the basic methods used in Amazing Snake- including randomization- are just what I would use! Imagine the playfield of Amazing Snake as the main map, with the barriers, apples, cherries, and brick borders as different things to interact with- same thing.

How to Turn a 2-D maze into a 1-D maze:

The idea of a maze on a computer screen is only an illusion. In any computer, all information is stored in a string of memory; in the case of a C-64, it's just arranged on screen in a 25X40 block. This is why, when you move the cursor to the right- adding 1 to its current position- it goes down a row when it reaches the right edge.
For example:

XXXXXX
X____X
XXXX8X
X____X
X_XXXX
XXXXXX

This is a 6X6 maze. To move left or right, you subtract/add 1 to your position. To move up or down, you subtract/add 6.

But, look at it as a string:

XXXXXXX____XXXXX8XX____XX_XXXXXXXXXX

Go ahead- add or subtract 6 or 1. You'll always end up in the same spaces as with the "2-D" maze. To the computer, this is what the maze really looks like, so you don't have to draw it in a 6X6 block- a string 36 characters long will do, which, on a Commodore 64, wouldn't take up one "row."

It's really not that difficult a game to program IF you know how to program on a ColecoVision- which I don't. Most likely, I'd use "C"- it looks the easiest.
Where might one find an instruction manual?

[newcoleco]

I can explain to you the example "test.c" I write here in this forum.. this way you will learn a little of C language and Coleco tricks.

First, a C program is a set of sub-routines and functions. The program start by running a routine named "main".

NOTE : In C language, the case for the letters is very important.

I use the "main" to call each sub-routines I need to execute properly my program. I don't code directly my game into the "main" routine. It's way I preffer to call a sub-routine named "game" to code the game engine. Before calling "game" it's important to init graphics and some global variables in the "main" routine. In my project, my "main" routine call a set of routine to init the graphics and the variables (calling a "menu" routine) before starting the game engine.

In my "test.c" example, you see many /* and */ .. it's like REM in BASIC. They are here to inform the programmer. I use the /* and */ at the end of the "test.c" to let you know which extern routine I call to avoid re-coding a set of asm instructions in my C code.

If you have questions, contact me on MSN and/or Yahoo Messenger.
nickname ? newcoleco, of course

[newcoleco]

For Island of Foxes to work on a CV, I would need a completely unused block of memory 768 Bytes ("spaces") long, other than the portion you "see," to hold the main map. I would also require an area large enough to hold the lesser mazes, one at a time- an area 18X18 or 324 Bytes long. As long as 2 such areas are available, in a place that will not be messed up in any way, then the game can be done. I would have to know what the CV equivalent of a PEEK command is; clearly, Amazing Snake uses such a thing- in fact, the basic methods used in Amazing Snake- including randomization- are just what I would use! Imagine the playfield of Amazing Snake as the main map, with the barriers, apples, cherries, and brick borders as different things to interact with- same thing.

768 Bytes? that too many for the RAM. You will need to use an unused video RAM space for that.

If the 324 Bytes are only caracters showed on screen (not to be in memory too), there is no problem to do something like "POKE " and "PEEK", my getput library have two (2) routines named "get_char (x,y)" and "put_char (x,y,char)" specific to get and put caracters on screen (one at a time). "get_char" and "put_char" are firsts usefull routines/functions I programmed, it's why my library is named "getput"

Serge-Eric Tremblay used my getput library to quickly program his game Amazing Snake.

[Aswald]

Just as long as a section of memory 768 Bytes (spaces) and another 324 Bytes (spaces) long are available somewhere, other than the on-screen (the part you "see") is available somewhere, then it works. It just has to be able to have numbers placed in them, and changed, and PEEKed, as needed. You never actually see these areas on the screen.

[newcoleco]

ok... so, if you don't need too many ram memory space for the variables (memory spaces to do operation or to modify sometimes like A=A+5 or A$="TATA"...A$="TOTO") in your program, you can put the "324 bytes" somewhere in the little 1k RAM available.

I forgot to tell you this :
Avoid using numbers with decimals like "3.02" ... use only "integer" [-32768,32767] or "byte" [0,255] or "char" [-128,127]. This warning is for any projects you want to do for old processors like z80.

[Aswald]

Never once in my entire life have I ever programmed a game that used "3.02"- only integers (1, 35, 102, etc.), so not using decimals is no problem at all.

In a Commodore 64, the on-screen portion- the part you see on the screen- was from memory locations 1024 to 2043 (1000 spaces). The problem was that this, of course, is where the text will appear- as in Zork and your own "Chateau Du Dragon." Therefore, no map can be here while the game is being played. This is why, at the very beginning, I would first set the map up using PRINT statements (again, an old trick), and then, using a subroutine, copy the map onto another portion of the memory. There were several such clear areas in a Commodore-64, in fact, it actually allowed you to completely set aside portions of memory from the BASIC!
In other words, once the copy was made, the first one was erased. This allowed text to be placed on the screen; the map was safely tucked away elsewhere in memory. In order to make "Island of Foxes" work on a ColecoVision, I would need 768 BYTES of memory for the main map, 324 for the lesser mazes, and a small portion to be used in place of variables (instead of A=23, I would POKE 23 into such a location, add or subtract to it as needed, and reference it using PEEK commands- nothing ever went over 255, so one space was enough for each). These "blocks" can be ANYWHERE in the memory, just so long as I can change the values in each memory space, and check their values with PEEK commands, AND nothing affects those spaces, except for me.
The example I gave above, with the 2-D and 1-D mazes, shows what I have in mind. I've been able to do it on a Commodore-64; can it be done on a ColecoVision?

[Sly DC]

hi! It's Daniel (newcoleco)... I'm using Slydc's computer.

Yes, you can do this for the ColecoVision!

But, for a first try, may I suggest you to code a static MAZE in the ROM and try to show it on screen like your program for C=64?

And, good news, my new front-end to compile a Colecovision project is done but still in beta version. I need someone who use a Windows 2000 or XP (english version) to test it. I will release this front-end after this last test.

If you want to test the front-end I'm talking about, write me a personal message here with your e-mail address. Warning, the zip file size is more than 550KBytes.