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.

[newcoleco]

Hello to everyone (not only Coleco programmers)!!

The following program makes you an expert to compile Coleco projects.

http://www.chez.com/cdi/cci/cci.html

Extract z80.zip (c:\z80) and cci.zip (c:\z80\cci).
Double-click on CCI.EXE in the cci sub-directory and try to compile the Coleco "test" project by following the instructions in the english.txt file.

My friends tested this program. Conclusion : CCI is easy to use.

[Colecovision]

Well i clicked on the link and have no idea what it says.Can anyone translate this to english?Is the site with the info gone?I would really like to start making some new games. :o

[newcoleco]

Which part you didn't understand?

Unzip z80.zip in a z80 folder and cci.zip in a z80\cci folder.

z80.zip include the Hi-tech C compiler, the 22nice emulator, the coleco library and my getput libraries.
cci.zip include the cci software, instructions (english.txt, francais.txt) and test files "test.c" and "music.c".

The frontend software is the CCi.EXE software in the z80\cci folder.

If you have absolutly no idea how to use CCI.EXE, you must read the instructions in the english.txt

But CCI is not a development software... not a debuger... it's a GUI to compile your Coleco projects.

[Aswald]

The maze and all of its elements were done in black, so you couldn't get a sneak peek, heh heh heh...

I found some more notes about the game- detailing combat probabilities, and the final combat with the Basilisk, whose name was "Shadowfang."
In the final combat...
The Paladin-Fox had the advantage of the most Hit Points (32).
The Lumamage-Fox could vanish, maybe (1/3 chance) not taking damage. 18 Hit Points.
The Forester-Fox could dodge (1/4 chance), and had more Hit Points than the Lumamage, but fewer than the Paladin. 24 Hit Points.

Obviously, you had to first reach the lair, after gathering all 3 Globes of the Elements. The Maze Guardians, Elolypas, Ariskyloc, and Arborashadows would try to wear you down. Worse yet, at regular intervals (e.g. 120 turns) the Basilisk would gain a Hit Point, adding to his base of 20. So you can't be reckless, but you also mustn't take too long, or you'll not have any realistic chance of winning. There was also a time limit: once he reached a certain strength, you automatically lost, although you'd have to play for some hours for it to reach this point.

You only played one of the 3 characters in the game. Clearly, you couldn't play them the same way. At full strength, the Paladin could withstand the most damage, while the Lumamage couldn't take nearly as much, so you had to play the latter in a more evasive way. The Forester was in between, as he could sense nearby danger.

In the Settlements, you could see a Healer-Mystic, gamble some Star Gems for more, rest up (time-consuming), or even (at a cost in Star Gems) gather information from a Temple-Oracle; e.g. for 20 Star Gems you could find out exactly where a particular Temple Ruin (Fire, Water, Air) was, while 2 Star Gems would tell you what was in the surrounding N, E, S, W spaces.

[newcoleco]

@Aswald : http://www.adamcon.org/~dmwick/mayan/
This link is like the project you want to do for the ColecoVision, right? It's for Coleco Adam computer and it's based on a MAZE, and the tiles are 4 caracters (like your description).

[Aswald]

Well, my mind's made up- first, I'm going to program a version of this game for the Commodore-64.
Last night, I dug up an old computer, blew the dust off of it, and, after nearly a decade, fired it up. It worked.
Still- I'm a bit rusty. Although a lot of it came back and I still have the all-important Programmer's Reference Guide, I'll need a few days to "get the hang of it" again. Even so, last night I did program a crude version of the game, which even included an Elolypa Combat Sequence. I even found the 4K block of (unused) RAM where I can place the Map and the Mazes!
Barring any catastrophies, there isn't any reason why this game cannot be done long before the CGE 2003. It isn't exactly the most complex or best RPG, but it is a pleasant way to spend a few hours on a weekend.
newcoleco and Digital Press- I'll send you copies once it is finished. But it will be on a tape cassette...

[newcoleco]

No problem. My C64 is always ready for experiment, programming, etc...