How did they code ML games back in the old days ?

[martin_f]

I have often wondered how ML games were programmed for the VIC back in the 80's.

Did they have assemblers back then that supported labels, thus not having to hard code addresses ? Or did they even cross assemble on another machine, if so what would the likely machine have been ?

I couldn't imagine using something like VIC-MON to write games like jetpac or perils of willy, it would have been tortuous.

I am just getting back into ML programming for the vic, and am cross assembling on the PC. A few years back however when I first got into it, I started disassembling jetpac to get some ideas of how things were done, and I must say. What little I did get done, I got the impression that they may well have used something like vic-mon, as the code was all over the place, with lots of gaps (unused bytes).

Its amazing what the coders back then did manage to prduce I reckon.

Cheers

Martin

[Boray]

I have an old original tape from HES called "6502 professional development system" that is two separate programs, one editor and one assembler. But I have never used them. I usually just use my HESMON cartridge... But I have never made a very long machine language program on the vic.... Usually just some small routines I call from basic.

Another aproach is to write the whole program on paper first (more or less), and then start using a ml monitor....

/Anders

[Leeeeee]

I have often wondered how ML games were programmed for the VIC back in the 80's.

By hand, on paper

Did they have assemblers back then that supported labels, thus not having to hard code addresses ?.

We dreamed of assemblers - any sort.

Or did they even cross assemble on another machine.

Other machine? What other machine? Most of us only had one machine, the one we were developing for.

I couldn't imagine using something like VIC-MON to write games like jetpac or perils of willy, it would have been tortuous..

Most of us didn't have any monitor programs, what we did was assemble bits of code, by hand, and convert them to BASIC program DATA statements and poke them into memory. Then we could save that block to tape (as BASIC and as binary). Once each part was tested and debugged a new binary and BASIC loader for the work so far would be made.

In spite of this we made loads of games, platform games, adventure games, 3D maze games, card games. We even had an assembler, written first in BASIC and finished in itself, but once it was loaded it didn't leave enough memory free.

I never got my name in lights but one of my school friends and programming partners, Michelangelo Pignani, found some fame with Mr Chip software. Most notably with a game he stole from me - pontoon.

Any time I hear someone saying 'to realy get the retro feel you should code for the Vic on the Vic' I remember how frustrating it used to be (on getting home from school to hear your mother say "you left that computer thing on so I turned it off" for example) and want to beat them about the head - with a Vic of course.

Lee.

[Guest]

Hey Leeeeee, gordon bennet mate. I dunno how you did it.

One of the (better) books I have about the vic-20 indicates coding the ML on paper first then inputting it into the vic. When I had my vic-20 back in 84, all I ever did was code BASIC programs, ML was a bit beyond me back then. Of course now I writing C++ at work but craving to do assembler (of any form really, hence getting into it on the vic-20).

I just couldn't imagine writing a 16k ML program on paper, or without an assembler than handled labels.

I guess those were the days when 'men were real men' and 'programmers were real programmers'.

Thanks for sharing your insight with me.

Martin

[Jeff-20]

We only had one TV in the house. My mom limited the time we could use it. We played Atari about once a month, and I got to program my VIC about once every other month.

I think I spent more time writing BASIC programs on paper than I spent typing them in. I was always suprised when they just wouldn't work.

There were always a million SYNTAX ERRORS. WHat works on paper doesn't always work when you get it to hardware. I can't imagine trying that with machine code. I've always wanted to try a few ML routines within a basic program, but I never get around to it.

[donfrench]

Geeze, you guys! Didn't you read Compute mag? I advertised my very first software product there in May '92. It was a very full-featured assembler that I sold for $19.95 called The Assembler. It was and still is the smallest assembler ever written and the only one to ever run on the unexpanded VIC.

[carlsson]

Hi Don. Are you sure you don't mean May '82 ?

I think the big software houses may have used some assembler, maybe even a cross-assembler running on some Unix | TOPS | VMS | CP/M machine. Tom Griner (Shamus etc) in his early years more or less POKEd his machine code programs, had some own developed system and only a Datasette for storage. With a such solution, there isn't even any "source code" worth preserving for the future, maybe sketches on paper.

[donfrench]

Of course, May 1982. I have the source for The Assembler around here somewhere. I will post it when I find it.

[billlagr]

My development suite of choice was the Bic Suite. It came in blue, red and black!
I also had a ML monitor, for plugging in all those hex digits. Never had a real assembler unfortunately

[bbell]

Yes, paper was it for me as well...

Once I had it sketched out in general, I would enter the assembly using Jim Butterfields monitor, and then save it binary to tape. (Data statements are only useful for smaller programs, just not enough memory for a whole machine language app).

I would then test it. However, I do remember enjoying the fact the older Vic-20's had SRAM, so if you turned them off and on quickly the contents of program RAM would not be lost (other than the beginning of basic 3 bytes, not a problem). This would save a lot of time reloading from tape if the machine locked up. (I don't think the C64/128 had this "feature").

What really burned me is when I finished a ~3K assembly program and the tape drive decides to chew up the tape within a week (who thought of backups!!!). I remember one game in particular this happened to... After proudly showing it off to a few friends I took it home and the tape drive ate it....

[adric22]

I remember in junior high, we were forced to take a computer programming class on Apple II systems, for BASIC. I could already code in ML on my C128 so I was way ahead of even the teacher. However, I could never understand why all the material said to make a flow chart and write the program on paper first. That never made sense to me. Seemed like a waste of time. I mean, even though the Apple II had a SUCKY BASIC editor, at least you could re-do a line and insert new lines.

But... now that I think about it.. it might be usefull in an ML programming environment if you had a long program and no assembler. Still wouldn't bother with the flow chart, but maybe paper. or even a text-editor or something.

[bbell]

I think there were a few reasons I used paper for coding on my VIC.

First, a computer wasn't always available. In the early 80's schools didn't have them. If businesses had them (for instance my Dad's office) they wouldn't willingly let an early teen touch it. And even if I had access to a computer elsewhere, I doubt it would have a commodore tape drive!! So if I had spare time anywhere but at home for coding it was paper.

Secondly, assembly language debugging was more difficult, since to be safe you have to save your program before running it (since it was way to easy to lock up the machine, or accidently trash memory). As all of you know, saving to tape was quite time consuming. So I think laying down the general code and "hand debugging" it before entering it into the computer saved time in the long run.

Of course, after things advanced and I got my C128 and 1571 drive, it was easier to do assembly on the computer, but also by those days basic compilers came along which made 100% assembly less useful (hmm now in hindsight I guess this was the beginning of bloatware, trading programming convenience for speed/size)...