PDA

View Full Version : Yet another pointless arguement?



Terry Yager
January 29th, 2004, 03:16 PM
OK, a quickie: How many bits are in a byte? Here's another fundament on which it's difficult to get the "authorities" to agree. I was taught that the correct answer to this question is "it depends on the word length". My definition is that a byte is half a word, so that in a 16-bit computer, a byte is 8 bits. When you get into other word lengths, the byte length changes, f'rinstance, in a 12-bit system, like the DEC PDP-11 the byte length should be 6 bits. (Any DEC programmers out there care to confirm this? What is the convention in the DEC world?)
Another definition I have seen is that a byte is enough bits to contain one character, meaning (usually) 8 bits, but ASCII is actually a 7-bit standard. Very confusing...

--T

Erik
January 29th, 2004, 04:02 PM
My understanding is that, although they are sometimes used interchangably, Byte, Character and Word are often different beasts.

A byte is always 8 bits.

A character is 7, 8 or 16 bits depending on the context.

A word can be just about anything with 8, 12 and 16 being common bit-lengths but with others existing.

Erik

vic user
January 29th, 2004, 04:33 PM
i am totally with Eric.

coincidentally, i just finished reading an rs232 article today, and they were talking a lot about this type of stuff, and the article mentioned much of what Eric said.

here is what i was reading:

http://www.taltech.comTALtech_web/resources/intro-sc.html

chris

vic user
January 29th, 2004, 04:35 PM
oops.

need to put a '/' between 'com' and 'TALtech for the link to work

chris

Terry Yager
January 29th, 2004, 05:58 PM
Ok, I googled these up: (in the same order google presented them.)

http://www.matisse.net/files/glossary.html#B
http://www.hyperdictionary.com/dictionary/byte
http://dict.die.net/byte/
http://www.thefreedictionary.com/byte
http://www.phonescoop.com/glossary/term.php?gid=26
http://www.books.md/B/dic/byte.php

Etc, etc, etc...

Btw, how many bits in a byte for a 4-bit processor?

--T

barryp
January 29th, 2004, 08:54 PM
A character is 7, 8 or 16 bits depending on the context.

And then there's Unicode. Let's not go there. Yet. For many years please.

CP/M User
January 29th, 2004, 09:52 PM
"Terry Yager" wrote:

> OK, a quickie: How many bits are in a byte?

256 isn't it?

> Another definition I have seen is that a byte is enough
> bits to contain one character, meaning (usually) 8 bits,
> but ASCII is actually a 7-bit standard. Very confusing...

Yeah, haven't you ever looked up an ASCII table to find it goes
up to 127 (which is 7 bits). My Amstrad has a 7bit printer port
which means it can only print characters up to 127 (is that
clear?)

Anyone know different?

Cheers,
CP/M User.

CP/M User
January 29th, 2004, 09:56 PM
"Erik" wrote:

> My understanding is that, although they are
> sometimes used interchangably, Byte,
> Character and Word are often different
> beasts.

> A byte is always 8 bits.

Oh okay, I've just listed the number of
combinations to that, that's all! :-)

> A character is 7, 8 or 16 bits depending on the
> context.

ASCII is 7 I believe.

Cheers,
CP/M User.

carlsson
January 29th, 2004, 11:17 PM
I would believe anyone working with 12, 36 or other number of bits* may not use the "byte" term too often, but instead words and half-words. I have also had this discussion elsewhere, but of the active computer users today I would say more than 90% are content with a byte is eight bits (but word length varies). If a byte always is a half word, it means the 8-bit generation has four bit bytes but we always thought they were eight bits. The mentioned 4-bits like 4004 should have two bit bytes, which is less than a nybble (normally four bits on a 8-bit machine).

*) How do you count bits - is it the ALU, the address bus, the data bus, average of all or just a number of the blue? This is another common argument, maybe more common than the number of bits in a byte.

Terry Yager
January 30th, 2004, 06:42 AM
*) How do you count bits - is it the ALU, the address bus, the data bus, average of all or just a number of the blue? This is another common argument, maybe more common than the number of bits in a byte.

I've always counted the word length by the number of bits in the internal registers, or more specifically, the acumulator. The 8080-family has 8-bit registers and even though they are capable of handling 16-bit values (by combining registers), they are still considered 8-bitters.

--T

mbbrutman
January 30th, 2004, 07:02 AM
I think a 'byte' has always been eight bits.

As for word length, there have been a lot of variations. Early machines had all sorts of funky word lengths. They also didn't use 'bytes' as machines use them today.

For example, you might have a machine with a 36 bit word, and a memory that only talks in words. To stuff the letter 'A' or a '1' in memory you might only need 6 bits of a word. (Think of 26 letters, 10 numbers, and some punctuation chars - 6 bits covers that fine.) So a single word might hold 6 characters of data.

The awkward thing on old machines was that you might not be able to address a single byte in a word - you'd have to use special instructions to set the particular bits within a word that you needed. String searching would be a pain too - lots of bit manipulation.

Some architectures had 'spare' bits after you packed characters into a word. Those spare bits could be used as flags for things like 'end of string.'

As things progressed in the 50s and 60s people figured out that a byte is a good basic unit of memory, and that being able to address specific bytes is a good thing too - it cuts down on the bit twiddling.

As for the word size of a machine, well, that's typically what the ALU could process in one cycle. So you look at something like the 8086 and it's clearly a 16 bitter. But you look at an 8088 with the hampered bus and you wind up thinking of it as '16/8' instead of pure 16.

Terry Yager
January 30th, 2004, 09:14 AM
An extensive google search failed to turn up any support for "my" definition of "byte" (half-a-word). I did p'ticularly like the one (above) that says "more than a bit, but less than a word". I think I'll start using that definition from now on.

--T

carlsson
January 30th, 2004, 10:26 AM
Then we can start counting how many bits an image is. They say that a picture says more than a thousand words, but not exactly how much more. Given the variations in word length, a picture could be anything from 8008 bits on a Z80 to 72000 bits or more on a PDP (limiting myself at 2000 words per image, as each word already is 36 bits IIRC). :lol:

Terry Yager
January 30th, 2004, 11:03 AM
Then we can start counting how many bits an image is.

Or how many angels can dance on the head of a pin. (Trick question--angels don't dance, they just sing.)

--T

olddataman
January 30th, 2004, 11:07 AM
As usualwith me, this will be longer than most can tolorate, but It is not so simplea question.
IBM coined the term Byte when they dessigned the System 360 series in the early 1960's. A byte was the basic increment of memory, and could be considered as a quarter-word, which was 32 bits. It also defined the length of a character in the IBM Standard EBCDiC code (Extended Binary Coded DDecimal (for) Information Interchange, or something close to that) which defined 256 characters. It deliberately ignored ASCII (American Standard Code for Informatioin Interchange) which had not yet been selected as the standard for computers purchased by hte US Government. ASCII was only a seven bit code and only defined 128 characters. Notice that both ASCII and EBCDIC ignore the use of an extra bit for parity and the necessity of tacking on a start bit and one or two stop bits for asynchronus communications applications.
In my opinion, the definition of a Byte has nothing much to do with a word oength, unless the word dlengthis 32 bits. Sixteen bits is a half word, but a byte is rarely described as a quarter word. And, one canthink of a Byte being a character length, except that sometimes it doesent, like when an application iswritten that communicates ssome items of data as BCD, 1/2 byte Knibbles! Over the years there have been a half dozen or moe "character codes used , but any resembelence or appearant similarity to the Byte is purely coincidental.

As for DEC, they have used only three alphaneumeric dodes for their basic I/O uses. In the 12-bit and 18-bit computers such as the PDP-1, -4,-7, 09, -15 (18-bit machines) and the PDP-8 series the PDP-5 and a couple other special purpose versions of the PDP-8, (the 12-bit machines) all used 6-bit alphanumeric I/O codes whichdefined 64 characters. I think one can include the PDP-6 here too, bacause it was a 36-bit machine. All of the later machines which include the PDP-11 and all of the VAX machines and I think the PDP-10 too) were all 16-bit or 32-bit machines and used the ASCII codesfor I/O to printers, console printers, and other similar devices

To summarze: A Byte is 8 bits long. It does not relate to any word-length other that as a factor of the physical length of a word or a fraction of a word or a multiple of a word. If it is not a factor of the word length it is not defineable as a Byte.
Ray

CP/M User
January 30th, 2004, 12:33 PM
"Terry Yager" wrote:

> I've always counted the word length by the
> number of bits in the internal registers, or
> more specifically, the acumulator. The
> 8080-family has 8-bit registers and even
> though they are capable of handling 16-bit
> values (by combining registers), they are
> still considered 8-bitters.

It's also possible to write equivalent of a 16bit
poke routine on my Z80. The routine I've
written may not be the best, but because you
cannot swap a 16 bit number using register
pairs, doesn't mean it can't be done, it just
takes a bit more code (that's all)!

It's like a "SRL" instruction on an IBM, on the
8086/8088 based computer's you can only
issue this instruction with 1 each time,
however on a 286 upwards you can issue a
higher number with it, for the 8086/8088 it
just means that if you want a compatable
equivalent, you'd need to put more of those
statements together (hence more code)
than the 286 equivalent.

Cheers,
CP/M User.

Terry Yager
January 30th, 2004, 05:07 PM
It's also possible to write equivalent of a 16bit
poke routine on my Z80. The routine I've
written may not be the best, but because you
cannot swap a 16 bit number using register
pairs, doesn't mean it can't be done, it just
takes a bit more code (that's all)!

It's like a "SRL" instruction on an IBM, on the
8086/8088 based computer's you can only
issue this instruction with 1 each time,
however on a 286 upwards you can issue a
higher number with it, for the 8086/8088 it
just means that if you want a compatable
equivalent, you'd need to put more of those
statements together (hence more code)
than the 286 equivalent.

Cheers,
CP/M User.

Ok, let's see if I understand how this works. (I'm just guessing.) In order to swap two registers you would set up a "buffer" area in memory, move the contents of the register into the buffer, then from memory into the target register? That kinda makes some sense to me...

--T

CP/M User
January 30th, 2004, 06:03 PM
"Terry Yager" wrote:

> Ok, let's see if I understand how this works.
> (I'm just guessing.) In order to swap two
> registers you would set up a "buffer" area
> in memory, move the contents of the
> register into the buffer, then from memory
> into the target register? That kinda makes
> some sense to me...

If you were reading data & using that data
for a routine, then yeah, I believe you have
to do it like that.

If you were going to poke a 16bit number
then you could do this:-

Load Memory address into HL
Load Data into DE
Load contents of E into HL
Increase HL
Load contents of D into HL
Return

Or it could even be BC loading it into HL,
I suppose. I've got some assembly code
if you want to have a look at it, but I've
used it when dealing with BASIC
programs in mind, though it should work
in assembly programming (I just haven't
tested it).

Cheers,
CP/M User.

Terry Yager
February 6th, 2004, 04:52 AM
If you were going to poke a 16bit number
then you could do this:-

Load Memory address into HL
Load Data into DE
Load contents of E into HL
Increase HL
Load contents of D into HL
Return


lxi h,<address to poke to>
lxi d,<sixteen bit data to poke>
mov h,e
inx h
mov h,d
ret


I've got some assembly code
if you want to have a look at it

Yes, I'd like that, if it's no trouble.

--T

CP/M User
February 6th, 2004, 11:22 PM
"Terry Yager" wrote:

>> If you were going to poke a 16bit number
>> then you could do this:-

>> Load Memory address into HL
>> Load Data into DE
>> Load contents of E into HL
>> Increase HL
>> Load contents of D into HL
>> Return


> lxi h,<address to poke to>
> lxi d,<sixteen bit data to poke>
> mov h,e
> inx h
> mov h,d
> ret

>> I've got some assembly code
>> if you want to have a look at it

> Yes, I'd like that, if it's no trouble.

This is what I've done on my Z80:


LD E,&#40;IX+00&#41;
LD D,&#40;IX+01&#41;
LD L,&#40;IX+02&#41;
LD H,&#40;IX+03&#41;
LD &#40;HL&#41;,E
INC HL
LD &#40;HL&#41;,D
RET

So, if I was calling this (from BASIC)
it would look like this,
'CALL AOR,ATP,V'
AOC = Address of routine (which were've
just written)
ATP = Address to Poke (where to poke our
16bit number)
V = Value (which is our 16bit number!) :-)

I don't quite follow your routine you posted
above, is that 8080 code? AFAIK on my Z80
you can only use the HL register pair when
storing the contents of a register into an
address. My little routine seems to work
fairly quickly though (which I'm happy
about).

Cheers,
CP/ M User.

Terry Yager
February 8th, 2004, 09:21 AM
"Terry Yager" wrote:

>> If you were going to poke a 16bit number
>> then you could do this:-

>> Load Memory address into HL
>> Load Data into DE
>> Load contents of E into HL
>> Increase HL
>> Load contents of D into HL
>> Return


> lxi h,<address to poke to>
> lxi d,<sixteen bit data to poke>
> mov h,e
> inx h
> mov h,d
> ret

>> I've got some assembly code
>> if you want to have a look at it

> Yes, I'd like that, if it's no trouble.

This is what I've done on my Z80:


LD E,&#40;IX+00&#41;
LD D,&#40;IX+01&#41;
LD L,&#40;IX+02&#41;
LD H,&#40;IX+03&#41;
LD &#40;HL&#41;,E
INC HL
LD &#40;HL&#41;,D
RET

So, if I was calling this (from BASIC)
it would look like this,
'CALL AOR,ATP,V'
AOC = Address of routine (which were've
just written)
ATP = Address to Poke (where to poke our
16bit number)
V = Value (which is our 16bit number!) :-)

I don't quite follow your routine you posted
above, is that 8080 code? AFAIK on my Z80
you can only use the HL register pair when
storing the contents of a register into an
address. My little routine seems to work
fairly quickly though (which I'm happy
about).

Cheers,
CP/ M User.

The "code" above was just my feeble attempt at translating your pseudo-code into 8080 mnemonics. I didn't attempt to test it or anything until yesterday, when I discovered a bug. The line that reads "mov h,d" should read "mov l,d" in order to put the byte into the low-order byte of HL without trashing the byte in H. I think that was what the routine was intended to do, right? I used 8080 code because that is what I have the tools for, and besides, I'm not real familiar with Z-80 code.
I'm also not very familiar with CALLing ML routines from BASIC, so have a couple of questions. First, what data is in your index register when the routine is called? How did it get there? (LD E,(IX+00) Second, how does BASIC pass the parameters (ATP,V) to the CALLed routine? Is that the data in the IX register? Also, what version of BASIC are you using? MBASIC 5.5, (for CP/M) or is it some kinda BASIC that is built-in to your Amstrad's firmware?
Another question is, how do you go about writing/storing a ML subroutine from BASIC? Is it entered using BASIC's built-in line editor, or do you have to write (and store) it before running BASIC? (I know, I should just RTFM, but I'm feeling kinda lazy...)
BTW, I think you can use the Z-80's HL register pair to pass data without using memory with a command like "LD HL,nnnn", with nnnn representing a 16-bit constant, instead of "LD HL,(nnnn)", where (nnnn) is an address. (I could be wrong about this, I really need to learn more about the Z80.)

--T

CP/M User
February 9th, 2004, 01:16 AM
"Terry Yager" wrote:

>> This is what I've done on my Z80:


>> LD E,&#40;IX+00&#41;
>> LD D,&#40;IX+01&#41;
>> LD L,&#40;IX+02&#41;
>> LD H,&#40;IX+03&#41;
>> LD &#40;HL&#41;,E
>> INC HL
>> LD &#40;HL&#41;,D
>> RET

>> So, if I was calling this (from BASIC)
>> it would look like this,
>> 'CALL AOR,ATP,V'
>> AOC = Address of routine (which were've
>> just written)
>> ATP = Address to Poke (where to poke our
>> 16bit number)
>> V = Value (which is our 16bit number!) :-)

>> I don't quite follow your routine you posted
>> above, is that 8080 code? AFAIK on my Z80
>> you can only use the HL register pair when
>> storing the contents of a register into an
>> address. My little routine seems to work
>> fairly quickly though (which I'm happy
>> about).

> The "code" above was just my feeble attempt
> at translating your pseudo-code into 8080
> mnemonics. I didn't attempt to test it or
> anything until yesterday, when I discovered a
> bug. The line that reads "mov h,d" should
> read "mov l,d" in order to put the byte into
> the low-order byte of HL without trashing the
> byte in H. I think that was what the routine
> was intended to do, right? I used 8080 code
> because that is what I have the tools for, and
> besides, I'm not real familiar with Z-80 code.

I'll a little stumped from this code you're using
(even after you've fixed it), since what my
routine is doing is POKEing 16bit data into
memory & in order to do this, you have to
load the byte data into the contents of that
address (which is what it's doing)! I would
have just though that routine would move the
contents of a 16bit number from one register
to another (if that's what you're trying to do! :-)

> I'm also not very familiar with CALLing ML
> routines from BASIC, so have a couple of
> questions. First, what data is in your index
> register when the routine is called? How did it
> get there? (LD E,(IX+00) Second, how does
> BASIC pass the parameters (ATP,V) to the
> CALLed routine? Is that the data in the IX
> register? Also, what version of BASIC are you
> using? MBASIC 5.5, (for CP/M) or is it some
> kinda BASIC that is built-in to your Amstrad's
> firmware?

Yes, the index registers '(IX+some_number)' are
used for passing numbers called in BASIC to the
M/C routine. The number next to this register
represents one part of the paramaters & usually
the register from the back starts as from 0, so
since E represents the low byte of register DE this
is the start & then D which is 1. This represents
the 16bit number. Then we go to HL we use 2 & 3
& it works the same way (L for the Low & H for the
High bytes! :-)

I'm pretty sure the Index registers are standard
for Z80s, so they should work on your machine if
it works that way. The trick to remember is that
you could have other routines with more
paramaters (this one just happens to need two), so
it's important to get the right register in the right
spot (otherwise you maybe stumped! :-)

No, I've used BASIC in Amstrads ROM, but in
theory the same routine could be used in MBASIC.

I've written a simular routine in TP 3 except it
doesn't use Index registers, this is because TP 3
uses a slightly different form of support in M/C,
by using Inline statements & in that it's possible
to use variables names in those statements to
optain the contents of them & put them into a
register (for example 'LD HL,(address)' &
'LD DE,(value)'. Everything else is the same.

> Another question is, how do you go about
> writing/storing a ML subroutine from BASIC?

Oh dear, I've done it a number of ways in most
recent times I've done it the hard way by going
to my Assembly book & poking the values (I've
also used my assembler program a bit) &
memory editor (for debugging), there's lots of
handy routines written in BASIC & freebies
which make handling M/C fun! :-)

> Is it entered using BASIC's built-in line editor,
> or do you have to write (and store) it before
> running BASIC? (I know, I should just RTFM,
> but I'm feeling kinda lazy...)

Since I've been using my Amstrad emulator, I've
been using a text editor (which is ROM based &
accessible at a keystroke from a RSX).

But small routines I've done like this, have been
done from hand & using a monitor type program
for debugging & disassembling (which shows you
what the code is doing).

I'd suggest that if you have something in memory
& want to write it out as a BASIC program, to write
a program which writes out a BASIC data file. I
have written one myself & know of a couple of
others, but they will of course be Amstrad Specific.

> BTW, I think you can use the Z-80's HL register
> pair to pass data without using memory with a
> command like "LD HL,nnnn", with nnnn
> representing a 16-bit constant, instead of
> "LD HL,(nnnn)", where (nnnn) is an address.

You probably could (I'm not sure), however, I've
never seen any examples of this. I've only ever
seen Index Registers been used (except for when
I've used Turbo Pascal). I first tried "LD HL,nnnn"
in it's Turbo Pascal equivalent, but this doesn't
work, because all you're doing is returning the
address of where the variable resides, when I
realised this I wrote a routine to put the contents
of that variable into that register, which works,
because it's getting the value we want to use &
not the address for where it belongs & corrupting
the memory! But we're talking about two
different things.

Okay, lets say for example you wrote a routine
& you know where HL resides & DE resides, the
trouble is that I don't believe you can pass
values into those registers, you could poke the
values into that (which I've done in TP), but in
BASIC it would mean a tedious process of
poking values everytime, unless you wrote a
BASIC program which goes backwards &
fowards getting values & you tell it to poke into
memory. It just means more BASIC though,
which could be prone to slowing things down
rather than call a routine & give it some
numbers to deal with, I believe it would be
quicker than Poking those numbers & calling a
routine.

No, I'm not so convinced you can do it like this
(unless you did a poke), & certainally not put
contents of variables into HL just like that (it
might take some more code to do it & by the
time you've been pulling out hair & stuff, using
the Index Registers isn't such a bad idea - the
code maybe the same length or a couple of
bytes longer, but it still works & is quick for
that purpose), it's really a question of if you're
using the Index Registers for something else
(I can't think of what or what else you'd use
them for), but if that were the case, then yes,
maybe alternatives like feeding numbers into
the registers direct maybe the way to go, but
since I've never seen a way (apart from Poking
values into the address area for which those
registers are in memory), I can't say it's
possible. It's only in TP I've seen something like
this, but the cirstances are slightly different in
that Inline M/C has been designed to be more
flexible.

> (I could be wrong about this, I really need to
> learn more about the Z80.)

Sure if you were programming straight out Z80
assembly programs (no BASIC) & writing routines
which other assembly routines used to pass values
in between, then yes, it's possible to put values
straight into that register.

The Stack Pointer maybe another way of getting
values from BASIC into Registers, but having
played with this kinda thing on an IBM, I would
have to say it's slightly tricker than using the
Index Register (not much though).


Cheers,
CP/M User.

Terry Yager
February 9th, 2004, 08:45 AM
OK, now I see the problem. I was trying to transfer the data from the DE reg into the HL reg, which was not the intent of your routine. The object is to get the value from DE into *memory* at the address pointed to by the HL reg. I can do that fairly easily:


lxi h,<address> ;place an address into the HL reg. pair
lxi d,<data to POKE> ;place the value in DC
mov m,c ;place value from C into memory at address in HL
inx h ;increment the HL reg pair
mov m,d ;put D into memory
ret ;back to BASIC

Unfortunatly, what cannot be done easily is to get the routine into the BASIC program using Micro$oft MBASIC 5.5. There is really no (easy) way of CALLing a ML routine in that dialect. (I used DDT to test-drive the routine, then with DDT verified that the data was where it's s'posed to be.
That's OK tho, because I have another solution. I dusted off the manual for my Cambridge Z88, which uses BBCBASIC, and lo and behold, there is a command to CALL an ML program, just like in your Amstrad. (Does the Amstrad use BBC BASIC?)


The CALL statement
CALL allows a machine code subroutine to be called, with optional passing of parameters. The CALL statement sets up a parameter block which contains details of the parameters (their types and addresses). Parameters are passed by reference and can therefore be altered by the machine code routine. On entry to the subroutine the processor's registers are set up as described for USR above; also the Z80's IX register is set to the address of the parameter block and IY to the address of the subroutine (this can be useful if the machine code routine needs to find out where it is). The parameter block contains the following information:-
number of parameters - 1 byte (IX)
1st parameter type - 1 byte (IX+1)
1st parameter address - 2 bytes (IX+2, IX+3), LS first
2nd parameter type - 1 byte ) repeated as often
2nd parameter address - 2 bytes ) as necessary.


At least now we're on the same page. I can use the Z88 to practice on for now, as it seems to be similar to the dialect you're using. And it recognizes Z80 opcodes, so that can't be all bad. (I wanted an excuse to start using my Z88 more anyways.)

--T

CP/M User
February 9th, 2004, 01:43 PM
> OK, now I see the problem. I was trying to transfer the data
> from the DE reg into the HL reg, which was not the intent of
> your routine. The object is to get the value from DE into
> *memory* at the address pointed to by the HL reg. I can do
> that fairly easily:


> lxi h,<address> ;place an address into the HL reg. pair
> lxi d,<data to POKE> ;place the value in DC
> mov c,M ;place value from C into memory at address in HL
> inx h ;increment the HL reg pair
> mov d,M ;put D into memory
> ret ;back to BASIC

Oh okay, that's fairly different, I'm not sure if there's a
mistake in there, you've got DC instead of DE, I guess if it's
DC, then that would be correct! :-)

> Unfortunatly, what cannot be done easily is to get the
> routine into the BASIC program using Micro$oft MBASIC 5.5.
> There is really no (easy) way of CALLing a ML routine in that
> dialect. (I used DDT to test-drive the routine, then with DDT
> verified that the data was where it's s'posed to be.

I thought there was a 'CALL' command in MBASIC, though I've
mainly used MBASIC under CP/M-86 (v5.1 I think it was), which
is just an interpreter. I know there were some MBASIC
compilers under CP/M-80, but would have though that a command
like 'CALL' would have been present. Maybe it's just in the
Interpreted version of MBASIC under CP/M-80 (I'm assuming that
there is one).

> That's OK tho, because I have another solution. I dusted off
> the manual for my Cambridge Z88, which uses BBCBASIC, and lo
> and behold, there is a command to CALL an ML program, just
> like in your Amstrad. (Does the Amstrad use BBC BASIC?)

I believe there are some simularities between BBCBASIC &
Amstrads Locomotive BASIC, but that's about all. Some RSXes
were once written which demonstrated the BBCBASIC proc command
(that was one thing Amstrad's BASIC didn't have), or and a
'EVAL' command, but that's about all.

I'm not familiar with the Cambridge Z88, but I'm guessing it's
Z80 based & can run CP/M! Interesting to see it's using a
BASIC found on a different computer system, I'm guessing that
it's compatable with BBC BASIC programs. I did a little
research into the BBC computer & found that it's 6502 based,
but also had a Z80 card available for it (which I didn't know
about)

--- Quote: ---

> The CALL statement
> CALL allows a machine code subroutine to be called, with optional
> passing of parameters. The CALL statement sets up a parameter
> block which contains details of the parameters (their types and
> addresses). Parameters are passed by reference and can therefore
> be altered by the machine code routine. On entry to the subroutine
> the processor's registers are set up as described for USR above;
> also the Z80's IX register is set to the address of the parameter
> block and IY to the address of the subroutine (this can be useful
> if the machine code routine needs to find out where it is). The
> parameter block contains the following information:-
> number of parameters - 1 byte (IX)
> 1st parameter type - 1 byte (IX+1)
> 1st parameter address - 2 bytes (IX+2, IX+3), LS first
> 2nd parameter type - 1 byte ) repeated as often
> 2nd parameter address - 2 bytes ) as necessary.

--- End Quote: ---

Unfortunately, I find that a little confusing (if it's working
differently) from the way I know it, I guess the only way to
find out would be to try the routine I wrote & see if it works.

> At least now we're on the same page. I can use the Z88 to practice
> on for now, as it seems to be similar to the dialect you're using.
> And it recognizes Z80 opcodes, so that can't be all bad. (I wanted
> an excuse to start using my Z88 more anyways.)

I'll check your computer out at old-computers museum & get the
details of it, but I'm curious to know, is the Z88 a seperate
processor which is an enhanced version of the Z80? If so, it would
be interesting to see what extra features that processor supports.
It would be a bit like the C64s 6510 which is an enhanced version of
the 6502 processor.

Cheers,
CP/M User.

Terry Yager
February 9th, 2004, 04:15 PM
> OK, now I see the problem. I was trying to transfer the data
> from the DE reg into the HL reg, which was not the intent of
> your routine. The object is to get the value from DE into
> *memory* at the address pointed to by the HL reg. I can do
> that fairly easily:


> lxi h,<address> ;place an address into the HL reg. pair
> lxi d,<data to POKE> ;place the value in DE
> mov d,m ;place value from D into memory at address in HL
> inx h ;increment the HL reg pair
> mov e,m ;put E into memory
> ret ;back to BASIC

Oh okay, that's fairly different, I'm not sure if there's a
mistake in there, you've got DC instead of DE, I guess if it's
DC, then that would be correct! :-)

Yeah, you're right, it's DE. (My brain musta been on hold at 5:00 this a.m.) Anyways, you got the idea, that's what counts. There, I've fixed it.


> Unfortunatly, what cannot be done easily is to get the
> routine into the BASIC program using Micro$oft MBASIC 5.5.
> There is really no (easy) way of CALLing a ML routine in that
> dialect. (I used DDT to test-drive the routine, then with DDT
> verified that the data was where it's s'posed to be.

I thought there was a 'CALL' command in MBASIC, though I've
mainly used MBASIC under CP/M-86 (v5.1 I think it was), which
is just an interpreter. I know there were some MBASIC
compilers under CP/M-80, but would have though that a command
like 'CALL' would have been present. Maybe it's just in the
Interpreted version of MBASIC under CP/M-80 (I'm assuming that
there is one).

No, there is a USR command, which is used to execute a M/L subroutine, but only after you have figgered out how to get the routine into memory. There are several methods for doing this, none of which are simple. One way is to load a (hex only) file with DDT, then exit out of DDT and run BASIC. Another way is to use lots of POKEs. Anyways, once you have the routine in memory, and BASIC is loaded (with the area in memory where your program resides protected), then you have to use a DEFUSR command to pass the address of the ML routine. Now you're ready to call the routine with a command like USR. Even after all that, you can only pass one argument to your routine from BASIC. Any more than that and you're screwed. At least, that is the way I understand it to work.


> That's OK tho, because I have another solution. I dusted off
> the manual for my Cambridge Z88, which uses BBCBASIC, and lo
> and behold, there is a command to CALL an ML program, just
> like in your Amstrad. (Does the Amstrad use BBC BASIC?)

I believe there are some simularities between BBCBASIC &
Amstrads Locomotive BASIC, but that's about all. Some RSXes
were once written which demonstrated the BBCBASIC proc command
(that was one thing Amstrad's BASIC didn't have), or and a
'EVAL' command, but that's about all.

I'm not familiar with the Cambridge Z88, but I'm guessing it's
Z80 based & can run CP/M! Interesting to see it's using a
BASIC found on a different computer system, I'm guessing that
it's compatable with BBC BASIC programs. I did a little
research into the BBC computer & found that it's 6502 based,
but also had a Z80 card available for it (which I didn't know
about)

Yeah, the Z88 is a Z80 based machine, but doesn't run CP/M. It has a proprietary OS called "OZ". The version of BASIC that was written for the Z88 is the same as the version for the BBC with a Z80 co-processor. It's the 6502 BASIC translated for the Z80. One very kewl feature is that it has a built-in Z80 line-assembler, which allows you to enter Z80 codes right from the command line. It assembles and executes the code on-the-fly! You probably don't even need the CALL statement. (Not sure how well this works, I'm still playing with it.)


--- Quote: ---

> The CALL statement
> CALL allows a machine code subroutine to be called, with optional
> passing of parameters. The CALL statement sets up a parameter
> block which contains details of the parameters (their types and
> addresses). Parameters are passed by reference and can therefore
> be altered by the machine code routine. On entry to the subroutine
> the processor's registers are set up as described for USR above;
> also the Z80's IX register is set to the address of the parameter
> block and IY to the address of the subroutine (this can be useful
> if the machine code routine needs to find out where it is). The
> parameter block contains the following information:-
> number of parameters - 1 byte (IX)
> 1st parameter type - 1 byte (IX+1)
> 1st parameter address - 2 bytes (IX+2, IX+3), LS first
> 2nd parameter type - 1 byte ) repeated as often
> 2nd parameter address - 2 bytes ) as necessary.

--- End Quote: ---

Unfortunately, I find that a little confusing (if it's working
differently) from the way I know it, I guess the only way to
find out would be to try the routine I wrote & see if it works.


I dunno, seems the same to me. (Parameters are passed through the IX register, which contains the address of the actual parameter block in memory.) I'll try it and get back to you on this.



> At least now we're on the same page. I can use the Z88 to practice
> on for now, as it seems to be similar to the dialect you're using.
> And it recognizes Z80 opcodes, so that can't be all bad. (I wanted
> an excuse to start using my Z88 more anyways.)

I'll check your computer out at old-computers museum & get the
details of it, but I'm curious to know, is the Z88 a seperate
processor which is an enhanced version of the Z80? If so, it would
be interesting to see what extra features that processor supports.
It would be a bit like the C64s 6510 which is an enhanced version of
the 6502 processor.

The processor in the Z88 is a straight-up cmos version of the Z80. AFAIK, it has no extra goodies included. But, it's still a very kewl computer. If you ever get a chance, grab one up. They're a lot more common on your side of the pond than they are here. (I see 'em on eBay.com.au all the time.)

--T

Terry Yager
February 9th, 2004, 05:13 PM
Well, I tried your routine on my Z88, and it seems to have worked. (Returned without error msg., and didn't crash my machine.) I don't have a debugger to eXamine the registers and verify that everything is where it belongs, but I'm assumung that it's all ok.

--T

CP/M User
February 9th, 2004, 06:32 PM
"Terry Yager" wrote:

> No, there is a USR command, which is used to execute a M/L
> subroutine, but only after you have figgered out how to get
> the routine into memory. There are several methods for doing
> this, none of which are simple. One way is to load a (hex
> only) file with DDT, then exit out of DDT and run BASIC.
> Another way is to use lots of POKEs.

Well if you're BASIC supports DATA statements & you can use
BASIC to read the program in & poke it into memory, with just
a single POKE. Of course my routine could just about go
anywhere in memory, it's just a matter of picking the safest
spot.

> Yeah, the Z88 is a Z80 based machine, but doesn't run CP/M.
> It has a proprietary OS called "OZ". The version of BASIC
> that was written for the Z88 is the same as the version for
> the BBC with a Z80 co-processor. It's the 6502 BASIC
> translated for the Z80. One very kewl feature is that it
> has a built-in Z80 line-assembler, which allows you to
> enter Z80 codes right from the command line. It assembles
> and executes the code on-the-fly! You probably don't even
> need the CALL statement. (Not sure how well this works, I'm
> still playing with it.)

Very friendly. When you say it assembles & executes the code
on-the-fly, you mean you enter the code & it runs it?

> The processor in the Z88 is a straight-up cmos version of
> the Z80. AFAIK, it has no extra goodies included. But, it's
> still a very kewl computer. If you ever get a chance, grab
> one up. They're a lot more common on your side of the pond
> than they are here. (I see 'em on eBay.com.au all the time.)

They certainally look small enough to carry around. It's
reminds me of the Amstrad NC100 notebook when I saw a picture
of it on old-computers.com museum.

> Well, I tried your routine on my Z88, and it seems to have
> worked. (Returned without error msg., and didn't crash my
> machine.) I don't have a debugger to eXamine the registers
> and verify that everything is where it belongs, but I'm
> assumung that it's all ok.

If you can test the routine in BBCBASIC, just try this:
Poke a 16bit number in memory somewhere & then use
this program to see if it's working:

10 for addr=address_of_number to address_of_number+1
20 print hex$&#40;peek&#40;addr&#41;&#41;
30 next addr
Just modify line 10 to put in the spot in memory where the
number was poked to, hopefully if BBCBASIC supports
displaying hex numbers & can peek at the contents of memory,
then you'll be able to see if it's there or not. If 'hex$'
doesn't work use this 'print peek(addr)' & if peek doesn't
work, then I don't know what it's equivalent should be. You
did say it supports POKE, so PEEK should be there as well (in
theory).

Cheers,
CP/M User.

CP/M User
February 9th, 2004, 07:08 PM
"Terry Yager" wrote:

> The processor in the Z88 is a straight-up
> cmos version of the Z80. AFAIK, it has
> no extra goodies included. But, it's still
> a very kewl computer. If you ever get a
> chance, grab one up. They're a lot more
> common on your side of the pond than
> they are here. (I see 'em on
> eBay.com.au all the time.)

Yeah, I just had a look at eBay, but could
only find one of these machines there.
The seller sounds like the nicest person in
the world, but it looks like they don't have
any Manuals for the machine (hence
saying it's just the machine). I've got 4
days to think about it though!

Cheers,
CP/M User.

Terry Yager
February 9th, 2004, 07:57 PM
"Terry Yager" wrote:


Well if you're BASIC supports DATA statements & you can use
BASIC to read the program in & poke it into memory, with just
a single POKE. Of course my routine could just about go
anywhere in memory, it's just a matter of picking the safest
spot.

I haven't tried a DATA statement yet, but I don't remember the manual mentioning it so it's probably not supported.



Very friendly. When you say it assembles & executes the code
on-the-fly, you mean you enter the code & it runs it?

Well, mebbe not quite on the fly, but close to it. You set a variable to point to the address of the ML, then invoke the assembler. After entering the code, you exit from the assembler (but not from BASIC), then you can just RUN the prog you have created, or execute the CALL to the address you used, depending how the program is written. I tried both ways and both seem to work.


Quoted from the manual:

BASIC Inline Assembler

BBC BASIC on the Z88 comes with an inline assembler built in. The
variable P% is used as a program counter. The user must set P% to
the desired start point for the machine code before invoking the
assembler. The assembler can be invoked with the [ symbol on a
single line. It is uninvoked by a ] on a single line. Below is a
sample program:

10 DIM code 100
20 P% = code
30 [
40 LD BC,50
50 RET
60 ]

It is recommended that the user have a good knowledge of Z80
machine code programming before trying the assembler. Locking up
your Z88 could cause it to do a hard reset (take it to a "virginal"
blank state).

Note:I would also recommend that you not CALL 0 from your BASIC program, as that caused a hard reset when I tried it. (I thought it would just cause a soft reset, like it does in CP/M.)


They certainally look small enough to carry around. It's
reminds me of the Amstrad NC100 notebook when I saw a picture
of it on old-computers.com museum.

Yes, it is quite small, and weighs just shy of two pounds. It's size/weight is similar to a Tandy WP-2 word processor, if you've ever seen one of those. I think the similarity between the Z88 and the Amstrad NC 100 (and 200) may be more than just a coincidence. Both systems owe a lot to the genius of Sir Clive Sinclair. I have never seen one of the Amstrads in real life, but it's definately on my "wish list".


If you can test the routine in BBCBASIC, just try this:
Poke a 16bit number in memory somewhere & then use
this program to see if it's working:

10 for addr=address_of_number to address_of_number+1
20 print hex$&#40;peek&#40;addr&#41;&#41;
30 next addr
Just modify line 10 to put in the spot in memory where the
number was poked to, hopefully if BBCBASIC supports
displaying hex numbers & can peek at the contents of memory,
then you'll be able to see if it's there or not. If 'hex$'
doesn't work use this 'print peek(addr)' & if peek doesn't
work, then I don't know what it's equivalent should be. You
did say it supports POKE, so PEEK should be there as well (in
theory).

Cheers,
CP/M User.

The Z88 BASIC doesn't support POKE or PEEK. (At least there's nothing about it in the manual.) I did try PEEKing the address where I had put the code, but it didn't work--just returned an error message. (No such variable, or something like that.)

--T

CP/M User
February 9th, 2004, 10:57 PM
"Terry Yager" wrote:

>> Well if you're BASIC supports DATA statements & you can use
>> BASIC to read the program in & poke it into memory, with just
>> a single POKE. Of course my routine could just about go
>> anywhere in memory, it's just a matter of picking the safest
>> spot.

> I haven't tried a DATA statement yet, but I don't remember
> the manual mentioning it so it's probably not supported.

See below! :-)

>> Very friendly. When you say it assembles & executes the code
>> on-the-fly, you mean you enter the code & it runs it?

> Well, mebbe not quite on the fly, but close to it. You set a
> variable to point to the address of the ML, then invoke the
> assembler. After entering the code, you exit from the
> assembler (but not from BASIC), then you can just RUN
> the prog you have created, or execute the CALL to the
> address you used, depending how the program is written.
> I tried both ways and both seem to work.

> Quoted from the manual:

--- Quote ---

> BASIC Inline Assembler

> BBC BASIC on the Z88 comes with an inline assembler built in.
> The variable P% is used as a program counter. The user must
> set P% to the desired start point for the machine code before
> invoking the assembler. The assembler can be invoked with
> the [ symbol on a single line. It is uninvoked by a ] on a single
> line. Below is a sample program:

> 10 DIM code 100
> 20 P% = code
> 30 [
> 40 LD BC,50
> 50 RET
> 60 ]

> It is recommended that the user have a good knowledge
> of Z80 machine code programming before trying the
> assembler. Locking up your Z88 could cause it to do a
> hard reset (take it to a "virginal" blank state).

--- End Quote ---

With this type of facility, you don't need POKE, PEEK or
DATA statements for that matter, as the assembly can
just be put into those statements. Does it have any
further detail about now to pass values between BASIC &
this Inline Assembly. If not, then I guess you could
try 'LD HL,(address)' & 'LD DE,(value)' & GOSUB where
you're line number starts or perhaps 'CALL code,adr,val'

In that case it would be as easy as you mentioned
earlier (without using the Index Registers).

This Inline Assembly would have to be a new feature on
this system (the original BBCBASIC wouldn't have had
this).

> Note:I would also recommend that you not CALL 0 from
> your BASIC program, as that caused a hard reset when
> I tried it. (I thought it would just cause a soft reset, like
> it does in CP/M.)

>> They certainally look small enough to carry around. It
>> reminds me of the Amstrad NC100 notebook when I saw a
>> picture of it on old-computers.com museum.

> Yes, it is quite small, and weighs just shy of two pounds.
> It's size/weight is similar to a Tandy WP-2 word
> processor, if you've ever seen one of those. I think the
> similarity between the Z88 and the Amstrad NC 100 (and
> 200) may be more than just a coincidence. Both systems
> owe a lot to the genius of Sir Clive Sinclair. I have never
> seen one of the Amstrads in real life, but it's definately on
> my "wish list".

Around 1992/3 I used to see the Amstrad NC100 (I don't think
the NC200 came out to Australia) & even played with the Text
editor on one (on display). I thought the keyboard was great. I
was nearly going to get either that or an Atari Portfolio, but
got my folks got a Typewriter instead (I wasn't impressed!)-:

The Amstrad NC100 is virtually identical to your Z88, well
perhaps the programs are different, but it came with BBCBASIC
as well. The Amstrad NC100 had no Disk Drive (unlike the NC200),
so it stored documents in Memory (or some RAM disk which had a
battery backup to keep the RAM Disk functioning - not a bad
idea!) :-)

The Amstrad NC200 from what I've heard & seen is quite different
in looks (& as mentioned earlier has a Disk Drive 3.5DSDD" I
believe) & unlike the NC100 which is like the Z88 the screen folds
up (it's perhaps more like a Atari Portfolio - so it's a small
notebook).

>> If you can test the routine in BBCBASIC, just try this:
>> Poke a 16bit number in memory somewhere & then use
>> this program to see if it's working:

>> 10 for addr=address_of_number to address_of_number+1
>> 20 print hex$&#40;peek&#40;addr&#41;&#41;
>> 30 next addr
>> Just modify line 10 to put in the spot in memory where the
>> number was poked to, hopefully if BBCBASIC supports
>> displaying hex numbers & can peek at the contents of memory,
>> then you'll be able to see if it's there or not. If 'hex$'
>> doesn't work use this 'print peek(addr)' & if peek doesn't
>> work, then I don't know what it's equivalent should be. You
>> did say it supports POKE, so PEEK should be there as well (in
>> theory).

> The Z88 BASIC doesn't support POKE or PEEK. (At least
> there's nothing about it in the manual.) I did try PEEKing
> the address where I had put the code, but it didn't work--
> just returned an error message. (No such variable, or
> something like that.)

Well I would have just thought that if the original BBCBASIC
had support for this, then it would have been for this machine,
but then they could have removed it in favor for the Inline
Assembly (it really does make a big difference).

Cheers,
CP/M User.

Terry Yager
February 10th, 2004, 10:22 AM
"Terry Yager" wrote:

> The processor in the Z88 is a straight-up
> cmos version of the Z80. AFAIK, it has
> no extra goodies included. But, it's still
> a very kewl computer. If you ever get a
> chance, grab one up. They're a lot more
> common on your side of the pond than
> they are here. (I see 'em on
> eBay.com.au all the time.)

Yeah, I just had a look at eBay, but could
only find one of these machines there.
The seller sounds like the nicest person in
the world, but it looks like they don't have
any Manuals for the machine (hence
saying it's just the machine). I've got 4
days to think about it though!

Cheers,
CP/M User.

I hope you do get one, I'm sure you'll like it. I used a Tandy 102 as my computer-of-choice for years and it was always my favorite. I think I like the Z88 even better. Some things to keep in mind if you're shopping for one:
How much memory? The base memory is only 32K, but may be expanded to as much as 3Mb of rom/ram. There is a special slot that will take either a ram cartridge or a rom, which is programable by the machine.
Extra software/firmware? A lot of programs were distributed for them on rom cartridges.
Cables? The only connection to the outside world is thru the serial port, and with a special cable may be connected to another computer for file transfer, etc. If it comes with a cable that you can use, it is obviously worth more.
I see them go on eBay.au and eBay.uk a lot, and they usually sell for around 40 UK pounds.
There is a company in UK that still supports them. They sell new and reconditioned units, as well as supporting software/peripherals.

http://www.rakewell.com/main/index.shtml

They should have a manual if you should need one. (You may not need one, the computer/software is very friendly, and on-line support is plentiful. The manual is not all that informative anyways--more like a quick-reference guide.)

--T

Terry Yager
February 10th, 2004, 11:00 AM
"Terry Yager" wrote:

>> Very friendly. When you say it assembles & executes the code
>> on-the-fly, you mean you enter the code & it runs it?

> Well, mebbe not quite on the fly, but close to it. You set a
> variable to point to the address of the ML, then invoke the
> assembler. After entering the code, you exit from the
> assembler (but not from BASIC), then you can just RUN
> the prog you have created, or execute the CALL to the
> address you used, depending how the program is written.
> I tried both ways and both seem to work.

> Quoted from the manual:

> BASIC Inline Assembler

> BBC BASIC on the Z88 comes with an inline assembler built in.

With this type of facility, you don't need POKE, PEEK or
DATA statements for that matter, as the assembly can
just be put into those statements. Does it have any
further detail about now to pass values between BASIC &
this Inline Assembly. If not, then I guess you could
try 'LD HL,(address)' & 'LD DE,(value)' & GOSUB where
you're line number starts or perhaps 'CALL code,adr,val'

In that case it would be as easy as you mentioned
earlier (without using the Index Registers).

This Inline Assembly would have to be a new feature on
this system (the original BBCBASIC wouldn't have had
this).

What it does, after you enter the code and escape out to BASIC, if you type RUN it assembles the code in memory at the address specified, returns a PRN-type listing of the file showing the addresses, etc. then waits for the next BASIC command. If you type CALL<address>, then it executes the ML routine

Actually, the manual doesn't even mention the in-line assembler, and barely touches on the CALL and USR commands. The information I quoted above was not from the manual (I just realized), but from another source I found on the web called The Z88 Book.


Around 1992/3 I used to see the Amstrad NC100 (I don't think
the NC200 came out to Australia) & even played with the Text
editor on one (on display). I thought the keyboard was great. I
was nearly going to get either that or an Atari Portfolio, but
got my folks got a Typewriter instead (I wasn't impressed!)-:

That must have been a real disapointment to you. Even a word processor would've been better than a typewriter.


The Amstrad NC100 is virtually identical to your Z88, well
perhaps the programs are different, but it came with BBCBASIC
as well. The Amstrad NC100 had no Disk Drive (unlike the NC200),
so it stored documents in Memory (or some RAM disk which had a
battery backup to keep the RAM Disk functioning - not a bad
idea!) :-)

Yeah, I don't understand why they didn't see fit to include backup batteries in the ram carts. for the Z88. As it is, the ram is volitile, so if you should remove it from the machine, you lose whatever is on it. (I wonder if this was a marketing strategy, to promote the (costlier) ROM carts, which are non-volitile?)


The Amstrad NC200 from what I've heard & seen is quite different
in looks (& as mentioned earlier has a Disk Drive 3.5DSDD" I
believe) & unlike the NC100 which is like the Z88 the screen folds
up (it's perhaps more like a Atari Portfolio - so it's a small
notebook.)
Yeah, I'd really like to have one of each...and an Atari Portfolio!


> The Z88 BASIC doesn't support POKE or PEEK.

Well I would have just thought that if the original BBCBASIC
had support for this, then it would have been for this machine,
but then they could have removed it in favor for the Inline
Assembly (it really does make a big difference).

Cheers,
CP/M User.

I really like that feature. I've never run across such a thing before. I do wish they would have included a debugger too, tho. (Mebbe they did, and it's as undocumented as the assembler, eh? Still hoping to find one...)

--T

CP/M User
February 11th, 2004, 12:13 AM
"Terry Yager" wrote:

> I hope you do get one, I'm sure you'll like it.
> I used a Tandy 102 as my computer-of-choice for
> years and it was always my favorite. I think I
> like the Z88 even better. Some things to keep
> in mind if you're shopping for one:
> How much memory? The base memory is only 32K,
> but may be expanded to as much as 3Mb of rom/ram.
> There is a special slot that will take either a
> ram cartridge or a rom, which is programable by
> the machine.

Yeah, I read that this on old-computers.com museum.

> Extra software/firmware? A lot of programs were
> distributed for them on rom cartridges.
> Cables? The only connection to the outside world
> is thru the serial port, and with a special cable
> may be connected to another computer for file
> transfer, etc. If it comes with a cable that you
> can use, it is obviously worth more.
> I see them go on eBay.au and eBay.uk a lot, and
> they usually sell for around 40 UK pounds.

Do you know how affordable this would be for those
add-ons?

Crikey 40 for the Z88 over in the UK?

The one sold here on eBay.au is only $20, but while
you only get the machine, I might be a bad money
for that (well unless someone has bidded pretty
high! :-)

> There is a company in UK that still supports them.
> They sell new and reconditioned units, as well as
> supporting software/peripherals.

> http://www.rakewell.com/main/index.shtml

Oh well, I guess I better check them out. Although
pound currency is quite a bit usually, against the
ol' Aussie Dollar! :-)

> They should have a manual if you should need one.
> (You may not need one, the computer/software is
> very friendly, and on-line support is plentiful.
> The manual is not all that informative anyways--more
> like a quick-reference guide.)

Well unless this machine has a self help guide built
in, the language would be harder to learn.


>> This Inline Assembly would have to be a new feature on
>> this system (the original BBCBASIC wouldn't have had
>> this).

> What it does, after you enter the code and escape out
> to BASIC, if you type RUN it assembles the code in
> memory at the address specified, returns a PRN-type
> listing of the file showing the addresses, etc.
> then waits for the next BASIC command. If you type
> CALL<address>, then it executes the ML routine

> Actually, the manual doesn't even mention the in-line
> assembler, and barely touches on the CALL and USR
> commands. The information I quoted above was not from
> the manual (I just realized), but from another source
> I found on the web called The Z88 Book.

Oh okay, I see. Not much of a manual then! :-)

>> Around 1992/3 I used to see the Amstrad NC100 (I don't think
>> the NC200 came out to Australia) & even played with the Text
>> editor on one (on display). I thought the keyboard was great. I
>> was nearly going to get either that or an Atari Portfolio, but
>> got my folks got a Typewriter instead (I wasn't impressed!)-:

> That must have been a real disapointment to you. Even a word
> processor would've been better than a typewriter.

Unfortunately, I can't remember how much the NC100 was (I though
it was around the $200 mark, but it might of been $400). This
typewriter was around $100 & being electronic you could imagine
some of the features (like correcting mistakes), but I would
have perfered a Notebook like the NC100 (just for school work). I
should have really brought it forespite.

>> The Amstrad NC100 is virtually identical to your Z88, well
>> perhaps the programs are different, but it came with BBCBASIC
>> as well. The Amstrad NC100 had no Disk Drive (unlike the NC200),
>> so it stored documents in Memory (or some RAM disk which had a
>> battery backup to keep the RAM Disk functioning - not a bad
>> idea!) :-)

> Yeah, I don't understand why they didn't see fit to include
> backup batteries in the ram carts. for the Z88. As it is,
> the ram is volitile, so if you should remove it from the
> machine, you lose whatever is on it. (I wonder if this was
> a marketing strategy, to promote the (costlier) ROM carts,
> which are non-volitile?)

I don't know if you could have removed the RAM from a NC100,
the battery backup I was thinking of was the sort which
works when the machine is turned off for transportation or
whatever.

Sorry, but could you tell me more about this RAM cartridges?

>> The Amstrad NC200 from what I've heard & seen is quite different
>> in looks (& as mentioned earlier has a Disk Drive 3.5DSDD" I
>> believe) & unlike the NC100 which is like the Z88 the screen folds
>> up (it's perhaps more like a Atari Portfolio - so it's a small
>> notebook.)

> Yeah, I'd really like to have one of each...and an Atari Portfolio!

Basically an Atari Portfolio I believe is a notepad of an IBM XT I
believe & can run M$-DOS & have something upto 640Kb (it was sold as
standard for about $300 & only had 128k). Cause they mightn't fetch
much now days.

>> The Z88 BASIC doesn't support POKE or PEEK.

>> Well I would have just thought that if the original BBCBASIC
>> had support for this, then it would have been for this machine,
>> but then they could have removed it in favor for the Inline
>> Assembly (it really does make a big difference).

> I really like that feature. I've never run across such a thing
> before. I do wish they would have included a debugger too, tho.
> (Mebbe they did, and it's as undocumented as the assembler, eh?
> Still hoping to find one...)

I just realised their the other night that 'DATA', 'READ variable'
are standard BASIC commands, if they aren't there, there's something
horribly wrong. Poke & Peek maybe there, but in some other form,
but I must admit that Peek & Poke are more for M/C handling. 'DATA'
& 'READ variable' for example are used for more than just Machine
Code, that are also used for reading & storing information into an
Array, there is another way you could do it, but 'DATA' & 'READ
variable' is the most common way! :-)

Cheers,
CP/M User.

Terry Yager
February 11th, 2004, 11:52 AM
"Terry Yager" wrote:

> Extra software/firmware?

Do you know how affordable this would be for those
add-ons?

Crikey 40 for the Z88 over in the UK?

The one sold here on eBay.au is only $20, but while
you only get the machine, I might be a bad money
for that (well unless someone has bidded pretty
high! :-)

I think the most interesting thing available are the new flash eprom carts. Rakewell sells them for 59 pounds for a 1Mb cart. These seem to offer the best of both worlds, non-volitile storage and the ability to read/write/erase/rename/etc. in the machine. The regular Eprom carts can only be written to (in slot 3). You cannot erase a file, or rename it or anything without erasing the whole eprom, a process which is done outside of the machine, with a regular (flourescent light) eprom eraser, which must be purchased separately (or home-built).
Most of the Z88s I have seen on eBay were expanded in some way. In fact, I don't remember ever seeing a bare unit, hence the higher prices. Twenty Aussie dollars for a unexpanded unit sounds like a good price to me. That comes to about 15 bucks in American. Besides, mebbe it does have some extra memory, just forgot to mention it. I don't believe anybody tried to seriously use these machines with just the base ram of 32K. (Although I did get by with "only" 32K in my Tandy 102 for years. Very rarely did I ever fill it up.)


> There is a company in UK that still supports them.
> They sell new and reconditioned units, as well as
> supporting software/peripherals.

> http://www.rakewell.com/main/index.shtml

Oh well, I guess I better check them out. Although
pound currency is quite a bit usually, against the
ol' Aussie Dollar! :-)

> They should have a manual if you should need one.
> (You may not need one, the computer/software is
> very friendly, and on-line support is plentiful.
> The manual is not all that informative anyways--more
> like a quick-reference guide.)

Well unless this machine has a self help guide built
in, the language would be harder to learn.

Actually, there is a key marked "Help", which brings up a help screen (if the programmer say fit to write one), that has info about the current application. Unfortunately, the BASIC does not have any Help attached.


>> This Inline Assembly would have to be a new feature on
>> this system (the original BBCBASIC wouldn't have had
>> this).

I downloaded the manual for BBCBASIC from the web, and it mentions the assembler. (Mebbe it's just in the Z80 version and not the original 6502 version.)


> Actually, the manual doesn't even mention the in-line
> assembler, and barely touches on the CALL and USR
> commands. The information I quoted above was not from
> the manual (I just realized), but from another source
> I found on the web called The Z88 Book.

Oh okay, I see. Not much of a manual then! :-)

Well, it's a pretty good tutorial on using Pipedream and the other included popdown programs, just not a very good BASIC manual--not much more than a list of all the keywords. I haven't run across a copy of the users guide on the web so far, but there is a very nice presentation of the Service Manual out in webland.


Sorry, but could you tell me more about this RAM cartridges?

The internal memory consists of 32K of RAM and 128K of ROM, which has a number of programs built-in. This internal memory can be expanded to 128K(easily, if you're handy with a soldering iron), or 512K (more difficult, requires a little bit of re-wiring). The ram is called "pseudo-static" ram, which is a type of (dynamic) ram that has it's own refresh circuitry built on-chip, so doesn't require external refresh. It can easily be replaced with a regular static ram, which is pin-for-pin compatible. (In fact, the static rams are recomended, as they are cheaper, more common, and use less power). The ram chip is a 28-pin dipp. but the mainboard is drilled and wired for a 32-pin package, which the 128K & 512K chips are. A 128K Static ram chip sells for less than ten buck$ over here, I'm sure they are pretty reasonable where you are. Anyways, that's the route I would recomend for you, if the machine you purchase doesn't come with any extra ram.
Externally, there are three expansion slots, numbered Bank1, Bank2, and Bank3, (Bank0 is the internal ram). You can use any slot for any size of ram or rom cart (read-only for the eprom, unless it's in slot 3, where the eprom burner lives). The carts come in a variety of sizes, from 32K all the way up to 1Mb. The best part is that the ram is available for use by your programs, not just as a ramdisk, like you might expect with a Z80. They get around the Z80's 64K memory limit by using a "page/offset" memory management scheme, where 2 bits are used to select a page, and 14 bits select the address within that page. The memory is divided up into 256 pages 0f 16K each, for a total addressable range of 4Mb.


I just realised their the other night that 'DATA', 'READ variable'
are standard BASIC commands, if they aren't there, there's something
horribly wrong. Poke & Peek maybe there, but in some other form,
but I must admit that Peek & Poke are more for M/C handling. 'DATA'
& 'READ variable' for example are used for more than just Machine
Code, that are also used for reading & storing information into an
Array, there is another way you could do it, but 'DATA' & 'READ
variable' is the most common way! :-)

Cheers,
CP/M User.

Ok, yeah...I just checked the manual again and there is Read/Data statements available. Musta missed it the first time I read the manual.

--T

Terry Yager
February 11th, 2004, 06:27 PM
They get around the Z80's 64K memory limit by using a "page/offset" memory management scheme, where 2 bits are used to select a page, and 14 bits select the address within that page.

This has been bugging me all afternoon, but I can't seem to find where I read it from. It just doesn't make any sense. Two bits can only select one out of four, not 256. It would require 8 bits to do that. I must have misunderstood something. Mebbe they use 2 bits to select one out of the four *banks*... (Anyways, I don't completely understand just how it works, but then, I still have a lot to learn).

--T

Terry Yager
February 11th, 2004, 06:39 PM
Oh well, I did find the thing that was confusing me. The following is quoted from something on the web called "The Z88 Developer's Notebook":


The logical address consists of a 14 bit offset
within a bank with the upper two bits defined by the memory mask.

So, I guess they do use two bits to select the bank, and some other means to select the segment. A bank contains (up to) 4 segments (pages).

--T

Terry Yager
February 11th, 2004, 07:52 PM
...and then I found this in another document somewhere else on the web.


The address space accessible by the Z80 in the Z88 is on the order of 4 MB.
This is accomplished by paging the memory in 16KB "chunks", with four such
chunks in play at any one time.

So apparently it allocates the full 4 pages (64K) at once when it selects the bank. Now I can sleep. G'nite, I'm off to bed. (And it's only midnite?)

--T

CP/M User
February 11th, 2004, 11:53 PM
"Terry Yager" wrote:

> This has been bugging me all afternoon, but I can't
> seem to find where I read it from. It just doesn't
> make any sense. Two bits can only select one out
> of four, not 256. It would require 8 bits to do that.
> I must have misunderstood something. Mebbe
> they use 2 bits to select one out of the four
> *banks*... (Anyways, I don't completely understand
> just how it works, but then, I still have a lot to learn).

My Amstrad uses 8bit numbers to represent bank
switching, however they are within a certain range
C4h->C7h which represents each 16k of the extra 64k
it can access. This number can also be higher, if there's
even more memory (e.g. If the Amstrad had 384k! :-)

Some of the other numbers can be used such as C1h,
but I don't quite understand them as well! :-(

I would have thought that a machine which can have
upto 3Mb with Bank Switching facilities, would need
as much as possible, but I don't quite know :-(

Cheers,
CP/M User.

detrokkid
February 13th, 2004, 06:07 PM
as a great man once said "a byte is more than a bit, but less than a word" and the great person that said that was the creator of the high tech red-neck thread on a bbs n e one care to guess who that was terry yager can't answer though..