[M100] VirtualT mainline source code

[B 9]

Is Virtual T no longer being released by the original developers? (Ken
Petit? Stephen Hurd?)

I was thinking about reporting some bugs and want it to go to whatever is
the mainline these days. I've been noticing some strange artifacts in the
way that NEC PC8201a binary files are saved to disk and I think it might be
a problem with the tokenizer. Also, the file loading routines are overly
strict and do not accept .BA files that run fine on real hardware.

--b9

P.S. If anyone knows anything about the N82 BASIC token format, I would
love to hear from you. I rewrote my optimizing tokenizer for the M100
 family (converts .DO files to .BA on
a host computer before downloading) and was able to figure out the file
format
 by
using my Tandy 200 and Virtual T. But when I tried to reverse engineer and
document the N82 BASIC file format using just Virtual T, I got weird,
inconsistent results. (.BA files saved from Virtual T to the host computer
and then read back in would be different. But maybe that's to be expected
with the illegal token sequences I'm throwing at it?)

Re: [M100] Got RexCPM working and CP/M, too, now what?

[Will Senn]

This sounds important. So far as I know, mine's original equipment. Do I 
need to be worried?


Will

On 3/16/24 8:21 PM, Doug Jackson wrote:
Every time I see one of those evil NiCad batteries, I replace it with 
a 0.5F supercap.


I have never had an issue with my M100, or with the Olivetti 
equivalent (number escapes me at the moment)


Having said that, the oldest would have been 8 years ago, so I don't 
have the same 30years of experience regarding leaking characters.


Doug

On Sun, 17 Mar 2024, 11:44 am Brian K. White,  
wrote:


You can run plugged in to the wall for all normal random on/off
operating times without worrying about it too much, IE, all day
long for
8 to 12 hours or whatever, and for multiple days in a row, if
unplugged
when turned off.

And you can leave it plugged in turned on or off overnight for one
night
to a few days.

And you can even get away with exceeding those pretty badly once
in a while.

What you want to avoid is plugging it in and leaving it plugged in
24/7
for weeks or months or years, whether it's on or off.

The harm is the charging circuit that charges the internal nicd
battery
soldered on the motherboard. The battery is not a lead/acid or gel
cell
that has a float value where it can just stay floating at a certain
value forever, and the charging circuit is not a smart modern battery
manager that knows how to stop charging when the battery is full, it
just keeps on supplying a bit higher voltage than the the cells own
voltage, and current just keeps on flowing backwards through the
cell,
and sooner or later this kills the battery by a couple different
possible mechanisms from plain heat & pressure making it leak and
cook
off all the electrolyte, to things like the electrolysis process like
electroplating, eating away all of one plate and building gunk up
on the
other.

It's pretty forgiving so you don't have to be super careful. You can
*mostly* never even think about it, and a normal random usage pattern
will just naturally be fine. Just don't plug it in and forget
about it
for a year.

It doesn't touch the AA's and it doesn't matter if the machine is
turned
on or turned off.

Now that you make me run through it all like that, I realise this
might
finally be be an actual valid useful reason to install a supercap
instead of a new nimh cell.

Mostly there is no point, because both a cap and a battery will only
last about the same number of years, and both will start to leak
corrosive juice after about the same number of years. A cap is not
harmed by being allowed to go all the way dead (which a battery
is), nor
by being allowed to stay dead for a long time (extra especially
bad for
a battery), but even a battery that has been so badly treated still
supplies more standby time than a brand new perfect cap. All in
all, no
point.

But one difference that matters, a cap should not be harmed by the
crudeness of the charging circuit. A cap will just charge up and stop
conducting and won't care about the charging supply at all. No
current
will keep flowing through the cap, no cooking or electrolysis etc.

I have always been very much not in the supercap camp, but this is
one
real thing.

-- 
bkw


On 3/16/24 16:33, Will Senn wrote:
> Wow, Brian! Super clear. Now, I want a REX# :).
>
> When you say that leaving it plugged in will kill the battery,
do you
> mean that I should run it off AA batteries most of the time and
not my
> 6v 200ma adapter? And the battery you're talking about killing
is the
> nicad on the board, right?
>
>   Thanks,
>
> Will
>
>
> On 3/16/24 3:21 PM, Brian K. White wrote:
>> I summarize REX as: "An on-board software-controlled option rom
>> library and ram image library."
>>
>> That's the shortest way I've found to say what it does, but
that's not
>> the same as saying what it's good for or why you want one.
>>
>> Because of the particular features and limitations of a M100,
probably
>> the single most life-improving thing you can do to one is to have
>> TS-DOS in ROM.
>>
>> That one thing addresses a few different pain points.
>>
>> The biggest pain points of a M100 are:
>>
>> - Battery-backed ram only storage. Very little storage, and easily
>> erased or corrupted, either by dead batteries or a software crash.
>>
>> - The way in manages machine-language software. How they all
want to
>> run in the same place in ram, yet the OS does not provide very
much in
>> the way of automatically moving programs into and out of that
spot, so
>> software is always clobbering other software, or you limit
yourself to
>> just having a 

Re: [M100] Got RexCPM working and CP/M, too, now what?

[Gregory McGill]

Is the same behavior with nimh as with NiCAD?

On Sat, Mar 16, 2024, 6:46 PM Brian K. White  wrote:

> One problem with batteries for sure is you can't tell a junk future
> leaker by just looking at it. Even if the actual cells are stamped with
> a quality manufacturer name, they could be fake or they could be real
> but rejects, or they could be illegitimate extra production "after hours
> runs" from the same plant in china or wherever that makes the real ones,
> or real but aged-out old stock repackaged and sold as new etc.
>
> And there is essentially no way to detect or prove any of that by
> examining the battery in your hand. If it's visibly corroded or doesn't
> take a charge or something, you can tell that obviously, but if it
> visually looks perfect, and functions within spec, that doesn't prove
> anything except that it looks good and works today. It could be utter
> garbage that dies and leaks in 1 year or 5 years.
>
> The only hope that it will actually last the promised number of years
> before starting to leak, is to buy it from a source that you can trust
> to be very careful with their own sources. No ebay, no amazon, certainly
> no aliexpress, it must be someone who will actually care if any
> customers ever start giving them a bad reputation.
>
> I guess all that is true for caps too really, so maybe no difference on
> that front.
>
> --
> bkw
>
> On 3/16/24 21:21, Doug Jackson wrote:
> > Every time I see one of those evil NiCad batteries, I replace it with a
> > 0.5F supercap.
> >
> > I have never had an issue with my M100, or with the Olivetti equivalent
> > (number escapes me at the moment)
> >
> > Having said that, the oldest would have been 8 years ago, so I don't
> > have the same 30years of experience regarding leaking characters.
> >
> > Doug
> >
> > On Sun, 17 Mar 2024, 11:44 am Brian K. White,  > > wrote:
> >
> > You can run plugged in to the wall for all normal random on/off
> > operating times without worrying about it too much, IE, all day long
> > for
> > 8 to 12 hours or whatever, and for multiple days in a row, if
> unplugged
> > when turned off.
> >
> > And you can leave it plugged in turned on or off overnight for one
> > night
> > to a few days.
> >
> > And you can even get away with exceeding those pretty badly once in
> > a while.
> >
> > What you want to avoid is plugging it in and leaving it plugged in
> 24/7
> > for weeks or months or years, whether it's on or off.
> >
> > The harm is the charging circuit that charges the internal nicd
> battery
> > soldered on the motherboard. The battery is not a lead/acid or gel
> cell
> > that has a float value where it can just stay floating at a certain
> > value forever, and the charging circuit is not a smart modern battery
> > manager that knows how to stop charging when the battery is full, it
> > just keeps on supplying a bit higher voltage than the the cells own
> > voltage, and current just keeps on flowing backwards through the
> cell,
> > and sooner or later this kills the battery by a couple different
> > possible mechanisms from plain heat & pressure making it leak and
> cook
> > off all the electrolyte, to things like the electrolysis process like
> > electroplating, eating away all of one plate and building gunk up on
> > the
> > other.
> >
> > It's pretty forgiving so you don't have to be super careful. You can
> > *mostly* never even think about it, and a normal random usage pattern
> > will just naturally be fine. Just don't plug it in and forget about
> it
> > for a year.
> >
> > It doesn't touch the AA's and it doesn't matter if the machine is
> > turned
> > on or turned off.
> >
> > Now that you make me run through it all like that, I realise this
> might
> > finally be be an actual valid useful reason to install a supercap
> > instead of a new nimh cell.
> >
> > Mostly there is no point, because both a cap and a battery will only
> > last about the same number of years, and both will start to leak
> > corrosive juice after about the same number of years. A cap is not
> > harmed by being allowed to go all the way dead (which a battery is),
> > nor
> > by being allowed to stay dead for a long time (extra especially bad
> for
> > a battery), but even a battery that has been so badly treated still
> > supplies more standby time than a brand new perfect cap. All in all,
> no
> > point.
> >
> > But one difference that matters, a cap should not be harmed by the
> > crudeness of the charging circuit. A cap will just charge up and stop
> > conducting and won't care about the charging supply at all. No
> current
> > will keep flowing through the cap, no cooking or electrolysis etc.
> >
> > I have always been very much not in the supercap camp, but this is
> one
> > real thing.
> >
> > 

Re: [M100] next project!

[B 9]

On Fri, Mar 1, 2024 at 6:45 PM Stephen Adolph  wrote:

> I have so many Model T around here-- too many!  One of the reasons is for
> testing, but another reason is because I have different computers for
> different use cases.
> For example, I have an M100 set up for CP/M using an NSC800 CPU using
> REXCPM, and of course I have a normal M100 with 80C85 CPU again with REXCPM.
> So, I've decided my next widget is going to be a dual CPU card for M100,
> so I can have Z80-based CP/M and normal M100 in the same box!
>

A noble goal and worthwhile project and, somehow, I think that when this
project is complete you will have *n*+1 Model T's.  :-D

--b9

Re: [M100] Got RexCPM working and CP/M, too, now what?

[Brian K. White]

One problem with batteries for sure is you can't tell a junk future 
leaker by just looking at it. Even if the actual cells are stamped with 
a quality manufacturer name, they could be fake or they could be real 
but rejects, or they could be illegitimate extra production "after hours 
runs" from the same plant in china or wherever that makes the real ones, 
or real but aged-out old stock repackaged and sold as new etc.


And there is essentially no way to detect or prove any of that by 
examining the battery in your hand. If it's visibly corroded or doesn't 
take a charge or something, you can tell that obviously, but if it 
visually looks perfect, and functions within spec, that doesn't prove 
anything except that it looks good and works today. It could be utter 
garbage that dies and leaks in 1 year or 5 years.


The only hope that it will actually last the promised number of years 
before starting to leak, is to buy it from a source that you can trust 
to be very careful with their own sources. No ebay, no amazon, certainly 
no aliexpress, it must be someone who will actually care if any 
customers ever start giving them a bad reputation.


I guess all that is true for caps too really, so maybe no difference on 
that front.


--
bkw

On 3/16/24 21:21, Doug Jackson wrote:
Every time I see one of those evil NiCad batteries, I replace it with a 
0.5F supercap.


I have never had an issue with my M100, or with the Olivetti equivalent 
(number escapes me at the moment)


Having said that, the oldest would have been 8 years ago, so I don't 
have the same 30years of experience regarding leaking characters.


Doug

On Sun, 17 Mar 2024, 11:44 am Brian K. White, > wrote:


You can run plugged in to the wall for all normal random on/off
operating times without worrying about it too much, IE, all day long
for
8 to 12 hours or whatever, and for multiple days in a row, if unplugged
when turned off.

And you can leave it plugged in turned on or off overnight for one
night
to a few days.

And you can even get away with exceeding those pretty badly once in
a while.

What you want to avoid is plugging it in and leaving it plugged in 24/7
for weeks or months or years, whether it's on or off.

The harm is the charging circuit that charges the internal nicd battery
soldered on the motherboard. The battery is not a lead/acid or gel cell
that has a float value where it can just stay floating at a certain
value forever, and the charging circuit is not a smart modern battery
manager that knows how to stop charging when the battery is full, it
just keeps on supplying a bit higher voltage than the the cells own
voltage, and current just keeps on flowing backwards through the cell,
and sooner or later this kills the battery by a couple different
possible mechanisms from plain heat & pressure making it leak and cook
off all the electrolyte, to things like the electrolysis process like
electroplating, eating away all of one plate and building gunk up on
the
other.

It's pretty forgiving so you don't have to be super careful. You can
*mostly* never even think about it, and a normal random usage pattern
will just naturally be fine. Just don't plug it in and forget about it
for a year.

It doesn't touch the AA's and it doesn't matter if the machine is
turned
on or turned off.

Now that you make me run through it all like that, I realise this might
finally be be an actual valid useful reason to install a supercap
instead of a new nimh cell.

Mostly there is no point, because both a cap and a battery will only
last about the same number of years, and both will start to leak
corrosive juice after about the same number of years. A cap is not
harmed by being allowed to go all the way dead (which a battery is),
nor
by being allowed to stay dead for a long time (extra especially bad for
a battery), but even a battery that has been so badly treated still
supplies more standby time than a brand new perfect cap. All in all, no
point.

But one difference that matters, a cap should not be harmed by the
crudeness of the charging circuit. A cap will just charge up and stop
conducting and won't care about the charging supply at all. No current
will keep flowing through the cap, no cooking or electrolysis etc.

I have always been very much not in the supercap camp, but this is one
real thing.

-- 
bkw


On 3/16/24 16:33, Will Senn wrote:
 > Wow, Brian! Super clear. Now, I want a REX# :).
 >
 > When you say that leaving it plugged in will kill the battery, do
you
 > mean that I should run it off AA batteries most of the time and
not my
 > 6v 200ma adapter? And the battery you're talking about killing is
the
 > nicad on the board, right?
 >
 >   Thanks,
 >
 > Will

Re: [M100] Using CP/M for assembly work

[Brian K. White]

On 3/16/24 21:05, Kenneth Pettit wrote:



On 3/16/24 5:46 PM, Brian K. White wrote:


Thanks, and don't worry about it. It is simple enough for me to just 
hook up a 100 and save a file, and then I'll know everything.




"Everything"!  Wow, that's an impressive M100 you've got there!  ;-)



It does frequently do things that I don't understand, just like every 
genius I ever met.


--
bkw

Re: [M100] Got RexCPM working and CP/M, too, now what?

[Doug Jackson]

Every time I see one of those evil NiCad batteries, I replace it with a
0.5F supercap.

I have never had an issue with my M100, or with the Olivetti equivalent
(number escapes me at the moment)

Having said that, the oldest would have been 8 years ago, so I don't have
the same 30years of experience regarding leaking characters.

Doug

On Sun, 17 Mar 2024, 11:44 am Brian K. White,  wrote:

> You can run plugged in to the wall for all normal random on/off
> operating times without worrying about it too much, IE, all day long for
> 8 to 12 hours or whatever, and for multiple days in a row, if unplugged
> when turned off.
>
> And you can leave it plugged in turned on or off overnight for one night
> to a few days.
>
> And you can even get away with exceeding those pretty badly once in a
> while.
>
> What you want to avoid is plugging it in and leaving it plugged in 24/7
> for weeks or months or years, whether it's on or off.
>
> The harm is the charging circuit that charges the internal nicd battery
> soldered on the motherboard. The battery is not a lead/acid or gel cell
> that has a float value where it can just stay floating at a certain
> value forever, and the charging circuit is not a smart modern battery
> manager that knows how to stop charging when the battery is full, it
> just keeps on supplying a bit higher voltage than the the cells own
> voltage, and current just keeps on flowing backwards through the cell,
> and sooner or later this kills the battery by a couple different
> possible mechanisms from plain heat & pressure making it leak and cook
> off all the electrolyte, to things like the electrolysis process like
> electroplating, eating away all of one plate and building gunk up on the
> other.
>
> It's pretty forgiving so you don't have to be super careful. You can
> *mostly* never even think about it, and a normal random usage pattern
> will just naturally be fine. Just don't plug it in and forget about it
> for a year.
>
> It doesn't touch the AA's and it doesn't matter if the machine is turned
> on or turned off.
>
> Now that you make me run through it all like that, I realise this might
> finally be be an actual valid useful reason to install a supercap
> instead of a new nimh cell.
>
> Mostly there is no point, because both a cap and a battery will only
> last about the same number of years, and both will start to leak
> corrosive juice after about the same number of years. A cap is not
> harmed by being allowed to go all the way dead (which a battery is), nor
> by being allowed to stay dead for a long time (extra especially bad for
> a battery), but even a battery that has been so badly treated still
> supplies more standby time than a brand new perfect cap. All in all, no
> point.
>
> But one difference that matters, a cap should not be harmed by the
> crudeness of the charging circuit. A cap will just charge up and stop
> conducting and won't care about the charging supply at all. No current
> will keep flowing through the cap, no cooking or electrolysis etc.
>
> I have always been very much not in the supercap camp, but this is one
> real thing.
>
> --
> bkw
>
> On 3/16/24 16:33, Will Senn wrote:
> > Wow, Brian! Super clear. Now, I want a REX# :).
> >
> > When you say that leaving it plugged in will kill the battery, do you
> > mean that I should run it off AA batteries most of the time and not my
> > 6v 200ma adapter? And the battery you're talking about killing is the
> > nicad on the board, right?
> >
> >   Thanks,
> >
> > Will
> >
> >
> > On 3/16/24 3:21 PM, Brian K. White wrote:
> >> I summarize REX as: "An on-board software-controlled option rom
> >> library and ram image library."
> >>
> >> That's the shortest way I've found to say what it does, but that's not
> >> the same as saying what it's good for or why you want one.
> >>
> >> Because of the particular features and limitations of a M100, probably
> >> the single most life-improving thing you can do to one is to have
> >> TS-DOS in ROM.
> >>
> >> That one thing addresses a few different pain points.
> >>
> >> The biggest pain points of a M100 are:
> >>
> >> - Battery-backed ram only storage. Very little storage, and easily
> >> erased or corrupted, either by dead batteries or a software crash.
> >>
> >> - The way in manages machine-language software. How they all want to
> >> run in the same place in ram, yet the OS does not provide very much in
> >> the way of automatically moving programs into and out of that spot, so
> >> software is always clobbering other software, or you limit yourself to
> >> just having a single machine language app installed, or you have to
> >> figure out the arcane way to hack the binaries to relocate them to run
> >> at different addresses side by side, or you have to keep double copies
> >> of binaries so that the running copy can get clobbered and later
> >> replaced from the ram file copy...
> >>
> >> - The main rom provides no binary file transfer other than the
> >> cassette. And no 

Re: [M100] Using CP/M for assembly work

[Kenneth Pettit]

On 3/16/24 5:46 PM, Brian K. White wrote:


Thanks, and don't worry about it. It is simple enough for me to just 
hook up a 100 and save a file, and then I'll know everything.




"Everything"!  Wow, that's an impressive M100 you've got there!  ;-)

Re: [M100] Using CP/M for assembly work

[Brian K. White]

On 3/16/24 20:37, Stephen Adolph wrote:
Not a rexcpm function.  It is handled by import and export written by 
Philip.


I can say that I believe import and export use tpdd routines that mirror 
the rex routines and are based on Code built by Wilson van alst.


I'd have to do some work to understand how the name is structured.  I 
think it is fixed length.


Thanks, and don't worry about it. It is simple enough for me to just 
hook up a 100 and save a file, and then I'll know everything.


--
bkw

Re: [M100] Got RexCPM working and CP/M, too, now what?

[Brian K. White]

You can run plugged in to the wall for all normal random on/off 
operating times without worrying about it too much, IE, all day long for 
8 to 12 hours or whatever, and for multiple days in a row, if unplugged 
when turned off.


And you can leave it plugged in turned on or off overnight for one night 
to a few days.


And you can even get away with exceeding those pretty badly once in a while.

What you want to avoid is plugging it in and leaving it plugged in 24/7 
for weeks or months or years, whether it's on or off.


The harm is the charging circuit that charges the internal nicd battery 
soldered on the motherboard. The battery is not a lead/acid or gel cell 
that has a float value where it can just stay floating at a certain 
value forever, and the charging circuit is not a smart modern battery 
manager that knows how to stop charging when the battery is full, it 
just keeps on supplying a bit higher voltage than the the cells own 
voltage, and current just keeps on flowing backwards through the cell, 
and sooner or later this kills the battery by a couple different 
possible mechanisms from plain heat & pressure making it leak and cook 
off all the electrolyte, to things like the electrolysis process like 
electroplating, eating away all of one plate and building gunk up on the 
other.


It's pretty forgiving so you don't have to be super careful. You can 
*mostly* never even think about it, and a normal random usage pattern 
will just naturally be fine. Just don't plug it in and forget about it 
for a year.


It doesn't touch the AA's and it doesn't matter if the machine is turned 
on or turned off.


Now that you make me run through it all like that, I realise this might 
finally be be an actual valid useful reason to install a supercap 
instead of a new nimh cell.


Mostly there is no point, because both a cap and a battery will only 
last about the same number of years, and both will start to leak 
corrosive juice after about the same number of years. A cap is not 
harmed by being allowed to go all the way dead (which a battery is), nor 
by being allowed to stay dead for a long time (extra especially bad for 
a battery), but even a battery that has been so badly treated still 
supplies more standby time than a brand new perfect cap. All in all, no 
point.


But one difference that matters, a cap should not be harmed by the 
crudeness of the charging circuit. A cap will just charge up and stop 
conducting and won't care about the charging supply at all. No current 
will keep flowing through the cap, no cooking or electrolysis etc.


I have always been very much not in the supercap camp, but this is one 
real thing.


--
bkw

On 3/16/24 16:33, Will Senn wrote:

Wow, Brian! Super clear. Now, I want a REX# :).

When you say that leaving it plugged in will kill the battery, do you 
mean that I should run it off AA batteries most of the time and not my 
6v 200ma adapter? And the battery you're talking about killing is the 
nicad on the board, right?


  Thanks,

Will


On 3/16/24 3:21 PM, Brian K. White wrote:
I summarize REX as: "An on-board software-controlled option rom 
library and ram image library."


That's the shortest way I've found to say what it does, but that's not 
the same as saying what it's good for or why you want one.


Because of the particular features and limitations of a M100, probably 
the single most life-improving thing you can do to one is to have 
TS-DOS in ROM.


That one thing addresses a few different pain points.

The biggest pain points of a M100 are:

- Battery-backed ram only storage. Very little storage, and easily 
erased or corrupted, either by dead batteries or a software crash.


- The way in manages machine-language software. How they all want to 
run in the same place in ram, yet the OS does not provide very much in 
the way of automatically moving programs into and out of that spot, so 
software is always clobbering other software, or you limit yourself to 
just having a single machine language app installed, or you have to 
figure out the arcane way to hack the binaries to relocate them to run 
at different addresses side by side, or you have to keep double copies 
of binaries so that the running copy can get clobbered and later 
replaced from the ram file copy...


- The main rom provides no binary file transfer other than the 
cassette. And no *convenient* file transfer even for text.


These things combine to make life kind of difficult. For instance you 
want some better file transfer app, but since you have no binary file 
transfer to begin with getting the file transfer app itself installed 
is a pain. Then once it's installed, it consumes precious ram, and is 
easily broken because of the way machine language apps are are run, 
and the simplest way to address that is to have a 2nd physical copy in 
ram, which uses up yet more of that precious 32k. etc.


Having any tpdd client at all installed in any form makes transferring 
files a breeze, 

Re: [M100] Using CP/M for assembly work

[Stephen Adolph]

Not a rexcpm function.  It is handled by import and export written by
Philip.

I can say that I believe import and export use tpdd routines that mirror
the rex routines and are based on Code built by Wilson van alst.

I'd have to do some work to understand how the name is structured.  I think
it is fixed length.

Steve



On Saturday, March 16, 2024, Brian K. White  wrote:

> On 3/16/24 13:48, Stephen Adolph wrote:
>
>> regarding file transfer, use
>> IMPORT
>> or
>> EXPORT
>> in CP/M.  Included in package.
>> These programs access a "TPDD".  Filenames are 8.3 format,
>>
>> cheers
>> Steve
>>
>
> What is the ATTR byte? Presumably F ?
>
> And is that fixed-length space-filled like what Floppy or WP-2 do or not?
> "a___.txt" or "a.txt___"?
>
> And do you know if what REXCPM does matches what other CP/M systems that
> use a TPDD do?
>
> I think there is something that can use a tpdd from a NEC PC-8401 and
> PC-8500 but I never used it yet and don't know what it exactly writes to
> the drive, or expects to find on a drive.
>
> I have a REXCPM and both a 8401 and 8500 so I can test and answer all
> those myself some time. I'm not asking for real unless you do just happen
> to know.
>
> The reason I ask is I would add a CP/M compatibility mode to both dl2 and
> pdd.sh if I knew what it should be.
>
> And, if REXCPM and PC-8401/8500 don't currently match each other, I
> suggest REXCPM should change to match NEC, so that you can move files and
> disks between the two.
>
> There are settings in both dl2 and pdd.sh to manually configure every
> detail, so already right now neither program is actually limited to the
> baked-in convenience modes, but it's not as convenient.
>
> For instance to use dl2 in this case I'm guessing you probably want
> "dl -0 -a F"
>
> "-0" sets a "raw" mode where dl2 doesn't care about spaces or dots or
> anything in the filename, doesn't re-write filenames to different formats,
> and sets the ATTR field to ' ' (0x20, space). In other words acts like a
> real drive, which also doesn't have opinions on any of that.
>
> And "-a F" sets ATTR to F, overriding that -0 set it to space.
> (I should clean that up to make a more consistent interface but that's the
> way it works currently)
>
> And attr only matters for new files created on the pc or from the internet.
>
> A real drive never fabricates an attr value, or cares what it is, it just
> saves whatever a client supplies when creating a file, and then reads it
> later when accessing files. The byte can be anything, and must match from
> one operation to the next only for the same reason a byte in the filename
> must match. And on a real drive, ALL files had to have been created by a
> client saving them initially. There are no files that come directly from
> the internet to the disk and need some attr value fabricated.
>
> A couple months ago I added xattr support so that dl2 now acts even more
> like a real drive. When creating a file (when a client saves a file,
> meaning dl2 has to create a new local file on the pc side), instead of
> ignoring the attr field from the client dirent() request, dl2 now saves it
> in a xattr metadata field attached to the file. And when listing or
> accessing existing files, instead of fabricating attr=F for all files, it
> gets a real attr value from xattr, and only fabricates the default value if
> there is no xattr.
>
> So in one sense dl2 already works fully (should anyway), at least to the
> extent of matching a real drive.
>
> --
> bkw
>
>
>> On Sat, Mar 16, 2024 at 1:36 PM Will Senn > will.s...@gmail.com>> wrote:
>>
>> __
>> I broke down and started reading the manuals (REXCPM, CP/M 2.2,
>> etc). It's starting to come together (again?)... I've inlined the
>> answers I figured out for posterity or the next clueless newb who
>> comes along.
>>
>> On 3/16/24 11:00 AM, Will Senn wrote:
>>
>>> 2. CP/M works from RexCPM, which is great, cuz CP/M recognizes
>>> more memory:
>>>
>>> 64K CP/M 2.2 M100 CP/M + REXCPM 2MB 1.0
>>>
>>> Yes, it does recognize more memory and it serves up an A: drive
>> that's a big chunk of that 2MBs. Solid. Talked about here:
>> http://bitchin100.com/wiki/index.php?title=M100_CP/M
>> 
>>
>> My questions are as follows:
>>>
>>> 4. In CP/M, how do I get back to MENU?
>>>
>>> Duh, F8 :).
>>
>> 5. When I start CP/M, is it just running CP/M against the M100's
>>> memory or am I in some special whizbang virtual environment where
>>> I have additional disks available somehow?
>>>
>> It's a whizbang environment for sure - 64K ram and a nearly 2MB A:
>> drive.
>>
>> As for my broken ASM, another duh, thanks John for the tip - I need
>> to write a CP/M friendly program that call it's routines and not the
>> ROM calls.
>>
>> CP/M seems the way to go, though. It kinda reminds me of RT11, but
>> with ASM instead of MACRO11.  

Re: [M100] Using CP/M for assembly work

[Brian K. White]

On 3/16/24 13:48, Stephen Adolph wrote:

regarding file transfer, use
IMPORT
or
EXPORT
in CP/M.  Included in package.
These programs access a "TPDD".  Filenames are 8.3 format,

cheers
Steve


What is the ATTR byte? Presumably F ?

And is that fixed-length space-filled like what Floppy or WP-2 do or not?
"a___.txt" or "a.txt___"?

And do you know if what REXCPM does matches what other CP/M systems that 
use a TPDD do?


I think there is something that can use a tpdd from a NEC PC-8401 and 
PC-8500 but I never used it yet and don't know what it exactly writes to 
the drive, or expects to find on a drive.


I have a REXCPM and both a 8401 and 8500 so I can test and answer all 
those myself some time. I'm not asking for real unless you do just 
happen to know.


The reason I ask is I would add a CP/M compatibility mode to both dl2 
and pdd.sh if I knew what it should be.


And, if REXCPM and PC-8401/8500 don't currently match each other, I 
suggest REXCPM should change to match NEC, so that you can move files 
and disks between the two.


There are settings in both dl2 and pdd.sh to manually configure every 
detail, so already right now neither program is actually limited to the 
baked-in convenience modes, but it's not as convenient.


For instance to use dl2 in this case I'm guessing you probably want
"dl -0 -a F"

"-0" sets a "raw" mode where dl2 doesn't care about spaces or dots or 
anything in the filename, doesn't re-write filenames to different 
formats, and sets the ATTR field to ' ' (0x20, space). In other words 
acts like a real drive, which also doesn't have opinions on any of that.


And "-a F" sets ATTR to F, overriding that -0 set it to space.
(I should clean that up to make a more consistent interface but that's 
the way it works currently)


And attr only matters for new files created on the pc or from the internet.

A real drive never fabricates an attr value, or cares what it is, it 
just saves whatever a client supplies when creating a file, and then 
reads it later when accessing files. The byte can be anything, and must 
match from one operation to the next only for the same reason a byte in 
the filename must match. And on a real drive, ALL files had to have been 
created by a client saving them initially. There are no files that come 
directly from the internet to the disk and need some attr value fabricated.


A couple months ago I added xattr support so that dl2 now acts even more 
like a real drive. When creating a file (when a client saves a file, 
meaning dl2 has to create a new local file on the pc side), instead of 
ignoring the attr field from the client dirent() request, dl2 now saves 
it in a xattr metadata field attached to the file. And when listing or 
accessing existing files, instead of fabricating attr=F for all files, 
it gets a real attr value from xattr, and only fabricates the default 
value if there is no xattr.


So in one sense dl2 already works fully (should anyway), at least to the 
extent of matching a real drive.


--
bkw



On Sat, Mar 16, 2024 at 1:36 PM Will Senn > wrote:


__
I broke down and started reading the manuals (REXCPM, CP/M 2.2,
etc). It's starting to come together (again?)... I've inlined the
answers I figured out for posterity or the next clueless newb who
comes along.

On 3/16/24 11:00 AM, Will Senn wrote:

2. CP/M works from RexCPM, which is great, cuz CP/M recognizes
more memory:

    64K CP/M 2.2 M100 CP/M + REXCPM 2MB 1.0


Yes, it does recognize more memory and it serves up an A: drive
that's a big chunk of that 2MBs. Solid. Talked about here:
http://bitchin100.com/wiki/index.php?title=M100_CP/M



My questions are as follows:

4. In CP/M, how do I get back to MENU?


Duh, F8 :).


5. When I start CP/M, is it just running CP/M against the M100's
memory or am I in some special whizbang virtual environment where
I have additional disks available somehow?

It's a whizbang environment for sure - 64K ram and a nearly 2MB A:
drive.

As for my broken ASM, another duh, thanks John for the tip - I need
to write a CP/M friendly program that call it's routines and not the
ROM calls.

CP/M seems the way to go, though. It kinda reminds me of RT11, but
with ASM instead of MACRO11.  ed... well, after you figure out that
you need to retrieve the file contents into the buffer, it kinda
makes sense - nice video - I love ED:
https://www.youtube.com/watch?v=7pqaj050X7g


Still need to figure out how to get files into and out of cp/m though...

Off to read some more.

-will

Re: [M100] Re-directing CP/M console to serial port in REXCPM

[Will Senn]

Before I joined the list, there was a discussion about using CP/M over 
the serial line:


http://lists.bitchin100.com/htdig.cgi/m100-bitchin100.com/2021-November/086361.html

This definitely seems like something I want to do (log into the M100, 
via minicom/screen). The thread is a bit involved and convoluted and I'm 
not sure that the author, Tom Hoppe, got it working completely, but I 
was wondering if anyone knew about it or had a short howto...


Is it possible to to control the M100 CP/M session via screen/minicom 
(enough to edit files, assemble them, and run them)? Is there a 
straightforward method to do so?


Thanks,

Will

Re: [M100] Got RexCPM working and CP/M, too, now what?

[Brian K. White]

On 3/16/24 01:50, John R. Hogerhuis wrote:
Laddiealpha and DLplus do the same thing, they're just different 
implementations of the server/disk side of the tpdd protocol. There are 
some differences in how they map to/from 6.2 filenames and how they deal 
with misnamed ASCII BASIC files. Probably some other features.


But for most functionality, they perform the same function. I assume 
dlplus supports rex cpm too. But I know that rexcpm was developed 
against laddiealpha.


-- John.



dl2 has specific support for REXCPM, in that REXCPM violates the tpdd 
spec to load the large cpm disk image. Part of the spec is a 16 byte 
field for the file size, which is physically impossible to encompass the 
file size.


Any tpdd client is *supposed* to read that field to know when to stop 
asking for another block of file data, but the way REXCPM gets around 
that is it ignores that field and just keeps asking for another block 
until failure. This can only possibly work with an emulator that is 
willing to keep going beyond 64K and do -something- with the file size 
field (I set it to 0). A real drive can not do it.


dl2 actually makes a very convenient REXCPM loader because you can use 
the bootstrapper to inject-and-run the initial rxcini.DO in a single 
step without ever actually copying or saving it as a file. Happily 
rxcini.DO actually works with RUN "COM:..." like a tpdd2 bootstrap (so 
thanks Steve!). And then the normal tpdd server to serve up the rexcpm 
"firmware", cpm installer, and cpm disk image.


If you download all the files into a directory, you end up with this 
short sweet command to do the whole thing (you have to do several manual 
steps on the 100, but nothing more on the pc, other than press enter 
once when it tells you to)


$ dl -vb rxcini.DO && dl -vu


Full directions to supply the "download all the files" and "manual steps 
on the 100" parts:

https://github.com/bkw777/dl2/blob/master/ref/REXCPM.md

Adding tsend.ps1 to Laddie gives essentially the same convenience when 
using Laddie on Windows.

https://github.com/bkw777/tsend

dl2 works on windows too in cygwin or msys2, but that's not convienient 
unless you already wanted cygwin anyway, while tsend is just a 
powershell script.


--
bkw

Re: [M100] Got RexCPM working and CP/M, too, now what?

[Will Senn]

Wow, Brian! Super clear. Now, I want a REX# :).

When you say that leaving it plugged in will kill the battery, do you 
mean that I should run it off AA batteries most of the time and not my 
6v 200ma adapter? And the battery you're talking about killing is the 
nicad on the board, right?


 Thanks,

Will


On 3/16/24 3:21 PM, Brian K. White wrote:
I summarize REX as: "An on-board software-controlled option rom 
library and ram image library."


That's the shortest way I've found to say what it does, but that's not 
the same as saying what it's good for or why you want one.


Because of the particular features and limitations of a M100, probably 
the single most life-improving thing you can do to one is to have 
TS-DOS in ROM.


That one thing addresses a few different pain points.

The biggest pain points of a M100 are:

- Battery-backed ram only storage. Very little storage, and easily 
erased or corrupted, either by dead batteries or a software crash.


- The way in manages machine-language software. How they all want to 
run in the same place in ram, yet the OS does not provide very much in 
the way of automatically moving programs into and out of that spot, so 
software is always clobbering other software, or you limit yourself to 
just having a single machine language app installed, or you have to 
figure out the arcane way to hack the binaries to relocate them to run 
at different addresses side by side, or you have to keep double copies 
of binaries so that the running copy can get clobbered and later 
replaced from the ram file copy...


- The main rom provides no binary file transfer other than the 
cassette. And no *convenient* file transfer even for text.


These things combine to make life kind of difficult. For instance you 
want some better file transfer app, but since you have no binary file 
transfer to begin with getting the file transfer app itself installed 
is a pain. Then once it's installed, it consumes precious ram, and is 
easily broken because of the way machine language apps are are run, 
and the simplest way to address that is to have a 2nd physical copy in 
ram, which uses up yet more of that precious 32k. etc.


Having any tpdd client at all installed in any form makes transferring 
files a breeze, including binary files. This somewhat alleviates the 
small ram problem because you can easily put files away and get them 
back, as long as your tpdd software stays working.


Even better is having a full featured tpdd client like ts-dos instead 
of teeny, and having it in rom instead of ram.


That alleviates all kinds of annoyances.
- It consumes almost no ram.
- It doesn't require a pain in the neck bootstrap/loader process to 
get installed.
- It isn't subject to being clobbered and needing to be reinstalled 
because of some other software writing over it or crashing.

- It isn't lost after a hard reset or dead batteries.

With TS-DOS in rom, you can pick up a totally dead machine, or totally 
kill your machine with a hard reset on purpose, or suffer a total ram 
corruption from buggy software, and with just "CALL 63012" you are up 
and running again, connect to a computer and pull down files.


But even though this makes a lot of things a lot better, this still 
needs a computer and serial cable. The tpdd client just makes it so 
that you can effortlessly connect to a pc and move files back & forth, 
and having it in rom just means you can effortlessly always have the 
tpdd client regardless of crashes or dead batteries.


That still leaves a couple things that could be better:
- If you had a plain ts-dos option rom, it means you can't use any 
other option rom because the single socket is occupied already by ts-dos.
- You still need a serial cable and pc (or a real tpdd drive or a 
Backpack or PDDuino) to actually get the files from somewhere / put 
them somewhere.


REX gives you ts-dos in rom just for starters. It gives you ts-dos in 
rom which just that right there alleviates several things above, but 
also:


- all other options roms besides ts-dos
- full ram image backups
- all on-device self-contained with no computer or serial cable needed 
(after initial loading)

- impervious to dead batteries or resets or crashes

And although you do need a computer to install option rom images onto 
the rex one time, ts-dos in particular is pre-installed, so that 
single most-needed one never needs even the initial one-time install 
from a computer. Only all the other roms need to be loaded from a pc 
once. And the loading process is easy, because REXMGR uses tpdd 
protocol internally to pull the rom images from a pc. No 
bootstrapper/loader procedure.


The other option roms give you mostly a few different office software 
kits, ie spreadsheets and word processors, and a few other things like 
there is a FORTH rom and an assembler/debugger/renumberer.


The ram image backups give you essentially more copies of 32k ram. It 
helps a few different ways:

- you can physically hold 

[M100] Assembly on CP/M a mini-tutorial

[Will Senn]

All,

Here's a mini-tutorial I just wrote (so I wouldn't forget) for doing 
assembly on the M100, in CP/M 2.2. Corrections, suggestions welcome.


#
#** m100-assembly-on-cpm.txt
#

Notes:

Case is weird on CP/M, just turn off caps-lock and use lower case unless 
upper is required for something


Tabs are better than spaces. Turn off spaces and set tab stops to 8 
before editing asm files.


requirements:
    CP/M is installed and running
    dl or laddie are running
    unix2dos - or some other way to convert line endings to DOS, I use 
Sublime


xrefs:
CP/M Reference Manual
CP/M* Versions 1.4 & 2.X Programmer's Reference Guide
CP/M Operating System Manual

BTW, this is definitely the way to go for 8085 assembly language 
programming.


The M100 normally only has 32K memory available and ZBG and TEENY take
up a lot of that space, leaving very little for programming. Still, that 
is also a worthwhile endeavor.


We will write and assemble two assembly programs. One to read characters 
from the console and echo them until an * is typed and another to print 
"hello, world to the console". The process will be to:


1. Write the source code on host system.
2. Transfer the source to the M100 CP/M system, translating the filename 
along the way.

3. Assemble the source to a HEX file
4. Load the HEX and create a CO file
5. Run the CO file

There are a couple of things we need to keep in mind as we go through 
these steps. First, use tabs, not spaces to separate fields and use 8 
character tab stops. Second, the TPDD emulation requires that files be 
in 6.2 format, but on CP/M, we can use 8.3. So, when saving the file 
into the TPDD directory, we will use all UPPER-CASE characters and 
constrain the filenames to 6.2. The import/export funcionality in CP/M 
will allow us to convert the names as we load/save files from the OS.


--- GETCS.AS

1. Write the source code on host system.

In this step, I'm using sublime and disabling spaces and setting tab 
stops to 8... right click on Tab Size in the status bar and choose 
according to your preferences.


; GETCS.AS
BDOS    EQU 0005H
CONIN    EQU 1
;
    ORG 0100H
NEXTC:    MVI C,CONIN
    CALL BDOS
    CPI '*'
    JNZ NEXTC
    RET
    END


Be sure to have an empty line after END. Also make sure you have DOS 
line endings. In Sublime, View->Line Endings->Windows.


Save the file into your TPDD directory (where you're running dl or laddie).

2. Transfer the source to the M100 CP/M system, translating the filename 
along the way.


On the M100, in CP/M:

import getcs.as getcs.asm


3. Assemble the source to a HEX file:

asm getcs

4. Load the HEX and create a COM file:

load getcs

5. Run the COM file, remember to type stuff and end it with *.:

getcs

Now is the time for ...*

--- HOWDY.AS

1. Write the source code on host system:

; HOWDY.AS
BDOS    EQU 0005H
PRIN    EQU 9

    ORG 0100H
    LXI D,TEXT
    MVI C,PRIN
    CALL BDOS
    RET

TEXT:    db    'howdy, world', 0Dh, 0AH, '$'
    END


Be sure to have an empty line after END. Also make sure you have DOS 
line endings. In Sublime, View->Line Endings->Windows.


Save the file into your TPDD directory (where you're running dl or laddie).

2. Transfer the source to the M100 CP/M system, translating the filename 
along the way.


On the M100, in CP/M:

import howdy.as howdy.asm


3. Assemble the source to a HEX file:

asm howdy

4. Load the HEX and create a COM file:

load howdy

5. Run the COM file:

howdy

howdy, world

Celebrate!

Alternatively, the source code can be created and edited on the CP/M 
system using the built in editor, ED, or a visual editor such as VEDIT:


# install VED40.CO into CP/M
import ved40.co ved40.com
ESC-ESC to exit visual mode
EQ followed by ESC-ESC to abort and exit from command mode
EX and ESC-ESC to exit and save

Re: [M100] Got RexCPM working and CP/M, too, now what?

[Brian K. White]

I summarize REX as: "An on-board software-controlled option rom library 
and ram image library."


That's the shortest way I've found to say what it does, but that's not 
the same as saying what it's good for or why you want one.


Because of the particular features and limitations of a M100, probably 
the single most life-improving thing you can do to one is to have TS-DOS 
in ROM.


That one thing addresses a few different pain points.

The biggest pain points of a M100 are:

- Battery-backed ram only storage. Very little storage, and easily 
erased or corrupted, either by dead batteries or a software crash.


- The way in manages machine-language software. How they all want to run 
in the same place in ram, yet the OS does not provide very much in the 
way of automatically moving programs into and out of that spot, so 
software is always clobbering other software, or you limit yourself to 
just having a single machine language app installed, or you have to 
figure out the arcane way to hack the binaries to relocate them to run 
at different addresses side by side, or you have to keep double copies 
of binaries so that the running copy can get clobbered and later 
replaced from the ram file copy...


- The main rom provides no binary file transfer other than the cassette. 
And no *convenient* file transfer even for text.


These things combine to make life kind of difficult. For instance you 
want some better file transfer app, but since you have no binary file 
transfer to begin with getting the file transfer app itself installed is 
a pain. Then once it's installed, it consumes precious ram, and is 
easily broken because of the way machine language apps are are run, and 
the simplest way to address that is to have a 2nd physical copy in ram, 
which uses up yet more of that precious 32k. etc.


Having any tpdd client at all installed in any form makes transferring 
files a breeze, including binary files. This somewhat alleviates the 
small ram problem because you can easily put files away and get them 
back, as long as your tpdd software stays working.


Even better is having a full featured tpdd client like ts-dos instead of 
teeny, and having it in rom instead of ram.


That alleviates all kinds of annoyances.
- It consumes almost no ram.
- It doesn't require a pain in the neck bootstrap/loader process to get 
installed.
- It isn't subject to being clobbered and needing to be reinstalled 
because of some other software writing over it or crashing.

- It isn't lost after a hard reset or dead batteries.

With TS-DOS in rom, you can pick up a totally dead machine, or totally 
kill your machine with a hard reset on purpose, or suffer a total ram 
corruption from buggy software, and with just "CALL 63012" you are up 
and running again, connect to a computer and pull down files.


But even though this makes a lot of things a lot better, this still 
needs a computer and serial cable. The tpdd client just makes it so that 
you can effortlessly connect to a pc and move files back & forth, and 
having it in rom just means you can effortlessly always have the tpdd 
client regardless of crashes or dead batteries.


That still leaves a couple things that could be better:
- If you had a plain ts-dos option rom, it means you can't use any other 
option rom because the single socket is occupied already by ts-dos.
- You still need a serial cable and pc (or a real tpdd drive or a 
Backpack or PDDuino) to actually get the files from somewhere / put them 
somewhere.


REX gives you ts-dos in rom just for starters. It gives you ts-dos in 
rom which just that right there alleviates several things above, but also:


- all other options roms besides ts-dos
- full ram image backups
- all on-device self-contained with no computer or serial cable needed 
(after initial loading)

- impervious to dead batteries or resets or crashes

And although you do need a computer to install option rom images onto 
the rex one time, ts-dos in particular is pre-installed, so that single 
most-needed one never needs even the initial one-time install from a 
computer. Only all the other roms need to be loaded from a pc once. And 
the loading process is easy, because REXMGR uses tpdd protocol 
internally to pull the rom images from a pc. No bootstrapper/loader 
procedure.


The other option roms give you mostly a few different office software 
kits, ie spreadsheets and word processors, and a few other things like 
there is a FORTH rom and an assembler/debugger/renumberer.


The ram image backups give you essentially more copies of 32k ram. It 
helps a few different ways:

- you can physically hold more than 32k of apps or data.
- you can recover from a dead battery or reset or corrupted ram from 
crashed software by restoring a ram image.


There are something like 30 or so available slots, and each slot can be 
either an option rom or a ram image. That's a lot.


All without a computer. In the coffee shop, on the train etc, just 
recover from 

Re: [M100] Using CP/M for assembly work

[Will Senn]

Soo do I need/want a Z80? Is that a mod for the M100? I had a DEC 
rainbow back in the day, that had an 8088/Z80 combo. It was nifty, but I 
used DOS on it, the Z80 was apparently tasked with doing video stuff.


Will

On 3/16/24 3:06 PM, Brian Brindle wrote:
Quick correction, if you don't have a Z80 rst 7 is gonna end poorly - 
try rst 6 instead.

Only see these things AFTER hitting send..

Start DDT
A100  # Start assembly at location $100

mvi c,2   # Put 2 in the C-register for Console Out
mv e,48  # $48 is ASCII H
call 5      # entry point for all system calls (BDOS)
mvi c,2   # Put 2 in C-register for Console Out
mvi e,49  #$49 ASCII I
call 5       # BDOS call again
rst 6        # return to DDT

g100 to execute, should print something like "HI" with memory location 
after.


Still tons of fun!

On Sat, Mar 16, 2024 at 4:03 PM Brian Brindle  wrote:

Simple DDT "HI" program - can be expanded to "hello world" if
ambitious enough.

Start DDT
A100  # Start assembly at location $100

mvi c,2   # Put 2 in the C-register for Console Out
mv e,48  # $48 is ASCII H
call 5      # entry point for all system calls (BDOS)
mvi c,2   # Put 2 in C-register for Console Out
mvi e,49  #$49 ASCII I
call 5       # BDOS call again
rst 7        # return to DDT

g100 to execute, should print something like "HI" with memory
location after.

Tons of fun!

Brian



On Sat, Mar 16, 2024 at 3:12 PM Will Senn  wrote:

Brian,

Definitely. DDT is great. I'll be working through that next. I
finally got a program working and assembled - from the 2.2
manual - read chars until *. Now, I just gotta get hello,
world working I was sure, it would work... oh, wait, when
it says to CALL CPM, I bet it's not talking about where CP/M
is DE1EH... I bet it's that 0005H entry point... off to explore.

Will

On 3/16/24 1:08 PM, Brian Brindle wrote:

If you just want to play, don't discount ddt in CP/M. Cheap
and dirty way to play with everything.

On Sat, Mar 16, 2024, 1:48 PM Stephen Adolph
 wrote:

regarding file transfer, use
IMPORT
or
EXPORT
in CP/M.  Included in package.
These programs access a "TPDD".  Filenames are 8.3 format,

cheers
Steve

On Sat, Mar 16, 2024 at 1:36 PM Will Senn
 wrote:

I broke down and started reading the manuals (REXCPM,
CP/M 2.2, etc). It's starting to come together
(again?)... I've inlined the answers I figured out
for posterity or the next clueless newb who comes along.

On 3/16/24 11:00 AM, Will Senn wrote:

2. CP/M works from RexCPM, which is great, cuz CP/M
recognizes more memory:

    64K CP/M 2.2 M100 CP/M + REXCPM 2MB 1.0


Yes, it does recognize more memory and it serves up
an A: drive that's a big chunk of that 2MBs. Solid.
Talked about here:
http://bitchin100.com/wiki/index.php?title=M100_CP/M


My questions are as follows:

4. In CP/M, how do I get back to MENU?


Duh, F8 :).


5. When I start CP/M, is it just running CP/M
against the M100's memory or am I in some special
whizbang virtual environment where I have additional
disks available somehow?

It's a whizbang environment for sure - 64K ram and a
nearly 2MB A: drive.

As for my broken ASM, another duh, thanks John for
the tip - I need to write a CP/M friendly program
that call it's routines and not the ROM calls.

CP/M seems the way to go, though. It kinda reminds me
of RT11, but with ASM instead of MACRO11.  ed...
well, after you figure out that you need to retrieve
the file contents into the buffer, it kinda makes
sense - nice video - I love ED:
https://www.youtube.com/watch?v=7pqaj050X7g

Still need to figure out how to get files into and
out of cp/m though...

Off to read some more.

-will

Re: [M100] Using CP/M for assembly work

[Will Senn]

Sweet! Thanks.

Will

On 3/16/24 3:03 PM, Brian Brindle wrote:
Simple DDT "HI" program - can be expanded to "hello world" if 
ambitious enough.


Start DDT
A100  # Start assembly at location $100

mvi c,2   # Put 2 in the C-register for Console Out
mv e,48  # $48 is ASCII H
call 5      # entry point for all system calls (BDOS)
mvi c,2   # Put 2 in C-register for Console Out
mvi e,49  #$49 ASCII I
call 5       # BDOS call again
rst 7        # return to DDT

g100 to execute, should print something like "HI" with memory location 
after.


Tons of fun!

Brian



On Sat, Mar 16, 2024 at 3:12 PM Will Senn  wrote:

Brian,

Definitely. DDT is great. I'll be working through that next. I
finally got a program working and assembled - from the 2.2 manual
- read chars until *. Now, I just gotta get hello, world
working I was sure, it would work... oh, wait, when it says to
CALL CPM, I bet it's not talking about where CP/M is DE1EH... I
bet it's that 0005H entry point... off to explore.

Will

On 3/16/24 1:08 PM, Brian Brindle wrote:

If you just want to play, don't discount ddt in CP/M. Cheap and
dirty way to play with everything.

On Sat, Mar 16, 2024, 1:48 PM Stephen Adolph
 wrote:

regarding file transfer, use
IMPORT
or
EXPORT
in CP/M.  Included in package.
These programs access a "TPDD".  Filenames are 8.3 format,

cheers
Steve

On Sat, Mar 16, 2024 at 1:36 PM Will Senn
 wrote:

I broke down and started reading the manuals (REXCPM,
CP/M 2.2, etc). It's starting to come together
(again?)... I've inlined the answers I figured out for
posterity or the next clueless newb who comes along.

On 3/16/24 11:00 AM, Will Senn wrote:

2. CP/M works from RexCPM, which is great, cuz CP/M
recognizes more memory:

    64K CP/M 2.2 M100 CP/M + REXCPM 2MB 1.0


Yes, it does recognize more memory and it serves up an A:
drive that's a big chunk of that 2MBs. Solid. Talked
about here:
http://bitchin100.com/wiki/index.php?title=M100_CP/M


My questions are as follows:

4. In CP/M, how do I get back to MENU?


Duh, F8 :).


5. When I start CP/M, is it just running CP/M against
the M100's memory or am I in some special whizbang
virtual environment where I have additional disks
available somehow?

It's a whizbang environment for sure - 64K ram and a
nearly 2MB A: drive.

As for my broken ASM, another duh, thanks John for the
tip - I need to write a CP/M friendly program that call
it's routines and not the ROM calls.

CP/M seems the way to go, though. It kinda reminds me of
RT11, but with ASM instead of MACRO11.  ed... well, after
you figure out that you need to retrieve the file
contents into the buffer, it kinda makes sense - nice
video - I love ED:
https://www.youtube.com/watch?v=7pqaj050X7g

Still need to figure out how to get files into and out of
cp/m though...

Off to read some more.

-will

Re: [M100] Using CP/M for assembly work

[Brian Brindle]

Quick correction, if you don't have a Z80 rst 7 is gonna end poorly - try
rst 6 instead.
Only see these things AFTER hitting send..

Start DDT
A100  # Start assembly at location $100

mvi c,2   # Put 2 in the C-register for Console Out
mv e,48  # $48 is ASCII H
call 5  # entry point for all system calls (BDOS)
mvi c,2   # Put 2 in C-register for Console Out
mvi e,49  #$49 ASCII I
call 5   # BDOS call again
rst 6# return to DDT

g100 to execute, should print something like "HI" with memory location
after.

Still tons of fun!

On Sat, Mar 16, 2024 at 4:03 PM Brian Brindle  wrote:

> Simple DDT "HI" program - can be expanded to "hello world" if ambitious
> enough.
>
> Start DDT
> A100  # Start assembly at location $100
>
> mvi c,2   # Put 2 in the C-register for Console Out
> mv e,48  # $48 is ASCII H
> call 5  # entry point for all system calls (BDOS)
> mvi c,2   # Put 2 in C-register for Console Out
> mvi e,49  #$49 ASCII I
> call 5   # BDOS call again
> rst 7# return to DDT
>
> g100 to execute, should print something like "HI" with memory location
> after.
>
> Tons of fun!
>
> Brian
>
>
>
> On Sat, Mar 16, 2024 at 3:12 PM Will Senn  wrote:
>
>> Brian,
>>
>> Definitely. DDT is great. I'll be working through that next. I finally
>> got a program working and assembled - from the 2.2 manual - read chars
>> until *. Now, I just gotta get hello, world working I was sure, it
>> would work... oh, wait, when it says to CALL CPM, I bet it's not talking
>> about where CP/M is DE1EH... I bet it's that 0005H entry point... off to
>> explore.
>>
>> Will
>>
>> On 3/16/24 1:08 PM, Brian Brindle wrote:
>>
>> If you just want to play, don't discount ddt in CP/M. Cheap and dirty way
>> to play with everything.
>>
>> On Sat, Mar 16, 2024, 1:48 PM Stephen Adolph 
>> wrote:
>>
>>> regarding file transfer, use
>>> IMPORT
>>> or
>>> EXPORT
>>> in CP/M.  Included in package.
>>> These programs access a "TPDD".  Filenames are 8.3 format,
>>>
>>> cheers
>>> Steve
>>>
>>> On Sat, Mar 16, 2024 at 1:36 PM Will Senn  wrote:
>>>
 I broke down and started reading the manuals (REXCPM, CP/M 2.2, etc).
 It's starting to come together (again?)... I've inlined the answers I
 figured out for posterity or the next clueless newb who comes along.

 On 3/16/24 11:00 AM, Will Senn wrote:

 2. CP/M works from RexCPM, which is great, cuz CP/M recognizes more
 memory:

 64K CP/M 2.2 M100 CP/M + REXCPM 2MB 1.0

 Yes, it does recognize more memory and it serves up an A: drive that's
 a big chunk of that 2MBs. Solid. Talked about here:
 http://bitchin100.com/wiki/index.php?title=M100_CP/M

 My questions are as follows:

 4. In CP/M, how do I get back to MENU?

 Duh, F8 :).

 5. When I start CP/M, is it just running CP/M against the M100's memory
 or am I in some special whizbang virtual environment where I have
 additional disks available somehow?

 It's a whizbang environment for sure - 64K ram and a nearly 2MB A:
 drive.

 As for my broken ASM, another duh, thanks John for the tip - I need to
 write a CP/M friendly program that call it's routines and not the ROM 
 calls.

 CP/M seems the way to go, though. It kinda reminds me of RT11, but with
 ASM instead of MACRO11.  ed... well, after you figure out that you need to
 retrieve the file contents into the buffer, it kinda makes sense - nice
 video - I love ED:
 https://www.youtube.com/watch?v=7pqaj050X7g

 Still need to figure out how to get files into and out of cp/m though...

 Off to read some more.

 -will

>>>
>>

Re: [M100] Using CP/M for assembly work

[Brian Brindle]

Simple DDT "HI" program - can be expanded to "hello world" if ambitious
enough.

Start DDT
A100  # Start assembly at location $100

mvi c,2   # Put 2 in the C-register for Console Out
mv e,48  # $48 is ASCII H
call 5  # entry point for all system calls (BDOS)
mvi c,2   # Put 2 in C-register for Console Out
mvi e,49  #$49 ASCII I
call 5   # BDOS call again
rst 7# return to DDT

g100 to execute, should print something like "HI" with memory location
after.

Tons of fun!

Brian



On Sat, Mar 16, 2024 at 3:12 PM Will Senn  wrote:

> Brian,
>
> Definitely. DDT is great. I'll be working through that next. I finally got
> a program working and assembled - from the 2.2 manual - read chars until *.
> Now, I just gotta get hello, world working I was sure, it would work...
> oh, wait, when it says to CALL CPM, I bet it's not talking about where CP/M
> is DE1EH... I bet it's that 0005H entry point... off to explore.
>
> Will
>
> On 3/16/24 1:08 PM, Brian Brindle wrote:
>
> If you just want to play, don't discount ddt in CP/M. Cheap and dirty way
> to play with everything.
>
> On Sat, Mar 16, 2024, 1:48 PM Stephen Adolph  wrote:
>
>> regarding file transfer, use
>> IMPORT
>> or
>> EXPORT
>> in CP/M.  Included in package.
>> These programs access a "TPDD".  Filenames are 8.3 format,
>>
>> cheers
>> Steve
>>
>> On Sat, Mar 16, 2024 at 1:36 PM Will Senn  wrote:
>>
>>> I broke down and started reading the manuals (REXCPM, CP/M 2.2, etc).
>>> It's starting to come together (again?)... I've inlined the answers I
>>> figured out for posterity or the next clueless newb who comes along.
>>>
>>> On 3/16/24 11:00 AM, Will Senn wrote:
>>>
>>> 2. CP/M works from RexCPM, which is great, cuz CP/M recognizes more
>>> memory:
>>>
>>> 64K CP/M 2.2 M100 CP/M + REXCPM 2MB 1.0
>>>
>>> Yes, it does recognize more memory and it serves up an A: drive that's a
>>> big chunk of that 2MBs. Solid. Talked about here:
>>> http://bitchin100.com/wiki/index.php?title=M100_CP/M
>>>
>>> My questions are as follows:
>>>
>>> 4. In CP/M, how do I get back to MENU?
>>>
>>> Duh, F8 :).
>>>
>>> 5. When I start CP/M, is it just running CP/M against the M100's memory
>>> or am I in some special whizbang virtual environment where I have
>>> additional disks available somehow?
>>>
>>> It's a whizbang environment for sure - 64K ram and a nearly 2MB A: drive.
>>>
>>> As for my broken ASM, another duh, thanks John for the tip - I need to
>>> write a CP/M friendly program that call it's routines and not the ROM calls.
>>>
>>> CP/M seems the way to go, though. It kinda reminds me of RT11, but with
>>> ASM instead of MACRO11.  ed... well, after you figure out that you need to
>>> retrieve the file contents into the buffer, it kinda makes sense - nice
>>> video - I love ED:
>>> https://www.youtube.com/watch?v=7pqaj050X7g
>>>
>>> Still need to figure out how to get files into and out of cp/m though...
>>>
>>> Off to read some more.
>>>
>>> -will
>>>
>>
>

Re: [M100] Using CP/M for assembly work

[Will Senn]

Brian,

Definitely. DDT is great. I'll be working through that next. I finally 
got a program working and assembled - from the 2.2 manual - read chars 
until *. Now, I just gotta get hello, world working I was sure, it 
would work... oh, wait, when it says to CALL CPM, I bet it's not talking 
about where CP/M is DE1EH... I bet it's that 0005H entry point... off to 
explore.


Will

On 3/16/24 1:08 PM, Brian Brindle wrote:
If you just want to play, don't discount ddt in CP/M. Cheap and dirty 
way to play with everything.


On Sat, Mar 16, 2024, 1:48 PM Stephen Adolph  wrote:

regarding file transfer, use
IMPORT
or
EXPORT
in CP/M.  Included in package.
These programs access a "TPDD".  Filenames are 8.3 format,

cheers
Steve

On Sat, Mar 16, 2024 at 1:36 PM Will Senn  wrote:

I broke down and started reading the manuals (REXCPM, CP/M
2.2, etc). It's starting to come together (again?)... I've
inlined the answers I figured out for posterity or the next
clueless newb who comes along.

On 3/16/24 11:00 AM, Will Senn wrote:

2. CP/M works from RexCPM, which is great, cuz CP/M
recognizes more memory:

    64K CP/M 2.2 M100 CP/M + REXCPM 2MB 1.0


Yes, it does recognize more memory and it serves up an A:
drive that's a big chunk of that 2MBs. Solid. Talked about
here: http://bitchin100.com/wiki/index.php?title=M100_CP/M


My questions are as follows:

4. In CP/M, how do I get back to MENU?


Duh, F8 :).


5. When I start CP/M, is it just running CP/M against the
M100's memory or am I in some special whizbang virtual
environment where I have additional disks available somehow?

It's a whizbang environment for sure - 64K ram and a nearly
2MB A: drive.

As for my broken ASM, another duh, thanks John for the tip - I
need to write a CP/M friendly program that call it's routines
and not the ROM calls.

CP/M seems the way to go, though. It kinda reminds me of RT11,
but with ASM instead of MACRO11.  ed... well, after you figure
out that you need to retrieve the file contents into the
buffer, it kinda makes sense - nice video - I love ED:
https://www.youtube.com/watch?v=7pqaj050X7g

Still need to figure out how to get files into and out of cp/m
though...

Off to read some more.

-will

Re: [M100] Using CP/M for assembly work

[Will Senn]

Thanks, Steve! I didn't truly appreciate CP/M until I decided to start 
mucking about in Assembler. I just got my first assembly program working 
in CP/M, yay and it's easy enough to just do the editing on my PC using 
sublime (after figuring out how to get 8 charater tabs and not spaces), 
dos2unix, and with import export it's swell. VEDIT works too, but it's 
faster to do the editing on the pc.


Later,

Will

On 3/16/24 12:48 PM, Stephen Adolph wrote:

regarding file transfer, use
IMPORT
or
EXPORT
in CP/M.  Included in package.
These programs access a "TPDD".  Filenames are 8.3 format,

cheers
Steve

On Sat, Mar 16, 2024 at 1:36 PM Will Senn  wrote:

I broke down and started reading the manuals (REXCPM, CP/M 2.2,
etc). It's starting to come together (again?)... I've inlined the
answers I figured out for posterity or the next clueless newb who
comes along.

On 3/16/24 11:00 AM, Will Senn wrote:

2. CP/M works from RexCPM, which is great, cuz CP/M recognizes
more memory:

    64K CP/M 2.2 M100 CP/M + REXCPM 2MB 1.0


Yes, it does recognize more memory and it serves up an A: drive
that's a big chunk of that 2MBs. Solid. Talked about here:
http://bitchin100.com/wiki/index.php?title=M100_CP/M


My questions are as follows:

4. In CP/M, how do I get back to MENU?


Duh, F8 :).


5. When I start CP/M, is it just running CP/M against the M100's
memory or am I in some special whizbang virtual environment where
I have additional disks available somehow?

It's a whizbang environment for sure - 64K ram and a nearly 2MB A:
drive.

As for my broken ASM, another duh, thanks John for the tip - I
need to write a CP/M friendly program that call it's routines and
not the ROM calls.

CP/M seems the way to go, though. It kinda reminds me of RT11, but
with ASM instead of MACRO11.  ed... well, after you figure out
that you need to retrieve the file contents into the buffer, it
kinda makes sense - nice video - I love ED:
https://www.youtube.com/watch?v=7pqaj050X7g

Still need to figure out how to get files into and out of cp/m
though...

Off to read some more.

-will

Re: [M100] Using CP/M for assembly work

[Brian Brindle]

If you just want to play, don't discount ddt in CP/M. Cheap and dirty way
to play with everything.

On Sat, Mar 16, 2024, 1:48 PM Stephen Adolph  wrote:

> regarding file transfer, use
> IMPORT
> or
> EXPORT
> in CP/M.  Included in package.
> These programs access a "TPDD".  Filenames are 8.3 format,
>
> cheers
> Steve
>
> On Sat, Mar 16, 2024 at 1:36 PM Will Senn  wrote:
>
>> I broke down and started reading the manuals (REXCPM, CP/M 2.2, etc).
>> It's starting to come together (again?)... I've inlined the answers I
>> figured out for posterity or the next clueless newb who comes along.
>>
>> On 3/16/24 11:00 AM, Will Senn wrote:
>>
>> 2. CP/M works from RexCPM, which is great, cuz CP/M recognizes more
>> memory:
>>
>> 64K CP/M 2.2 M100 CP/M + REXCPM 2MB 1.0
>>
>> Yes, it does recognize more memory and it serves up an A: drive that's a
>> big chunk of that 2MBs. Solid. Talked about here:
>> http://bitchin100.com/wiki/index.php?title=M100_CP/M
>>
>> My questions are as follows:
>>
>> 4. In CP/M, how do I get back to MENU?
>>
>> Duh, F8 :).
>>
>> 5. When I start CP/M, is it just running CP/M against the M100's memory
>> or am I in some special whizbang virtual environment where I have
>> additional disks available somehow?
>>
>> It's a whizbang environment for sure - 64K ram and a nearly 2MB A: drive.
>>
>> As for my broken ASM, another duh, thanks John for the tip - I need to
>> write a CP/M friendly program that call it's routines and not the ROM calls.
>>
>> CP/M seems the way to go, though. It kinda reminds me of RT11, but with
>> ASM instead of MACRO11.  ed... well, after you figure out that you need to
>> retrieve the file contents into the buffer, it kinda makes sense - nice
>> video - I love ED:
>> https://www.youtube.com/watch?v=7pqaj050X7g
>>
>> Still need to figure out how to get files into and out of cp/m though...
>>
>> Off to read some more.
>>
>> -will
>>
>

Re: [M100] Using CP/M for assembly work

[Stephen Adolph]

regarding file transfer, use
IMPORT
or
EXPORT
in CP/M.  Included in package.
These programs access a "TPDD".  Filenames are 8.3 format,

cheers
Steve

On Sat, Mar 16, 2024 at 1:36 PM Will Senn  wrote:

> I broke down and started reading the manuals (REXCPM, CP/M 2.2, etc). It's
> starting to come together (again?)... I've inlined the answers I figured
> out for posterity or the next clueless newb who comes along.
>
> On 3/16/24 11:00 AM, Will Senn wrote:
>
> 2. CP/M works from RexCPM, which is great, cuz CP/M recognizes more memory:
>
> 64K CP/M 2.2 M100 CP/M + REXCPM 2MB 1.0
>
> Yes, it does recognize more memory and it serves up an A: drive that's a
> big chunk of that 2MBs. Solid. Talked about here:
> http://bitchin100.com/wiki/index.php?title=M100_CP/M
>
> My questions are as follows:
>
> 4. In CP/M, how do I get back to MENU?
>
> Duh, F8 :).
>
> 5. When I start CP/M, is it just running CP/M against the M100's memory or
> am I in some special whizbang virtual environment where I have additional
> disks available somehow?
>
> It's a whizbang environment for sure - 64K ram and a nearly 2MB A: drive.
>
> As for my broken ASM, another duh, thanks John for the tip - I need to
> write a CP/M friendly program that call it's routines and not the ROM calls.
>
> CP/M seems the way to go, though. It kinda reminds me of RT11, but with
> ASM instead of MACRO11.  ed... well, after you figure out that you need to
> retrieve the file contents into the buffer, it kinda makes sense - nice
> video - I love ED:
> https://www.youtube.com/watch?v=7pqaj050X7g
>
> Still need to figure out how to get files into and out of cp/m though...
>
> Off to read some more.
>
> -will
>

Re: [M100] Using CP/M for assembly work

[Will Senn]

More duh, export and import writes and reads from tpdd emulator!
Awesome.

On 3/16/24 12:34 PM, Will Senn wrote:
I broke down and started reading the manuals (REXCPM, CP/M 2.2, etc). 
It's starting to come together (again?)... I've inlined the answers I 
figured out for posterity or the next clueless newb who comes along.


On 3/16/24 11:00 AM, Will Senn wrote:
2. CP/M works from RexCPM, which is great, cuz CP/M recognizes more 
memory:


    64K CP/M 2.2 M100 CP/M + REXCPM 2MB 1.0

Yes, it does recognize more memory and it serves up an A: drive that's 
a big chunk of that 2MBs. Solid. Talked about here: 
http://bitchin100.com/wiki/index.php?title=M100_CP/M



My questions are as follows:

4. In CP/M, how do I get back to MENU?


Duh, F8 :).

5. When I start CP/M, is it just running CP/M against the M100's 
memory or am I in some special whizbang virtual environment where I 
have additional disks available somehow?

It's a whizbang environment for sure - 64K ram and a nearly 2MB A: drive.

As for my broken ASM, another duh, thanks John for the tip - I need to 
write a CP/M friendly program that call it's routines and not the ROM 
calls.


CP/M seems the way to go, though. It kinda reminds me of RT11, but 
with ASM instead of MACRO11.  ed... well, after you figure out that 
you need to retrieve the file contents into the buffer, it kinda makes 
sense - nice video - I love ED:

https://www.youtube.com/watch?v=7pqaj050X7g

Still need to figure out how to get files into and out of cp/m though...

Off to read some more.

-will

Re: [M100] Using CP/M for assembly work

[Will Senn]

I broke down and started reading the manuals (REXCPM, CP/M 2.2, etc). 
It's starting to come together (again?)... I've inlined the answers I 
figured out for posterity or the next clueless newb who comes along.


On 3/16/24 11:00 AM, Will Senn wrote:
2. CP/M works from RexCPM, which is great, cuz CP/M recognizes more 
memory:


    64K CP/M 2.2 M100 CP/M + REXCPM 2MB 1.0

Yes, it does recognize more memory and it serves up an A: drive that's a 
big chunk of that 2MBs. Solid. Talked about here: 
http://bitchin100.com/wiki/index.php?title=M100_CP/M



My questions are as follows:

4. In CP/M, how do I get back to MENU?


Duh, F8 :).

5. When I start CP/M, is it just running CP/M against the M100's 
memory or am I in some special whizbang virtual environment where I 
have additional disks available somehow?

It's a whizbang environment for sure - 64K ram and a nearly 2MB A: drive.

As for my broken ASM, another duh, thanks John for the tip - I need to 
write a CP/M friendly program that call it's routines and not the ROM calls.


CP/M seems the way to go, though. It kinda reminds me of RT11, but with 
ASM instead of MACRO11.  ed... well, after you figure out that you need 
to retrieve the file contents into the buffer, it kinda makes sense - 
nice video - I love ED:

https://www.youtube.com/watch?v=7pqaj050X7g

Still need to figure out how to get files into and out of cp/m though...

Off to read some more.

-will

Re: [M100] Using CP/M for assembly work

[Will Senn]

Got it. I'll find a text on CP/M Assembly - dos calls or whatnot.

Will

On 3/16/24 11:41 AM, John R. Hogerhuis wrote:

You'd want to use CP/M for as much I/O as possible.

CP/m runs in all-RAM mode. So the main ROM isn't mapped in lower 
address space.


Though I'm sure Steve or Phil could show you how to do a far call to 
the main ROM if you really need to. But you probably don't.


Of course you also can do direct I/o using the in and out instructions 
without jumping to the main ROM. No ROM switching code needed.


-- John.

Re: [M100] Using CP/M for assembly work

[John R. Hogerhuis]

You'd want to use CP/M for as much I/O as possible.

CP/m runs in all-RAM mode. So the main ROM isn't mapped in lower address
space.

Though I'm sure Steve or Phil could show you how to do a far call to the
main ROM if you really need to. But you probably don't.

Of course you also can do direct I/o using the in and out instructions
without jumping to the main ROM. No ROM switching code needed.

-- John.

[M100] Using CP/M for assembly work

[Will Senn]

I figured out a bunch of stuff:

1. ZBG "works" and I was able to get the sample checkerboard app to run. 
I ran into memory issues, though. For example, when I edited the source 
and saved it out of TEXT. All was well with the world, but when I tried 
'ASM SAMPLE.DO SAMPLE /WE' from within ZBG.CO from MENU, it didn't work. 
However, the same command worked fine when I "RUN ZBG.BA" from BASIC. 
Weird, I figure it's my lack of understanding of how memory and files 
work on the M100.


2. CP/M works from RexCPM, which is great, cuz CP/M recognizes more memory:

    64K CP/M 2.2 M100 CP/M + REXCPM 2MB 1.0

3. I worked out (through much pain and suffering) how to create my 
SAMPLE.ASM file using ED and compiled it successfully using 'ASM SAMPLE'


4. I ran it using 'LOAD SAMPLE' then 'SAMPLE'

Of course, it cratered - hung there and wouldn't respond.

I figure, I will work through it eventually, but I have questions. But, 
before that, here's the sample code, in case it's obvious where I went 
wrong (it's using ROM functions, are those available from CP/M?):


    ORG    0CC00H
   HOME:    CALL    422DH
   SCREEN:    MVI    A,0FFH
    CALL    4B44H
   ROW:    LDA    0F639H
    CPI    8H
    JNZ    SCREEN
   COL:    LDA    0F63AH
    CPI    28H
    JNZ    SCREEN
   WAIT:    CALL    12CBH
   EXIT:    CALL    5797H
    END    HOME

I also tried it with ORG 100H (like Sgt. Schultz, I know nothing... 
about CP/M's memory model).


My questions are as follows:

Bare M100:
1.  After copying ZBG.CO and ZBG.BA over and creating my SAMPLE.DO file 
(the only other file on the machine is TEENY.CO), I have 768 bytes left 
(it's a 32K RAM M100). Does that sound right or am I supposed to delete 
the CO files after they're loaded or run some funky clear command, or what?


2. ZBG is expecting to be loaded from cassette with CLOAD, is there a 
fake-the-cassette command that will use DataLink or something?


With REXCPM:

3. In CP/M, how to I transfer files to / from my host system (is there a 
TEENY for CP/M)?


4. In CP/M, how do I get back to MENU?

5. When I start CP/M, is it just running CP/M against the M100's memory 
or am I in some special whizbang virtual environment where I have 
additional disks available somehow?


Wow! So many questions, so little time :).

Thanks,

Will