Commodore 16

Discuss and discover all the great games of yesteryear!

Moderators: mknott, NickThorpe, Darran@Retro Gamer, MMohammed, lcarlson

User avatar
TMR
Posts: 5756
Joined: Wed Dec 21, 2005 10:56 am
Location: Leeds, U.K.
Contact:

Re: Commodore 16

Post by TMR » Fri Jul 17, 2009 8:15 am

gunbladelad wrote:How about a port to the CPC to appease all the Amstrad fans (I'm one myself, admittedly), lol...
That wouldn't be a straight port, it'd need a total re-write and apart from anything else i don't code on the CPC. Shifting C16 games to the C64 on the other hand is relatively easy because they behave similarly and the only disadvantage the C64 has is CPU speed (which can usually be fudged around by using a hardware sprite for the player and juggling the load on the interrupts).
gunbladelad wrote:In all seriouslness, I'll probably start digging around online to see if I can play Jetbrix again. my old C16 itself is long gone, but IIRC, the old RG coverdiscs might have had a C16 emulator or 2 on them
Or you could simply download YAPE (Yet Another Plus/4 Emulator) or VICE since it has the inaccurate but at least workable xPlus4 as a component...

stardust
Posts: 8
Joined: Wed Jan 05, 2011 1:00 am

Re: Commodore 16

Post by stardust » Wed Jan 05, 2011 3:05 am

New register and new post today:
C16/Plus 4 fan (as I don't own C64 that time), consule gaming fan here, game program fan here
I will post my favoraite later as after read the topic, I have several questions to ask, espenciall for TMR, of course, others are welcome.

1.Fire Ant, Bongo, Tom: In Fire Ant, the Ant and scopion ared acted like a spirite, having animation and transparance at the same time (Move over the key on level 1 and open the first door on level 1). Tom and Bongo: character acted like spirite (Smooth movement, aninmation and transparance). But I know C16 doesn't have a hardware spirite. How to do this in C16? I found some so-called software spirite program for C16, but they are just serveral characters jumps in normal text mode
2.Space Pilot: Is this a graphic mode game or text mode game? If graphic, those enemy planes and my plane are drawed and rotated? If text mode, the game full of rotation and smooth movement of homing missles, seems impossible. Still like a magic to me
3. Kikstart, Autozone: How to do smooth scolling in C16, is there any good document. for Kikstart I am not sure if it is smooth scrolling, but autozone, it is.

Here Smooth movement means an object move by one pixcel, not jump by character (which is 8 pixcels)

Mentioned game are of course part of my favoraties.

User avatar
TMR
Posts: 5756
Joined: Wed Dec 21, 2005 10:56 am
Location: Leeds, U.K.
Contact:

Re: Commodore 16

Post by TMR » Wed Jan 05, 2011 3:44 am

stardust wrote:1.Fire Ant, Bongo, Tom: In Fire Ant, the Ant and scopion ared acted like a spirite, having animation and transparance at the same time (Move over the key on level 1 and open the first door on level 1). Tom and Bongo: character acted like spirite (Smooth movement, aninmation and transparance). But I know C16 doesn't have a hardware spirite. How to do this in C16? I found some so-called software spirite program for C16, but they are just serveral characters jumps in normal text mode
Software sprites can be a number of things, starting from being as simple as moving around in character steps as you've described to using work spaces, copying in what's currently underneath where the sprite sits and drawing in pre-shifted masks and frames to get what Bongo and others are doing. i can explain this further if you want, but need at least two cups of tea and more time than i have right now. =-)
stardust wrote:2.Space Pilot: Is this a graphic mode game or text mode game? If graphic, those enemy planes and my plane are drawed and rotated? If text mode, the game full of rotation and smooth movement of homing missles, seems impossible. Still like a magic to me
It's using text mode (the titles page mixes multicolour and high resolution characters) so the in-game objects are all generated from character blocks which are constantly having their definitions changed using pre-rendered rotation. There's colour clash where the software sprite enemies pass over each other as well, if you run the game in an emulator, try slowing the overall speed down and you'll see more of what is happening.

Generally speaking, running with bitmap is problematic for the C16 because there's only really 14K of available memory and a bitmap needs 10K of that (8,000 bytes of bitmap data with two 1,000 byte blocks of attribute RAM) - it doesn't leave a lot of space for anything else!
stardust wrote:3. Kikstart, Autozone: How to do smooth scolling in C16, is there any good document. for Kikstart I am not sure if it is smooth scrolling, but autozone, it is.
Kikstart and Autozone are both smooth scrolling. The C16 shares the hardware smooth scroll that the C64 has, two registers that allow for up to seven pixels of offset in X or Y; the value in the horizontal scroll register is changed each frame and the landscape smoothly scrolls between character cells, when the register reaches it's stop point it resets and the landscape is scrolled by one character.

stardust
Posts: 8
Joined: Wed Jan 05, 2011 1:00 am

Re: Commodore 16

Post by stardust » Wed Jan 05, 2011 10:10 pm

Thank you a lot for professional techincal reply.
For software sprites, I want to know more, espencially in smooth movement and transparance. I don't know how to put an object (e.g. a normal character) on a text mode screen (40*25) with 300*200 location. I remmembering when I am young and program a game by BASIC for Plus/4, I want the main character to perform smooth move, but all the reference program I can find is move by characters.
For hardware smooth scrooling, what is the register address for Plus/4?
Space pilot still have many maigic for me, the background starfield, the 16-way bullet, good collision detect.....
Asking for too much,just let it as a magic for me.

User avatar
TMR
Posts: 5756
Joined: Wed Dec 21, 2005 10:56 am
Location: Leeds, U.K.
Contact:

Re: Commodore 16

Post by TMR » Thu Jan 06, 2011 6:26 am

stardust wrote:For software sprites, I want to know more, espencially in smooth movement and transparance. I don't know how to put an object (e.g. a normal character) on a text mode screen (40*25) with 300*200 location.
Hmm, i've two cups of tea in me today and this might end up as the first draft for an article on OSG so i'll have a go. =-)

Right, for a starter it's far more often 160x200 positioning rather than 320x200 because the graphics and the software sprite will usually be running in multicolour. There's also a number of ways to do this, but i'll explain one of the most involved since the majority of the rest can be worked out from there.

Each soft sprite object needs a work space; for the sake of example we'll assume an 8 by 16 pixel ball which is two by two characters and that'll need a three by three character work space because the ball is going to have to smoothly travel between character cells. That space can be organised like this...

Code: Select all

ADG
BEH
CFI
...and i'll explain why it's in columns rather than rows a bit later on. The object itself is stored in four possible states somewhere in memory (not in the character set) with each being offset by a pixel so they look like the column on the left in this diagram...
8x16_pre-shift.png
Example of pre-shifting (with masks) split into character cells.
8x16_pre-shift.png (5.34 KiB) Viewed 650 times
...whilst the column on the right is a series of masks for each pre-shift. The process of writing in a software sprite using the work area and mask might go like this:

1. Work out where the work area characters need to be plotted to the screen, these values will be the software sprite's X and Y position divided by 4 and 8 respectively (since it's multicolour, the pixels have a 2:1 aspect ratio). The nine characters already on the screen at that point are pushed off into a storage space because they'll be needed for a couple of things.

2. Draw in the nine character work space and then copy the definitions from the characters that were there previously (see, i said they'd be needed! =-) This makes the work area "invisible" because it now looks exactly like the characters it overwrote.

3. Select which of the four blocks of pre-shifted sprite data (from the example above) is going to be used - again, the sprite's X position provides the value, it's the lowest two bits that were previously ignored when positioning the work area.

4. Work out the drawing height within the work area (the bottom 3 bits of the sprite Y since it was divided by 8 rather than 4).

5. Cut a "hole" in the work area character definitions at the selected height (done using the mask for the selected frame, the data is ANDed against what is already in the work area so the "hole" is the shape of the ball and the background surrounding that hole is left intact).

6. Draw in the object at the selected height (this time ORing the data in so that the background that survived the masking process is still unharmed).

When it comes to moving the object there's a couple of extra steps:

7. Overwrite the work area with the characters that were in it's place previously.

8. Update the sprite's position, then jump back to step 1 to redraw it.

And that happens once a refresh (with all the work needing to be done out of the visible screen or to a second buffer to avoid it looking a mess) and for many games that'll mean 25 or 50 times a second. The reason for the work area being arranged into columns is simple, it means that the mask and definition can be written in with a simple loop rather than needing fiddly exceptions to skip between rows; if character A is at $2000 and character B at $2008 you can just keep drawing over the boundary if one is above the other, if A is at $2000 but the character below it is D at $2018, there'll need to be a "skip" checked for.
stardust wrote:I remmembering when I am young and program a game by BASIC for Plus/4, I want the main character to perform smooth move, but all the reference program I can find is move by characters.
Trying to handle software sprites from BASIC is highly problematic, moving in character steps is normally used because it's the fastest and least resource hungry solution. Even from machine code what i've described above is quite a hefty chunk of processing power to handle and many games pare down the process, either managing sprite positions to avoid the need for overwriting the background, keeping the overall sprite count down, going for character steps or variations on those themes.

There are techniques to speed things up such as unrolling all the loops (instead of having one LDA and STA in a loop, having loads of LDA and STA commands) but these solutions are memory hungry and therefore not always viable on the C16.
stardust wrote:For hardware smooth scrooling, what is the register address for Plus/4?
For horizontal scrolling it's $ff07 and vertical is handled by $ff06 but it's important to note that these are multi-purpose registers and only the lowest three bits (and the fourth governs if the borders are in smooth scroll mode or not) are used for smooth scrolling; writing the wrong value into these locations can "mangle" the output since $ff06 can do things like enable bitmap mode or disable the screen.

Slight disclaimer: i'm still not fully awake and aren't going to proofread this properly before posting it, so if something doesn't make sense just say and i'll have another go. =-)

stardust
Posts: 8
Joined: Wed Jan 05, 2011 1:00 am

Re: Commodore 16

Post by stardust » Thu Jan 06, 2011 10:34 pm

Thanks a lot, very detail
I begin to understand now, But I am not sure my understanding is right or wrong, collect me if I am wrong.
But 2*2 is a bit complex for beginner. Let's use 1*1 as example
For Smooth movement: It is all pre-rendered character set. If I want move by one pixcel in one direction, I need 8*2 definations
For transparance: get the 2 charactes involed in moving. Dynamicly define two temporary new characters, the new chararacters's defination is handled the by using these 2 characters+ a mask + the software sprite character (using AND and OR, I know this magic). Yes, BASIC language handling this one is too much. If I am right, the main technology used is dynamic character re-defination (i haven't try dynamic re-defination in plus/4 before, is this possible?)

User avatar
TMR
Posts: 5756
Joined: Wed Dec 21, 2005 10:56 am
Location: Leeds, U.K.
Contact:

Re: Commodore 16

Post by TMR » Fri Jan 07, 2011 5:59 am

stardust wrote:For Smooth movement: It is all pre-rendered character set. If I want move by one pixcel in one direction, I need 8*2 definations
For a 1x1 character high res object, yes. High res isn't often used because it "clashes" if the object is a different colour to whatever it's passing over (a random example of high res with software sprites is Zeppelin), multicolour mode tends to be used and that only needs four possible definitions.

It's also possible to do the pixel shifting of the objects in realtime but that takes even more processor power, so that technique is only used when memory is desperately low and there isn't room for the pre-shifts.
stardust wrote:For transparance: get the 2 charactes involed in moving. Dynamicly define two temporary new characters, the new chararacters's defination is handled the by using these 2 characters+ a mask + the software sprite character (using AND and OR, I know this magic).
Yup that's right, although two characters will only get you motion on one axis; for free, multi-dimensional movement you need four temporary characters arranged in a square.
stardust wrote:Yes, BASIC language handling this one is too much.
Moving character by character in BASIC is too much if there's more than a couple of objects. =-)
stardust wrote:If I am right, the main technology used is dynamic character re-defination (i haven't try dynamic re-defination in plus/4 before, is this possible?)
Yes it does and yes, dynamic redefining of characters is no problem for the C16; whever the character set pointer has been told to look in RAM, change the content of that RAM and if you've just modified an on screen character, all instances of it immediately update.

stardust
Posts: 8
Joined: Wed Jan 05, 2011 1:00 am

Re: Commodore 16

Post by stardust » Fri Jan 07, 2011 10:19 pm

Thank you for help me unfold the magic behind the sprite in C16!
The smooth movement, animation and transparance in moving object make me enjoyed lots of game. I remeber during my childhood, after finished FIRE ANT. I enjoy moving the ant to an untakeable key, and watch it's animation and transpance effect over the key. I know all the environment is done by predifined the characters in text mode, but this part is a magic. AUTOZONE is a very hard and classic game which I finished that time. The car must be controlled to pixel level to avoid all kind of dangous place. Kik start is the same. just autozone need more delicated control.
Yes, many classic game move object by 2 or 4 pixcels in a text enviroment. As long as it not jump by characters, the effect is very satisfying. For Basic programing, I remember program a game in basic that time, I will try hard to avoid moving more than 3 characters at the same time, otherwise it will be very slow. I dreamed to be able to write machine code that time, but I just can not master the machine code.

F-zero
Posts: 61
Joined: Wed Jul 29, 2009 1:22 pm

Re: Commodore 16

Post by F-zero » Mon Jan 10, 2011 3:01 pm

Hi there C16 fans, i was considering buying a system and i was wondering if its worth buying the Plus4 rather than the standard C16?
Is there any benefit games wise or other?
Thanks.

User avatar
TMR
Posts: 5756
Joined: Wed Dec 21, 2005 10:56 am
Location: Leeds, U.K.
Contact:

Re: Commodore 16

Post by TMR » Mon Jan 10, 2011 4:11 pm

F-zero wrote:Hi there C16 fans, i was considering buying a system and i was wondering if its worth buying the Plus4 rather than the standard C16?
Is there any benefit games wise or other?
If you're only wanting to run 1980s games, there are a few requiring 64K but the bulk of them will be fine on a stock C16. Probably about half of the more recent games need 64K, give or take.

stardust
Posts: 8
Joined: Wed Jan 05, 2011 1:00 am

Re: Commodore 16

Post by stardust » Tue Jan 18, 2011 4:40 am

I have two additional question in scrolling:

1. I have written a very simple program (scroll up in BASIS language) to test the C16 hard scroll, result is very good and speed is also good, but with a probelm.
Set the corresponding resister 0 to 6 is very good also in BASIC, but when set to 7 the whole screen will scrolling back, I have to make a chararter level scroll up and continue to do the smooth scroll. This result in a junk on the screen(becasue set to 7 whole screen scroll back a character, then I scrollling up one character again). So how to avoid this, I know very few about raster. Is it the only way to avoid that?
2. How to make the hardscroll happen in a fixed window. e.g only in line 16 of text mode

User avatar
TMR
Posts: 5756
Joined: Wed Dec 21, 2005 10:56 am
Location: Leeds, U.K.
Contact:

Re: Commodore 16

Post by TMR » Tue Jan 18, 2011 6:21 am

stardust wrote:1. I have written a very simple program (scroll up in BASIS language) to test the C16 hard scroll, result is very good and speed is also good, but with a probelm.
Set the corresponding resister 0 to 6 is very good also in BASIC, but when set to 7 the whole screen will scrolling back, I have to make a chararter level scroll up and continue to do the smooth scroll. This result in a junk on the screen(becasue set to 7 whole screen scroll back a character, then I scrollling up one character again). So how to avoid this, I know very few about raster. Is it the only way to avoid that?
It sounds like you're using the vertical scroll register and relying on the hardware PRINT command in some form to do the coarse scrolling; from memory that just isn't fast enough from BASIC to be handled smoothly, so there'll be a point once every eight refreshes where the hardware scroll is reset but the PRINT routine hasn't shunted the screen up yet so it "shudders".

Even doing a vertical scroll like that in machine code is something of a balancing act, essentially involving the data shifting loop having to race the display refresh in order to avoid "tearing" the display.
stardust wrote:2. How to make the hardscroll happen in a fixed window. e.g only in line 16 of text mode
That'd require machine code and the most common method would be to use a raster interrupt and, since i'm again assuming vertical hardware scrolling, the timings are quite fiddly and the display can get quite seriously "mangled" if they're stuffed up.

stardust
Posts: 8
Joined: Wed Jan 05, 2011 1:00 am

Re: Commodore 16

Post by stardust » Thu Jan 20, 2011 9:29 pm

Thank you,but I think it is not the probelm of slow basic language. I tried to close the screen before reset register value to 7 and then open it. the result is very good, but the screen flicks, of course, due to screen close and open again and again.
the program is someting like this
10 poke 65286,peek(65286)and239 turn off screen
20 poke 65286,peek(65286)and240or7 scroll up -7 pixcel (scroll down 7 pixcel)
30 print scroll up 8 pixcel
40 poke 65286,peek(65286)and239or16 turn on again
put differnet new data on last line every time
for I=6to 0 step -1
poke 65286,peek(65286)and240or I scroll up one pixcel
wait some time as hardware scroll is fast
next I
goto 10
line 20 is where I confused most as the screen willl scroll down 7 pixcel.Of course, I don't think it is a good way to scroll up 1 pixcel by scrolling down 7 first and scroll up 8 agian.Is this correnct way to use scroll register? If correct, how to do hide the last pixcel of scrolling?

User avatar
TMR
Posts: 5756
Joined: Wed Dec 21, 2005 10:56 am
Location: Leeds, U.K.
Contact:

Re: Commodore 16

Post by TMR » Fri Jan 21, 2011 4:53 am

stardust wrote:Thank you,but I think it is not the probelm of slow basic language. I tried to close the screen before reset register value to 7 and then open it. the result is very good, but the screen flicks, of course, due to screen close and open again and again.
It's going to be a BASIC speed issue because you're using PRINT; basically, the value going into 65286 spends eight iterations counting from 7 to 0, then it has to skip back up to 7 during the same 50th of a second when the scroll needs to happen - sometimes that might happen quickly enough by sheer luck, but the odds are seriously stacked against it and the result is that the scroll register and actual display go out of sync for a frame or perhaps even two and it glitches.

The attached archive contains a machine code program called vscroll.prg (drag and drop it into VICE or preferably YAPE) and the source code (open with Notepad) that i threw together in an hour this morning whilst remembering where registers are on the 264 series.
Attachments
vscroll.zip
PRG and C64Asm source
(1.17 KiB) Downloaded 25 times

stardust
Posts: 8
Joined: Wed Jan 05, 2011 1:00 am

Re: Commodore 16

Post by stardust » Sat Jan 22, 2011 9:37 pm

The demo program is a great help, thank you.
I have read the program, I can undestand the program, but exceprt for the RAS part as I know almost nothing about raster.
Fortunately, I know how NES light gun works, otherwise I will totally lost. After modify the RAS part many many times, at last, I have some concept about raster and begin to understand. Another childhood magic is unfold, thank you a lot.
My understanding: screen update before raster #$50 will not show until next raster line, so character level scroll in hidden by #$50
and register level scroll is hidden by #$00. Then scroll up, left, right have no problem. just out of curosity, scroll down also need update the screen from upper part using a temporary buffer ?
Do you know how NES and Genesis scrolling work? are they the same?

Post Reply

Who is online

Users browsing this forum: No registered users and 4 guests