From: "FyberOptic" <fyberoptic@...>
Jan 31, 2010
Yep, that's Zork 1!
So, how is it working? Basically, I (mostly) c=
ompleted my CP/M BIOS
module, finally emulating a floppy disk with the data=
flash. This is the
same BIOS code that I was using for the core of FyOS be=
fore, btw, though
just mostly for the console I/O at the time. Except now =
I'm using the
real CP/M BDOS v2.2 with it, because I thought that would be =
the easiest
way to ensure my BIOS module was working properly. I have no co=
mmand
processor at the moment, but I didn't need one. I just wanted to
dire=
ctly load this one program to see if it worked. And it does.
Kinda.
Ther=
e's still limitations. First is the obvious, with the text display
I'm gen=
erating only supporting 40 x 16 characters. Zork likely expects
an 80 char=
acter display, and I would bet other CP/M apps would as well.
Second, my B=
IOS still can't write to "disk". This was partially due to
the fact that I=
wasn't even sure my read routine was going to work
properly. Which it did=
, and only needed one little fix, surpisingly.
I'm hoping it won't be much=
effort to do the reverse now for writing.
Originally I wanted to go to th=
e trouble of some kind of smart system
which would cycle the dataflash sect=
ors to increase their lifetime, but
then I decided a.) it was too much work=
, and b.) if the Mailstation
folks were too lazy to do it, then why should =
I?
For those who may have not followed some of the other work I've done
ar=
ound here in the past, then you should know that this is only possible
due =
to a hardware mod I made to my Mailstation. I've replicated this
functiona=
lity in my current test build of the emulator. Basically, I
added in a cir=
cuit to allow the lower 16KB of address space to be
swapped from codeflash =
to RAM. Normally the first 16KB of codeflash is
permanently in that spot. =
My toggle lets me put in the second page of
RAM (since the first page is p=
ermanently in the uppermost 16KB of
address space). This is necessary in o=
rder to run CP/M and its
applications natively.
As for the "disk", I took =
a bit of a clever approach. My #1 requirement
was that it couldn't disrupt=
the normal functionality of the
Mailstation, and oppositely, the Mailstati=
on's normal functionality
couldn't disrupt it. I am in fact still running =
the Mailstation
firmware at power-up, after all. So, what I did was take a=
dvantage of
all the available app space. Which is apparently 128KB worth. =
This
meant that nothing which the Mailstation firmware did should mess up =
my
disk image, and nothing my disk image did should mess up Mailstation
set=
tings.
The virtual disk has 256-byte sectors (to match the dataflash), 16
=
sectors per track, and 32 tracks. That makes each track 4KB. I
reserved 4=
tracks for system use, which is 16KB, which is conveniently
the same size =
as a dataflash page. This means the system tracks can be
used as a normal =
Mailstation app. And this is exactly how I used them,
placing a loader app=
to put the BDOS + BIOS into upper memory, which
then executes the BIOS col=
d boot procedure.
Since I wanted to support any version of BDOS that might=
be attached to
this BIOS at some point, I decided to handle deblocking int=
ernally.
This means that as far as CP/M knows, the disk actually uses 32 1=
28-byte
sectors per track. 128 was the common size, and even in the later
=
versions is still the size of things like the DMA and BDOS read routines
us=
e from what I understand.
Regardless of CP/M version, the disk is configur=
ed to use 64 directory
entries, using a 1KB block size.
I wrote a utility =
on the PC to generate this disk as a 128KB file, using
a separate text file=
to determine what files should be inserted into the
disk (calculating exte=
nts, writing the directory entries, all the crap
necessary for CP/M disks).=
That disk image file can then just be dumped
into the dataflash.bin that =
my emulator uses. Since the first 16KB acts
as a standalone Mailstation ap=
p, you can simply launch the OS from the
Mailstation menu like you would an=
y other 3rd-party app.
The fact that you're seeing the game text on the sc=
reen shows that it is
indeed properly reading files from the virtual disk, =
because zork1.com
loads all of that from zork1.dat. That's part of why I w=
anted to use it
as a test. The executable was small, and I knew what to ex=
pect from it.
I haven't tried this on the Mailstation hardware yet, mostly=
due to the
fact that it will erase my loader app. Before I go writing any=
thing
into my datflash, I'm going to wait until I have both a command
proce=
ssor and a standalone loader utility which I can run from there.
But I hav=
e no reason to think it wouldn't run, because the disk routine
is the only =
new part. All the console I/O functions have been run on
the hardware befo=
re.
I'd still like to finish my own original BDOS code, since I think it's=
still technically stealing to use this one even though it's 30 years
old. =
But then again, it's probably stealing to be using this copy of
Zork too. =
And my BIOS module is currently using a ripped out version of
the Mailstat=
ion's keyboard routines, as well as the original CGA font
(which I'm sure i=
s copyrighted or something). Oh well!
Anyhoo, this is turning into a huge=
post, but my work is finally coming
along into something I can actually sh=
ow results from, so I thought I'd
share what I have so far!
"></P><P><BR></P>
asically, I (mostly) completed my CP/M BIOS module, finally emulating a flo=
ppy disk with the dataflash. This is the same BIOS code that I was using f=
or the core of FyOS before, btw, though just mostly for the console I/O at =
the time. Except now I'm using the real CP/M BDOS v2.2 with it, because I =
thought that would be the easiest way to ensure my BIOS module was working =
properly. I have no command processor at the moment, but I didn't need one.=
I just wanted to directly load this one program to see if it worked. And =
it does. Kinda.</P>
with the text display I'm generating only supporting 40 x 16 characters. Z=
ork likely expects an 80 character display, and I would bet other CP/M apps=
would as well. Second, my BIOS still can't write to "disk". This was par=
tially due to the fact that I wasn't even sure my read routine was going to=
work properly. Which it did, and only needed one little fix, surpisingly.=
I'm hoping it won't be much effort to do the reverse now for writing. Or=
iginally I wanted to go to the trouble of some kind of smart system which w=
ould cycle the dataflash sectors to increase their lifetime, but then I dec=
ided a.) it was too much work, and b.) if the Mailstation folks were too la=
zy to do it, then why should I?</P>
some of the other work I've done around here in the past, then you should =
know that this is only possible due to a hardware mod I made to my Mailstat=
ion. I've replicated this functionality in my current test build of the em=
ulator. Basically, I added in a circuit to allow the lower 16KB of address=
space to be swapped from codeflash to RAM. Normally the first 16KB of cod=
eflash is permanently in that spot. My toggle lets me put in the second pa=
ge of RAM (since the first page is permanently in the uppermost 16KB of add=
ress space). This is necessary in order to run CP/M and its applications n=
atively.</p>
#1 requirement was that it couldn't disrupt the normal functionality of the=
Mailstation, and oppositely, the Mailstation's normal functionality couldn=
't disrupt it. I am in fact still running the Mailstation firmware at powe=
r-up, after all. So, what I did was take advantage of all the available ap=
p space. Which is apparently 128KB worth. This meant that nothing which t=
he Mailstation firmware did should mess up my disk image, and nothing my di=
sk image did should mess up Mailstation settings.</p>
has 256-byte sectors (to match the dataflash), 16 sectors per track, and 32=
tracks. That makes each track 4KB. I reserved 4 tracks for system use, w=
hich is 16KB, which is conveniently the same size as a dataflash page. Thi=
s means the system tracks can be used as a normal Mailstation app. And thi=
s is exactly how I used them, placing a loader app to put the BDOS + BIOS i=
nto upper memory, which then executes the BIOS cold boot procedure.</p>
is BIOS at some point, I decided to handle deblocking internally. This mea=
ns that as far as CP/M knows, the disk actually uses 32 128-byte sectors pe=
r track. 128 was the common size, and even in the later versions is still =
the size of things like the DMA and BDOS read routines use from what I unde=
rstand.</p>
4 directory entries, using a 1KB block size.</p>
he PC to generate this disk as a 128KB file, using a separate text file to =
determine what files should be inserted into the disk (calculating extents,=
writing the directory entries, all the crap necessary for CP/M disks). Th=
at disk image file can then just be dumped into the dataflash.bin that my e=
mulator uses. Since the first 16KB acts as a standalone Mailstation app, y=
ou can simply launch the OS from the Mailstation menu like you would any ot=
her 3rd-party app.</p>
screen shows that it is indeed properly reading files from the virtual dis=
k, because zork1.com loads all of that from zork1.dat. That's part of why =
I wanted to use it as a test. The executable was small, and I knew what to=
expect from it.</p>
et, mostly due to the fact that it will erase my loader app. Before I go w=
riting anything into my datflash, I'm going to wait until I have both a com=
mand processor and a standalone loader utility which I can run from there. =
But I have no reason to think it wouldn't run, because the disk routine is=
the only new part. All the console I/O functions have been run on the har=
dware before.</p>
ince I think it's still technically stealing to use this one even though it=
's 30 years old. But then again, it's probably stealing to be using this c=
opy of Zork too. And my BIOS module is currently using a ripped out versio=
n of the Mailstation's keyboard routines, as well as the original CGA font =
(which I'm sure is copyrighted or something). Oh well!</p>
s is turning into a huge post, but my work is finally coming along into som=
ething I can actually show results from, so I thought I'd share what I have=
so far!</p>
From: Ethan Dicks <ethan.dicks@...>
Feb 1, 2010
On 1/31/10, FyberOptic <fyberoptic@...> wrote:
Well done!
There are versions of the CP/M Z-machine floating around (I found them
in one of the massive repositories a couple of years back) that came
with an Infocom-written customizer front-end. You might look for CP/M
Zork or Starcross or Planetfall that happen to have a .ASM file
included beyond just the usual .COM and .DAT file. They mostly let
you select your terminal type (ADM3, VT100, etc), but there might be
something in there for screen size.
Overall, though, Infocom did support 40 column machines (Apple II,
C-64, etc.) It's up to the Z-machine where to wrap, etc. The
appearance of the status line depends on matching up the column width,
and there is at least one puzzle clue that I know of that is easy to
spot with an 80-column screen but hard to spot at 40 columns.
Yep. I've done similar sorts of things with the Z-machine for the
6502. It's not large and you know how it's going to behave (lots of
disk reads for game text and game data).
In order to get that opening screen, lots of things have to be working
right. I had a long-standing bug with my port of the 6502 engine to a
new platform - for me, the opening screen was fine, but it got
squirrely with the first line of user input. At least it was at an
obvious blocking point, so somewhat easy to create test-cases for.
Smashing work. I can't wait to see a photograph of it running on the
real hardware someday.
-ethan
From: "cyranojones_lalp" <cyranojones_lalp@...>
Feb 1, 2010
Hey, that pretty cool!!!=
ght that would be the easiest
operly. I have no command
Is the "console command processor" (CCP) a separate prog???
Or is it pa=
rt of the BDOS??? I don't remember.
I do recall that the BIOS was suppose=
d to be the only
part that needs to be customized.
Perhaps you are closer =
than you think!
Did you cold boot CP/M, or just preload cp/m & Zork, and
s=
tart from there (0x0100)?
This was
tine was going to work
Might it be useful if the bank-switchi=
ng was not one way,
and you could call routines from the ms firmware?
Then =
you could use ms firmware to access the dataflash, and
even use the built i=
n keyboard code.
I guess you would need to give back the ram at C000 to
ge=
t that to work, but I don't see that as a real problem.
You get a pretty bi=
g stack out of the deal, too!
Most CP/M systems never had full 64K RAM. M=
ine
did have 64K, but a big chunk was dedicated to screen
RAM (I forget th=
e actual size, but it did have a graphic
mode, I want to say it used 24k fo=
r screen, but I would
need to look it up somewhere).
take advantage of
worth.
There is a lot more space available in the mailstation's
"file" =
area. I think there is even one or two "filenames"
available (where filena=
me is just a byte, from 0 to 0x2f.
Using the space that way would let your =
cp/m files coexist
with the other mailstation files.
s on the Mailstation hardware yet, mostly due
erase my loader app. Before I go writing anything
going to wait until I have both a command
der utility which I can run from
What if you combined your load=
er, your cpm boot code, & cpm system
tracks into a single app? Or just use=
2 app pages? For that
matter, if there is any space left in your system p=
age, you
could still use it as part of cpm's non-system tracks. An
app doe=
sn't need to use the whole 16K, they just need to
start at begining of one.=
Your own, but "ori=
ginal" might not be the right word! :-)
cally stealing to use
There goe=
s your "innocent" defense.
"Anything you say may be used..."
How do you in=
terpret this:
(URL)
Does it mean we can just u=
se it now??? Or does it only apply
to that site?????
's probably stealing to be using this copy of
Gosh, and now yo=
u even confessed! In public!!!
ripped out version of
e original
I won=
der if they have net access in prisons these days? :-)
I have a putchar t=
hat uses the ms font, and a getchar that
calls ms keyboard code.
CJ
From: "FyberOptic" <fyberoptic@...>
Feb 2, 2010
Couple of updates to point out here. One is obvious, the other maybe
not=
so much unless you know what you look for!
Let's start with the font. It=
's now 4x6. The reason I used an 8x8 font
originally is because it fit per=
fectly into the restraints of the
hardware. The screen being 320x128 meant=
you could divide both
dimensions evenly by 8, getting 40x16 characters on =
the screen. I had
the font data aligned to a 256-byte page in memory, and =
formatted the
data so that each character row could be pulled out by simply=
incrementing the high byte of the memory address. The low byte was set
to=
which ASCII character you wanted (since there were 256 characters in
the f=
ont). No multiplication or anything was necessary to get the
character off=
set into the font data. And since each byte of LCD data
represented 8 pixe=
ls, it was an easy matter to write an entire row of
character data to the s=
creen at a time, then just increment a couple of
pointers, and repeat 7 mor=
e times. This made drawing characters pretty
speedy. What took the most t=
ime is calculating all the junk necessary
to translate X/Y coordinates into=
the wacky backwards way the
Mailstation LCD hardware works.
Well 40x16 is=
n't really enough for many circumstances, particularly in
width. Not even =
a CP/M directory listing. So I did some math on
various sizes. A 5x7 font=
would give me a 64x18 display, with a few
pixels left over at the bottom. =
Not much more vertically, but 24 more
horizontally was good. So I looked =
around for some fonts on the
internet, and ended up on this page
sher.dk/rockbox/fonts/misc/> . It has a bunch of Linux fonts,
but best of =
all, has images available of all the character sets. There
was a nice 5x7 =
font, but I also noticed the 4x6 one. More math showed
that a 4x6 font wou=
ld give me 80x21! That's almost a full CRT display's
worth, just a few shy=
vertically. And the more I thought about how I
would implement a font whi=
ch wasn't 8 pixels wide, the more I realized
that using one with an even wi=
dth would be easiest. A 4x6 font means a
single byte of LCD data can hold =
exactly two character columns of row
data. Imagine the nightmare of trying=
to calculate your position on the
screen if every character was 5 pixels w=
ide. Five bits of one character
would be in one byte, then the next charac=
ter would have 3 bits in the
last byte and 2 bits in the next byte, etc. I=
t hurts my brain to even
think about it!
The other thing I noticed is that=
most of those fonts, including the 4x6
one I wanted, are public domain. A=
wesome.
So I formatted the image of the font characters into something I c=
ould
work with and insert into my assembly. I didn't go with 256 character=
s
this time because I'm honestly not sure if all the IBM ASCII characters
t=
hat were in the CGA font are even present in this one. If they are,
they'r=
e so small that it's hard to distinguish which are which. I left
the first=
32 characters blank as well. No more smiley face characters!
I might sti=
ll extend it to 256 later, but CP/M was primarily 7-bit ASCII
anyway. I on=
ly included the upper 128 of the CGA font before because it
could be used f=
or drawing lines and borders and things.
It took a bit of figuring things =
out and code reworking, but I converted
my putchar object file to work with=
the new font data/size. And
conveniently, changes were only made to that =
object file, which means I
can recompile my BIOS to use the 8x8 font again =
as easy as specifying a
different object file when linking. The new one =
probably isn't as
fast due to extra math involved, but the increased displa=
y size is worth
it in most cases.
Anyway, I'll stop rambling about fonts. =
It looks small in the emulator
unless I 2X, but I think on the real hardwa=
re it'll be okay.
The other thing you might not have noticed on the scree=
n there is that I
actually loaded Zork via the command processor. I got a =
directory
listing beforehand too, though there's only three files on the vi=
rtual
disk.
I've had some quirks out of this. I can launch stuff, but whe=
n the
application exits and the warm boot happens, the CCP never reloads
pr=
operly again. I haven't been able to figure it out yet, unless it
and/or t=
he BDOS are storing values which are messing it up, or
something's getting =
overwritten when Zork runs. I dunno yet. I suppose
I could totally re-rea=
d the BDOS/BIOS too. Maybe that's even what
you're supposed to do.
Part o=
f the problem might be that I didn't use any of the original tools
used to =
build a CP/M system. I've manually converted the assembly code
over to wor=
k with AS-Z80, and am linking everything together as best I
can figure it s=
hould work based on CP/M manuals. I had to increase the
default tiny BDOS =
stack too because my BIOS calls were overflowing it
(since I doubt most BIO=
Ses needed as much bloaty hardware translations
as this one). I think the =
CCP is normally part of the whole mess that
gets loaded off the system trac=
ks in v2.2, but I was trying to take more
of a CP/M 3 approach. I'm pullin=
g the .COM off the disk, but just
loading it at an abnormal location (under=
the BDOS) instead of at 0x100.
I probably should rename it to .SYS just to=
avoid confusion.
CP/M 3 actually loads its CCP at 0x100, but puts a loade=
r module up
under the BDOS for executing programs (using the memory-residen=
t module
functionality of v3). The reason I didn't go all-out in supportin=
g the
CP/M 3 BDOS though is because the BIOS would need a bunch more stuff
=
added to it. Which I'd still like to do eventually and all, but for the
ti=
me being the plan has just been "make it work". CP/M 2.2 was the
easiest/q=
uickest way to reach that goal. And I still have some fiddling
to do.
So=
yeah, a lot of blabbing just to mention a new font and CCP. But
maybe fol=
ks are interested in the technical junk too. Either way, Zork
fits on the =
screen fine now!
ybe not so much unless you know what you look for!<br><br>Let's start with =
the font. It's now 4x6. The reason I used an 8x8 font originally is becau=
se it fit perfectly into the restraints of the hardware. The screen being =
320x128 meant you could divide both dimensions evenly by 8, getting 40x16 c=
haracters on the screen. I had the font data aligned to a 256-byte page in=
memory, and formatted the data so that each character row could be pulled =
out by simply incrementing the high byte of the memory address. The low by=
te was set to which ASCII character you wanted (since there were 256 charac=
ters in the font). No multiplication or anything was necessary to get the =
character offset into the font data. And since each byte of LCD data repre=
sented 8 pixels, it was an easy matter to write an entire row of character =
data to the screen at a time, then just increment a couple of pointers, and=
repeat 7 more times. This made drawing characters pretty speedy. What to=
ok the most time is calculating all the junk necessary to translate X/Y coo=
rdinates into the wacky backwards way the Mailstation LCD hardware works.<b=
r><br>Well 40x16 isn't really enough for many circumstances, particularly i=
n width. Not even a CP/M directory listing. So I did some math on various=
sizes. A 5x7 font would give me a 64x18 display, with a few pixels left o=
ver at the bottom. Not much more vertically, but 24 more horizontally was =
good. So I looked around for some fonts on the internet, and ended up <a h=
ref=3D"(URL)c/">on this page. It has a bu=
nch of Linux fonts, but best of all, has images available of all the charac=
ter sets. There was a nice 5x7 font, but I also noticed the 4x6 one. More=
math showed that a 4x6 font would give me 80x21! That's almost a full CRT=
display's worth, just a few shy vertically. And the more I thought about =
how I would implement a font which wasn't 8 pixels wide, the more I realize=
d that using one with an even width would be easiest. A 4x6 font means a s=
ingle byte of LCD data can hold exactly two character columns of row data. =
Imagine the nightmare of trying to calculate your position on the screen i=
f every character was 5 pixels wide. Five bits of one character would be i=
n one byte, then the next character would have 3 bits in the last byte and =
2 bits in the next byte, etc. It hurts my brain to even think about it!<br=
x6 one I wanted, are public domain. Awesome.<br><br>So I formatted the ima=
ge of the font characters into something I could work with and insert into =
my assembly. I didn't go with 256 characters this time because I'm honestl=
y not sure if all the IBM ASCII characters that were in the CGA font are ev=
en present in this one. If they are, they're so small that it's hard to di=
stinguish which are which. I left the first 32 characters blank as well. =
No more smiley face characters! I might still extend it to 256 later, but =
CP/M was primarily 7-bit ASCII anyway. I only included the upper 128 of th=
e CGA font before because it could be used for drawing lines and borders an=
d things.<br><br>It took a bit of figuring things out and code reworking, b=
ut I converted my putchar object file to work with the new font data/size. =
And conveniently, changes were only made to that object file, which means =
I can recompile my BIOS to use the 8x8 font again as easy as specifying a d=
ifferent object file when linking. The new one probably isn't as fast du=
e to extra math involved, but the increased display size is worth it in mos=
t cases.<br><br>Anyway, I'll stop rambling about fonts. It looks small in =
the emulator unless I 2X, but I think on the real hardware it'll be okay.<b=
r><br><br>The other thing you might not have noticed on the screen there is=
that I actually loaded Zork via the command processor. I got a directory =
listing beforehand too, though there's only three files on the virtual disk=
.<br><br>I've had some quirks out of this. I can launch stuff, but when th=
e application exits and the warm boot happens, the CCP never reloads proper=
ly again. I haven't been able to figure it out yet, unless it and/or the B=
DOS are storing values which are messing it up, or something's getting over=
written when Zork runs. I dunno yet. I suppose I could totally re-read th=
e BDOS/BIOS too. Maybe that's even what you're supposed to do.<br><br>Part=
of the problem might be that I didn't use any of the original tools used t=
o build a CP/M system. I've manually converted the assembly code over to w=
ork with AS-Z80, and am linking everything together as best I can figure it=
should work based on CP/M manuals. I had to increase the default tiny BDO=
S stack too because my BIOS calls were overflowing it (since I doubt most B=
IOSes needed as much bloaty hardware translations as this one). I think th=
e CCP is normally part of the whole mess that gets loaded off the system tr=
acks in v2.2, but I was trying to take more of a CP/M 3 approach. I'm pull=
ing the .COM off the disk, but just loading it at an abnormal location (und=
er the BDOS) instead of at 0x100. I probably should rename it to .SYS just=
to avoid confusion.<br><br>CP/M 3 actually loads its CCP at 0x100, but put=
s a loader module up under the BDOS for executing programs (using the memor=
y-resident module functionality of v3). The reason I didn't go all-out in =
supporting the CP/M 3 BDOS though is because the BIOS would need a bunch mo=
re stuff added to it. Which I'd still like to do eventually and all, but f=
or the time being the plan has just been "make it work". CP/M 2.2 was the =
easiest/quickest way to reach that goal. And I still have some fiddling to=
do.<br><br><br>So yeah, a lot of blabbing just to mention a new font and C=
CP. But maybe folks are interested in the technical junk too. Either way,=
Zork fits on the screen fine now!
From: "FyberOptic" <fyberoptic@...>
Feb 2, 2010
e:
ork 1!
Thanks!
machine floating around (I found them
a couple of years back) that came
t-end. You might look for CP/M
en to have a .ASM file
They mostly let
here might be
You know, that'd be pr=
etty handy to have. One of the things I want to do to all of this is make =
it work on both modified and unmodified Mailstations. I'll detect if the h=
ardware mod is present, and if not, the CP/M system area will start at 0x40=
00 instead of 0x0000, and apps will load at 0x4100 rather than 0x0100. Of =
course, this means only apps compiled to run at that starting address will =
work. But if one has the original source to something, it makes it a lot e=
asier. Disassembling something and trying to find all the memory accesses =
to the system area is a huge chore. I've tried!
But yeah, I could compile=
a separate version of the Z-machine to run using the other start address, =
if I can find what you're talking about. Maybe for executables that use th=
e higher starting address I can use an .EXE extension, and write a custom c=
ommand processor (or modify this one) which knows to load them at the diffe=
rent location. That way unmodified .COM programs can launch at the traditi=
onal 0x0100, if one has the hardware for it.
And of course, recompiling wo=
uld also let me do your original point, to specify the display width depend=
ing on which font I want to use.
t 40 column machines (Apple II,
re to wrap, etc. The
p the column width,
that is easy to
mns.
Well, who knows where this copy of Zork even came from. It might hav=
e been for a specific machine. I've found lots of software during my diggi=
ng around which is computer-dependent, despite CP/M being so open-ended. A=
ll the different displays available was probably the biggest reason. Espec=
ially for computers which had graphical hardware rather than just character=
output.
I think this copy was probably suited to a 64 character-wide scre=
en. I would have had that with the 5x7 font I wanted to switch to, but now=
I'm up to 80 characters with this 4x6 font. That should be fine for any C=
P/M app!
o be working
ngine to a
vious blocking point, so somewhat easy to create test-cases for.
It's funn=
y you had that problem, because my very first problem after getting the ope=
ning screen was an issue when I input text. But I was using a clunky way o=
f dumping the .COM file into memory rather than properly loading it off the=
disk, and I think I as clipping the end of it off. Once I upgraded to usi=
ng BIOS commands to pull sectors off until EOF, it worked okay.
hing work. I can't wait to see a photograph of it running on the
rdware someday.
Thanks again. I'll be sure to take one!
From: "FyberOptic" <fyberoptic@...>
Feb 2, 2010
p@...> wrote:
???
Depends on the CP/M=
version. From what I understand, the CCP/BDOS/BIOS were one big clump in =
the system tracks before version 3, and all loaded into upper memory by the=
loader also on the system tracks. With version 3, the CCP became a .COM f=
ile. Though v3 also uses a stripped down BDOS and BIOS in the system track=
s, which it uses to then load the full versions off of the data area of the=
disk.
Even though I'm using v2.2 of the CCP now, I'm loading it off the d=
ata area of the disk rather than being part of the system tracks, though st=
ill placing it into an area below the BDOS. I originally decided on this m=
ethod because my BIOS was getting a bit pudgy from having to have the font =
data in it, not to mention all the code in general for handling the virtual=
text display and virtual disk which a normal CP/M system wouldn't have had=
(I think a normal BIOS was supposed to just be 2KB), and I didn't want to =
waste too much disk space with system tracks. I started out with 2 tracks =
(8KB), realized that wasn't enough, went to 3, then realized it would just =
make sense to use a full four for 16KB, giving me some growing room. I thi=
nk I might could cram it in there now though, especially since the new font=
I'm using takes less space.
sed to be the only
That's true. The t=
hing is though, there are tools used for actually creating/modifying a CP/M=
system. Tools which run on the system itself, already running that versio=
n of CP/M you're going to modify. I obviously didn't have that luxury, so =
I had to get by with modifying the BDOS and CCP assembly files to work with=
SDCC's AS-Z80 assembler. I'm linking the BDOS against the BIOS myself, al=
ong with my loader app in front of all of that. It seems to be fine, surpr=
isingly, aside from the CCP part. It works at boot, but doesn't work after=
the warm boot when an app exits, even though the same code is called. I h=
aven't been able to figure out why yet.
you think!
Let's hope!
& Zork, and
My original test involved lit=
erally dumping the zork.com directly off the dataflash and into memory and =
executing it. The BDOS and BIOS were already in place in upper memory thou=
gh via the OS loader app, and this file dumping was happening in the BIOS a=
s part of the startup, so it was practically the same as loading it off a d=
isk, even if a bit of a kludge. It was reading zork1.dat off the disk in a=
ny case.
After I saw that the disk routines were working, I went on to act=
ually loading zork1.com off of the disk using BDOS commands, reading 128 by=
tes at a time until I hit EOF, then executing 0x0100.
Now I'm still doing =
something similar at startup, except with CCP.COM, but loading it into high=
er memory underneath the BDOS. It's compiled to base at that address too, =
so I ought to name it like CCP.SYS now probably so that it can't be execute=
d from the command line.
I did originally make the CCP.COM load at 0x0100,=
but it was incapable of launching apps at that location, which is what pro=
mpted me to shift it upwards where it belongs for this version. CP/M 3's C=
CP loads at 0x0100 though, but loads apps via a resident loader module whic=
h it loads up high using the RSX functions in the v3 BDOS. The transient p=
ortion of the CCP then gets overwritten by the new app. I like this approa=
ch, and will probably use it if I ever write my own CCP. Though if I rewri=
te the BDOS too, I'll just write the app loading capability directly into t=
here via a custom function call.
ching was not one way,
=
e built in keyboard code.
at C000 to
u get a pretty big stack out of the deal, too!
My hardware mod can actuall=
y switch slot0000 back to codeflash by toggling P28.3 back to 0, but that w=
ould put the original interrupt code and everything back into place. I cou=
ld still get around it with the interrupt jump trick using the other interr=
upt mode, but as you mentioned, I'd have to waste some ram to do it. I onl=
y really wanted to have to use this method for people who won't have a hard=
ware mod, since it's such a kludge.
I wrote my own routine though which re=
ads any 256-byte dataflash sector into a buffer. I probably could have rip=
ped that function out of the Mailstation disassembly too, but I prefer to w=
rite as much of my own code as possible. I started rewriting the keyboard =
routines before, but debouncing and key repeat were giving me issues, so I =
ended up just going with the borrowed code so that I could move forward at =
the time. Not to mention, making the keyboard work again was fairly boring=
, to be honest. They're still separate and compatible object files though,=
I can just swap them in and out of the BIOS module, so maybe one day I can=
have all original code in the BIOS. The font I'm using is public domain n=
ow, too!
Speaking of switching banks though, I've considered it for some o=
f the larger functions (and the font, for example) into one of the other RA=
M pages, and just bank-switch it in when needed during BIOS calls. CP/M 3 =
supports bank-switching, even, but I don't have a full understanding of how=
it works yet. Not that I need v3 though to take advantage of such a thing=
if I wanted. But so far RAM hasn't been a problem for the things I've tri=
ed.
" area. I think there is even one or two "filenames"
lename is just a byte, from 0 to 0x2f.
your cp/m files coexist
That's the th=
ing, I knew that the Mailstation uses a file system of some kind in its OS,=
but I have no idea how it works. So I just avoided that whole area where =
it stores emails and things.
How much do you know about it? Like, where=
exactly in dataflash does it start, what format do the files/directory ent=
ries use, etc etc? Anything you've figured out might be useful for getting=
more usable space!
Eventually I also want to finish the code which would =
let me have a drive B which works across the parallel port cable to a serve=
r app on the PC side. That would let a person copy and move files onto the=
ir Mailstation flash disk via the OS. At least, once I actually implement =
disk writing, that is!
ot code, & cpm system
For that
could still use it as part of cpm's non-system tracks. An
ed to use the whole 16K, they just need to
=
I'm actually using a fair amount of the 16KB of system tracks for my OS loa=
der + BDOS + BIOS. The CCP I compiled is a little less than 2KB though, wh=
ich is smaller than I originally expected one to be, so I might be able to =
fit that into the system tracks too, which would save a bit of space on the=
data area of the disk.
I've thought of different ways of including a trad=
itional loader app. One is to include it in the OS loader, where maybe you=
hold a key when you launch the app in the Mailstation menu and it falls ba=
ck on that mode to let you load things on the parallel port like before. O=
r maybe putting a key combo you can press any time the OS is loaded. And t=
hen of course is the other method of just making it a .COM file on the disk=
. It's one of the next things on the list to do though so I'll figure some=
thing out.
e.html
that site?????
Well, considering that's where I downloaded most of the st=
uff from, I guess that means it's okay! I dunno. That's one reason I alwa=
ys like writing as much of my own code as possible, like with the BDOS. It=
'd perform the same interface functions for CP/M applications, but is still=
different on the inside. And be another member in the ocean of OS clones~=
!
I'll plead insan=
ity when they drag me away to jail. They'll surely believe it when they re=
alize I was rewriting a 30 year old operating system for a 10 year old devi=
ce.