.

- - - - - - - - - -

Q. Do you have plans to release the title commercially through a Scene distributor

No, there won't be a commercial release as it isn't an original game; and
so legally a grey area. Also, it's nice to just give something back to the community; after using all the excellent free resources like Vice, etc.

- - - - - - - - - -

Q. How close to the original version do you think this port is

I tried to make it as close as I could within the constraints of the vic.
E.g. I put in nearly all the animations from the Arcade, eyes blinking up
and down, etc that I could. There are some omissions due to graphics and memory constraints….

- - - - - - - - - -

Q. So what's missing from the Vic version that the "full" version had, and what did you use for reference

The arcade has some more cut scenes, different coloured super-wolves, free floating balloons and fruit. All these features would push the game to 24K
at least, - something I resisted doing. I wanted to make it playable on
real hardware, a vic + 16K is (was) a fairly common configuration. I used
the original arcade game running under MAME and also the C64/NES versions
for reference.

- - - - - - - - - -

Q. What was the main problem converting the game to the Vic

I think lack of user defined character space for the graphics was the main obstacle to overcome. It was difficult to fit everything in. For example,
I couldn't include the full alphabet and only copied across the letters I needed from the Vic character ROM.

- - - - - - - - - -

Q. What process did you follow with the conversion, did you for example
create a test code; or did you start with the graphics then try to fit the
code around them?

I mocked up the main screen; then developed some PC based utilities in C#
to convert the graphics to compressed (Run Length Encoded) data; and then
wrote my first ever 6502 routine to display this on the screen. It was
really nice to see it appear on the Vic screen for the first time. Next
step was to define some graphics for the wolves sprites; and float these
over the top (learning more 6502 along the way). It all followed on from
that, with game elements being introduced one by one. The final step was
to develop the music player.

- - - - - - - - - -

Q. Do you plan any other conversions to the Vic

No, not at the moment at least. Pooyan took pretty much every minute of my spare time for about 6 months, so was quite a drain for me; on top of my
full time job. I find it difficult to put things down once I start, so the game kind of took over. Sometimes; I would have to get up in the middle of
the night if I had thought of a solution; and type in the code for it
otherwise I just couldn't sleep

So now I'm quite enjoying the rest from it, but eventually I might try my
hand at something else - there are a couple of possibilities I have in
mind.

- - - - - - - - - -

Q. What are the conversions Best features in your opinion?

I have always liked chip-tune music; and I think that the in-game music
isn't too bad considering the limitations of the Vic. It took me a while
to get the music and sound effects to play independently. I also like the
cut scene and title screen.

- - - - - - - - - -

Q. I know you mentioned some of the tools you used but could you expand on that a little, and do you intend to release the source code to the general public

Yes, as I already mentioned; the game is built on top of the Robert Hurst's Software Sprite Stack from Denial. I created the graphics and sprites
using CBM Prg Studio. I used the CA65 as the assembler; and Notepad++ with
a couple of plug-ins as the development environment.

Sorry - I've no plans to release the source code at the moment.

- - - - - - - - - -

Q. So you programmed this as a "one man team" didn't you have input from anyone else

It was just me really, well apart from help on the Denial forum; and also
my wife helped, she made the spreadsheet to generate the curve data for the projectiles in the game.

- - - - - - - - - -

Q. How do you go about testing the game to iron out the bugs that may
appear

Nothing special - just repeatedly playing the game mostly. There was a particularly nasty bug that I found by setting the game up to invincible
mode with auto-fire; and running several instances of the game under the
Vice emulator in warp mode (10 x normal speed) over night. Some of them
had crashed by morning due to overwriting a wrong zero-page memory address.



*************************************
THE ASSEMBLY LINE
$00: An Introduction and Tools of
the Trade
By Bert Novilla (satpro)
*************************************

Well, here we go. This is the first installment of a series focused on learning to write assembly language programs for the 65x family of
processors found in Commodore computers. I would like to publicly thank
Nigel at Commodore Free for allowing me to share some of my programming knowledge and experience with you here. My belief is that as the current computer "Renaissance" plays out it is important to have modern information regarding assembly language available to all of us. This series of
articles is my effort. Thank you, Nigel.

LET'S BEGIN

Our mutual goal in this series, yours and mine, is to explore the world of
65x assembly language. Together we will discuss various aspects of what
many consider the "black art" of computer programming. I will show, and
you shall soon see, that assembly language is indeed nothing more than a
method of communicating through a computer using a set of human-readable
codes called mnemonics. These mnemonics are translated into a series of instructions the computer understands using a tool called an assembler.
Unlike BASIC or C, which are considered "high level" languages, and where
one command is translated into a series of machine language computer instructions that may easily reach hundreds of bytes in length, assembly language is translated in a one to one fashion, and is known as a "low
level" language. One assembly language mnemonic equals one computer instruction. Therefore, assembly language programs execute very quickly,
often hundreds or even thousands of times faster than the equivalent
program written in BASIC, and substantially faster than equivalent C
language code. In addition, assembly language programs use less memory
than their BASIC and C counterparts.

In this series we will examine the 6502/65816 instruction set in detail,
and you will learn efficient ways to use these instructions in the programs
you write. The choice to learn assembly language puts you, the programmer,
in the driver's seat. Contrary to popular belief, any program can be
written in assembly language, and also contrary to popular belief, program development time does not have to be an issue provided you are equipped
with the proper setup and have the right tools, skills, and habits for the
job. This article is devoted to helping you with this endeavor.

More importantly, throughout this series you will learn to communicate
through the computer at a level that is either not possible or is very difficult with BASIC or C alone. We will explore the 8-bit 6502 as well as
the advanced 16-bit 65816 processor found in the SuperCPU. Along the way
we will discuss good programming habits and techniques advanced programmers
use in programs they create. Our discussion will be limited to assembly language programming in the generic sense, so I will not attempt to bog you down with lists of specific computer addresses nor will I demonstrate
hard-core sound and graphics as they are complete subjects of their own.
We will, however, discuss our topics within the context of the Commodore
64.

THE PLAN

So, what is planned for this series? Each time out we will explore a topic relevant to learning assembly language programming, beginning today

--- MBSE BBS v1.0.01 (GNU/Linux-i386)
* Origin: Dragon's Lair ---:- bbs.vk3heg.net -:--- (39:901/280)