I programmed in 6502 assembly exclusively for two years straight, back in the 80s, but I don't think any individual program exceeded 500 instructions (a few KB of final binary). Back then, on my Atari 800XL, it was mostly small experiments as I learned to use the machine. Each experiment unlocking a new mystery... and then I'd move onto the next challenge.

There's a wide range of experience this forum, with people having personally built everything from blinky LEDs to operating systems and languages.

It might be fun to hear about members' largest 65xx programming feats (as opposed small projects that integrated large external works).

Share your stories. For people who have implemented larger systems, some questions or areas that might be fun to talk about:
- Was the project scale/function known going in, or did the project evolve over time?
- Was the program modular, with each module developed and tested within a test environment and then integrated into the whole, or were new things added in-place?
- Did you make heavy use of macros?
- Was the project spread around multiple independently assembled source files and then combined using a linker to produce a single binary, or did you use independent binaries with jump tables, or did you include all source files into one large file for assembly, or something else?
- If your system processed I/O and had timing elements, could you exhaustively test all the code paths prior to integration, or did you cook up a test environment that let you simulate events, or something else?
- Did your program include telemetry, stats, counters or other run-time data to let you examine the run-time condition of the system? If so, how was that data extracted and observed?
- Did your system include an interface for debugging and/or examination? If so, and if your system included real-time elements (e.g. service I/O or dealt with critical timing), did you encounter any particular conflicts between debug/run-time.

I'm probably at the few hundred instructions level too - for all my great interest in the 6502 I don't have much code to show for it. The beeb816 project has a boot rom and maybe half the code is mine. It's only 2.5k and that includes quite a lot of strings. Didn't use macros, modules, testing, debugging... There is a makefile, which ends up doing something like this:

I started out writing games for the Commodore pet in assembler then moved on to applications and ROMs for the BBC Microcomputer. My biggest co-authored ROM was a database package in 16K of ROM. At various times we ran out of memory space and had to rewrite sections to make the code smaller and compress all the text strings.

_________________
Andrew Jacobs
6502 & PIC Stuff - http://www.obelisk.me.uk/
Cross-Platform 6502/65C02/65816 Macro Assembler - http://www.obelisk.me.uk/dev65/
Open Source Projects - https://github.com/andrew-jacobs

I'd be interested to know, BitWise, did you have a process for building and testing that database package? Was it modular?

_________________
http://WilsonMinesCo.com/ lots of 6502 resources
The "second front page" is http://wilsonminesco.com/links.html .
What's an additional VIA among friends, anyhow?

Thanks for the info, Garth - very interesting. Are the code snippets in that article representative of your macros? If so, they're pretty slick.

_________________
http://WilsonMinesCo.com/ lots of 6502 resources
The "second front page" is http://wilsonminesco.com/links.html .
What's an additional VIA among friends, anyhow?

I worked on a fairly large Ethernet switch product in the late 90s (one of the first Gigabit Ethernet switches) that used cooperative multitasking much like this. There were 30+ modules, each scheduled via a message queue. Each time around the "big loop", any module with a non-empty message queue had its entry-point invoked. The module ran to completion and then returned. Simple 'C'. No "context" to save or restore. Switches like these run all sorts of applications and protocols. Everything had to be state-machine driven as there was no escape within a single call chain (no threading). We did it... but it gave me a new appreciation for OSes that maintain thread-state. Eventually (after 3 or so years) one of the engineers implemented a thread-state mechanism that would allow a single run of code to say, 'yield()', which would push a message to the front of the module's message queue and then return to the big loop. When the big loop re-entered the module, its state would be restored and it would continue from the "return" of yield. It was all still co-operative, but it permitted more straightforward code without forcing everything to be an FSM. It was a cute hack, but wasn't used beyond a few proofs of concept as the whole team were hardened to FSMs by then.

Good times.

My largest project would have been that time I attempted to write a "tracker" style music program for the SFX Sound Expander on the C64. The Sound Expander used a chip, YM3526 (OPL), that was the direct ancestor of the YM3812 (OPL2) that was used in AdLib (-compatible) sound cards on the PC. It's a fairly rare expansion module, and there were really no programs that made use of it.

I got as far as having a very simple instrument editor and single-channel music playback that would play "patterns" (phrases?) sequentially. The thing that kept the project from going further was that I would have had to write a more general GUI in order to really make it useful, and that was just too complicated and boring.

It might have been a thousand lines or so of code. All written in "Turboassembler" on the C64, all in one file, no macros, no modularity to speak of.

Development was mostly in the style of "write a few lines of code, assemble, run, inspect memory, reset machine, restart assembler, write some more..." so none of that modern debugger nonsense. This actually works reasonably well when you can instantly see the results of what you are doing. At least as long as you can keep everything in memory and can just keep going. If I'd had to reload the assembler and source for every iteration I wouldn't have gotten past even playing one note.

Very cool. I wrote a YM2149 emulator in ARM assembly for the Nintendo Gameboy Advance for something I did back in '03. I was never really into sounds effects and music back in the 80s, and whenever I'd try to do something on the 8-bit Atari, I tended to get little more than a farting sound. I was often amazed at what people could do with trackers.

My kind of guy! Yeah!


My adaptation and subsequent enhancements of the VTL-2 mini-interpreter came to about 1K lines of source (and about 1K bytes of executable), plus or minus, but I used a cross-assembler and emulator to ease the process somewhat. I had to find a few bugs with strategic break-points, and a few others by hand-simulating parts of the source. All in all, a satisfying little journey ... not too easy, not too difficult.

Mike B.

:-)

I didn't do anything meaningful with sound in the 80s either, the music editor project would have been in the mid-late 90s.

My memories of early sound programming are two things: First, going through the BASIC examples and typing in the various programs that would go "bing" in slightly different ways; and then later on piping audio into the SID chip's audio input and trying to read it out with PEEK commands. (That didn't work.)


Off topic: It arguably wasn't really a tracker project either, strictly speaking, but I suppose that depends on the definition. A tracker, as I've always understood it, arranges music into multi-channel patterns and then lets you string together those patterns in a sequence.

There is also another flavor of music editor that was (less) popular, which instead would use single-channel patterns of variable length, and let you do transposition of those in addition to defining the sequence in which they played, for each channel independently. This saved memory compared to doing things the tracker way, where you might manually copy a drum track into multiple patterns, or copy-and-transpose a bass line.

I believe this style originated on 8-bit systems; at least Rob Hubbard's music routine for the C64 did something very similar. He would have banged in music data as hex values in a machine code monitor though, no editor needed!

That was that style of music editor I was going for.


Somewhat back on topic, C= Hacking issue 5 (1993) did have a commented disassembly of Hubbard's routine. For someone who grew up on C64 music, this was like finding the holy grail!

http://www.ffd2.com/fridge/chacking/c=hacking5.txt

_________________
http://WilsonMinesCo.com/ lots of 6502 resources
The "second front page" is http://wilsonminesco.com/links.html .
What's an additional VIA among friends, anyhow?

Funny the nostalgic detours this conversation is taking. That YM2149 emulator I wrote on ARM was for the purpose of playing a Rob Hubbard tune that he'd written for an Atari ST game.
Fascinating!

I envy your musical ability. I did two years of piano in my 20s, but things came up and I never got back to it. Nowadays I could make excuses for why I won't take it up again, but in all honesty it simply isn't the priority that the romanticized version of me would like it to be.

I have a MIDI keyboard that I hooked up to my Atari ST for a time. I didn't get much out of it, but it was cool to play with.

It sounds like you and magetoo should get together on a project!