c99 - getting started?

[Tursi]

You do need interrupts for sprite motion to happen. I can't explain the compiler error on inon(), that's not a part of grf1, is it? Just try a different function name?

[Willsy]

 

while (c!=81)

{

c=key(0,&s);

if (c=="E") up();

if (c=="X") down();

if (c=="S") left();

if (c=="D") right();

/*inon();*/

}

 

I could be wrong here. C isn't really my bag. The code above appears to read that you are trying to compare a char ('E' 'X' 'S' and 'D') to the integer c. Should you not be using a cast?

if((char)c=='E') up();

 

etc?

 

As I say, I'm probably wrong. I haven't done any C for years. I just have a (possibly mis-guided) dim and distant memory that a character in quotes returned a char. It would be worth looking at the assembler source that compiler emits for this section of the code. That will tell you if there's a type conversion issue.

 

FWIW!

Edited March 31, 2015 by Willsy

[+mizapf]

I don't know much about c99; in "real" C you would have to use single quotes ('E') instead of double quotes ("E"). In worst case, the equality could be checked against the address of the string constant "E". (Apart from the fact that there are no strings in standard C, well, maybe today, don't know.)

[Tursi]

You're both sort of right, and I didn't notice the quotes. That's probably the biggest issue -- (c == "E") - this defines a static const string "E", and returns the address in memory of it. 'c' is a char, of course. c is promoted to 16-bits and compared against the address that the string was stored at, which won't match, guaranteed. So, yes, single quotes for single character comparisons.

 

You don't need to cast to compare chars to ints, and in fact in K&R C, which this is, you almost never need to cast, it just assumes you know what you're doing and does whatever it wants with it. But char against int was always defined behavior (most compares against a larger size are - the smaller size is expanded to the larger and then the compare happens).

 

That said, actually using a cast without knowing you need it is dangerous, because it turns off some of the type checking. You are telling the compiler "I know what I'm doing", so you better. The rule of thumb is don't cast. If you get a warning about mismatched comparisons or assignments, see whether you are using the wrong variable type in the first place. After deciding that yes, this is the right way to go, then you can consider a cast. (And modern C++ even made casting complex with new cast declarations that preserve type checking, go figure. ).

 

You still need that interrupt call to work before it will move, though

[+mizapf]

During my works in MESS, when they switched to C++, I had to learn the differences between static_cast, dynamic_cast, and reinterpret_cast, the latter one being the ultimate "I really know what I'm doing, don't tell me stories about subtypes and inheritance...".

[+hloberg]

FYI: I tried in non-cast with the char numbers c==89, c==67 etc.. still didn't work. I tried it this way from an example in on the the C99 tutorials.

I'll try the interrupts coding and see if I can't figure out the error.

thanks

[+hloberg]

fixed it!

1.) should read the docs closer needed spmct(2); this tells the program which sprites are allowed motion 0>x-1

2.) This part doesn't make sense but you have to also define the size of the spites or no motion spmag(2); .

3.) Fixed the error with the embedded assembler. forget the space before LIMI.

4.) Also changed the 'if' commands to compare int i.e. c==89. I got the other way c=="X" from one of the tutorials. It looked fishy to me but I thought I would try it. also going to stay away from cast, outcome too unpredictable.

Corrected program below.

 

Note on C99. Starting to like it. With the funnelweb integration it easy to compile. It's also very powerful for such a simple version of 'C'. It is quirky though.

 

#include "DSK1.GRF1RF"

/*loaders CSUP,GRF1*/

#define sng -10

#define spo 10

main()

{

int c,s;

c=0;

grf1();

clear();

spmag(2);

sprite (0,88,5,100,125);

spmct(2);

inon();

spmotn(0,10,10);

while (c!=81)

{

c=key(0,&s);

if (c==69) up();

if (c==88) down();

if (c==83) left();

if (c==68) right();

inon();

}

}

up()

{ spmotn(0,sng,0); }

down()

{ spmotn(0,spo,0); }

left()

{ spmotn(0,0,sng); }

right()

{ spmotn(0,0,spo); }

inon()

{

#asm

LIMI 2

LIMI 0

#endasm

}

Edited March 31, 2015 by hloberg

[+OLD CS1]

C99 looks interesting. Your code makes for a good bit of a primer.

[+Lee Stewart]

Did you try the suggestions of using “if (c=='E') ...”? That should work and it is definitely clearer.

 

...lee

[Tursi]

That spmag() is required for motion is definitely fishy... when you get more comfortable you might want to look into why that is..

[+hloberg]

C99 looks interesting. Your code makes for a good bit of a primer.

changing jobs, but as soon as things calm down Ill start putting a blog of the creation of megamania in C99 as a tutorial.

creating the game will cover all the basic from graphics to sprites to sound.

[+hloberg]

Did you try the suggestions of using “if (c=='E') ...”? That should work and it is definitely clearer.

 

...lee

I just caught that, your right. Still getting used to the difference between " and ' in C

[Gazoo]

changing jobs, but as soon as things calm down Ill start putting a blog of the creation of megamania in C99 as a tutorial.

creating the game will cover all the basic from graphics to sprites to sound.

 

That sounds wonderful. Every time I've looked at C code it just looks like a bunch of IF - THEN jibberish, makes no sense.

Is there a way to convert it to Assembly code before assembling it, so it would be readable and I could make some sense of it?

 

Gazoo

[+hloberg]

Anybody wanting to play with C99 here's a quick "how to compile".

First, get a copy of the C99 with funnelweb. It makes life much easier.

Start the funnelweb under XB or E/A and choose the Assembler portion.

Cut/Paste my code in to the editor and save as SPRITES/C. I've also seen people use ;C and -C for the extension.

now choose the 'C-compler' from the main menu. your input file 'SPRITES/C' will automatically be filed in. But be sure to change the output file to SPRITES/S for the assembler source code.

If no errors (there shouldn't be if you cut and pasted correctly) start the assembler. The input (source) file will filed in with SPRITES/S and output (object) SPRITES/O. change the (option) switches to just C from RC then compile.

Again no errors you choose Loaders and then Load/Run. The name of the object file SPRITES/O is already entered so press Enter. Now you add the libraries which (in my case) are on DSK1 so type DSK1.CSUP Enter (this is the library that has all the basic run time directives), and DSK1.GRF1 Enter. Now Alt+3 to exit.

All the subroutines will be listed on the screen. Arrow over to START and press Alt+6.

The program should start.

Q exits then Alt+9

that's it.

Edited April 1, 2015 by hloberg

[+hloberg]

 

That sounds wonderful. Every time I've looked at C code it just looks like a bunch of IF - THEN jibberish, makes no sense.

Is there a way to convert it to Assembly code before assembling it, so it would be readable and I could make some sense of it?

 

Gazoo

The code compiles to Assembler. It an extra step to compile object but makes debugging much easier.

[+hloberg]

Every time I've looked at C code it just looks like a bunch of IF - THEN jibberish,

gazoo

 

Oh yes, If ... Else if... Else if... going on for several levels, It can be a bit of a challenge to keep straight.

Don't even get me started about pointers, unions and the like. Still, I'm starting to like it.

[+hloberg]

I'm going to transfer this to a blog soon and describe in more detail what is going on but here is a short program I wrote that's like the 'lines' demo program from the (If I remember right) Mini-Memory module.

It uses the bit-map mode and works fairly well. However there is a bug in the 'line' routine that makes a bit of a mess after you rewrite over the same area too many times but to fix (it looks to me) would require a rewrite of the 'line' routine in assembler and I'm not there yet.

 

below the program is the some docs from GRF1 graphics lib and bitmap lib to show what C99 can do.

 

Here it is:

Concept: draw 5 lines in a row then write over the sixth with blank line. continue so that it looks like only 5 lines trailing around the screen.

when at edge bounce the other direction. randomly change the color.

#include "DSK1.BITRTN" /* This is the bitmap lib. Note: I put all my libs on DSK1 with the funnelweb to simplify thing */

#include "DSK1.RANDOM;C" /* random # lib */

#include "DSK1.GRF1RF" /* graphic package. only need here for key() */

#include "DSK1.STDIO" /* standard I/O, I probably didn't need this */

/* LOADERS DSK1.CSUP,GRF1 */

main()

{

int x1,y1,x2,y2,lc,k,s; /* declarations area */

int my1,my2,mx1,mx2,cnt;

int maxy,maxx,mn;

int ay1[100],ay2[100],ax1[100],ax2[100]; /* this is arrays */

maxy=170;

maxx=230;

mn=22;

ay1[0]=ax1[0]=ay2[0]=ax2[0]=1; /* you can define several variables at the same time this way */

randomize();

/*set rnd loc & clr*/

x1=(rnd(090)+40);

x2=(rnd(080)+50);

y1=(rnd(30)+20);

y2=(rnd(80)+100);

lc=(rnd(14)+2);

/*set rnd move*/

my1=(rnd(20)+1);

my2=(rnd(20)+1);

mx1=(rnd(20)+1);

mx2=(rnd(20)+1);

bitmap(16, 5); /* this turns on bitmap */

bitclr();

/* chk key to end & main loop*/

s=0;cnt=1;

while (s==0 || cnt<=99) /* check if key pressed or have looped 99 times to end */

{

k=key(0,&s);

line(x1, y1, x2, y2, lc);

y1=my1+y1;

y2=my2+y2;

x1=mx1+x1;

x2=mx2+x2;

if (x1>=maxx || x1<=mn) /* is line > maxx or less mn*/

mx1=-mx1;

if (x2>=maxx || x2<=mn)

mx2=-mx2;

if (y1>=maxy || y1<=mn)

my1=-my1;

if (y2>=maxy || y2<=mn)

my2=-my2;

if (rnd(10) >= 8 ) /* randomly change color and slightly change maxx, mn so that don't go over same territory again and again */

{

lc=(rnd(14)+2);

mn=(rnd(5)+20);

maxy=(rnd(10)+160);

maxx=(rnd(10)+230);

}

ay1[cnt]=y1;

ax1[cnt]=x1;

ay2[cnt]=y2;

ax2[cnt]=x2;

cnt++;

if (cnt >= 6) /* look to see if drawn 6th line then from there on write over lines > 5 with blank */

{

line(ax1[cnt-5],ay1[cnt-5],

ax2[cnt-5],ay2[cnt-5],5);

}

}

grf1(); /* on exit reset to char mode and standard char set or get real mess */

chrset();

exit(0);

}

Functions available in GRF1 :.

grf1();.

Set to graphics 1 mode (24x32 characters). Load standard

character patterns. Character colors set to black/transparent,

backdrop set to cyan..

text();.

Set to text mode (24x40 characters, no sprites). Load standard

character patterns. Screen set to black/cyan..

screen( c );.

Set screen (backdrop) color to c..

color(cs,f,b);.

Change colors for char set cs to f/b..

chrdef(ch,str);.

Define character pattern(s) starting at character ch. Up to 4

characters may be defined with one call. str is either a quoted

string or a pointer to a string consisting of 1-64 hex (0-9, A-F)

digits. Incomplete patterns are zero-filled..

chrset();.

Load standard character patterns..

patcpy(a,b);.

Copy the pattern for character a to the pattern space for

character b. This function is provided instead of Ex Basic's

CHARPAT..

clear();.

Clear the screen..

hchar(r,c,ch,n);.

Place character ch at row r, col c and repeat n times

horizontally..

vchar(r,c,ch,n);.

Place character ch at row r, col c and repeat n times

vertically..

c=gchar(r,c);.

Return the value (int) of the character at row r, col c..

s=joyst(u,&x,&y);.

Read joystick u (1 or 2) and return the x and y values (0 , +4,

or -4). s is true if x or y != 0..

c=key(u,&s);.

Read keyboard u (0-5) and return char value c and status s (-1,

0, or 1)..

sprite(spn,ch,col,dr,dc);.

Define sprite number spn with char ch, color col, located at

dr,dc..

spdel(spn);.

Delete sprite spn..

spdall();.

Delete all sprites and clear automotion table..

spcolr(spn,col);.

Set sprite spn to color col..

sppat(spn,ch);.

Set pattern for sprite spn to char ch..

sploct(spn,dr,dc);.

Locate sprite spn at row dr, col dc..

spmag(f);.

Set sprite magnification to f (1-4)..

spmotn(spn,rv,cv);.

Set row velocity rv and col velocity cv for sprite spn..

spmct(n);.

Enable automotion for the first n sprites (numbers 0 to n-1)..

spposn(spn,&rp,&cp);.

Return row position rp and col position cp for sprite spn..

dsq=spdist(spn1,spn2);.

Return the square of the distance between sprites spn1 and spn2..

dsq=spdrc(spn,dr,dc);.

Return the square of the distance between sprite spn and location

dr,dc..

flg=spcnc(spn1,spn2,tol);.

Returns true if the distance between sprites spn1 and spn2 is <=

tol..

flg=spcrc(spn,dr,dc);.

Returns true if the distance between sprite spn and location

dr,dc is <= tol..

flg=spcall();.

Returns true if any sprites are in coincidence..

 

 

INCLUDED IN THE BITRTN FILE:

bitmap(fore,back)--must be called first to change the screen configuration from

text mode (used by c) to bitmapped mode. The arguments are respectively the

fore and background colors selected for the screen default.

bitclr() clears the entire screen, but does not change any color defaults. If

you wish to modify screen color defaults, the bitmap() call can be repeated.

plot(x,y,color)--will turn 'on' a single pixel at the screen location

indicated.

line(x1,y1,x2,y2,color)--draws a line of the specified color between the points

indicated.

rect(x1,y1,x2,y2,color)--draws a rectangle with opposite corners at the points

indicated.

INCLUDED IN THE BITWRT FILE:

bitxt()--call this function once, before calling bitmap(); this function copies

all ascii character definitions into a buffer in CPU ram.

bputch(ascii,row,column,color)--places the character at location indicated

bputs(row,column,color,str)--places text on the screen in 24x32 format (works

similar to 'puts()' in normal c).

Edited April 1, 2015 by hloberg

[+hloberg]

restarted the blog http://atariage.com/forums/blog/528/entry-11894-from-c99-getting-started/

as I do more I'll add to it.

[Willsy]

Nice. Great to see C99 being used again. I did a sprite designer in C99 and I was delighted at how it turned out. There's a video of it on you tube. Search for TI-99/4A Sprite Designer and it should come up.

[+hloberg]

Nice. Great to see C99 being used again. I did a sprite designer in C99 and I was delighted at how it turned out. There's a video of it on you tube. Search for TI-99/4A Sprite Designer and it should come up.

will do and add to my blog

[patrickmcmichael]

Well, when you want it, send me your mail address.... I'll email you Forth and the reference guide for it. Also, have you played "Honeycomb Rapture?" It's pretty fast for an XB game and it's got some cool assembly music support with it. You can DL it from the TI Gameshelf or from my site.

 

I was browsing the TI Gameshelf tonight. If a file is in .DSK format (say SKI99.DSK) - does that mean it only runs on the emulator? I am already enjoying many of the FinalGrom99 cartridge.bin files, which is cool. But I'd love to get my hands on some of the things I had on floppy back in the day to run natively on TI vs on an emulator. How do I get a .DSK file back to native TIFILES format?

[twoodland]

I use Fred Kaal's TI99DIR.

[RickyDean]

You can also use mizapf's TiImageTool which will run on PC's and mac's I believe, also you could use a floppy emulator like an HxC or a Gotek and run the image as a floppy on your system, using a usb thumb drive or SD card. There is a lot of info here on Atariage, on how to do so.

[+mizapf]

How do I get a .DSK file back to native TIFILES format?

 

Your question confuses me slightly, since I would not consider TIFILES to be "native" in any sense. It is the storage format for single TI files on a PC file system. The DSK files are complete disk images. You could as well ask how to get a ZIP file back to native DOC. :-)

 

As already said, you can use TIImageTool: Open the DSK, select all files by mouse or CTRL-A, drag and drop to your target folder on your PC, there you go. (You can adjust the target name creation in "Preferences/Exporting").

[patrickmcmichael]

Your question confuses me slightly, since I would not consider TIFILES to be "native" in any sense. It is the storage format for single TI files on a PC file system. The DSK files are complete disk images. You could as well ask how to get a ZIP file back to native DOC. :-)

 

As already said, you can use TIImageTool: Open the DSK, select all files by mouse or CTRL-A, drag and drop to your target folder on your PC, there you go. (You can adjust the target name creation in "Preferences/Exporting").

I may’ve misread this, but I was going by this description:

 

“1- TIFILES format which is native to the TI 99/4A computer, which means that they will run directly on a real TI 99/4A machine as well as on the Classic 99 emulator. These files are appended with the .bin extension, and you will need to remove that extension prior to using the files. In addition, some of these files are archived, and those will have a filename ending with arc. You will need to use Barry Boone's Archiver to expand them.”

 

I took that to mean that minus the .bin extension, these were native TI files. As for the .DSK files, I was going off of this:

 

“2- Emulator .DSK format. This format will run using the V9t9, Classic99 and MESS emulators. In some browsers, you might have to right-click on the link and select Save Link As to save the file to disk. These files will also run using the Win994a emulator if you change the .DSK extension to .TIDISK . For those of you using the PC99 emulator, the .DSK files can be converted to PC99 format using Fred Kaal's TIDir program.”

 

I had not gathered from that that these were multi-file bundles, but simply that they were tailored for emulators.