Jump to content

Recommended Posts

stdio is actually a rather large library of functions. If you really want stdio, you can find some examples in the Z88DK package. A lot of the code is portable and there is MSX support so if you know assembly... have at it.

 

A more realistic approach would be what I did on another machine One of the first things I wrote for the graphics character generator I wrote for the MC-10 were PRINTAT and PRINT functions. That was assembly but you can certainly do the same in C. You won't have the string formatting stuff but you can output text.

  • 4 months later...

Hi guys, I just did a port of the old Ritchie C compiler from pdp11 to 9900. The source is here:

http://1587660.websites.xs4all.nl/

 

Some discussion is here:

http://www.vintage-computer.com/vcforum/showthread.php?15580-Powertran-Cortex/page60

 

For sure this compiler is not as good as gcc or clang, but it is small enough to run on a 9995 with 64kb of ram.

 

Enjoy!

 

  • Like 4

Hi guys, I just did a port of the old Ritchie C compiler from pdp11 to 9900. The source is here:

http://1587660.websites.xs4all.nl/

 

Some discussion is here:

http://www.vintage-computer.com/vcforum/showthread.php?15580-Powertran-Cortex/page60

 

For sure this compiler is not as good as gcc or clang, but it is small enough to run on a 9995 with 64kb of ram.

 

Enjoy!

 

 

Very cool!! I've read through the thread at the vcforum, but am not sure I understand it correctly. This can be used as both a cross compiler as well as a native compiler on 9995 based systems with enough memory? Have you tried compiling a 99/4a program with it, and if so can you share how to get something like a hello world up and running?

 

Very cool!! I've read through the thread at the vcforum, but am not sure I understand it correctly. This can be used as both a cross compiler as well as a native compiler on 9995 based systems with enough memory? Have you tried compiling a 99/4a program with it, and if so can you share how to get something like a hello world up and running?

 

Yes, it is both a cross and a native compiler. The current source is set up for cross-compiling, but once you revert it to plain K&R it will run natively. Nearly all Unix version 6 programs ran in 32KB of memory. See this paper for some background:

http://www.60bits.net/msu/mycomp/terak/termubel.htm

(note that it mostly speaks in 'words', i.e. 2 bytes).

 

I'm not targeting the 99/4A. If you want to run some C on the 99/4A, Insonmia's compiler together with Tursi's library is probably your best bet. You may also want to look at Al Beard's TI-C, which he did for the Geneve 9640. That one is also both cross and native, but requires extensive bank switching for native (I believe that including all overlays it needs some 80KB). TI-C is here:

ftp://whtech.com/programming/

You can use Dave Pitt's assembler and linker to complete the tool chain.

 

Enjoy!

  • 2 months later...

I could also pimp my (completely non-standard) library for the TI here: https://github.com/tursilion/libti99

 

;)

 

Tursi, you've added a fast joystick scanning function in one of the later updates. Is it possible to scan for the joystick button with that? How would one go about doing so?

On entry, joystick to scan should be in R1:
R1 = 0 = Scan first joystick
R2 = 1 = Scan second joystick

Side Effects: R1 Changed, R12 Changed

        ai r1,6                     ; use keyboard select 6 for #0, 7 for #1
        swpb r1
        li r12,36
        ldcr r1,3
        li r12,6
        stcr r1,5
        swpb r1
        inv r1
        andi r1,>001f

On exit, R1 contains the direction and the firebutton status, as follows:

 

The returned value value is a bit-code which can be decoded as follows:

 

1=Fire
2=Left
4=Right
8=Down
16=Up

 

As you can see, these are binary bits. Fire has a value of 1, so if the routine returns 5, then you know right and fire were detected.

Hope this helps. Should be easy enough to put that into the GCC compiler. This code was taken from TurboForth and is tested.

On entry, joystick to scan should be in R1:

R1 = 0 = Scan first joystick

R2 = 1 = Scan second joystick

 

Side Effects: R1 Changed, R12 Changed

        ai r1,6                     ; use keyboard select 6 for #0, 7 for #1
        swpb r1
        li r12,36
        ldcr r1,3
        li r12,6
        stcr r1,5
        swpb r1
        inv r1
        andi r1,>001f

On exit, R1 contains the direction and the firebutton status, as follows:

 

The returned value value is a bit-code which can be decoded as follows:

 

1=Fire

2=Left

4=Right

8=Down

16=Up

 

As you can see, these are binary bits. Fire has a value of 1, so if the routine returns 5, then you know right and fire were detected.

Hope this helps. Should be easy enough to put that into the GCC compiler. This code was taken from TurboForth and is tested.

 

Thanks Willsy, I compared your code to Tursi's in libti99. They're very close to each other, but libti99 simply doesn't export a way to check for the fire button (in that function at least). I duplicated that function and added the check for 0x01 and it works.

 

Code looks like this:

#define JOYST_1		0x0001
#define JOYST_2		0x0002
#define	JOYST_LEFT	0x0002
#define	JOYST_RIGHT	0x0004
#define	JOYST_UP	0x0010
#define	JOYST_DOWN	0x0008
#define	JOYST_FIRE	0x0001
unsigned char read_joyst(int joystick_id)
{
	unsigned int	result;
	unsigned char 	retval = 0;
	
	__asm__
	(
		"li r12,>0024	\n\t"	
		"ai %1,5		\n\t"
		"swpb %1		\n\t"
		"ldcr %1,3		\n\t"
		"src r12,7		\n\t"
		"li r12,>0006	\n\t"
		"clr %0			\n\t"
		"stcr %0,8"
		:"=r"(result)
		:"r"(joystick_id)
		:"r12"
	);

	if ((result & 0x0100) == 0) retval |= JOYST_FIRE;
	if ((result & 0x0200) == 0) retval |= JOYST_LEFT;
	if ((result & 0x0400) == 0) retval |= JOYST_RIGHT;
	if ((result & 0x0800) == 0) retval |= JOYST_DOWN;
	if ((result & 0x1000) == 0) retval |= JOYST_UP;

	return retval;
}

The compiler doesn't let me immediately return the result variable (which I think it should, so perhaps a bug...), but other than that I had no issues...

Edited by TheMole

I based the functions on the BASIC versions, so, use kscanfast(x) for the buttons where x is 1 or 2 for joystick 1 or 2.

 

It's three tests (two for mode and one for return value) and 6 lines of inline asm, so pretty tight. :)

 

Still... I like Willsy's observation that you can read the fire button with just one more bit of CRU... :)

My post 161 in this thread links to a video that shows step by step how to do it, and post 166 corrects a mistake in my video as well. I was following the instructions in post 27.

 

4.6.3 probably won't accept the 4.4.0 patches. You can try, if you're willing to solve the issues if it doesn't work. Better to start with the exact versions to get familiar with it first.

  • Like 1

I've been looking around but can't seem to find the answer - how does one apply these patches? Also, I noticed it says it's a gcc 4.4.0 patch, but I have 4.6.3 installed, is that a problem?

 

The question is a bit confusing, but I am guessing you mean your host compiler is gcc 4.6.3? Gcc 4.6.3 should compile gcc 4.4.0 just fine (keep in mind you're compiling the compiler with a compiler... :) ). As for how to patch, you should be able to use Tursi's instructions for that without any major modifications (I think you're using Linux, if I remember correctly, so some details will be different but the overall process should be similar enough).

  • Like 1

Would it be possible to post the full installation of GCC as a zip file? I haven't tried it yet because of the many steps involved in the installation, so I have had to stick to assembler. :)

I'm not sure how to do that, but I have a hunch it's possible. I'm running Linux Mint 13. Not sure what other info is relevant for creating such a package, but I thought I'd include these:

$ gcc --version
gcc (Ubuntu/Linaro 4.6.3-1ubuntu5) 4.6.3
$ whereis gcc
gcc: /usr/bin/gcc /usr/lib/gcc /usr/bin/X11/gcc /usr/share/man/man1/gcc.1.gz

Edit: Of course I will watch Tursi's How-to as well (looking forward to it - it's been a while since I've watched a Tursi production :D).

Edited by RobertLM78
  • Like 1

 

The question is a bit confusing, but I am guessing you mean your host compiler is gcc 4.6.3? Gcc 4.6.3 should compile gcc 4.4.0 just fine (keep in mind you're compiling the compiler with a compiler... :) ). As for how to patch, you should be able to use Tursi's instructions for that without any major modifications (I think you're using Linux, if I remember correctly, so some details will be different but the overall process should be similar enough).

Yeah, I realized the question was a bit confusing after looking at it again - sorry about that. I'm sure Tursi's video will clear things up. Ironic that we have a compiler compiling a compiler (but probably not that unusual though ;))

 

Edit: Admittedly I didn't dig that far for instructions as I figured the necessary instructions, if they were included, would be on (or at least near) the first post. Do you think we could persuade Insomnia to edit that first post to include the instructions and updated links ? ;)

Edited by RobertLM78

Well, I've ran into trouble when I go to apply the patch. I've downloaded the source for gcc-4.4.0 and binutils-2.19.1a as well as the patches, and when I go to apply the patch, I get this:

$ patch p1 < ./binutils-2.19.1-tms9900-1.5-patch/binutils-2.19.1-tms9900-1.5.patch
patching file p1
Hunk #1 FAILED at 407.
Hunk #2 FAILED at 501.
Hunk #3 FAILED at 570.
3 out of 3 hunks FAILED -- saving rejects to file p1.rej
patching file p1
Hunk #1 FAILED at 2029.
1 out of 1 hunk FAILED -- saving rejects to file p1.rej
patching file p1
Hunk #1 FAILED at 102.
Hunk #2 FAILED at 1432.
2 out of 2 hunks FAILED -- saving rejects to file p1.rej
patching file p1
Hunk #1 FAILED at 19740.
1 out of 1 hunk FAILED -- saving rejects to file p1.rej
patching file p1
patching file p1
Hunk #1 FAILED at 372.
1 out of 1 hunk FAILED -- saving rejects to file p1.rej
The next patch would create the file p1,
which already exists!  Assume -R? [n] 
Apply anyway? [n] 
Skipping patch.
1 out of 1 hunk ignored
patching file p1
Hunk #1 FAILED at 546.
Hunk #2 FAILED at 2140.
2 out of 2 hunks FAILED -- saving rejects to file p1.rej
patching file p1
Hunk #1 FAILED at 660.
1 out of 1 hunk FAILED -- saving rejects to file p1.rej
patching file p1
Hunk #1 FAILED at 152.
Hunk #2 FAILED at 1198.
Hunk #3 FAILED at 1825.
3 out of 3 hunks FAILED -- saving rejects to file p1.rej
patching file p1
Hunk #1 FAILED at 148.
Hunk #2 FAILED at 284.
2 out of 2 hunks FAILED -- saving rejects to file p1.rej
The next patch would create the file p1,
which already exists!  Assume -R? [n] 
Apply anyway? [n] 
Skipping patch.
1 out of 1 hunk ignored
The next patch would create the file p1,
which already exists!  Assume -R? [n] 
Apply anyway? [n] 
Skipping patch.
1 out of 1 hunk ignored
patching file p1
Hunk #1 FAILED at 81.
Hunk #2 FAILED at 384.
2 out of 2 hunks FAILED -- saving rejects to file p1.rej
patching file p1
Hunk #1 FAILED at 275.
1 out of 1 hunk FAILED -- saving rejects to file p1.rej
patching file p1
Hunk #1 FAILED at 334.
1 out of 1 hunk FAILED -- saving rejects to file p1.rej
The next patch would create the file p1,
which already exists!  Assume -R? [n] 
Apply anyway? [n] 
Skipping patch.
1 out of 1 hunk ignored
patching file p1
Hunk #1 FAILED at 607.
1 out of 1 hunk FAILED -- saving rejects to file p1.rej
The next patch would create the file p1,
which already exists!  Assume -R? [n] 
Apply anyway? [n] 
Skipping patch.
1 out of 1 hunk ignored
patching file p1
Hunk #1 FAILED at 640.
Hunk #2 FAILED at 2520.
2 out of 2 hunks FAILED -- saving rejects to file p1.rej
The next patch would create the file p1,
which already exists!  Assume -R? [n] 
Apply anyway? [n] 
Skipping patch.
1 out of 1 hunk ignored
patching file p1
Hunk #1 FAILED at 11885.
1 out of 1 hunk FAILED -- saving rejects to file p1.rej
patching file p1
Hunk #1 FAILED at 77.
Hunk #2 FAILED at 386.
2 out of 2 hunks FAILED -- saving rejects to file p1.rej
patching file p1
Hunk #1 FAILED at 420.
Hunk #2 FAILED at 1664.
2 out of 2 hunks FAILED -- saving rejects to file p1.rej
The next patch would create the file p1,
which already exists!  Assume -R? [n] 
Apply anyway? [n] 
Skipping patch.
1 out of 1 hunk ignored

Edit: I tried binutils-2.19.1 instead of the 2.19.1a and I got the same errors :(. Edited by RobertLM78

Well, I've ran into trouble when I go to apply the patch. I've downloaded the source for gcc-4.4.0 and binutils-2.19.1a as well as the patches, and when I go to apply the patch, I get this:

$ patch p1 < ./binutils-2.19.1-tms9900-1.5-patch/binutils-2.19.1-tms9900-1.5.patch
patching file p1
Hunk #1 FAILED at 407.
Hunk #2 FAILED at 501.


Edit: I tried binutils-2.19.1 instead of the 2.19.1a and I got the same errors :(.

 

 

You're missing the dash. It should be patch -p1 < "name of patch". I recommend looking at post #91 of this thread for lucien2's instructions. Ignore the cygwin part if you are using Linux.

Edited by mdorman
  • Like 1

 

You're missing the dash. It should be patch -p1 < "name of patch". I recommend looking at post #91 of this thread for lucien2's instructions. Ignore the cygwin part if you are using Linux.

 

Indeed, -p1 is a single letter command line option and hence needs the dash. Typically with Unix style applications, you need to add a "-" for all command line options that are a single letter (in this case "p") and a double dash ("--") for the long, fully written out version of those options (which in this case would be "strip"). The "1" after the "-p" is the parameter for that option and in this case means "strip 1 level from all directory prefixes". Oddly enough, if you use the long version you need to use an "=" between the option and the parameter, so the long equivalent of "-p1" would be "--strip=1", which is quite a bit more readable.

Normally patch takes it's input from the terminal instead of from a file, but by adding the "<" you're basically saying that the shell, instead of asking for keyboard input, should feed the file after the "<" sign into the program.

 

It's all very cool, and very powerful stuff and imho a lot of fun to use and get to know. You can write full fledged programs in bash scripts, and it's not that difficult to learn.

  • Like 1

You're missing the dash. It should be patch -p1 < "name of patch". I recommend looking at post #91 of this thread for lucien2's instructions. Ignore the cygwin part if you are using Linux.

Well, this is embarrassing, I should have known better - and the dash is there in Tursi's video. Not sure how I missed that.

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

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...