Designing / Engineering a Biggish M/L Program

[Robbie]

I was just wondering how people go about designing / engineering a biggish M/L Program.

Do you design the whole thing on paper (or some kind of s/w package) first? Pseudocode? At which point do you define variables etc? Do you hack proof of principles early-on?

Do you use a Cross Assembler and develop on a modern computer? At what point (if ever) do you switch to 'real' hardware?

When and how do you test subroutines? Debugging is a bit of a 'mare. How do you approach it?

It's quite a daunting process, and I was just wondering how you go about it.

[chysn]

Do you design the whole thing on paper (or some kind of s/w package) first? Pseudocode? At which point do you define variables etc? Do you hack proof of principles early-on?

I do start with pencil and paper. Specifically, I use the 3.5" x 5.5" Field Notes graph paper books, usually about one per project. I'll use this to write ideas for features, design data structures, sketch out custom characters, write subroutines that I'll need, sometimes write actual code. I can take these books anywhere I go, and for me it's a lot more immediate than any kind of electronic note-taking tool.

I definitely make proofs-of-concept on my real VIC for things I haven't done before. Helix Colony was the first time I've used single-pixel movement on a VIC-20, so I wrote those routines (left/right, up/down) with wAx as BASIC, which makes it easy to add and move around code.

Do you use a Cross Assembler and develop on a modern computer? At what point (if ever) do you switch to 'real' hardware?

I use a cross-assembler (XA) for development and wAx for debugging and proof-of-concept code.

I have a lot of routines I've built up in advance. So, things like joystick reading, hardware initialization, sound and music, these things I'll add to my cross-assembler file. But the VIC-20 doesn't lend itself to re-usable "library" code. Memory is tight, so everything is bespoke in the end. But I'll at least start with things I've used before, and modify them for the project at hand.

I start testing in VICE when there's a main loop and something to control, or move around. I write (or, these days, modify) a build shell script for the project. This will assemble with XA, then add a two-byte header, then copy the resulting file to my virtual device directory for VICE. The testing on my real VIC comes later and later with every project I do. Helix Colony was almost feature-complete before I tried it on my real VIC.

When and how do you test subroutines? Debugging is a bit of a 'mare. How do you approach it?

It depends on the complexity of the subroutine. wAx is designed to facilitate automated testing of subroutines with BASIC. This gets more useful the more complex the operations become. An example of this kind of test coding is in the GitHub repo for wAx. There's a test suite in BASIC that I ran before each push, to make sure that the assembler--every instruction, every addressing mode, every operand type, every symbolic feature--generates the correct binary output. I never had to worry about introducing errors that would compromise the assembled code in subtle, undetected ways.

The basic two steps are to (1) set up memory and register conditions for a test, and (2) compare the correct result to the one that your subroutine yields. Take a look at this video: https://www.youtube.com/watch?v=ej9Uhqg6QYg

This kind of thing is why wAx has the ability to change the BASIC stage (memory range). You can have various test programs and other things in memory.

Breakpoints are also important to my debugging process, the ability to see the values of registers and memory at selected points. This was difficult in VICmon because my games use custom characters, and when I'd hit the breakpoint, I couldn't read the register output. With wAx, I can hit STOP/RESTORE after the break to reset the character set, then use the register (;) tool to see the values of the registers as they were at the breakpoint. With VICmon, register values are lost when you re-enter it after STOP/RESTORE.

It's quite a daunting process, and I was just wondering how you go about it.

I tried to keep this post short-ish, but there's obviously a lot more to say. My approaches and craftsmanship constantly evolve, too, and hopefully always will.

[beamrider]

First I tend to hack together proof of concept code for anything I'm unsure of technically.

I also then use a notebook for rough outlines and pseudo-code, after which I write the skeleton of the code as a tree of jsr calls and fill them in as I go.

For anything complex where multiple things are happening in parallel I find coding directly in assembler quite tedious so now I tend to write the game logic in a proprietary script with a simple execution engine that acts as a bunch of state machines manipulating sprites and sounds effects etc.

I tend to use cross-assembly and VICE exclusively, never debugged on the real machine. I also use my own graphics designer .

My assembler of preference is CA65. One thing I do make use of is segmentation and adding watches in VICE to trap any code writing to areas of memory it isn't supposed to.

[Kweepa]

I tend to just dive in and start writing the bits that interest me, and then sort it out later.
That could be why I have a drive full of unfinished projects though.

[Robbie]

I tend to just dive in and start writing the bits that interest me, and then sort it out later.
That could be why I have a drive full of unfinished projects though.

Yeah, I tried that.
Probably explains all these grey hairs!

Time to get out the notebook and pen.