Yet another pointless arguement?

[Terry Yager]

Re: 16bit numbers

Re: 16bit numbers

"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,(IX+00)
LD D,(IX+01)
LD L,(IX+02)
LD H,(IX+03)
LD (HL),E
INC HL
LD (HL),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]

Re: 16bit numbers

Re: 16bit numbers

"Terry Yager" wrote:

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

>> LD E,(IX+00)
>> LD D,(IX+01)
>> LD L,(IX+02)
>> LD H,(IX+03)
>> LD (HL),E
>> INC HL
>> LD (HL),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]

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]

> 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]

> 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]

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]

"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$(peek(addr))
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]

Cambridge Z88

Cambridge Z88

"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]

"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$(peek(addr))
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]

"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$(peek(addr))
>> 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]

Re: Cambridge Z88

Re: Cambridge Z88

"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]

"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]

"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]

"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]

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]

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]

...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]

"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]

byte length

byte length

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..