Jump to content
xahmol

Developing LUDO game for TI-99/4a in C

Recommended Posts

Looked at that existsFile function from Force Command, but see that it is depending on a LOT of other routines such as mds_lvl3_dsrlnk instead of the normal dsklnk (which again uses mds_lvl3_dsrlnkraw......) . Was stubborn and tried the normal dsklnk, but that indeed does not work in detecting if a file is there or not (always returns the same). And want to avoid having to include half of the Force Command DSR code just to do this. That is way overcomplicating things compared to the alternative to just support DSK1 alone.

Suggestion to Matt: your Force Command DSR routines look great. Of course completely your call if you want to spent time on it, but would love to see a file operations C lib based on it, cleaned from Force Command dependencies and that banking magic you are doing there. For now, that is too big a job for me with my very limited knowledge on what actually goes on in how DSR things work on the TI. Would also be strange and hard to maintain if I would do a lib based 100% on your code. But love your code!

 

So for now, have fallen back to support boot tracking for DSK1, DSK2 and DSK3 only and revert to DSK1 if anything else is found. That should cater for most use cases I guess if TIPI users are used to DSK1 mapping anyway.

Doing it more advanced otherwise gets a project on its own (and also would hate to ask for user interaction on the file path).

With that it works now over here in both emulators as my real hardware, also when using call tipi("TIPI.LUDO.LUDO") to start.

 

Will do some more playtesting and than will post a new beta release also here.

Edited by xahmol
  • Like 2

Share this post


Link to post
Share on other sites

The direction I am taking Force Command is that the cart is the runtime library. The examples/gcc folder shows what I am playing with..  For example, the FTP client is a ForceCommand executable that loads and calls back into the exposed cartridge API.

 

The plan is to work out what of the internal routines I have should be in the exposed API, test them in that context, and then roll ForceCommand to 2.0. I also want to provide useable SAMS memory management features before 2.0. Probably sometime late this year.

 

My fileExist routine might be suffering quirks of TIPI. TIPI supports some exploits of old hard drive simulating DSK1. files.. If level3 io and target file doesn't exist, it returns 0-skip, allowing traditional DSRLNK to proceed to asking the next device. It is probably a bug that I suspect it also does this for TIPI paths instead of only for mapped drive paths. The DSRLNK in ForceCommand doesn't search across cards. My fileExist routine is probably dependent on that.

  • Like 2
  • Thanks 1

Share this post


Link to post
Share on other sites
2 hours ago, jedimatt42 said:

The direction I am taking Force Command is that the cart is the runtime library.

Sounds great! Will follow with great interest!

Share this post


Link to post
Share on other sites
On 4/6/2021 at 10:01 AM, xahmol said:

Oh, and the other workaround I needed is that cputc() and cputcxy() do not work for non-printable characters (values under 32).

Not sure how it is meant to work in ANSI C, but in CC65 for the targets I coded for that does work for all values between 0 and 255.

Needed that as I do use patterns with codes from 0 to 31, so used a direct vdpchar() from Libti99 instead.

I don't really care what ANSI says to do... but the implementation handles control codes (backspace, form feed, newline, tab) -- are you saying that conio normally does NOT do that?

 

I was pretty sure I used a cc65 reference document to write it, but it's been a while. Also possible I was assuming. ;)

 

 

Share this post


Link to post
Share on other sites
13 hours ago, Tursi said:

I don't really care what ANSI says to do... but the implementation handles control codes (backspace, form feed, newline, tab) -- are you saying that conio normally does NOT do that?

 

I was pretty sure I used a cc65 reference document to write it, but it's been a while. Also possible I was assuming. ;)

It does handle control codes, but that was exactly what I was not expecting it to do ;-)

And unsure if it is an incorrect implementation of conio on the Oric Atmos target or not, but it was pretty handy to be able to use cputc to just copy an attribute code to the screen instead of the ASCII control code for the codes under 32.

 

Just did check the CC65 reference documentation, and I actually think you are right. It does not explicitely say so, but as it states there that it supports \n and \r, I am now pretty sure that indeed cputc is supposed to output the control code instead of just copying the value itself to the screen position. 'Like all other conio output functions, cputc distinguishes between \r and \n.'  https://cc65.github.io/doc/funcref.html#cputc

 

Then it is just a damn handy incorrect implementation on the Atmos target of conio.h..... Actually curious now what it then does on the Commodore 64/128 target. On Atmos target, behaviour of cputc is indeed different.... but tend to agree with you now that is actually an incorrect implementation.

Hope now they never correct that Atmos implementation as that would directly break my code, used it extensively to copy color attribute codes to the screen which on the Oric are values under 32 and take a character position instead of going to separate attribute memory...... Funny how every retro computer has its completely different quirks to handle color. You really never can make assumptions coming from another target.

 

Anyway: I then assume that vdpchar() is really the only correct way to print user defined patterns numbered under 32? Not really a problem, just needs vdpchar(gImage+x+32*y,c) instead of just cputcxy(x,y,c). And need of reminding yourself that vdpchar() does not take care of the cursor position so is only a cputcxy replacement and not a cputc.....

Edited by xahmol

Share this post


Link to post
Share on other sites

Added new version which I hope could be the release version. See ZIP and changelog in startpost. Added speech and boottracking.

  • Thanks 1

Share this post


Link to post
Share on other sites
On 4/9/2021 at 4:05 AM, xahmol said:

It does handle control codes, but that was exactly what I was not expecting it to do ;-)

And unsure if it is an incorrect implementation of conio on the Oric Atmos target or not, but it was pretty handy to be able to use cputc to just copy an attribute code to the screen instead of the ASCII control code for the codes under 32.

 

Just did check the CC65 reference documentation, and I actually think you are right. It does not explicitely say so, but as it states there that it supports \n and \r, I am now pretty sure that indeed cputc is supposed to output the control code instead of just copying the value itself to the screen position. 'Like all other conio output functions, cputc distinguishes between \r and \n.'  https://cc65.github.io/doc/funcref.html#cputc

 

Then it is just a damn handy incorrect implementation on the Atmos target of conio.h..... Actually curious now what it then does on the Commodore 64/128 target. On Atmos target, behaviour of cputc is indeed different.... but tend to agree with you now that is actually an incorrect implementation.

Hope now they never correct that Atmos implementation as that would directly break my code, used it extensively to copy color attribute codes to the screen which on the Oric are values under 32 and take a character position instead of going to separate attribute memory...... Funny how every retro computer has its completely different quirks to handle color. You really never can make assumptions coming from another target.

 

Anyway: I then assume that vdpchar() is really the only correct way to print user defined patterns numbered under 32? Not really a problem, just needs vdpchar(gImage+x+32*y,c) instead of just cputcxy(x,y,c). And need of reminding yourself that vdpchar() does not take care of the cursor position so is only a cputcxy replacement and not a cputc.....

I find it a little bit satisfying to read that the decisions I had to make to figure out how to map this stuff onto a Forth system can be just as challenging in C.  Somehow in my imagination I thought C, with more history, would give you function names or some kind of commonly used templates to do this stuff.  It seems from an outsider perspective to be at about the same level as Forth.

 

For what its worth I ended up making a function in assembler vpos(x,y) that computed the screen address and it uses the current gImage  and line-length ( 32,40 or 80 chars) under the hood.

Not sure if that kind of micro-factoring is done in C but it was useful to me as a common factor for some of the other stuff.

Share this post


Link to post
Share on other sites

Haha, well, C is old and mature, but C on 8 bits with cross compilers much less so 😉

CC65 is relatively mature for Commodore targets. But many other targets are fairly recent. And also C cross compilers on the TI are a fairly recent thing if I read this forum, with libs getting developed basically by the need of somebody who misses them while programming.

So it’s getting there, but you always encounter surprises coming from target to another target. But honestly, that is a large part of the fun doing it 😉and coping with playtesting the same game all over again. The fun is solving problems you encounter on a new target, if just copy paste compile for new target would work all the fun would be gone.

  • Like 1

Share this post


Link to post
Share on other sites
On 4/9/2021 at 2:05 AM, xahmol said:

It does handle control codes, but that was exactly what I was not expecting it to do ;-)

And unsure if it is an incorrect implementation of conio on the Oric Atmos target or not, but it was pretty handy to be able to use cputc to just copy an attribute code to the screen instead of the ASCII control code for the codes under 32.

 

Just did check the CC65 reference documentation, and I actually think you are right. It does not explicitely say so, but as it states there that it supports \n and \r, I am now pretty sure that indeed cputc is supposed to output the control code instead of just copying the value itself to the screen position. 'Like all other conio output functions, cputc distinguishes between \r and \n.'  https://cc65.github.io/doc/funcref.html#cputc

 

Then it is just a damn handy incorrect implementation on the Atmos target of conio.h..... Actually curious now what it then does on the Commodore 64/128 target. On Atmos target, behaviour of cputc is indeed different.... but tend to agree with you now that is actually an incorrect implementation.

Hope now they never correct that Atmos implementation as that would directly break my code, used it extensively to copy color attribute codes to the screen which on the Oric are values under 32 and take a character position instead of going to separate attribute memory...... Funny how every retro computer has its completely different quirks to handle color. You really never can make assumptions coming from another target.

 

Anyway: I then assume that vdpchar() is really the only correct way to print user defined patterns numbered under 32? Not really a problem, just needs vdpchar(gImage+x+32*y,c) instead of just cputcxy(x,y,c). And need of reminding yourself that vdpchar() does not take care of the cursor position so is only a cputcxy replacement and not a cputc.....

Ah well. Conio is the slowest output method in libti99 and was only implemented for someone who was porting something. ;)

 

There's also a macro you can drop into vdpchar - VDP_SCREEN_POS(row,col)

For continuing output, the TI VDP has its own address register, so once anything has set the screen position, assuming you don't change it, you can just write bytes directly to VDPWD and they will continue on across the screen. ( VDPWD='A'; ) This is much faster than reloading the address for every character (3 times as fast, in fact). String writes take advantage of this.

 

Of course, that's all getting very TI specific.

 

  • Like 2

Share this post


Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...

  • Recently Browsing   0 members

    No registered users viewing this page.

×
×
  • Create New...