From Newsgroup: comp.os.cpm

Hi,

Cowgol is a programming language for very small systems, including Z80 computers ( see https://github.com/davidgiven/cowgol ).

I published on GitHub a Cowgol development environment hosted on Z80 computers running CP/M (see https://github.com/Laci1953/Cowgol_on_CP_M ).

To compile a Cowgol source file or to build an executable starting from a Cowgol source file, the following command is used:

COWGOL [-c] [-m] source ([source]...)

More than one source file may be specified (with extensions: .cow = cowgol source file, .as = assembler source file)

If you want just to compile/assemble the files, the option -c must be used. The object code format is the HiTech's object code format.

If the option -c is not specified, the files will be first compiled/assembled, then linked into a CP/M executable (named after the first file).

The option -m builds a memory map for the executable.

The GitHub page contains also some examples of Cowgol compile sessions.

Ladislau
--- Synchronet 3.21d-Linux NewsLink 1.2

From Newsgroup: comp.os.cpm

-----------------------------------8<-----------------------------------

dir like.*

G: LIKE COM | LIKE COW

like

_
/ )
___ / /__
|-' _)
| _)
| _)
___|-.____)

_

----------------------------------->8-----------------------------------

(You probably can guess the source... just prints...)
--
This stealth signature intentionally left blank.

--- Synchronet 3.21d-Linux NewsLink 1.2

From Newsgroup: comp.os.cpm

Can the file ENVIRON be used like in HiTech-C to separate toolchain and workdir?
--
Solid facts do not need 1001 pictures.
--- Synchronet 3.21d-Linux NewsLink 1.2

From Newsgroup: comp.os.cpm

Pe luni, 13 noiembrie 2023, la 08:36:37 UTC+2, yeti a scris:

Can the file ENVIRON be used like in HiTech-C to separate toolchain and workdir?

--
Solid facts do not need 1001 pictures.

I'm working on it + other changes...

Ladislau
--- Synchronet 3.21d-Linux NewsLink 1.2

From Newsgroup: comp.os.cpm

ladislau szilagyi <ladislau_szilagyi@euroqst.ro> writes:

Pe luni, 13 noiembrie 2023, la 08:36:37 UTC+2, yeti a scris:

Can the file ENVIRON be used like in HiTech-C to separate toolchain and
workdir?

I'm working on it + other changes...

Thanks!

So it wasn't PEBKAC that despite seeing ENVIRON in COWGOL.COM I couldn't
find how to use it. ;-)
--
Stay ommmmmmptimistic!
--- Synchronet 3.21d-Linux NewsLink 1.2

From Newsgroup: comp.os.cpm

Pe luni, 13 noiembrie 2023, la 11:23:59 UTC+2, yeti a scris:

ladislau szilagyi <ladislau...@euroqst.ro> writes:

Pe luni, 13 noiembrie 2023, la 08:36:37 UTC+2, yeti a scris:

Can the file ENVIRON be used like in HiTech-C to separate toolchain and >> workdir?

I'm working on it + other changes...

Thanks!

So it wasn't PEBKAC that despite seeing ENVIRON in COWGOL.COM I couldn't find how to use it. ;-)

--
Stay ommmmmmptimistic!

I just uploaded a new COWGOL.HEX...

Ladislau
--- Synchronet 3.21d-Linux NewsLink 1.2

From Newsgroup: comp.os.cpm

Hi,

I made a comparison between the size of two executables:

- dumpx.com ( written in C , see https://github.com/Laci1953/RTM-Z80/tree/main/RESOURCES/dumpx.c )
- hexdump.com ( written in Cowgol, see https://github.com/Laci1953/Cowgol_on_CP_M/blob/main/Examples/hexdump.cow )

The output produced is almost similar:

dumpx crtcpm.obj

0000 : 0A 00 07 00 01 02 03 00 01 5A 38 30 00 46 00 01 : .........Z80.F..
0010 : 00 01 00 00 74 65 78 74 00 2A 06 00 F9 11 00 00 : ....text.*......
0020 : B7 21 00 00 ED 52 4D 44 0B 6B 62 13 36 00 ED B0 : .!...RMD.kb.6...
0030 : 21 00 00 E5 21 80 00 4E 23 06 00 09 36 00 21 81 : !...!..N#...6.!.
0040 : 00 E5 CD 00 00 C1 C1 E5 2A 00 00 E5 CD 00 00 E5 : ........*.......
0050 : CD 00 00 C3 00 00 44 00 03 05 00 22 5F 5F 4C 62 : ......D...."__Lb
0060 : 73 73 00 09 00 22 5F 5F 48 62 73 73 00 18 00 12 : ss..."__Hbss....
0070 : 64 61 74 61 00 2A 00 22 73 74 61 72 74 75 70 00 : data.*."startup.
0080 : 30 00 22 5F 5F 61 72 67 63 5F 00 34 00 22 5F 6D : 0."__argc_.4."_m
0090 : 61 69 6E 00 38 00 22 5F 65 78 69 74 00 0A 00 01 : ain.8."_exit....
00A0 : 00 00 00 00 64 61 74 61 00 00 03 00 02 D0 00 00 : ....data........
00B0 : 06 00 02 10 00 62 73 73 00 07 00 02 10 00 64 61 : .....bss......da
00C0 : 74 61 00 07 00 02 30 00 74 65 78 74 00 77 00 04 : ta....0.text.w..
00D0 : 00 00 00 00 16 00 00 5F 5F 48 62 73 73 00 00 00 : .......__Hbss...
00E0 : 00 00 16 00 00 5F 5F 4C 62 73 73 00 00 00 00 00 : .....__Lbss.....
00F0 : 16 00 00 5F 5F 61 72 67 63 5F 00 00 00 00 00 16 : ...__argc_......
0100 : 00 00 5F 65 78 69 74 00 00 00 00 00 16 00 00 5F : .._exit........_
0110 : 6D 61 69 6E 00 00 00 00 00 00 00 64 61 74 61 00 : main.......data.
0120 : 6E 75 6C 61 72 67 00 00 01 00 00 10 00 74 65 78 : nularg.......tex
0130 : 74 00 73 74 61 72 74 00 00 00 00 00 16 00 00 73 : t.start........s
0140 : 74 61 72 74 75 70 00 09 00 05 00 01 00 00 74 65 : tartup........te
0150 : 78 74 00 02 00 06 00 00 00 00 00 00 00 00 00 00 : xt..............
0160 : 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 : ................
0170 : 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 : ................

hexdump crtcpm.obj

00000000 0a 00 07 00 01 02 03 00 01 5a 38 30 00 46 00 01 |.........Z80.F..| 00000010 00 01 00 00 74 65 78 74 00 2a 06 00 f9 11 00 00 |....text.*......| 00000020 b7 21 00 00 ed 52 4d 44 0b 6b 62 13 36 00 ed b0 |.!...RMD.kb.6...| 00000030 21 00 00 e5 21 80 00 4e 23 06 00 09 36 00 21 81 |!...!..N#...6.!.| 00000040 00 e5 cd 00 00 c1 c1 e5 2a 00 00 e5 cd 00 00 e5 |........*.......| 00000050 cd 00 00 c3 00 00 44 00 03 05 00 22 5f 5f 4c 62 |......D...."__Lb| 00000060 73 73 00 09 00 22 5f 5f 48 62 73 73 00 18 00 12 |ss..."__Hbss....| 00000070 64 61 74 61 00 2a 00 22 73 74 61 72 74 75 70 00 |data.*."startup.| 00000080 30 00 22 5f 5f 61 72 67 63 5f 00 34 00 22 5f 6d |0."__argc_.4."_m| 00000090 61 69 6e 00 38 00 22 5f 65 78 69 74 00 0a 00 01 |ain.8."_exit....| 000000a0 00 00 00 00 64 61 74 61 00 00 03 00 02 d0 00 00 |....data........| 000000b0 06 00 02 10 00 62 73 73 00 07 00 02 10 00 64 61 |.....bss......da| 000000c0 74 61 00 07 00 02 30 00 74 65 78 74 00 77 00 04 |ta....0.text.w..| 000000d0 00 00 00 00 16 00 00 5f 5f 48 62 73 73 00 00 00 |.......__Hbss...| 000000e0 00 00 16 00 00 5f 5f 4c 62 73 73 00 00 00 00 00 |.....__Lbss.....| 000000f0 16 00 00 5f 5f 61 72 67 63 5f 00 00 00 00 00 16 |...__argc_......| 00000100 00 00 5f 65 78 69 74 00 00 00 00 00 16 00 00 5f |.._exit........_| 00000110 6d 61 69 6e 00 00 00 00 00 00 00 64 61 74 61 00 |main.......data.| 00000120 6e 75 6c 61 72 67 00 00 01 00 00 10 00 74 65 78 |nularg.......tex| 00000130 74 00 73 74 61 72 74 00 00 00 00 00 16 00 00 73 |t.start........s| 00000140 74 61 72 74 75 70 00 09 00 05 00 01 00 00 74 65 |tartup........te| 00000150 78 74 00 02 00 06 00 00 00 00 00 00 00 00 00 00 |xt..............| 00000160 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| 00000170 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| 00000180

But, the size of hexdump.com is about 25% the size of dumpx.com !!! (14 x 128 bytes vs. 61 x 128 bytes)

sdir dumpx.com

Directory For Drive D: User 0

Name Bytes Recs Attributes
------------ ------ ------ ------------
DUMPX COM 8k 61 Dir RW

sdir hexdump.com

Directory For Drive D: User 0

Name Bytes Recs Attributes
------------ ------ ------ ------------
HEXDUMP COM 4k 14 Dir RW



And, hexdump is faster than dumpx ( at least 2 X ).

It seems Cowgol outperforms C ( at least, in this particular case )

Ladislau

--- Synchronet 3.21d-Linux NewsLink 1.2

From Newsgroup: comp.os.cpm

ladislau szilagyi <ladislau_szilagyi@euroqst.ro> wrote:

But, the size of hexdump.com is about 25% the size of dumpx.com !!!
(14 x 128 bytes vs. 61 x 128 bytes)

Just for fun translated dumpx.c to T3X function by function, and the
resulting executable has a size of 23 records.

And, hexdump is faster than dumpx ( at least 2 X ).

The binary dumps itself in 4s on a 7.4Mhz Z80 (file system on a CF card).

Program: http://t3x.org/files/hexdump.t
Compiler: http://t3x.org/t3x/index.html#0
--
Nils M Holm < n m h @ t 3 x . o r g > http://t3x.org
--- Synchronet 3.21d-Linux NewsLink 1.2

From Newsgroup: comp.os.cpm

Hi,
the Cowgol development environment evolved...
Now, it's possible to mix Cowgol, C and assembler source files to build a CP/M executable.
The Cowgol command line accepts now also C files to be compiled, besides Cowgol files and assembler files.
Example:
( -lc means LIBC.LIB will be added in the final LINK command line)

cowgol -lc msort.cow merges.c rand.as

COWGOL COMPILER (CP/M-80) V2.0
Copyright (C) David Given
MSORT.COW
0:COWFE MSORT.COW $CTMP1.$$$
COWFE: 18kB free
> MSORT.COW
done: 16kB free
0:COWBE $CTMP1.$$$ MSORT.COO
COWBE: 22kB free
__main
print_char
print
UIToA
print_i16
random
done: 20kB free
MERGES.C
0:CPP -DCPM -DHI_TECH_C -Dz80 -I MERGES.C $CTMP1.$$$
0:P1 $CTMP1.$$$ $CTMP2.$$$ $CTMP3.$$$
0:CGEN $CTMP2.$$$ $CTMP1.$$$
0:OPTIM $CTMP1.$$$ $CTMP2.$$$
0:Z80AS -J -N -oMERGES.OBJ $CTMP2.$$$
Z80AS Macro-Assembler V4.8
Errors: 0
Jump optimizations done: 6
Finished.
RAND.AS
0:Z80AS -J -ORAND.OBJ RAND.AS
Z80AS Macro-Assembler V4.8
Errors: 0
Finished.
ERA $CTMP1.$$$
ERA $CTMP2.$$$
0:COWLINK COWGOL.COO MSORT.COO -o $CTMP1.$$$
COWLINK: 46kB free
Adding input file: COWGOL.COO
Adding input file: MSORT.COO
Analysing...
Workspace sizes:
#0: 2040 bytes
#1: 0 bytes
#2: 0 bytes
#3: 0 bytes
Creating output file: $CTMP1.$$$
Copying from input file: COWGOL.COO
Copying from input file: MSORT.COO
done: 42kB free
ERA MSORT.COO
0:COWFIX $CTMP1.$$$ $CTMP2.$$$
0:Z80AS -J -N -O$CTMP1.$$$ $CTMP2.$$$
Z80AS Macro-Assembler V4.8
Errors: 0
Jump optimizations done: 18
Finished.
0:LINK -Z -Ptext=100H,data,bss -C100H -OMSORT.COM $CTMP1.$$$ MERGES.OBJ RAND.OBJ LIBC.LIB
ERA $CTMP1.$$$
ERA $CTMP2.$$$
ERA $$EXEC.$$$

msort

Unsorted array: 9354,7162,28553,30556,10608,10552,5922,26465,7626,3830,31116,27859,21585,5103,14685,406,14835,21267,25790,22755,24183,8389,26148,10846,6428,23,6546,27322,22241,21618,10564,2561,20164,32466,3737,31288,27915,6143,25355,24248,31737,15674,2602,14885,6577,20497,26045,6944,28261,22411,20546,19258,18193,14838,21911,18008,18221,21637,22606,20017,3290,3050,11221,13429,31986,13744,11206,27298,1215,2386,25154,8291,31467,9004,822,25210,18965,13813,23826,27704,28672,18488,17938,31285,25989,12566,29003,13793,1603,30672,16607,9992,14873,13442,3576,29056,27096,8090,8691,18207,29627,556,12838,5942,31856,22034,8829,12211,15944,7941,5771,12642,25186,6219,26837,5652,18010,17455,5574,19389,25207,17051,4892,20306,1889,3514,722,3303,26392,17965,21893,6414,24385,510,163
...
Sorted array: 23,43,63,136,139,141,214,219,222,326,384,406,430,508,510,510,556,606,722,727,822,838,844,861,959,988,991,1009,1027,1051,1057,1083,1115,1131,1153,1215,1230,1239,1390,1405,1415,1418,1447,1488,1522,1592,1603,1681,1696,1706,1717,1733,1738,1792,1819,1889,1921,2052,2074,2085,2137,2151,2152,2234,2297,2317,2326,2350,2360,2386,2413,2481,2488,2496,2498,2530,2536,2545,2561,2602,2651,2659,2673,2683,2752,2783,2799,2803,2807,2817,2851,2862,2987,3050,3169,3262,3290,3296,3303,3327,3330,3396,3409,3428,3449,3512,3514,3535,3566,3576,3693,3713,3737,3763,3781,3830,3834,3883,3886,
... ,25047,25064,25166,25435,508,510,844,1230,1592,2085,2326,2413,2783,2987,4925,5308,5701,5710,5864,5957,6149,6450,6700,6724,7018,7362,7547,8216,8343,25708,25739,25880,26067,26218,26544,26924,26989,27218,27406,27441,27667,27853,28139,28533,28586,28717,28723,29298,29416,29618,29679,30018,30887,30923,31323,31641,32513,32615,32619,32641,

The program sorts 1000 random integers.
The Cowgol "main" routine calls the assembler routines xrndseed and xrnd to populate a vector of 1000 integers, then calls a C routine that sorts the vector; the texts are printed using Cowgol routines. The C routine calls another (reentrant) C routine to do the "merge sorting".
See the actual source files here: https://github.com/Laci1953/Cowgol_on_CP_M/tree/main/Examples
Ladislau
--- Synchronet 3.21d-Linux NewsLink 1.2

From Newsgroup: comp.os.cpm

Hi,

In Cowgol, you may use dynamic memory functions (Alloc, Free, ...) including the "malloc.coh" file in your source file.

When your CP/M program is written using ONLY Cowgol source files, the original "malloc.coh" may be used without any problem.

But, when you try to build CP/M programs that mix Cowgol and C source files, some modifications must be made to the original .coh files, in order to benefit from the Cowgol Alloc, Free, and other dynamic allocation functions.

The problem is caused by the fact that the original Cowgol runtime environment considered the "heap" as starting after the last byte of the executable code and finishing exactly below BDOS.

With the new Cowgol + C runtime environment, the executable map contains 3 sequential concatenated program sections : text ( the code ), data ( initialized buffers ) and bss ( uninitialized buffers ).

Therefore, the Cowgol heap area must start at the end of the bss program section.

Practically, instead of using the "standard" include "cowgol.coh", you MUST use instead include "cowgolc.coh".

The differences are minor, but essential.

The "standard" cowgol.coh starts with these lines:

var LOMEM: [uint8];
@asm "ld hl, LOMEM";
@asm "ld (", LOMEM, "), hl";

var HIMEM: [uint8];
@asm "ld hl, (6)";
@asm "ld (", HIMEM, "), hl";

(the dynamic memory functions contained in malloc.coh use the variables LOMEM & HIMEM to define the start & stop boundaries of the heap )

The "custom" cowgolc.coh contains a small modification:

var LOMEM: [uint8];
@asm "ld hl,__Hbss"; # @asm "ld hl, LOMEM";
@asm "ld (", LOMEM, "), hl";

var HIMEM: [uint8];
@asm "ld hl, (6)";
@asm "ld (", HIMEM, "), hl";

The value of __Hbss is declared and set by default as the "end of BSS" by the last tool in the Cowgol compile chain, the HiTech's LINK.

This sets the start of the Cowgol heap at the end of the BSS program section, allowing the C & Cowgol environments to "coexist" peacefully.

Therefore, when you intend to use dynamic memory allocation in a mixed Cowgol + C environment, you MUST include this "custom" cowgolc.coh, instead of the "standard " cowgol.coh file.

See in Examples the dynmsort.cow file (combined with merges.c & rand.as, will build the dynmsort.com program, which uses Alloc to obtain space for the integer vector to be sorted)

Ladislau

--- Synchronet 3.21d-Linux NewsLink 1.2

From Newsgroup: comp.os.cpm

Guess what?

Hackaday
Cowgol Development Environment Comes To Z80 And CP/M <https://hackaday.com/2023/12/10/cowgol-development-environment-comes-to-z80-and-cp-m/>
--
I do not bite, I just want to play.
--- Synchronet 3.21d-Linux NewsLink 1.2

From Newsgroup: comp.os.cpm

Hi,

I work now on an enhanced Cowgol compiler, able to compile larger source files, on Z80 systems provided with 128KB or 512KB RAM.
It will fully use the available RAM space to allocate objects, allowing to process very large Cowgol files (I hope it will be able to compile itself...)

A small test is already working with a part of the compiler (cowfe.com); the test is executed on a 512KB RAM Z80 computer:

cowfe t.cow test

COWFE: 18kB free main memory
448kB free extended memory
> T.COW
done: 17kB free main memory
442kB free extended memory


Of course, there is still a long way to go until all tests will be finished...

Ladislau
--- Synchronet 3.21d-Linux NewsLink 1.2

From Newsgroup: comp.os.cpm

Hi,

I took a decisive step in proving that the Cowgol compiler can compile large source files, if executed on Z80 computers provided with 128/512 KB RAM.

So far I have managed to modify the first component of the compiler, COWFE.

Here are the results of compiling the COWFE source, on RC2014 :
(first attempt using the new version of COWFE, the second using the original one)

cowfet main.cow test

COWFE: 18kB free main memory
448kB free extended memory
> MAIN.COW
> cowgol.coh
> common.coh
< cowgol.coh
< MAIN.COW
> argv.coh
< MAIN.COW
> strings.coh
< MAIN.COW
> malloc.coh
< MAIN.COW
> file.coh
> commfile.coh
< file.coh
< MAIN.COW
> coodecls.coh
< MAIN.COW
> types.coh
< MAIN.COW
> allocato.coh
< MAIN.COW
> lexer.coh
< MAIN.COW
> midcodec.coh
> midcodes.coh
Out of memory

cowfe main.cow test

COWFE: 19kB free
> MAIN.COW
> cowgol.coh
> common.coh
< cowgol.coh
< MAIN.COW
> argv.coh
< MAIN.COW
> strings.coh
< MAIN.COW
> malloc.coh
< MAIN.COW
> file.coh
> commfile.coh
< file.coh
< MAIN.COW
> coodecls.coh
< MAIN.COW
> types.coh
Out of memory



Therefore, the old COWFE stops at types.coh, the new one processes also allocator & lexer, stops at midcodes.coh

The "Out of memory" message was issued because the "main" 64 RAM was consumed (but in the 512KB RAM board there is still plenty of free space )

I work to improve the performance of the new COWFET.COM, basically by allocating more data structures in the 512KB RAM.

Then, I will start working on the second important COWGOL compiler executable: the COWBE.COM

In the final version, the new COWGOL compiler will be available on all Z80 computers having 128/512 KB RAM.

Ladislau

--- Synchronet 3.21d-Linux NewsLink 1.2

From Newsgroup: comp.os.cpm

Hi,

The original version of the compiler failed to compile large cowgol source files.

That was caused by the small amount of RAM memory available to the compiler to store the data structures involved in the compilation.

For sources larger than a few hundred lines, the first step of the compiler issued a fatal error message: "Out of memory".

I solved the problem, at least for the z80 computers provided with 128/512 KB RAM.

I modified the first step of the compiler (COWFE.COM), enabling-it to store part of the data on the "extended" RAM space, beyond the "main" 64KB.

You may find the enhanced version of the COWGOL compiler here: https://github.com/Laci1953/Cowgol_on_CP_M/tree/main/128_512_KB

Ladislau
--- Synchronet 3.21d-Linux NewsLink 1.2

From Newsgroup: comp.os.cpm

I published here: https://github.com/Laci1953/Cowgol_on_CP_M/tree/main/Examples

a version of the Stratrek game ported to the Cowgol language.

Ladislau

--- Synchronet 3.21d-Linux NewsLink 1.2

From Newsgroup: comp.os.cpm

Hi,

The enhanced version of the Cowgol compiler runs now also on Z80 computers provided with 512KB RAM, under ROMWBW.

I published the modified COWFE here: https://github.com/Laci1953/Cowgol_on_CP_M/blob/main/128_512_KB/cowfe_romwbw.hex

Ladislau
--- Synchronet 3.21d-Linux NewsLink 1.2

From Newsgroup: comp.os.cpm

I just published a new version of the Cowgol compiler ( https://github.com/Laci1953/Cowgol_on_CP_M/tree/main/New%20version )
It works on any Z80 computer with 64 KB RAM running CP/M.
The modified components of the compiler (cowfe.com and cowbe.com) are smaller (~ 1KB less) and 20% faster, compared to the old version.
The optimization was done directly on the assembler source files of cowfe & cowbe; the new source files are published too, along with the old versions, for reference.

Ladislau
--- Synchronet 3.21d-Linux NewsLink 1.2

From Newsgroup: comp.os.cpm

I published the Colossal Cave adventure game, ported to Cowgol : https://github.com/Laci1953/Cowgol_on_CP_M/tree/main/Games/Adventure

It must be compiled on a 128KB/512KB RAM Z80 machine.

cowgol advent.cow advmain.cow xrnd.as

COWGOL COMPILER (CP/M-80) V2.0
Copyright (C) David Given
ADVENT.COW
0:COWFE ADVENT.COW $CTMP1.$$$
COWFE: 21kB free main memory
63kB free extended memory
> ADVENT.COW
done: 12kB free main memory
51kB free extended memory
0:COWBE $CTMP1.$$$ ADVENT.COO
COWBE: 22kB free
__main
exit
get_char
print_char
print
print_nl
get_line
itoa
ltoa
isdigit
atoi
atol
bug
strcpy
strcmp
strlen
strcat
rindex
MemSet
ArgvInit
ArgvNext
file_i_init
fill
fcb_i_gbpb
fcb_i_blockin
fcb_i_blockout
fcb_i_changeblock
fcb_a_to_error
FCBOpenIn
FCBOpenUp
FCBOpenOut
FCBClose
FCBSeek
FCBPos
FCBExt
fcb_i_nextchar
FCBGetChar
FCBPutChar
closefiles
opentxt
rdupto
rdskip
rspeak
pspeak
desclg
descsh
binary
vocab
tolower
outwords
pct
yes
analyze
dstroy
juggle
put
liq2
copytrv
done: 15kB free
ADVMAIN.COW
0:COWFE ADVMAIN.COW $CTMP1.$$$
COWFE: 21kB free main memory
63kB free extended memory
> ADVMAIN.COW
done: 0kB free main memory
36kB free extended memory
0:COWBE $CTMP1.$$$ ADVMAIN.COO
COWBE: 22kB free
__main
get_dbugflg
set_saveflg
getwords
gettrav
english
addobj
toting
here
dark
forced
at
carry
drop
move
dcheck
liq
liqloc
needobj
actspk
score
normend
death
dwarfend
vdrop
vfill
vtake
vopen
vsay
describe
von
voff
vwave
vkill
vpour
veat
vdrink
vfeed
vthrow
vfind
vread
vblast
vbreak
vwake
ivtake
ivopen
ivkill
iveat
ivdrink
ivquit
ivfill
ivfoo
ivread
inventory
scanint
initplay
descitem
trverb
trobj
badmove
spcmove
dotrav
goback
domove
dopirate
dwarves
stimer
doobj
itverb
turn
done: 13kB free
XRND.AS
0:Z80AS -J -OXRND.OBJ XRND.AS
Z80AS Macro-Assembler V4.8

Errors: 0
Finished.
ERA $CTMP1.$$$
ERA $CTMP2.$$$
0:COWLINK COWGOL.COO ADVENT.COO ADVMAIN.COO -o $CTMP1.$$$
COWLINK: 46kB free
Adding input file: COWGOL.COO
Adding input file: ADVENT.COO
Adding input file: ADVMAIN.COO
Analysing...
Workspace sizes:
#0: 3109 bytes
#1: 0 bytes
#2: 0 bytes
#3: 0 bytes
Creating output file: $CTMP1.$$$
Copying from input file: COWGOL.COO
Copying from input file: ADVENT.COO
Copying from input file: ADVMAIN.COO
done: 24kB free
ERA ADVENT.COO
ERA ADVMAIN.COO
0:COWFIX $CTMP1.$$$ $CTMP2.$$$
0:Z80AS -J -N -OADVENT.OBJ $CTMP2.$$$
Z80AS Macro-Assembler V4.8

Errors: 0

Jump optimizations done: 918
Finished.
0:LINK -Z -Ptext=100H,data,bss -C100H -OADVENT.COM ADVENT.OBJ XRND.OBJ
ERA $CTMP1.$$$
ERA $CTMP2.$$$
ERA $$EXEC.$$$

advent

Welcome to ADVENTURE!
=====================
-Original development by Willie Crowther.
-Major features added by Don Woods.
-Conversion to BDS C by J. R. Jaeger
-Unix standardization by Jerry D. Pohl.
-OS/2 Conversion by Martin Heller
-Conversion to TurboC 2.0 by Daimler

Would you like instructions?

yes

Somewhere nearby is Colossal Cave, where others have
found fortunes in treasure and gold, though it is rumored
that some who enter are never seen again. Magic is said
to work in the cave. I will be your eyes and hands. Direct
me with commands of 1 or 2 words. I should warn you that I
look at only the first five letters of each word, so you'll
have to enter "Northeast" as "ne" to distinguish it from
"North". (Should you get stuck, type "help" for some
general hints).

You are inside a building, a well house for a large spring.
There are some keys on the ground here.
There is a shiny brass lamp nearby.
There is tasty food here.
There is a bottle of water here.

help

I know of places, actions, and things. Most of my vocabulary
describes places and is used to move you there. To move, try
words like forest, building, downstream, enter, east, west,
north, south, up or down. I know about a few special
objects, like a black rod hidden in the cave. These objects
can be manipulated using some of the action words I know.
Usually you will need to give both the object and action
words (In either order), but sometimes I can infer the
object from the verb alone. Some objects also imply verbs;
in particular, "inventory" implies "take inventory", which
causes me to give you a list of what you're carrying. The
objects have side effects; for instance, the rod scares the
bird. Usually people having trouble moving just need
to try a few more words. Usually people trying unsuccessfully
to manipulate an object are attempting something beyond their
(or my!) capabilities and should try a completely different
tack. To speed the game you can sometimes move long distances
with a single word. For example, "building" usually gets you
to the building from anywhere above ground except when lost
in the forest. Also, note that cave passages turn a lot, and
that leaving a room to the north does not guarantee entering
the next from the south.
Good luck!


---------------------------

This is an early functional version of the game, probably there are still bugs to be fixed.

The main purpose of this experiment was to use the @extern attribute of subroutines, in order to have a large source file divided into several smaller source files, each using the @external mechanism.

Ladislau
--- Synchronet 3.21d-Linux NewsLink 1.2