A NEW website for Turbo Pascal 3 code.

[CP/M User]

Yes, I've started building a Website (well it's actually a file directory),
full of samples of my Turbo Pascal code. I've done a few examples of
this using my Amstrad Emulator & have posted them there (for those
interrested).

I've just recently added another file to my website (other files have a
explaination of their function in the index.txt file):

* dechex.pas - a function which takes a decimal byte 0-255 &
converts it to Hexidecimal (0-FFh). A demonstration is included.

This is the direct link to it:
http://www.geocities.com/cpm22_user/programs/Amstrad_CPC/TurboPAS/

In case anyone is interested I've been thinking of adding comments to
my samples of code (like this), however if the demand for it is high, I'll
do this soon, rather than later.

Cheers,
CP/M User.

 

[CP/M User]

Re: A NEW website for Turbo Pascal 3 code.

"CP/M User" wrote:

> Yes, I've started building a Website (well it's actually a
> file directory), full of samples of my Turbo Pascal code.
> I've done a few examples of this using my Amstrad
> Emulator & have posted them there (for those interrested).

> I've just recently added another file to my website (other
> files have a explaination of their function in the index.txt file):

> * dechex.pas - a function which takes a decimal byte 0-255 &
> converts it to Hexidecimal (0-FFh). A demonstration is included.

> In case anyone is interested I've been thinking of adding
> comments to my samples of code (like this), however if the
> demand for it is high, I'll do this soon, rather than later.

In case anyone is interested, I've updated the dechex.pas file
due to some seriously bad programming issues. I've updated
this with an better array arrangement, so for those who were
lucky enough to get my old version, will have something to
brand against me! (I won't be bribed though! ;-)

For those who aren't sure (from the POLL count), rest assured,
there is generic code placed there (even some Z80 based Inline
M/C - which -should- work on other CP/M systems - it uses
commonly used Z80 instructions), this mean's that while the site
looks Amstrad CPC based, there's also Universal code. For
details, check the index.txt file (the generic code has been
approrately keyed - '*').

Cheers,
CP/M User.

 

[Terry Yager]

Could the testcpm2 program be made to work on other CP/M systems too? When I tried to run the DDT from my KayPro 10n on my PX-8, all it did was to return an error message that said it required CP/M 2.0 or more to run. So now I'm wondering what is the version number being reported by the PX-8? (I'm certain it's CP/M 2.2, but why the error?) When I run C. B. Falconer's DDTZ, it works just fine.

--T

 

[CP/M User]

"Terry Yager" wrote:

> Could the testcpm2 program be made to work on
> other CP/M systems too? When I tried to run the
> DDT from my KayPro 10n on my PX-8, all it did
> was to return an error message that said it
> required CP/M 2.0 or more to run. So now I'm
> wondering what is the version number being
> reported by the PX-8? (I'm certain it's CP/M 2.2,
> but why the error?) When I run C. B. Falconer's
> DDTZ, it works just fine.

Oh okay. I've got the required CP/M 2.0 or more to run
once before, but the situation was slightly different. I
was indeed using CP/M 2.2, but it was actually a fault
from the replacing of one DOS ROM with another. For
some reason, it didn't have the info it needed or
something & reported this error.

The testcpm2.pas program would have to be one of the
more Amstrad specifics, I wrote this in conjunction of
accessing the firmware in CP/M 2.2 & CP/M Plus on the
Amstrad. The problem was I wanted to make something
which worked in both OSes (on a CPC), because in
order to access the Firmware, an addresses were different
as shown here:

var  Address     : byte;
     CPM2        : integer absolute $BE9B;
     CPMPlus     : integer absolute $FC5A;

These were fixed addresses provided from both versions
of CP/M to access the Firmware on an Amstrad.

However, the code to detect which version of CP/M is
there, so I could change this & have a program which tells
you which version of CP/M is being used (if you like), that
would be generic code (in theory!

But just getting back to the Amstrad specifics of that
program, the name of it is a bit decieving, maybe I should
call it unifirm.pas or something, cause it works in both CP/M
environments for the CPC (unlike some of my other stuff!).

After it detects which version of CP/M is used, it uses the
relevant firmware code (an other Amstrad specific), which
simply waits for a single keypress.

Cheers,
CP/M User.

 

[Terry Yager]

I'm afraid that even if you could re-write it so as to be generic for CP/M, it still might not work on the PX-8 because it's a whole 'nother animal. CP/M on the Epson is in firmware too, so the version info would be in ROM too, like the Amstrad (which could account for the error message too, if DDT couldn't find the ver. # in the address it looked for it at, but then, why would DDTZ work ok?). Too bad Gary didn't include a "ReadVersionString" system call when he wrote CP/M, eh? Do you happen to know where the version string resides in a "normal" CP/M system?

--T

 

[CP/M User]

"Terry Yager" wrote:

> I'm afraid that even if you could re-write it so as to be
> generic for CP/M, it still might not work on the PX-8
> because it's a whole 'nother animal. CP/M on the Epson
> is in firmware too, so the version info would be in ROM
> too, like the Amstrad (which could account for the error
> message too, if DDT couldn't find the ver. # in the address
> it looked for it at, but then, why would DDTZ work ok?).
> Too bad Gary didn't include a "ReadVersionString" system
> call when he wrote CP/M, eh? Do you happen to know
> where the version string resides in a "normal" CP/M system?

I've uploaded a simple version check to my site now. I'd find it
very hard to see if the PX-8 rejected it, because it's using
CP/M's own BDOS functions, in this case function 12 which
returns a value of CP/M being used. Maybe if it's anything
different from V2.2 or Plus, the program may choke, but if that
PX-8 is using either one of those, then I can't see why it would
help.

I've renamed the testcpm2.pas file to unifirm.pas in order to
clear any further confusion, I'd suggest download/compiling the
testcpmv.pas file & see if it works, if either one of those CP/M's
are being used, I've removed all the firmware stuff specific to
it & have left a simple program which simply tells you which
version of CP/M is being used.

The version string resides at BDOS function 12 (which is what
testcpmv.pas is looking for). If your computer can't handle that,
then it sounds like it's in the minority of CP/M computers which
look to the BDOS.

Yeah, just a further note to check this link out:
http://www.seasip.demon.co.uk/Cpm/bdos.html#12

Unless you're using anything below v2.0, this BDOS function is
used for something else (Lift Head I believe), in v1.x of CP/M.

In v2.0 & later it returns a value which corresponds with the
version of CP/M being used, e.g. 20, 21, 22 & so on. CP/M
Plus returns 31 (hence v3.1).

Looking at Johns site, he hasn't specified any incompatabilities
with any CP/M machines relating to this function from what I've
noticed. You'll just need to compile the program in TP (I'm
assuming you do have it on your PX-8) & it should compile the
correct code (based on that machine).

All the Best,
CP/M User.

 

[Terry Yager]

Uh, yeah, tnx for that CP/M U, but I already figgered it out on my own. I looked it up and there is a system call, "Return Version Number", #12, like you said above. So with a little prog like:

0100 mvi c,0c
0101 call 5
0102 ret

The system returns the version # in the H reg, where it may be dumped to the screen using DDTZ's eXamine command. In my case, the # returned in H was 22, so the PX-8 is running v.2.2 like I thought. I'll have to figger out why the DR version of DDT doesn't like it. It is probably what you pointed out before, or mebbe just a simple glitch in transferring the program from the KayPro to the Epson. I'm going to try it again, with a fresh copy of DDT and see what happens.

--T

 

[CP/M User]

"Terry Yager" wrote:

> Uh, yeah, tnx for that CP/M U, but I already figgered it out
> on my own. I looked it up and there is a system call, "Return
> Version Number", #12, like you said above. So with a little
> prog like:

0100 mvi c,12
0101 call 5
0102 ret

> The system returns the version # in the H reg, where it may
> be dumped to the screen using DDTZ's eXamine command.
> In my case, the # returned in H was 22, so the PX-8 is running
> v.2.2 like I thought. I'll have to figger out why the DR version
> of DDT doesn't like it. It is probably what you pointed out
> before, or mebbe just a simple glitch in transferring the
> program from the KayPro to the Epson. I'm going to try it
> again, with a fresh copy of DDT and see what happens.

I'm sure I've got that program correct, but telling DDT to executes
it results in a crash. I'm not all that mad about, I'm telling DDT to do
a G100, which just crashes DDT. I'm not sure if the syntax of this
is correct, or if it's a fault of DDT. It's rather annoying.

You'll have to be careful typing 'mvi c,12' as that under DDT too,
because it interprets this as 12 Hexidecimal, not 12 decimal.

Cheers,
CP/M User.

 

[Terry Yager]

If you're using DDT, try changing the ret to a rst 7, that should work, I think. Oh yeah, DUH! Change the 12 to 0C also, (Ive corrected it above, tnx for pointing that out).
Actually, the solution to my question was even simpler than I thought. I fooled around with the machine enough to lock it up real good (HINT: Never fill your entire memory with zeros). Anyways, I had to do a hard reset to recover from that boo-boo (first time for everything). When I reset the machine, it displayed a startup banner with ver. 2.2 B. I guess I should have tried that sooner.

EDIT: I just tried it using rst 7 instead, and it works that way too (under DDTZ), with the added benefit of not having to use the "X" command to dump the reg's, it dumps them on it's own. I dunno why it crashes your Amstrad. Mebbe you could d/l a copy of DDTZ and see if it behaves the same way.

--T

 

[CP/M User]

"Terry Yager" wrote:

> If you're using DDT, try changing the ret to a rst 7, that
> should work, I think. Oh yeah, DUH! Change the 12 to
> 0C also, (Ive corrected it above, tnx for pointing that out).

> Actually, the solution to my question was even simpler
> than I thought. I fooled around with the machine enough
> to lock it up real good (HINT: Never fill your entire memory
> with zeros). Anyways, I had to do a hard reset to recover
> from that boo-boo (first time for everything). When I reset
> the machine, it displayed a startup banner with ver. 2.2 B.
> I guess I should have tried that sooner.

> EDIT: I just tried it using rst 7 instead, and it works that
> way too (under DDTZ), with the added benefit of not having
> to use the "X" command to dump the reg's, it dumps them
> on it's own. I dunno why it crashes your Amstrad. Mebbe
> you could d/l a copy of DDTZ and see if it behaves the same
> way.

So the problem maybe within the DDT program where instead
of CALLing a part of memory & RETurning at the issue of RET,
it's doing a unconditional JUMP ('JP'). I know those don't follow
RETurn statements. 'JP' IMO is the assembly equivalent of
BASICs GOTO & they you'd probably know how they react to
a RETURN in BASIC! (ERROR!). Maybe I should write this in my

memory: CALL 100
memory: RET

& get DDT to jump to that. Or perhaps not since RET after 'CALL
100' won't work. I don't like using those RSTs, I heard you have
to practice caution in using them!

Cheers,
CP/M User.

 

[CP/M User]

Here's some code I've just knocked up, this is the assembly version
which checks which version of CP/M is in use (either v2.2 or Plus).
Additional versions could easily be added with additional checking
'CP &2x or &3x' & 'JR Z, message for correct version'. This solved
the problem of using DDT & it doesn't crash!

	    ORG &100
        
	    LD C,&C
	    CALL 5
	    CP &22
       JR Z,CPM22
       CP &31
	    JR Z,CPM31
	    RET
CPM22: LD DE,MSG22
	    LD C,9
	    CALL 5
	    RET
CPM31: LD DE,MSG31
	    LD C,9
	    CALL 5
	    RET

MSG22:  DEFB"CP/M 2.2 is in use$"
MSG31:  DEFB"CP/M Plus is in use$"

Cheers,
CP/M User.

 

[Terry Yager]

So the problem maybe within the DDT program where instead
of CALLing a part of memory & RETurning at the issue of RET,
it's doing a unconditional JUMP ('JP'). I know those don't follow
RETurn statements. 'JP' IMO is the assembly equivalent of
BASICs GOTO & they you'd probably know how they react to
a RETURN in BASIC! (ERROR!). Maybe I should write this in my
Code:
memory: CALL 100
memory: RET

& get DDT to jump to that. Or perhaps not since RET after 'CALL
100' won't work. I don't like using those RSTs, I heard you have
to practice caution in using them!

Cheers,
CP/M User.

Yeah, I seem to remember something about DDT not liking ret statements. DDTZ seems to handle it just fine. It really is a good program, you should check it out if you're running CP/M on a Z80, for those times when & if you hafta use a assembly debugger.
RST's are not necessarily A Bad Thing, you just hafta be careful when you use them coz the wrong one in the wrong place or at the wrong time can trash (overwrite) your program. They work like CALL statements, each RST calling a different address in page zero, which hold the addresses of the various interupt-handling routines. After the interupt is servced, the RST command returns control back to the CALLing program, in this case, DDT. So we trick DDT into doing something we want by telling it that something we didn't want has happened, whereupon the interupt-handler loads, does nothing, then resets all the registers back to some default state (except for the PC & SP), and then RETurns control back to DDT. At least, I think that's how it works.

Here's some code I've just knocked up, this is the assembly version
which checks which version of CP/M is in use (either v2.2 or Plus).
Additional versions could easily be added with additional checking
'CP &2x or &3x' & 'JR Z, message for correct version'. This solved
the problem of using DDT & it doesn't crash!

	    ORG &100
        
	    LD C,&C
	    CALL 5
	    CP &22
       JR Z,CPM22
       CP &31
	    JR Z,CPM31
	    RET
CPM22: LD DE,MSG22
	    LD C,9
	    CALL 5
	    RET
CPM31: LD DE,MSG31
	    LD C,9
	    CALL 5
	    RET

MSG22:  DEFB"CP/M 2.2 is in use$"
MSG31:  DEFB"CP/M Plus is in use$"

Cheers,
CP/M User.

Looks good, but it's kinda pointless to run it on the Epson since they only used just the one version of CP/M (well, two different flavors of 2.2 ROM anyways, A or B). I wonder if I could mod your code enough to determine which ROM the PX-8 has installed. Nah, prob'ly not, since I don't know where the ROM version is stored.

--T

 

[CP/M User]

"Terry Yager" wrote:

>> So the problem maybe within the DDT program where instead
>> of CALLing a part of memory & RETurning at the issue of RET,
>> it's doing a unconditional JUMP ('JP'). I know those don't follow
>> RETurn statements. 'JP' IMO is the assembly equivalent of
>> BASICs GOTO & they you'd probably know how they react to
>> a RETURN in BASIC! (ERROR!). Maybe I should write this in my

memory: CALL 100 
memory: RET

>> & get DDT to jump to that. Or perhaps not since RET after 'CALL
>> 100' won't work. I don't like using those RSTs, I heard you have
>> to practice caution in using them!

> Yeah, I seem to remember something about DDT not liking
> ret statements. DDTZ seems to handle it just fine. It really
> is a good program, you should check it out if you're running
> CP/M on a Z80, for those times when & if you hafta use a
> assembly debugger.
> RST's are not necessarily A Bad Thing, you just hafta be
> careful when you use them coz the wrong one in the wrong
> place or at the wrong time can trash (overwrite) your
> program. They work like CALL statements, each RST calling
> a different address in page zero, which hold the addresses of
> the various interupt-handling routines. After the interupt is
> servced, the RST command returns control back to the
> CALLing program, in this case, DDT. So we trick DDT into
> doing something we want by telling it that something we didn't
> want has happened, whereupon the interupt-handler loads,
> does nothing, then resets all the registers back to some default
> state (except for the PC & SP), and then RETurns control back
> to DDT. At least, I "think" that's how it works.

Do you know where I can download DDTZ? I've been using Lara
on my Amstrad, which is very good (it can load COM files & view
them), but it doesn't run in CP/M (which is about the only problem
it's got!).

>> Here's some code I've just knocked up, this is the assembly version
>> which checks which version of CP/M is in use (either v2.2 or Plus).
>> Additional versions could easily be added with additional checking
>> 'CP &2x or &3x' & 'JR Z, message for correct version'. This solved
>> the problem of using DDT & it doesn't crash!

	    ORG &100
        
	    LD C,&C
	    CALL 5
	    CP &22
       JR Z,CPM22
       CP &31
	    JR Z,CPM31
	    RET
CPM22: LD DE,MSG22
	    LD C,9
	    CALL 5
	    RET
CPM31: LD DE,MSG31
	    LD C,9
	    CALL 5
	    RET

MSG22:  DEFB"CP/M 2.2 is in use$"
MSG31:  DEFB"CP/M Plus is in use$"

> Looks good, but it's kinda pointless to run it on the Epson
> since they only used just the one version of CP/M (well, two
> different flavors of 2.2 ROM anyways, A or B). I wonder if I
> could mod your code enough to determine which ROM the
> PX-8 has installed. Nah, prob'ly not, since I don't know
> where the ROM version is stored.

Oh okay, I thought you have multiple versions of CP/M on your
PX-8. How does the ROM setup work & what's the difference
between them?

Cheers,
CP/M User.

 

[Terry Yager]

You can d/l DDTZ from C.B. Falconer's webpage (go into comp.os.cpm and find one of his posts, there should be a link therein). I lifted my copy from the Walnut Creek CDROM, but I'm not sure if it's the latest version (v. 2.8). The CD is on-line at retroarchive:

http://www.retroarchive.org/cpm/

in the directory \ZSYS\ZNODE-12\A under the filename DDTZ28.com.

I'm not real clear on exectly how the ROM-based CP/M works, whether it's a bank-switching scheme or what. It could be that the CP/M is copied from ROM into RAM & then executed from there. I think that's how it works becausr examining the high memory where CP/M usually resides reveals that that area of RAM is occupied by something. I haven't tried booting it from a floppy (image), so I don't know if it can be done or not. Gonna hafta try it tho...

--T

 

[CP/M User]

"Terry Yager" wrote:

> You can d/l DDTZ from C.B. Falconer's webpage (go into
> comp.os.cpm and find one of his posts, there should be
> a link therein). I lifted my copy from the Walnut Creek
> CDROM, but I'm not sure if it's the latest version (v. 2.8).
> The CD is on-line at retroarchive:

> http://www.retroarchive.org/cpm/

> in the directory \ZSYS\ZNODE-12\A under the filename
> DDTZ28.com.

Thanks.

> I'm not real clear on exectly how the ROM-based CP/M
> works, whether it's a bank-switching scheme or what.
> It could be that the CP/M is copied from ROM into RAM
> & then executed from there. I think that's how it works
> becausr examining the high memory where CP/M usually
> resides reveals that that area of RAM is occupied by
> something. I haven't tried booting it from a floppy
> (image), so I don't know if it can be done or not. Gonna
> hafta try it tho...

Bit of a mystery then.

Good Luck,
CP/M User.

 

[Terry Yager]

> I'm not real clear on exectly how the ROM-based CP/M
> works, whether it's a bank-switching scheme or what.
> It could be that the CP/M is copied from ROM into RAM
> & then executed from there. I think that's how it works
> becausr examining the high memory where CP/M usually
> resides reveals that that area of RAM is occupied by
> something. I haven't tried booting it from a floppy
> (image), so I don't know if it can be done or not. Gonna
> hafta try it tho...

Bit of a mystery then.

Good Luck,
CP/M User.

I dunno if it's all that mysterious. The PX-8 has a couple of extra ROM sockets for additional software, and the system addresses them as if they were disk drives, B: & C:. If you burn your own ROMs for them, it requires some special handling. They must be burned as disk-images, not just normal program ROMs. I'm pretty sure that the boot-ROM is the same way, the CP/M is just read into memory off from it as it would be from a normal bootdisk. Sort of a virtual boot sector, I guess. Is that pretty much the way the Amstrad works too?

--T

 

[CP/M User]

"Terry Yager" wrote:

> I dunno if it's all that mysterious. The PX-8 has a couple of extra ROM
> sockets for additional software, and the system addresses them as if
> they were disk drives, B: & C:. If you burn your own ROMs for them, it
> requires some special handling. They must be burned as disk-images,
> not just normal program ROMs. I'm pretty sure that the boot-ROM is
> the same way, the CP/M is just read into memory off from it as it would
> be from a normal bootdisk. Sort of a virtual boot sector, I guess. Is
> that pretty much the way the Amstrad works too?

Sorry, I've just discovered this responce! :-(

I'm a little baffled with this technique with the ROMs, I'm guessing your saying that anything can be put onto these ROM sockets & that they can be accessed imediately. The CPC had provisions for ROM software & CP/M was actually transfered onto ROM. The principals of ROMs on the CPC was to actually have something which could be used at the press of a command stroke (usually done in BASIC). Not sure if these programs were moved into RAM instantally (don't think they were), but they did use some memory in order to activate on command.

I think CP/M on ROM was different in that it was all there to be used from the ROM, on disc though both versions (CP/M v2.2 & CP/M Plus) on bootable disc had some space allocated to them. They essentually belong System disks which used 9k - used for the bootup of these OSes. A regular Data disc had 178k, but on System you got 169k - for extra programs & files.

The ROM idea sounds like an interesting one on the Epson & it sounds like it's some kind of Memory Disk - which takes the program from these ROMs & puts it into memory. A good way I guess to tell this would be to see what happens if you run a program on this disk, if it would take some time to load. On an Amstrad they seem to work more like a Cartridge, where the program is onscreen very quickly (as if it's already in memory).

CP/M User.