n the Commodore world from a number of different
retailers. The device is usable on virtually all 8-bit Commodore machines.
For this article I am concentrating on just one device.

So simply, this device permits your Commodore 64 or other 8 bit Commodore
to use an SD card as a disk drive, This particular one has a standard IEC connector for the disk drive port, and this also has a connector that just plugs neatly into the tape port on your machine for its power. The device
is sadly not a full implementation of the 1541 disk drive, nor is it 100% compatible, but most games you will be putting on the device will be Fixed
or cracked version. Of course, you will be unable to copy the "real disk"
to the device. If you own the original you will be safe to use a copy from
the internet. I wouldn't like to condone any sort of copy theft, even if
the files are over 30 years old! I leave this to your conscience.

The beauty of this particular system is its size, just a little longer than
an SD card itself. It goes without saying that owning one of these will
change your computing experience with your Commodore forever. It will of course stop any sort of loading problems from magnetic media as the device
and files are digital and it stops that dancing disk drive effect as your
1541 fights with the copy protections thrashing the disk heads to load the game.

The Future was 8-bit - has a huge collection of games guaranteed to be compatible with the device available to download from their website. You
can download the files quickly as a large ZIP image but you must then decompress this onto the SD card. (Hey remember you need to do some work yourself!) The website also contains a wealth of useful information to help
you get the SD2IEC up and running so it's a first stop when you receive
your device.

The SD2IEC is still as slow as a 1541 drive. But you can however speed
this up, as the device is fully compatible with the JiffyDOS fast loader
ROM, along with a number of cartridge-based fast loader solutions again you
can find more details on website about these and the compatibility may
change with upgrades to the devices firmware.

To load the File Browser software for example you'd type 'LOAD "FB",8,1'. (Because the file is called FB) Once loaded, simply type type 'RUN' to
start the File Browser interface. Once running you can pick your game. If
you have a game that comes on more than one disk, you can use the disk swap switch. This automatically loads in the second disk with just a button
press on the device to "SWAP" disks. All of this functionality is
configured by a special file in the game's directory. Full Details of how
to create this and what it needs to contain are available on The Future was 8-bit website .

The device can be bought either cased or uncased. The cased version will
be the most popular; however, those wishing to attack there machines with a soldering iron can install the device inside their C64 or build their own
case and purchase the cheaper uncased version, but this will need
modification to add a swap button.

The cased version in use has two LEDs to indicate the devices status. A
green LED shows disk activity so as long as this is lit, you can assume a program is loading. The second red LED flashes whenever there's a disk
load error. This could happen if there's some incompatibility between the
disk image you've chosen and the SD2IEC's emulated 1541. If this happens
then you will need to find a version that will work with the device.

Along with the device is a useful "getting started guide" I suppose most
people will just use the device to load a program or run something from a
d64 image.

The build quality is fantastic, and the device does look like a miniature
1541 disk drive, the cables look professionally terminated, and the price
is justifiable for what the device can do and the work that's gone into manufacturing it. If this review has teased you enough you should visit
the website and buy the product, for a few pounds you could change your commodore experience forever!

www.sd2iec.co.uk/


*************************************
THE ASSEMBLY LINE
$05: Look at Us, All PRIMM and
Proper!
By Bert Novilla (satpro)
*************************************

The last time out I did something I said I wouldn't do: bog the reader
down. I apologize for that, and as soon as I can figure a way to write a
good sequel I promise we will continue on the subject from Assembly Line
#$04. This time however, we are going to explore and explain a related
task: printing in-line text strings.

WHAT IS PRIMM?

Many of us have seen or heard of the C-128 text-printing function called "PRIMM." It has been used in many applications, and quite prominently by
most of the major turbo utility cartridges. The Buddy assembler (and accompanying text editor) is another good example. What is PRIMM, or
"print immediate?" In short, it is a function which allows the 65x
programmer to print an inline, 0-terminated petscii text string. That is, placing the string characters (and optionally, screen location coordinates) directly after the call to print our string. Normally we tend to place our code in one location and our data in another, separate space. This can
make for cleaner, more understandable code, but other than for aesthetics
or reasons related to personal preference, there is really no rule which prevents us from placing code with (and around) data, or from printing an in-line string. The C-64 does not have a function for printing in-line strings, but we can borrow from big brother C-128. So let's see how PRIMM works -- and let's improve upon it some, and even see how we can add a
screen plotting enhancement. The code which follows makes a very nice
addition to the programmer's toolbox.

THE CODE AND WHAT IT DOES.

The call to PRIMM is actually quite simple. It takes no parameters,
preserves the registers, and is very economical with memory usage. You structure the call to PRIMM like this:

;a call to our in-line string
;printing function
JSR PRIMM
;petscii string with terminating 0
.text "Hello World.", 0
;this could be anything
... more code follows
;exit the program
RTS

Instead of returning to execute the next instruction PRIMM instead does
some parsing to retrieve and print the in-line text string. Once PRIMM encounters the zero byte (0) terminator, it returns to the code stream.
This is really very straight-forward, but it takes a moderate understanding
of both the stack and the program counter. Okay... let's take a first
look at the C-128 version (on the left) and our modified version (to the right).

C-128 Version

PRIMM =*
PHA ;save .A on the stack
TYA
PHA ;save .Y on the stack
TXA
PHA ;save .X on the stack

Our Version

PRIMM2 =*
PHA ;save .A on the stack
TXA
PHA ;save .X on the stack
TYA
PHA ;save .Y on the stack

This first section (above, left) preserves the 65x registers A, Y, and X.
If, as a conscientious programmer, you always preserve the registers your function modifies, you increase greatly the chances your code will work
later for both you and anyone who wishes to use your function in their own application. Why? Well, for example, what if we wanted our PRIMM function nested within a larger loop, and the loop is counted by the .X or .Y
register? In lieu of preserving registers we would be required to save the loop index register before making the call to PRIMM, and then we would have
to restore it later, wouldn't we? It would place an undue burden on the
person making use of such a function, and it's just one more needless thing
he would have to remember.

It has long been considered good practice to save any registers which are modified in a function, especially if someone else will use that function
in their own program. We are going to modify all three registers in our function, so first let's just save them on the stack and be done with it.
Our initial modification won't make or break us, but in the name of
consistency let's change the or

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