Traveller Trader

[robject]

Here are two versions of my Traveller Trader program.

I. Prototype

The first one is the Proof Of Concept. It's in BASIC (!), it's very primitive, but lets you fly around the Spinward Marches, and buy and sell some speculative goods.

https://www.commanderx16.com/forum/index.php?/files/file/100-traveller-trader-mini/

The world data is stored in piles of DATA statements, compressed to a certain degree, largely within the limits of PETSCII. You can probably break out of the program and do a LIST to see them.

II. Better

The second one is the one I'm working on. I'm trying to give it a decent UI, but the jury is out. I'm also trying to give it decent functionality -- again, not there yet. But, it does let you visit the Marches and Deneb, books passengers and freight, lets you do some speculative cargo, and forces you to buy fuel.

Ah, and this one is in C.

https://www.commanderx16.com/forum/index.php?/files/file/102-traveller-trader-wip/

The world data is stored in packed binary format and loaded into the machine's RAM banks, which means my program code can be larger than the BASIC one.

 

[kilemall]

Which version does this support, T5?

 

[ShawnDriscoll]

Oh, 6502. It's making a comeback of a sort? You're running C on a 6502? Yikes.

 

[robject]

Oh, 6502. It's making a comeback or a sort? You're running C on a 6502? Yikes.

Think of it like a microcontroller. Sure, the 6502 isn't designed with C in mind. But... not a big deal. It's on the bare metal, nearly. You just have to be aware of the hardware, so to speak.

 

[whartung]

Think of it like a microcontroller. Sure, the 6502 isn't designed with C in mind. But... not a big deal. It's on the bare metal, nearly. You just have to be aware of the hardware, so to speak.

Can be a big deal, depends on what you're trying to do.

C on the 6502 makes for some pretty lousy 6502. Same with the Z80. Both are pretty notorious for being bad hosts for high level language compilers.

There's a reason things like UCSD Pascal and Forth and, of course, BASIC were popular back in the day -- code density.

The amount of code functionality you could get in a few bytes of RAM was very high.

Certainly higher than C.

Consider adding two 16 bit numbers in Forth take 21 bytes for the add routine, plus 10 bytes for the Forth "code" to call it. The 21 bytes is reused for every add, so each simple addition really costs 10 bytes. UCSD Pascal is similar. BASIC tends to consume more since many don't use integer values in the tokenized form. if you put "a = 1234 + 4567" in C64 BASIC, the numbers are stored as characters.

In C, it's going to cost more than that.

Consider cc65 (popular 6502 C compiler):

        ; i = baz(i, c);

       	lda	_i 		; get 'i', low byte
       	ldx	_i+1		; get 'i', hi byte
       	jsr	pushax		; push it
       	lda	_c 		; get 'c'
       	ldx	#0 		; fill hi byte with 0
       	jsr	pushax		; push it
       	ldy	#4     	       	; arg size
       	jsr	_baz		; call the function
       	sta	_i  		; store the result
	stx	_i+1

That's 26 bytes.

In Forth that would be:

    I @ C @ BAZ I !

That's 18 bytes (of course, in Forth, you don't necessarily use variables this way). UCSD is comparable.

This is one reason the p-machine models were quite popular on small machines.

It's also a reason systems like Turbo Pascal made recursion a configuration option (default off), without recursion (and thus no re-entry) you could use static memory locations for procedure parameters, rather than the stack. Saves code that way (you can do this with C using static arguments in your functions). ACTION!, a language for the Atari had no support for recursion.

Now, 64K on a C64 may well be "more than enough" memory to where this is not a consideration, but if you want more room for data, code density can be an issue.