Making Programming the Lynx a little Easier

[+karri]

I am in. It would be very useful for me.

 

Last time I used Windows there was also a collection of native unix tools that worked well with Power Shell without need for Cygwin.

[pixelperfect]

Awesome, sounds like we're all on the same track now! Excited to see what comes

[Turbo Laser Lynx]

I want to join in too and do what I can to help. Some simple game-template(s) would first come to mind. Karri's template upon which shaken and pegsolitaire are built is already superb, but I could make stuff even more simple and put in lots of comments. Later I could add basic templates for a few common game types, like e.g. moving a character around the screen (rpg style), having a character jump on platforms (platformer style), scrolling, step by step guide for loading from cart etc.

 

Btw. to have everything that's needed for creating a game it would make sense to investigate how to have one sound channel for sfx and three for chipper, or the fancier way to pause one channel when a sfx occurs. (Personally I find the pausing thing slightly distracting in old games). Obviously one could program the game to let the user choose music or sfx too.

Edited September 14, 2016 by Turbo Laser Lynx

[+karri]

Getting LX superb tutorials to work flawlessly with the current version of atarilynx cc65 would be an excellent goal.

 

I already know about one myth that proved to be wrong. In EPYX documentation they say that they messed up partity and because of that the communication is not compatible with the rest of the world. I also took this for granted and the same lies are in the cc65 sources. But the truth seems to be that the Lynx works perfectly with any industry standard serial ports. The only problem is the number of stop-bits. The Lynx has just one.

 

I would very much like to go through all the Lynx specific routines in cc65 and create some tutorial about how to use them. The clock() was one. There is also things here that should not belong to the compiler. Like zero page reservations for abcmusic pointers, eeprom library routines.

 

Actually we could discuss functionality.

 

What kind of Lynx routines should be incuded as part of the compiler?

- fadein/fadeout/fade for palette transitions

- chipper / abcmusic

- ComLynx communications protocol

- eeprom drivers for all chips used

- clock() for interrupt controlled time

- 3D math package using Suzy hardware. This actually exists. Written by Thomas Harte.

 

Or should everything that is not absolutely necessary go into lynx/contrib? That would keep the compiler clean and stable. But you need to download the sources to your own game and compile them by yourself.

[pixelperfect]

I think the question should be: is this feature required to make a full game (say something as simple Tetris)? My thought is the installer should give a newcomer all the parts needed to make a full game (compiler, sprites, sfx, music, multiplayer). Maybe we can get the best of both worlds, like the installer includes everything together, but if you're a pro you can just download specific routines from atarilynx and compile what you want for something slimmer? My hope is stability will eventually come from everyone using the exact same version, running into problems, and then getting them fixed so the next person that uses the installer won't run into it. And that said it sounds like if there's stuff in there not in use by Lynx at all then perhaps it would be best to cut it?

 

So it sounds like our top priorities are:

 

- Compiling atarilynx CC65 cross-platform

- Compiling games with make instead of nmake.exe cross-platform

- New Game Template (Visual Studio) using atarilynx CC65 and make

- Installer with compiled sources and New Game template

- Update LX tutorials to work with installer

 

And then from there of course we can add more platform support, tools, documentation, samples, tutorials, etc. Did I miss anything?

Edited September 14, 2016 by pixelperfect

[visyli]

Hey,

 

just wanted to say that an easy install would be extremely interesting to me as a demoscene coder that's been a while interested in Lynx dev...

Terveiset Karrille tampereen demoskenevahvistuksilta x)

[+karri]

Nice to meet you. Thanks for the greetings in Finnish. So we have a scattered Lynx community in Espoo, Tampere, Vaasa.

 

Perhaps we need to establish an user group

 

Which brings me to the topic. It was so fun to meet all you Lynx guys in Amsterdam for the Amiga 30 years meeting. Perhaps we could hitch-hike with the Amiga folks if they arrange a 35 year party. Lynx would be 30 then.

[ThomH]

I'm a million years late to this, but the main obstacle for me isn't writing code, it's testing code — especially with Handybug being limited to Windows. A couple of ideas:

 

1) a Lynx-on-your-computer library. Exposes all the same functions as CC65 ordinarily does, but targets Windows and/or Linux and/or the Mac. So I write my code, complete with whatever tests I like, then can run with my normal debugger attached.

 

2) an assembler that allows one to apply unit tests.

 

I've considered a few ways around of doing this, and I'm starting to think the best solution is to kill the traditional assembler pipeline, converting the assembling logic from something you call from the command line to something you call from your high-level language of choice, and throwing in a 65SC02 emulator. So e.g. instead of:

 

; I intend that this method does task X when given inputs M, N, O.

routine:

...

RTS

 

And invoking my assembler and loading it up, and testing it, I'd have something more like, in C-ish pseudocode:

 

Fragment *fragment = assemble(STRINGIFY(

routine:

...

RTS

));

for(m in possible Ms) {

for(n in possible Ns) {

for(o in possible Os) {

Processor *processor = new_processor();

set_state(processor, m, n, o);

perform_fragment(processor, fragment);

if(get_state(processor) != expected_state) {

// throw error

}

}

}

}

...

Linker *linker = new_linker();

add_fragment(linker, fragment1);

(etc)

...

Cartridge *output = new_cartridge(target_name);

write_standard_booter(output);

write_object_code(get_output(linker));

Which probably means I don't need to visit an emulator at all until I've already got a large proportion of my code working, that my testing is not limited to the scenarios I manually produce, and that I can go back much later and optimise parts while being confident I'm not introducing edge-case breakages to the whole. I can wait to hit the emulator until I've got actual gameplay to experiment with, unless somebody here knows how to write a test case for "is this fun?".

EDIT: I guess the other advantage of having such an assembler-as-a-library would be that you'd get a whole bunch of higher-level functionality for free by just doing the computations in your high-level language. I'm thinking of things like building a trig table or performing a PNG -> native image conversion. The assembler could be relatively simple, probably just keeping track of labels and offering basic expression support for label manipulation (like LDA label+2).

Edited March 7, 2017 by ThomH

[+karri]

Have you tried adding the flag -g to your cc65 command? The only thing needed is to make a debugger understand the .dbg messages in the generates assembler source file.

;
; File generated by cc65 v 2.13.9
;
        .fopt           compiler,"cc65 v 2.13.9"
        .setcpu         "65C02"
        .smart          on
        .autoimport     on
        .case           on
        .debuginfo      on
        .importzp       sp, sreg, regsave, regbank
        .importzp       tmp1, tmp2, tmp3, tmp4, ptr1, ptr2, ptr3, ptr4
        .macpack        longbranch
        .dbg            file, "hello.c", 327, 1488969912
        .dbg            file, "/usr/local/lib/cc65/include/lynx.h", 7292, 1479370323
        .dbg            file, "/usr/local/lib/cc65/include/_mikey.h", 5329, 1479370322
        .dbg            file, "/usr/local/lib/cc65/include/_suzy.h", 11134, 1479370322
        .dbg            file, "/usr/local/lib/cc65/include/tgi.h", 10603, 1479370323
        .dbg            file, "/usr/local/lib/cc65/include/tgi/tgi-error.h", 3529, 1479370323
        .dbg            file, "/usr/local/lib/cc65/include/joystick.h", 5158, 1479370323
        .dbg            file, "/usr/local/lib/cc65/include/6502.h", 5114, 1479370322
        .forceimport    __STARTUP__
        .dbg            sym, "lynx_stdjoy", "00", extern, "_lynx_stdjoy"
        .dbg            sym, "lynx_160_102_16", "00", extern, "_lynx_160_102_16"
        .dbg            sym, "tgi_install", "00", extern, "_tgi_install"
        .dbg            sym, "tgi_init", "00", extern, "_tgi_init"
        .dbg            sym, "tgi_setcolor", "00", extern, "_tgi_setcolor"
        .dbg            sym, "tgi_outtextxy", "00", extern, "_tgi_outtextxy"
        .dbg            sym, "tgi_ioctl", "00", extern, "_tgi_ioctl"
        .dbg            sym, "joy_install", "00", extern, "_joy_install"
        .import         _lynx_stdjoy
        .import         _lynx_160_102_16
        .import         _tgi_install
        .import         _tgi_init
        .import         _tgi_setcolor
        .import         _tgi_outtextxy
        .import         _tgi_ioctl
        .import         _joy_install
        .export         _main
...
.segment        "CODE"

.proc   _main: near

        .dbg    func, "main", "00", extern, "_main"

.segment        "CODE"

        .dbg    line, "hello.c", 9
        lda     #<(_lynx_stdjoy)
        ldx     #>(_lynx_stdjoy)
        jsr     _joy_install
        .dbg    line, "hello.c", 10
        lda     #<(_lynx_160_102_16)
        ldx     #>(_lynx_160_102_16)
        jsr     _tgi_install
        .dbg    line, "hello.c", 11
        jsr     _tgi_init
        .dbg    line, "hello.c", 12
        cli
        .dbg    line, "hello.c", 13
        jmp     L0024
L0024:  lda     #$04
        jsr     pusha
        ldx     #$00
        lda     #$00
        jsr     _tgi_ioctl
        stx     tmp1
        ora     tmp1
        jne     L0024
        .dbg    line, "hello.c", 15
        lda     #$0A
        jsr     _tgi_setcolor
        .dbg    line, "hello.c", 16
        ldx     #$00
        lda     #$0A
        jsr     pushax
        ldx     #$00
        lda     #$0A
        jsr     pushax
        lda     #<(L002D)
        ldx     #>(L002D)
        jsr     _tgi_outtextxy
        .dbg    line, "hello.c", 17
        lda     #$04
        jsr     pusha
        ldx     #$00
        lda     #$01
        jsr     _tgi_ioctl
        .dbg    line, "hello.c", 18
        jmp     L0034
L0034:  jmp     L0034
        .dbg    line, "hello.c", 20
        ldx     #$00
        lda     #$01
        jmp     L001A
        .dbg    line, "hello.c", 21
L001A:  rts
        .dbg    line

.endproc

And the source hello.c

#include <lynx.h>
#include <tgi.h>
#include <joystick.h>
#include <6502.h>


int main()
{
  joy_install(&lynx_stdjoy);
  tgi_install(&lynx_160_102_16);
  tgi_init();
  CLI();
  while (tgi_busy())
    ;
  tgi_setcolor(COLOR_GREEN);
  tgi_outtextxy(10, 10, "Hello World!");
  tgi_updatedisplay();
  while (1)
    ;
  return 1;
}

[ThomH]

 

Have you tried adding the flag -g to your cc65 command? The only thing needed is to make a debugger understand the .dbg messages in the generates assembler source file.

...

 

Job one would actually be to make any debugger that runs away from Windows but at the cost of a more complicated workflow that does lend itself to a CPU+traps unit-testing route, which would give 70% of the benefit for about 10% of the work.

[+karri]

Code:Blocks has a fairly open architecture that should be able to host both a compiler and a debugger. It is also cross platform.

 

The other obvious candidate would be Eclipse.

[LX.NET]

You can also have a look at Visual Studio Code, which has a good extensibility story and is cross-platform on Linux, Windows and OSX. There's a whole lot of open-source extensions already. I might try to get CC65 up and running in it as a light-weight alternative to Visual Studio 2015 (I mean Visual Studio 2017 since yesterday )

[ThomH]

I was referring more to the absence of Handybug or anything like it other than in Windows but, in any case, I'd be surprised if you could plug it into anything.

 

If I were writing C, I'd probably knock up my own Lynx-on-computer simulation library to cover whatever I'd put on top of the cc65 libraries.