RC2014 Z88DK, serial troubles...

[Steve Baines]

So, I'm trying to use Z88DK to generate ROM images for my RC2014 and I'm having some, but not quite enough, success.

I'm pretty new to Z88DK, but it is installed and working, and I have been using it successfully
to do some ZX Spectrum experiments. This all seems to be working fine.

I've tried to build a few RC2014 projects with the following results:

1. 'Hello World'
test.c from first post in this thread: https://groups.google.com/forum/#!searchin/rc2014-z80/z88dk%7Csort:relevance/rc2014-z80/cGiPYtc4O8o/f70DhO84AAAJ

Built with
> zcc +rc2014 -subtype=rom -v -m -SO3 --max-allocs-per-node200000 --c-code-in-asm --list test.c  -o test -create-app

The Builds a 'hello.rom' file, which works.
Boot up with that, and I get the 'Hello' message, and any characters I type are echoed to screen.

So far so good...



2. 'Eliza'
eliza.c from https://github.com/z88dk/z88dk/blob/master/libsrc/_DEVELOPMENT/EXAMPLES/eliza.c
Built with:
> zcc +rc2014 -subtype=rom -v -startup=1 -clib=sdcc_ix -m -SO3 --c-code-in-asm --list eliza.c -o eliza_rc2014.bin -create-app -lm

This creates a rom which runs, but is ignoring serial input (including 'return', so not just lack of echo).
Interestingly, this is the same behaviour I'm seeing with the ROM images at
https://github.com/RC2014Z80/RC2014/tree/master/Hardware/SDDump/ROM%20Images

This suggests that I'm building them right - but why isn't the serial working?
Is it actually working for anybody?

FWIW, if I build it for the ZX Spectrum using the same source, and the following build line:
> zcc +zx -vn -SO3 -startup=4 -clib=sdcc_ix --reserve-regs-iy eliza.c -o eliza_zx.bin -lm -create-app
This creates a 'tap' file, which is working perfectly with e.g. Fuse and ZX Spin Spectrum emulators.
So this shows that the code itself seems to be fine.


3. 'Star Trek'
startrek.c from https://github.com/z88dk/z88dk/blob/master/libsrc/_DEVELOPMENT/EXAMPLES/startrek.c
Same deal as Eliza - seems to start up fine, but ignoring serial input.
Also, carriage returns seem broken.
Again, is this working for anyone else?



At this point I'm a bit puzzled, and not sure how to proceed.  If there's something wrong with my serial, then why does 'Hello World' work, and why does BASIC work? If there's nothing wrong with it, then why aren't Eliza and Startrek working, and why are they failing to work in the same way as the github ROMs?


Also, Z88DK supports RC2014 - but what configuration does it support?  How do I define this?

Overall Z88DK looks to be really good, but I'm finding the learning curve very steep...

   Cheers - Steve

[phillip.stevens]

So, I'm trying to use Z88DK to generate ROM images for my RC2014 and I'm having some, but not quite enough, success.

Steve, the short answer is that we broke the subtype=acia option, and it hasn't been fixed yet.

There is a check list of other things to fix at the bottom of this issue.

And we're working on fixing other things too.

After working out the rc2014 user base, it to made sense to focus on the subtype=basic_dcio users first. That is mentioned at the bottom of the thread you referenced. Most (over 80%) of the rc2014 users are working off the original Grant Searle NASCOM Basic ROM and using hexload.bas to install C programs.

Those users that don't have a ROM burner can use z88dk right now, without having to prepare a ROM. There are many example C programs here.

If are able to burn one ROM, then use HexLoadr ROM to get immediate access to the same path.

The three active rx2014 z88dk subtypes are now:

• subtype=acia is a compressed ROM compile, for stand alone use.
  
• subtype=basic is a for the NASCOM Basic path compile option.
  
• subtype=basic_dcio includes the stdio command line editing tools above NASCOM Basic option.
  

The subtype=acia version will be fixed, and will get a dc_io option so that command lines can be edited on-screen, and immediate keystrokes can be recognised (for games using the screen).

Just to point out that it is not me fixing it.

Please thank @aralbrec for the great work.

Enjoy, Phillip / @feilipu

All the example of 

[phillip.stevens]

So, I'm trying to use Z88DK to generate ROM images for my RC2014 and I'm having some, but not quite enough, success.

Steve, the short answer is that we broke the subtype=acia option, and it hasn't been fixed yet.

There is a check list of other things to fix at the bottom of this issue.

And we're working on fixing other things too.

Oh, it is probably self evident but, the z88dk is a fast moving project with a lot of activity on the ZX (Spectrum Next), rc2014, and z180 Targets currently.

It pays to clone z88dk from Github, and build it yourself (daily).

Or just download the daily Windows version when you're planning to do something.

[Steve Baines]

Hi Philip,
Thanks very much for your quick and detailed reply!
Knowing that this is in fact broken at the moment is valuable - saves me wasting time trying to find problems at my end that don't exist, thank you.

I need to spend some time digesting the info in the links you sent - I haven't grokked it yet.

I have to say, overall I'm very impressed with the Z88DK project:
1. I've got a ZX Spectrum, an RC2014, an Epson PX-4+, and soon a Spectrum NEXT board - and ALL of these targets are supported (or in active development). This is great - means I only need to learn one set of tools to be able to target any of them.
2. Very easy to mix any amount of C and any amount of asm.  This is a killer feature to me.  No way am I writing everything in assembler (life's too short!), but being able to mix them so easily as needed is fab.
3. Libs written in asm. Nice.
4. Very flexible.

The biggest problem I'm having at the moment is just the learning curve. 
The fact that there are two sets of compilers and libraries in particular is confusing things
 - it's not always clear which set any given piece of documentation is using.

Anyway, I will keep practicing.

Well done the the Z88DK team - great project!

   Cheers - Steve

[Phillip Stevens]

I've got a ZX Spectrum, an RC2014, an Epson PX-4+, and soon a Spectrum NEXT board - and ALL of these targets are supported (or in active development). This is great - means I only need to learn one set of tools to be able to target any of them.

Yes, I'm in a similar boat. I bought built a RC2014 in parallel with building my own YAZ180 board, and have a Spectrum NEXT due in August too. I like having one set of tools that works everywhere too.

The biggest problem I'm having at the moment is just the learning curve. 
The fact that there are two sets of compilers and libraries in particular is confusing things

@aralbrec does regular benchmarking on the different options. SDCC (renamed zsdcc in the z88dk) is getting quite close to the classic z88dk compiler, but some of the very old compilers are very good. Thus far, I've concentrated on using a very recent SDCC build, and use it exclusively with the new library (which is connected to the rc2014, and yaz180).

I would love to have access to the Softools z180 C compiler too, because it automatically handles the memory banking available on the z180. But, it is too expensive for such an "old" product, and I object to paying for something that hasn't been developed or improved for such a long time.

Cheers, Phillip

[Steve Baines]

On Sunday, July 16, 2017 at 11:52:17 AM UTC+1, phillip.stevens wrote:

I would love to have access to the Softools z180 C compiler too, because it automatically handles the memory banking available on the z180. But, it is too expensive for such an "old" product, and I object to paying for something that hasn't been developed or improved for such a long time.

Wow, that's quite steep.  "An Internet connection is required to license tools" - that's a big turn-off as well. Something else to go wrong when you need it.

[A A]

On Saturday, July 15, 2017 at 4:39:14 PM UTC-6, Steve Baines wrote:

This suggests that I'm building them right - but why isn't the serial working?
Is it actually working for anybody?

Yes sorry about that, as philip says some of the terminal drivers are broken currently.  With philip's help we found the right way to drive an attached terminal in the basic driver so that you can currently build programs that work properly from the base rc2014 system booted to basic (a compile with -subtype=basic_dcio).  The other drivers will be fixed up to match this when I get a few hours in a row to do it properly, then you'll be able to build standalone rom systems with terminal io working properly.  You can build stuff now, it's just that terminal input (ie scanf) will not work right.

The issue is down to how we're supposed to drive the attached terminal software on the PC.

The first attempt assumed the terminal software was going to be in line mode so that you enter and edit text at the PC and after pressing enter, the line gets sent to the rc2014.  That was wrong apparently :)  Plus you don't want line mode input if you are going to be writing games which require instantaneous detection of keypresses (ie char mode).

The second attempt understood there was no local echo and switched to char mode so more code was drawn in from the z88dk library to handle line editing.  But the ascii codes we used for a few things were wrong, eg backspace was mapped to the wrong character and the PC terminal was sending only \r for the enter key (we were expecting a \n or \r\n).

The third attempt in the basic_dcio driver fixed the above and we got something that works and only needs a little tweaking.

The last step will be to do the tweaking and implement an optional tty emulation layer on top.  The tty layer will allow some control codes to be sent to do, eg, cursor positioning.  I don't think we can just let vt100 codes pass through because the z88dk terminal code counts ascii chars sent to understand where the cursor is.  Passing these codes through would lead to a wrong cursor position being calculated so a layer has to be put on top to understand these control code sequences.  Unfortunately we don't have a vt100 layer yet in the newlib but we do have a "z88dk tty layer" that implements a small set of control codes that we can easily use.  These will get translated to vt100 escape sequences.  The interesting thing is we can then use this to open up multiple terminal windows on screen.

>Also, Z88DK supports RC2014 - but what configuration does it support?  How do I define this?

It can actually do all of them but it is defaulted to the 8k rom / 32k ram system.

The default settings about where the org should be, where the ram is, where the stack goes, etc are controlled by pragmas at compile time so it's easy to change the rc2014 system characteristics compile to compile.

This is going to be technical but the pragmas are described here:

https://www.z88dk.org/wiki/doku.php?id=libnew:target_embedded#crt_configuration
(Info on im2 interrupts and CLIB_MALLOC_HEAP_SIZE with values < -1 has to be updated).

The default settings for the rc2014 are here:

https://github.com/z88dk/z88dk/blob/master/libsrc/_DEVELOPMENT/target/rc2014/crt_config.inc
(acia model refers to the standalone rom build and the basic model refers to compiling to ram with basic booted).

There is a gentler introduction to using z88dk with zsdcc / newlib / zx spectrum being written:
https://github.com/z88dk/z88dk/blob/master/doc/ZXSpectrumZSDCCnewlib_01_GettingStarted.md

It's not rc2014 but tool usage is the same.  The rc2014 target is using "-subtype=xxx" to chose crt & drivers
rather than the lower level "-startup=n" values used on the zx target.


This maybe sounds a bit scary but that's because some details for advanced users are being revealed here.
It is possible and intended that someone can just enter a compile line and the output is generated very
simply using reasonable defaults set up by the target :)

> I've got a ZX Spectrum, an RC2014, an Epson PX-4+, and soon a Spectrum NEXT board

I know it's confusing while z88dk is going through this expansion phase with two compilers and two libraries in the mix.
The first choice should be in library because that determines what targets are supported.  Here's a list for your machines:

- ZX : classic and newlib
- RC2014: newlib
- EPSON: classic
- ZX NEXT:  newlib (when it appears, soon I hope)


Thanks again to the people who contribute to making z88dk better.  Especially Philip who has been writing some of the
driver code and pushing the z180 target to where it should be :)

Contributions are always welcome :)

[Steve Baines]

Hi,

On Sunday, July 16, 2017 at 7:20:30 PM UTC+1, A A wrote:

Lots of detailed stuff!

Thanks very much for all the help here.  I've been digging through it all day, and I'm starting to get some understanding.

I have now managed to build and run a working Eliza on an RC2014 with standard ROM, using basic_dcio:
1. zcc +rc2014 -subtype=basic_dcio -v -clib=sdcc_ix -m -SO3 --c-code-in-asm --list eliza.c -o eliza_rc2014_basic32_dcio.bin -create-app -lm
2. Boot RC2014, memtop 36863
2. Load the rom image into memory at 0x9000 using my hacked SD card dump board
4. hdoke &8049, &h9000   // This was an ordeal in itself - finding that the address is 0x8049, not 0x8048, nor 0x8224.
5. print usr(0)



I also managed to get StarTrek working - which actually revealed a very nasty bug.

Once I'd fixed the bug, I removed the instructions to make the image small enough, then basically did exactly the same as for Eliza.
Result:



Now, the bug: I was getting a corrupt version of the above 'short range scan', and if I did an 'lrs', then an 'srs', then my terminal would go berserk, and I'd have to power of.

Building for the ZX Spectrum had related problems and was easier to work with thanks to emulators.
Built using:
    zcc +zx -vn -SO3 -startup=4 -clib=sdcc_iy --opt-code-size startrek.c -o startrek_zx.bin -lm -create-app
then run on the Fuse emulator, I got this:

Note the ?'s all over the map.

Long story short, I found a very nasty bug, that is either an unpleasant obscure part of the C spec, or would appear to be a compiler bug.

It appears that in some cases, if:
1. You have an expression involving int16_t variables, and
2. the expression is used as an array index, and
2. the expression evaluates to >= 128, and
3. the array is < 256 bytes long
then the expression result will be implicitly cast to int8_t, and will be wrongly interpreted as a negative array index.

I assume that the compiler is being clever by realising that an array of <256 bytes can only ever be validly indexed
by an index that can be represented in 8 bits, but is then failing to ensure that the index is interpreted as unsigned.

Here is a program that demonstrates the bug by printing the addresses that are being accessed:

uint8_t testArr255[255]; // Fails
uint8_t testArr256[256]; // Succeeds

int16_t main()
{
    // Only if both i and j are unsigned does testArr255[i * 24 + j] work as expected.
    int16_t i, j; // Signed - this will fail in the absense of casting!

    uint16_t idx;

    i = 5;
    for (j = 4; j < 12; j++)
    {
        idx = i * 24 + j;
        printf("Index: %u %u\n", (uint16_t)idx, (uint16_t)(i * 24 + j));
        printf("Correct Addr: %u %u %u (and 256 el %u %u)\n", &testArr255[idx], &testArr255[(uint8_t)idx], &testArr255[(uint8_t)(i * 24 + j)], &testArr256[idx], &testArr256[i * 24 + j]);
        printf("Correct +1 Addr: %u (and 256 %u)\n", &testArr255[idx + 1], &testArr256[idx + 1]);
        printf("Bad Addr: %u %u %u\n", &testArr255[i * 24 + j], &testArr255[(int8_t)idx], &testArr255[(int8_t)(i * 24 + j)]);
    }

    while (1) {}
    return 1;
}

Note that as soon as the index reaches 128, the expressions in the 'Bad Addr' statement all give the wrong address.

The effect of this bug in StarTrek was to send random memory to the serial output. On the Spectrum this caused ???s.
On my RC2014, with a Grant Searle terminal, it caused chaos.

The fix/workaround for startrek was to replace (~ line 898):
        putchar(sQ[i * 24 + j]);
with
        putchar(sQ[(uint8_t)(i * 24 + j)]); // Cast essential, otherwise negative indices occur!

[Steve Baines]

Just to clarify - with the 'bad addresses', only 

   &testArr255[i * 24 + j]

is giving an unexpected result - the other two cases are simply demonstrating that the result is the same as including an explicit cast to (int8_t), thus suggesting that this is what the compiler is doing.

Since the expression is on int16_t types, I would expect the result to be interpreted as int16_t or int32_t.

Also, the fact that the indexing behaviour changes simply by changing the array length by one byte suggests a compiler bug to me.

   Cheers - Steve

[Steve Baines]

Forgot to say, these results were with last nights daily buid: z88dk-win32-20170716-dc252a4-9188.zip

[phillip.stevens]

I have now managed to build and run a working Eliza on an RC2014 with standard ROM, using basic_dcio:
1. zcc +rc2014 -subtype=basic_dcio -v -clib=sdcc_ix -m -SO3 --c-code-in-asm --list eliza.c -o eliza_rc2014_basic32_dcio.bin -create-app -lm

Great to hear, and see!

Just to note that the preferred library setting is -clib=sdcc_iy, because of the way that sdcc operates. It’s always preferable to use the “sdcc_iy” version of the library because this gives sdcc sole use of ix for its frame pointer while the library uses iy. If “sdcc_ix” is selected, sdcc and the library must share ix which means the library must insert extra code to preserve the ix register when it is used. This means the “sdcc_iy” compile will always be smaller and faster.

 

4. hdoke &8049, &h9000   // This was an ordeal in itself - finding that the address is 0x8049, not 0x8048, nor 0x8224.

I was beginning to think that I'd sold you a dud, but in fact the hexload.bas program does actually refer to 0x8049.

I'll look around to find where the bad info on 0x8048 is located.

0x8048 contains the actual JP instruction, rather than the destination address.

The relevant code fragment from NASCOM Basic is here, where the USR (X) jump instruction is set initially to point to the FCERR function, in NASCOM Basic.

; BASIC WORK SPACE LOCATIONS

WRKSPC  .EQU    8045H               ; BASIC Work space
USR     .EQU    WRKSPC+3H           ; "USR (x)" jump
OUTSUB  .EQU    WRKSPC+6H           ; "OUT p,n"
OTPORT  .EQU    WRKSPC+7H           ; Port (p)

; INITIALISATION TABLE -------------------------------------------------------

INITAB: JP      WARMST          ; Warm start jump <- this table is written to 8045H

        JP      FCERR           ; "USR (X)" jump (Set to Error)

        OUT     (0),A           ; "OUT p,n" skeleton

; BASIC ORIGIN ---------------------------------------------------------------

COLD:   JP      STARTB          ; Jump in for cold start

WARM:   JP      WARMST          ; Jump in for warm start

STARTB: 

        LD      IX,0            ; Flag cold start

        JP      CSTART          ; Jump to initialise

        .WORD   DEINT           ; Get integer -32768 to 32767

        .WORD   ABPASS          ; Return integer in AB

CSTART: LD      HL,WRKSPC       ; Start of workspace RAM

        LD      SP,HL           ; Set up a temporary stack

        JP      INITST          ; Go to initialise

INIT:   LD      DE,INITAB       ; Initialise workspace

        LD      B,INITBE-INITAB+3; Bytes to copy

        LD      HL,WRKSPC       ; Into workspace RAM

COPY:   LD      A,(DE)          ; Get source

        LD      (HL),A          ; To destination

        INC     HL              ; Next destination

        INC     DE              ; Next source

        DEC     B               ; Count bytes

        JP      NZ,COPY         ; More to move

The 0x8224 address comes from the revised origin location in my HexLoadr ROM, with performance optimised ACIA code and integrated Hexload code requiring more space. Sorry that was confusing.

 

I also managed to get StarTrek working - which actually revealed a very nasty bug.

I also couldn't get it working, because as you point out it is too large for an origin of 0x9000.

But using the HexLoadr ROM, and leaving Basic only a few bytes, I could set the program origin down to 0x8400 and fit it in with the additional space.

 

Long story short, I found a very nasty bug, that is either an unpleasant obscure part of the C spec, or would appear to be a compiler bug.

It appears that in some cases, if:
1. You have an expression involving int16_t variables, and
2. the expression is used as an array index, and
2. the expression evaluates to >= 128, and
3. the array is < 256 bytes long
then the expression result will be implicitly cast to int8_t, and will be wrongly interpreted as a negative array index.

Good catch.

Something to push upstream to sdcc.

[A A]

On Sunday, July 16, 2017 at 5:37:09 PM UTC-6, Steve Baines wrote:

It appears that in some cases, if:
1. You have an expression involving int16_t variables, and
2. the expression is used as an array index, and
2. the expression evaluates to >= 128, and
3. the array is < 256 bytes long
then the expression result will be implicitly cast to int8_t, and will be wrongly interpreted as a negative array index.

That is indeed a compiler bug.
https://sourceforge.net/p/sdcc/bugs/2632/

We'll just push it on philip at sdcc :D
 

[Steve Baines]

Hi Philip,

On Monday, July 17, 2017 at 2:37:59 AM UTC+1, phillip.stevens wrote:

I have now managed to build and run a working Eliza on an RC2014 with standard ROM, using basic_dcio:
1. zcc +rc2014 -subtype=basic_dcio -v -clib=sdcc_ix -m -SO3 --c-code-in-asm --list eliza.c -o eliza_rc2014_basic32_dcio.bin -create-app -lm

Great to hear, and see!

Yes!
 

Just to note that the preferred library setting is -clib=sdcc_iy, because of the way that sdcc operates. It’s always preferable to use the “sdcc_iy” version of the library because this gives sdcc sole use of ix for its frame pointer while the library uses iy. If “sdcc_ix” is selected, sdcc and the library must share ix which means the library must insert extra code to preserve the ix register when it is used. This means the “sdcc_iy” compile will always be smaller and faster.

Ok, thanks.
 

 4. hdoke &8049, &h9000   // This was an ordeal in itself - finding that the address is 0x8049, not 0x8048, nor 0x8224.

I was beginning to think that I'd sold you a dud, but in fact the hexload.bas program does actually refer to 0x8049.

I'll look around to find where the bad info on 0x8048 is located.

0x8048 contains the actual JP instruction, rather than the destination address

Yes, as I eventually realised!
Sorry, but I can't now find where I got the impression that 0x8048 contained the jump target address, rather than the correct (for standard ROM) value of 0x8049.  This info is frustratingly missing from my notes.
I think I'd (mis)read somewhere about how usr(0) causes a jump to 0x8048, and wrongly interpreted that as meaning that it jumped to the address stored at 0x8048.
This is probably because I had in mind the ZX Spectrum system variables area, and assumed that 0x8048 contained a system variable for where to jump on user code, not directly executable code.

The 0x8224 address comes from the revised origin location in my HexLoadr ROM, with performance optimised ACIA code and integrated Hexload code requiring more space. Sorry that was confusing.

Again, I realised after a while that the address changed between the HexLoadr ROM and the standard ROM.
I haven't actually tried the HexLoadr ROM yet - something for next weekend. :-)  I very much want to be able to use the RC2014 standalone without having to have another
computer attached to talk to it, so I've been using SD cards so far.
 

 I also managed to get StarTrek working - which actually revealed a very nasty bug.

I also couldn't get it working, because as you point out it is too large for an origin of 0x9000.

But using the HexLoadr ROM, and leaving Basic only a few bytes, I could set the program origin down to 0x8400 and fit it in with the additional space.

Ok, I'll try that. Would be nice to restore the instructions. :-)
 

[Steve Baines]

Thanks for filing the report - I wouldn't have known where to send it.
I can imagine this bug causing all kinds of chaos, so glad to have at least uncovered it and got a repeatable test case.

[phillip.stevens]

The 0x8224 address comes from the revised origin location in my HexLoadr ROM, with performance optimised ACIA code and integrated Hexload code requiring more space. Sorry that was confusing.

Again, I realised after a while that the address changed between the HexLoadr ROM and the standard ROM.
I haven't actually tried the HexLoadr ROM yet - something for next weekend. :-)  

I very much want to be able to use the RC2014 standalone without having to have another computer attached to talk to it, so I've been using SD cards so far.
 

 I also managed to get StarTrek working - which actually revealed a very nasty bug.

I also couldn't get it working, because as you point out it is too large for an origin of 0x9000.

But using the HexLoadr ROM, and leaving Basic only a few bytes, I could set the program origin down to 0x8400 and fit it in with the additional space.

Ok, I'll try that. Would be nice to restore the instructions. :-)

Hi Steve,

As the -subtype=basic_dcio build is now optimised for the bog-standard rc2014 Full Monty or Mini kit, there are a few things you'll need to do to get this origin shift using HexLoadr to work for you.

The default origin for the code is set to 0x9000, with the C stack also set to originate at 0x9000 (z80 decrements before stack push, so there're no conflict).

This was done because there's about 1,600 bytes left below 0x9000 after the hexload.bas programme, and its assembler working tool, are loaded.

The heap is set to fill the space from the end of the code through to 0xFFFF.

Create a file to contain pragmas. Call it mypragma.inc, or whatever you like. In the file you'll need the following lines to appear.

#pragma output CRT_ORG_CODE           = 0x8400  // new origin.
#pragma output REGISTER_SP            = 0  // stack origin is 0 (0xFFFF).
#pragma output CLIB_MALLOC_HEAP_SIZE  = -1 // -1 has the crt automatically place the heap between the end
                                           // of the bss section and the bottom of the stack
                                           // (now located in its usual position above the bss).

Then from the command line add the following incantation -pragma-include=mypragma.inc to your usual compilation instructions.

The HexLoadr ROM can be encouraged to allocate only about 150 bytes to BASIC, by setting Memory Top? 33790

and then when you load the program, you'll need to manually set the USR(0) location using your doke &h8224, &h8400 instruction at the Basic prompt.

Then, you should be set.

Enjoy, Phillip

[A A]

On Monday, July 17, 2017 at 3:34:59 AM UTC-6, phillip.stevens wrote:

Create a file to contain pragmas. Call it mypragma.inc, or whatever you like. In the file you'll need the following lines to appear.

#pragma output CRT_ORG_CODE           = 0x8400  // new origin.
#pragma output REGISTER_SP            = 0  // stack origin is 0 (0xFFFF).
#pragma output CLIB_MALLOC_HEAP_SIZE  = -1 // -1 has the crt automatically place the heap between the end
                                           // of the bss section and the bottom of the stack
                                           // (now located in its usual position above the bss).

Then from the command line add the following incantation -pragma-include=mypragma.inc to your usual compilation instructions.


Although with startrek.c specifically, the heap should be disabled ( CLIB_MALLOC_HEAP_SIZE = 0) so that it doesn't take up memory space.  There are pragmas in startrek.c that do this but your pragma file will override those.  Pragma priority is: 1- specified on the compile line  2- specified in a pragma file  3- specified in a .c source file.

For compiles where the crt automatically generates a heap ( CLIB_MALLOC_HEAP_SIZE is negative), there is a heap size calculation done at runtime.  If the heap size comes out negative, ie there is no space for a heap, the program will just terminate.  When CLIB_MALLOC_HEAP_SIZE = -1, the crt creates a heap that extends from the end of your program to the bottom of the stack (the bottom of the stack is the current value of SP minus headroom CRT_STACK_SIZE bytes which is typically 256 or 512).  When CLIB_MALLOC_HEAP_SIZE < -1, its absolute value is taken as the address of the last byte of the heap and the crt will try to make a heap from the end of your program to that address.   The other options are 0 which eliminates the heap and a positive value which will create a heap of that size in the bss section.