From: Vanessa Ezekowitz on
Replying to two messages at once here...

First message:

spike1(a) wrote:

> Indeed. While the [Commodore 64] didn't even have PRINT AT,

It didn't have PRINT AT, but there's an easy workaround. Most people who
write programs use cursor up/down codes and the TAB command to position the
cursor, which can be far more efficient than PRINT AT if it's done
properly, but if you do need a PRINT AT type of command, you can create one
with a small array, or you could POKE to a couple of memory locations to
manually set the cursor location.

The array was generated with a one-time loop at the start of the program,
typically of this form:

VT$(0)="{Home}": FOR X=1 TO 24: VT$(X)=VT$(X-1)+"{Down}":NEXT

Where {Home} and {Down} are the cursor keys, which embed visible codes into
the text when you're in "quote mode".

Then you could PRINT VT$(y)TAB(x)"your message" anywhere and get the same
effect as your PRINT AT command.

> let alone PLOT, DRAW, BEEP, etc. Sinclair's even had a much more sensible
> string splitting regime. Left$ right$ mid$???? pah, who needs them when
> you can split any string with the same command. A$(TO 5), A$(3 TO),
> A$(2 TO 5)

Actually, the LEFT$ and RIGHT$ functions are somewhat superfluous, as the
MID$ function can do what those two do also. It's not hard to remember:

PRINT MID$(A$,start,length) would do the same as PRINT A$(start TO end) in
your code. Leaving off the 'length' parameter is the same as specifying
the full length of the string after the 'start' parameter.

> Did the [Commodore 64] actually HAVE interrupt commands, error trapping
> and ON?

I don't know what you mean by interrupts (to me, that means IRQ's), so I
presume No to that question, however you could poll the hardware registers
that are normally used to configure IRQ's if you so choose. The C64 didn't
have error trapping, but it does have the ON GOTO/GOSUB commands.

> > If I remember rightly the commodore had no provision to save a block of
> > code from basic either, at least on the spectrum it was as simple as
> > SAVE "foo" CODE 32768,2048

This fellow is wrong regarding the C64.

> LOL! didn't know that. So, you couldn't even do a little machine code and
> save it to tape? Without storing it in a REM routine, like you had to do
> with the ZX81?

The way it works on the C64 is you create your code either with an assembler
or a machine code monitor, whichever way suits your fancy, as on any other
computer of the era. In the case of the true assembly, the code usually
gets saved to disk from within the assembler (some assemblers used a
secondary machine code monitor, which is where you'd save from in that

In the case of standalone machine code monitors, the same holds true - they
all have some sort of save function that works as you suggest it should.

If you *do* need to do this kind of save outside of a monitor or assembler
environment, there's a ROM routine you can call from BASIC to accomplish
the task after a few POKE's to set the start/end addresses. It's not as
convenient as your method, I concede, but it works fine, and is as fast as
saving from a monitor or assembler.

The C128 introduced a BSAVE command when it came out. Don't remember the
exact syntax, but it's similar to your SAVE command.

> Cue the [Commodore 64's] user's standard response "No it didn't, it didn't
> even have filters"

You had a single-channel tone/pulse generator. The C64 came standard with
the SID chip. Even if all the C64 had was an AY chip, there's still no
contest. The Spectrum just didn't come stock with a decent sound system.

> Cue the standard [Commodore user] response "Ah, but we had zero page so we
> had lots of memory addresses that were as fast as registers"

Every single home computer or game console that used the 6502, 6510, 65816,
8500, or 8502 had zero page registers, it's an integral part of the design
of those processors, not specific to the C64. The Zero Page serves its
purpose perfectly fine.

Besides, it has been proven over and over that a 6510 is far faster, in
terms of total data throughput, than a Z80 at the same clock speed; our 1
MHz 6510 is just about the same speed as your 3.5 MHz Z80.

This isn't speculation or opinion, it's a hard, proven fact. Can we PLEASE
drop this already?

> > [ had to spend 40 quid on a fastload system...]
> What a con, eh? You spend 350 quid on a computer which needs an add on to
> load quickly... Then you spend another 400 quid on a disk drive...

I can't argue on prices because I can't find anything about the Spectrum
except that it came out at 175 quid for the 48K model, and that a
Microdrive and interface combo cost about 80 quid.

I suspect that if you add together the cost of all the add-ons you'd need in
order to equip the Spectrum with everything that the C64 came with
standard, the two would probably be about equal in cost. The difference is
that with your machine, you started small and worked your way up as you
needed to, whereas most of us over here were happy that the C64 already
came with everything. I don't know how the market is in England, but in
America, market research has shown that for many things, demand increases
as more features are added to a product. Sort of an "I gotta have that!"

Personally, I would have been irritated had the C64 not been designed with
all of its features already present.

> ...and need to spend more money on THAT to get it to work faster than the
> tape.

The disk drive was faster than the tape drive without any software or
hardware help, as mentioned below.

If it's not fast enough, you still didn't *have* to spend money to get a
fast load system - a program can be loaded from disk or tape as part of
your normal chain of code, or loaded separately (for development or
something, maybe). It takes only a few seconds to load a fastload routine,
as most are very small.

One of my favorites was a routine simply called "Quick", that loaded
programs at about 2KB/sec, weighed in at less than 256 *bytes*, could be
placed anywhere in the computer's memory (except under a ROM), and came as
a type-in program from Compute's Gazette.

I borrowed a copy of the magazine to type that one in, thus I spent no money
on it. You could also download such software from some BBS's, get it from
your user's group, or borrow from a friend.
From: Vanessa Ezekowitz on
Adam wrote:

> you could use machine code to save a basic program that happened to
> have a load of code after it but all programs were basic programs
> (which is why most of them are like 10 SYS 2061 - Basic program starts

Not true in the slightest. With the exception of compiled BASIC, programs
that start out like this are machine code. The SYS command is just part of
a ~20 byte header that makes it easier to start the program by just RUN'ing
it. Everything after the three zeros that ends the header is pure machine

Many programs use the LOAD "filename",8,1 method, which starts the machine
code right away, and programs of this nature do not contain the above
header. Some other programs use this same method but must be started
manually with a SYS command. Often, a BASIC program might load a handful
of headerless machine code modules and start them as needed once the "main"
program (often written in BASIC) is running.

Some programs I've written follow this latter method.

> at 2048 so enough space for the line containing the SYS command then
> the actual block of code) - The disk system also suffered from this
> 'feature', the only filetypes were PRG (Basic program) and SEQ
> (Sequential file)!

Wrong again. File types PRG, SEQ and USR are just labels, and don't
actually mean anything. PRG is *usually* used to represent executeables,
either BASIC or machine code, but is also used for memory dumps, which is
typical of graphics utilities (e.g. for the picture data).

SEQ is normally used for Text files, configuration files, non-memory-dumped
images, and most anything else that is not an executeable. However, it can
be used for executeable code too, if you want.

USR is generally not used outside of GEOS, but from the native OS it can be
used to store executeable code if you want, as well as normal text. Within
GEOS, this filetype is used for both.

REL is used almost exclusively for database files and the like, as it is
more or less random access and is based on records, rather than

CBM and DIR filetypes are only used for 1581 sub-partitions and CMDfs
subdirectories, respectively.

> Oh well, still better than Beep -.o, Do you know there are cards for
> the PC now that allow the use of a real SID chip for sidplaying and C64
> emulation?

HardSID was one such card. Not sure if it still exists. There's also the
SIDstation and similar MIDI devices, which house real SID chips as well.

"Life is full of happy and sad events. If you take the time
to concentrate on the former, you'll get further in life."
Vanessa Ezekowitz <vanDEesLEsaeTEzekTHowiIStz(a)>
("DELETE THIS" to email me :-) )
From: zeem on
Vanessa Ezekowitz wrote:

> Besides, it has been proven over and over that a 6510 is far faster, in
> terms of total data throughput, than a Z80 at the same clock speed; our 1
> MHz 6510 is just about the same speed as your 3.5 MHz Z80.

Even though I like the Spectrum a lot, I'd have to agree with this.
Probably my favourite 8-bit computers are the Acorn/BBC machines with
their 2MHz 6502s, and they're not normally described as slow. Except
maybe the Electron in screen modes 0, 1 or 2, but that's because it's
slower than the Beeb in the same modes.

Neither the Spectrum nor the C64 have got 80-column screen modes. So there!

Alex Taylor
From: Mike Wynne on

"zeem" wrote...
> Except maybe the Electron in screen modes 0, 1 or 2, but that's because
> it's slower than the Beeb in the same modes.

That's because the Acorn engineers in an amazing cost cutting move decided
to use a single 64k x 4bit RAM chip for the 32k x 8bit memory, meaning that
every read/write required two memory accesses... wonderful idea!


From: Sam Gillett on

<spike1(a)> wrote ...
> Indeed. While the commode didn't even have PRINT AT, let alone PLOT, DRAW,
> BEEP, etc.

Later in your post you indicate that you are not comparing your Rectrum ZX81
to the Commodore 64, but rather your Rectrum 128. Therefore, the Commodore
128 and BASIC 7.0 will now enter stage left. (BTW, when you become sensible
enough quit referring to the Commodore a commode, I will stop calling the
Spectrum a Rectrum.) :-)

With CBM BASIC 7.0, PRINT AT can be achieved by using the CHAR (CHARacter)
command, which has options for setting the column and row of the first
character in the string. The CHAR command can also set the color source
and/or select reverse field to be used in displaying the string of characters
to be printed to the screen. The CHAR command can be used to print to either
a text _or_ graphic screen. By using a simple loop and MID$ functions the
CHAR command can even be used to place animated text on a graphic!

BASIC 7.0 does not have a PLOT command. However, as I remember, the Sinclair
PLOT command just places a little square box (about 4 pixels by 4 pixels), or
a series of little square boxes, on the screen. The same effect can be had
in BASIC 7.0 by using the BOX command with the paint option set to fill the
box with the color of ones choice. The BOX command gives the programmer
control over the size, shape, and rotation of the rectangle, as well as
whether or not to fill it with color.

BASIC 7.0 does have a DRAW command which can draw a single pixel, a line, or
more complex shapes (a hexagon for example).

In addition, there is the CIRCLE command. Besides the obvious option of
setting the size of the circle drawn, other optional parameters can be used
to draw an ellipse or an arc instead of a simple circle.

Then, there is the PAINT command which can be used to fill a circle, or any
other area already drawn with color.

And, the SSHAPE command can be used to save a selected portion of the screen
to memory so that it can be duplicated elsewhere on the screen with the
GSHAPE command.

You are right about the Commodore not having a BEEP command. Instead, BASIC
7.0 has the SOUND command, which can not only provide a beep, but more
complex sounds as well, even musical notes. Parameters of the SOUND command
include voice, frequency value, duration, step direction, minimum frequency
(if step is used), waveform, and pulse width. Note that each of the three
voices can play a different SOUND at the same time to create truly complex

Of course if it is music you want the PLAY command is easier to use in BASIC
7.0. You have several predefined envelopes which include piano, accordion,
calliope, drum, flute, guitar, harpsichord, organ, trumpet, and xylophone.
If you don't like any of these, the ENVELOPE command can be used to define
the musical instrument of your choice. Again you have three voices, so you
can have, for example, a piano, organ, and flute playing at the same time.

Parameters for the PLAY command include voice, octave, envelope, volume,
filter, notes (A thru G), and elements. Elements include sharp, flat, whole
note, half note, quarter note, eighth note, sixteenth note, and rest. If
filter is used, filter parameters are set by the FILTER command.

Oh, I almost forgot to mention the TEMPO command. That one should be
self-explanatory. ;-)

> Sinclair's even had a much more sensible string splitting regime.
> Left$ right$ mid$???? pah, who needs them when you can split any string
> with
> the same command. A$(TO 5), A$(3 TO), A$(2 TO 5)

All decent BASIC's have LEFT$, RIGHT$, and MID$ functions. These were
inherited from Dartmouth BASIC I believe. Without them, no BASIC is

> Did the commode actually HAVE interrupt commands, error trapping and ON?

There you go again, oh one of little brain. Just can't figure out how to
spell Commodore can you? In BASIC 7.0 the TRAP command followed by a line
number turns on error trapping and on an error sends program execution to the
referenced line number. TRAP without a line number turns error trapping off.

ON? ON what? Do you mean something like this:

20 ON X GOTO 30,40,50,60

> So, you couldn't even do a little machine code and save it to tape?
> Without storing it in a REM routine, like you had to do with the ZX81?

The Commodore 128 has a nice machine language monitor in ROM which was
activated by using the MONITOR command from BASIC. And, it was just as easy
to return to BASIC from the monitor. Any desired segment of memory could be
easily saved to a file from the monitor.

Any desired segment of RAM could also be saved directly from BASIC by using
the BSAVE command. A file could also be loaded anywhere in RAM with the
BLOAD command in BASIC, or from within the monitor if you desired to do it
that way instead.

Enough for now. Time to go eat some food.
Best regards,

Sam Gillett

I saw Sir Clive making crop circles,
But they turned out square!!