Machine Code Made Easy - Part 3

From Fred 8

Machine Code Made Easy - Part 3

Bonjour! Mes petits choufleurs, et bienventure.

Yes, ‘tis I again with part 3 (yup, THREE!) of the series. Today

we shall be looking at somethings I hope will be of relevance to

all you budding coders out there. After a short bit on ports,

we’ll head straight into building a program.

But first in this 15 page bumper issue…

PORTS

======

Ports are the vital parts of your coup‚ that allow you to talk to it from the keyboard, joystick, mouse etc. They also allow your coupe to talk back to a printer, tape recorder etc.

So, as you can see we need a way in machine code to control

what goes in (INPUT) and comes out (OUTPUT) from them.

Your coupe can address 64k (that’s 65536) of ports, and the

commands for doing so are pretty simple:

IN (xx),A ; ( must be A )

OUT (xx),A ; ( or B or C or D etc )

xx can be any 8-bit port number.

“Hmmm,”I hear you cry.”How do we get a 16 bit number into an 8 bit one?”

Well, the way in which it works is quite complicated, but to make matters easier I shall present a simple method: Firstly,

most of the useful ports lie between 0 and 255, so this ain’t a problem.

For the ones that don’t we simply use:

LD BC,xxxx ; Port number

IN (C),A

or OUT (C),A ; ( or B or C or D etc )

OK?

For example, to set the border colour to 3:

LD A,3

OUT (254),A ; 254 is the BORDER port

Simple eh?

MEMORY PAGING

===============

So, where is all this getting us? Well, the answer is simple:

To help us page memory.

Now, before I go an—.y further, I will suggest that if you are

keen to do some coding you should get the SAM Coupé Technical Manual. It can explain the paging process in more detail than I

have time or space for. But simply, there are 3 ports to choose

which parts of the 256k (or 512k) memory to wish to have present

in the CPU’s 64k addressing range. Think of it like a TV -

although there are 4 (or more!) channels always going, you

select the one you want to see. In the same way, the coup‚

always has its 256/512k memory there, but the processor can only

‘see’ 64k at a time. OK?

Well, in order to manage this memory, the 256/512k is split

into 16/32 PAGES each 16k long. You choose which two ADJACENT

pages go into low memory (0-7FFF) and which go into high memory

(8000-FFFF). Two ports are used to do this:

* LMPR (250 dec) - the number in this port equals the page

number in 0-3FFF. The page following this ( 0&1, 1&2 etc ) goes

in at 4000-7FFF.

* HMPR (251 dec) - just as above, except that the pages go in

at 8000 and C000

* VMPR (250 dec) - this chooses which page(s) the current

screen is held in.

However, the ports don’t just control the RAM pages in memory

The coupe has 2 16k pages of ROM - ROM0 & ROM1. ROM0 is present

in 0-3FFF if BIT 5 of LMPR is reset. ROM1 is present in

C000-FFFF if BIT 6 of LMPR is set. Also, BITS 5 & 6 of VMPR

select the screen mode (0-3). To sumarise:-

There is one thing to note about VMPR - with modes 1 and 2

screens, only 1 16k page is needed, but with modes 3 and 4 a

whopping 24k is required. This means 2 pages must be set aside

and VMPR holds the number of the first one. BUT this MUST be an

even number (0-31)

For example:

LD A,%00100000

OUT (250),A

This puts page 0 into 0-3FFF and page 1 into 4000-7FFF. It

also freezes out ROM0 to make way for the RAM pages.

OK? Good, then lets’s do….a program!!!

Phew! Don’t worry, it doesn’t take long to type in. In fact,

I’m so generous I’ve supplied it already coded ( PRESS ‘D’ FOR

THE DEMO ). It is located at #6000 when you assemble it, but you

should make sure you put in it the space after the second page

of the screen. ALSO, when you call it, do this first :-

1. Disable interrupts by using the command DI

2. Page the screen into 0-7FFF so that the sprite routine will

be at 6000

3. Make sure the page no. (0-15) of your sprite data is in L

4. Make sure the sprite no. (0-64) is in H

5. Make sure the X coord (0-127) is in E

6. Make sure the Y coord (0-191) is in D

OK?

Your sprites should be 3232 pixels in size (1632 bytes).

You can use any colours for them except palette 0. Any nibble

that is 0 is not printed; instead the background is shown

through. This effect is called MASKING and prevents a horrible

block appearing around your graphic.

To prepare your sprites I suggest you draw them with FLASH.

Once you’ve saved your screen, write a small B™.ASIC program to

load in the screen and then GRAB all the sprites in turn. Once a

sprite has been GRABbed into a$, POKE a$(3 TO) into memory. Then

save this data.

That’s about it for this month folks. If you have any queries

problems ( preferably m/c related ) or a routine to blow my mind

feel free to write to me at :-

29 Murray Crescent,

Perth PH2 OHN.

and I’ll try to reply on screen.

DEMO

——

This is just a (very!) simple demonstration of my sprite

routine. If you want to use the routine in your own programs

feel free, but note that it MUST be located in the spare 8k in a

page after the screen which must be paged in from 8000 onwards.

The demo uses 2 screens - the one we can see and another back

or dummy screen. For every frame it clears the dummy screen,

adds on the sprites and the logo and switches VMPR to point to

this screen ( the other screen is now the dummy ). Although this

uses twice the memory, it is a useful trick if you need fast,

flicker-free animation.

If you fancy disassembling the program code, it lies at #8000

and works without interupts, so be careful if you use

breakpoints - don’t enable them before continuing.

#———————————————#

I PRESS ANY KEY FOR THE DEMO I

#———————————————#