>
>Subject: RE: Stack Depth requirements for CP/M 2.2 CBIOS
> From: "ROBO5.8" <robo58 at optonline.net>
> Date: Sat, 31 Jan 2009 07:54:55 -0500
> To: "'General Discussion: On-Topic Posts Only'" <cctech at classiccmp.org>
>
>Hi Chuck,
>
>Thanks for the reply.
>
>My IDE drive is about 2GB which is overkill and beyond the capacities of
>CP/M 2.2. So I'm only using 20MB of the drive for this project. My system
>uses Interrupts for Floppy but polling for the IDE.
Anything under 16drives of 8mb will fly (128mb) and not using the full
drive is not an issue.
>In the mid 70's and early 80's I did lots of CBIOS work and never ran into
>stack problems with CP/M. Maybe the code was simpler and I used fewer
>Calls, Pushes and Pop's.
>
>I am currently using a Private Stack for some of my CBIOS debug routines
>since they are more stack intensive.
>
>Did you find that you had to make any other changes to the
>Blocking/Deblocking code other than the recommended CP/M 2.2 patches for
>success?
I'dn look at drive selection and allocation vector (alloc) for a 8mb logical
drive that nees to be at least for 4kb allocation size should be at least
256bytes for each drive! You can make it smaller by making the allocation
chunks larger (8kb would only need 128bytes).
I've never had stack size issues for just disk IO but interrrupt handlers
yes always on creatign private stack. I generally develop the disk IO
with minimal polled IO to limit the number of things that can go wrong
and ones the disk IO is up then roll in the interrupt IO and added features.
Allison
>
>Thanks Robo
>
>
>-----Original Message-----
>From: cctech-bounces at classiccmp.org [mailto:cctech-bounces at classiccmp.org]
>On Behalf Of Chuck Guzis
>Sent: Friday, January 30, 2009 7:29 PM
>To: General Discussion: On-Topic and Off-Topic Posts
>Subject: Re: Stack Depth requirements for CP/M 2.2 CBIOS
>
>On 30 Jan 2009 at 19:08, ROBO5.8 wrote:
>
>> I have rewritten my old systems CP/M 2.2 CBIOS to add an IDE Drive.
>>
>> I've run into a problem that has me stumped. Everything works as long as
>I
>> don't try and copy or assemble a large Assembly file (>80KB).
>>
>> I will be going along fine and then out of nowhere I will see CP/M request
>> access to Drive "T". My debug info says SELDSK is requesting Drive
>0FF00h.
>>
>> I have added debug code to all the CBIOS routines so that they report what
>> they are doing to the console (slow but nice).
>>
>> I've gone through my code many times and tested each routine via an
>embedded
>> debug monitor. I believe I have added every CP/M 2.2 patch (1-6 and
>9)that
>> is specific to the CBIOS including those dealing with Blocking/Deblocking.
>
>What do you mean by "large"? I've run 2.2 with disks up to 20MB with
>no problems.
>
>CP/M's stack can't be depended upon for much space at all. Since my
>BIOS code was interrupt driven, every interrupt service routine
>started with a change to a private "system" stack. I recall having a
>lot of problems before doing that.
>
>Cheers,
>Chuck
>
>
>
>Subject: Re: Stack Depth requirements for CP/M 2.2 CBIOS
> From: "Chuck Guzis" <cclist at sydex.com>
> Date: Fri, 30 Jan 2009 16:28:52 -0800
> To: "General Discussion: On-Topic and Off-Topic Posts" <cctalk at classiccmp.org>
>
>On 30 Jan 2009 at 19:08, ROBO5.8 wrote:
>
>> I have rewritten my old systems CP/M 2.2 CBIOS to add an IDE Drive.
>>
>> I've run into a problem that has me stumped. Everything works as long as I
>> don't try and copy or assemble a large Assembly file (>80KB).
>>
>> I will be going along fine and then out of nowhere I will see CP/M request
>> access to Drive "T". My debug info says SELDSK is requesting Drive 0FF00h.
>>
>> I have added debug code to all the CBIOS routines so that they report what
>> they are doing to the console (slow but nice).
>>
>> I've gone through my code many times and tested each routine via an embedded
>> debug monitor. I believe I have added every CP/M 2.2 patch (1-6 and 9)that
>> is specific to the CBIOS including those dealing with Blocking/Deblocking.
>
>What do you mean by "large"? I've run 2.2 with disks up to 20MB with
>no problems.
I have many systems with a minimum of 10mb drives and one has a
two 32mb and the other has 45mb SCSI/ However partitions are
limited to 8Mb as its' CP/M2.2.
>CP/M's stack can't be depended upon for much space at all. Since my
>BIOS code was interrupt driven, every interrupt service routine
>started with a change to a private "system" stack. I recall having a
>lot of problems before doing that.
>
Nominally one should preserve the stack and have one locally for that reason.
Howeer if the BIOS is using the minimal IO drivers (no interrupts) the stack
should be fine. Hoever is acc to drive "T" says he either has more than 16
partitions or he is crushing drive select.
Allison
>Cheers,
>Chuck
>
>
A friend forwarded me this YouTube link today:
http://www.youtube.com/watch?v=5WCTn4FljUQ
It's a KRON Channel 4 news (San Francisco, CA) report from 1981 about
the San Francisco Examiner (and others) making themselves available
online via BBS. My favorite line: "Of the estimated two to three
thousand home computer owners in the Bay Area..." Ah, those were the
days!
I spy a Tandy TRS-80 Model I, a TRS-80 Color Computer! But I'm mainly
interested in the Space-Age looking terminals being used by the SF
Examiner staff in the video. They've got swooping, rounded corners,
white shells, and what looks like an integrated 9 or 10 inch green
phosphor display. Screenshot is here:
http://www.loomcom.com/misc/examiner_terminal.jpg
Anyone know what kind of terminal this is? I'd freaking LOVE to have
one of those on my desk.
-Seth
> There was
> also a 4115 that used a raster display instead of the vector display.
-
4115/4125 uses an x86 processor
At one time, I had the full set of manuals for the 4115, while the company
I was working for was trying to write an emulation for it. The service manual
in particular seems very hard to find now.
Date: Thu, 29 Jan 2009 09:07:20 -0600
From: John Foust <jfoust at threedee.com>
Subject: Re: Seeking reverse-engineers - Apple II VisiCalc
To: cctalk at classiccmp.org
Message-ID: <6.2.3.4.2.20090129085638.05e74420 at mail.threedee.com>
Content-Type: text/plain; charset="us-ascii"
At 01:00 PM 1/28/2009, Tim McNerney wrote:
> >I am looking for volunteers to help reverse-engineer and document Apple II VisiCalc.
> >I have three versions of the Apple II software. I know one of them still boots (1983?)
> >and have some confidence that the other two versions (1979 and 1981) work too.
> >I have been in contact with both Bob Frankston and Dan Bricklin.
> >Of course you ask, well then why do you need volunteers?
> >The answer is because no one can find the sources.
>
No matter how many times I hear stories like this, or lived through
stories like this, I still shake my head and can't understand how the
source code gets lost. All these corporations, all the lawsuits, all
the programmers, all the marketing money, and so often no one, NO ONE,
preserves arguably the most important bits.
- John
In the case of Personal Software, I believe Lotus bought them to reduce
competition,
not to preserve VisiCalc. At the time, people seldom think about the
historical significance
of source documents. The Intel 4004 schematics would have been lost if
it hadn't been for
some Intel engineer who realized they needed to be saved. True, there
are some engineers
who take stuff home and store it in their basement, but in the case of
the 4004, Federico
Faggin couldn't hold on to any schematics when he left Intel because he
was going off to
found Zilog and had to protect himself legally. The problem with
packrats is that, even
when you are unusually organized, like Bob Frankston, you still end up
with boxes that
are mis-labeled. Even Hewlett Packard has thrown out some important
engineering
documentation. When the calculator division moved from Santa Clara to
Corvalis,
the threw out dumpsters full of drawings on their very first RPN
calculator, the 9100.
--Tim
Date: Thu, 29 Jan 2009 11:08:15 -0800
From: Guy Sotomayor <ggs at shiresoft.com>
Oh, I completely understand how it happens (after having seen it
happen a few times). Typically all of the source for a project is
kept on a server(s) that run the SCM (source code management) system.
Yes, they are backed up but in many cases it's just a rotating backup
set (ie they get overwritten). When the project is EOL'd usually the
server(s) are either re-tasked (involving a complete re-install and
wipe) or scrapped (which involves wiping). The backups are usually
scrapped at that time as well. Almost no one does an archive of those
backups. If they do, then that's were to look because they are kept
in an off-site location for disaster recovery. In many cases the off-
site storage is mostly write-only (ie tapes/whatever go in but are
never asked for and not purged).
Most of this stuff gets "lost" because of apathy on the part of the
owners rather than malicious intent.
TTFN - Guy
People have always been sloppy about old backups.
Even companies like Thinking Machines, who were
careful and kept off-site backups using Iron Mountain, or
somesuch, when the company went out of business, all these
tapes ended up in a dumpster. (I know this for a fact).
--Tim
P.S. Back in the 70's version control systems were rare.
Personal Software's backups were done on floppies.
I have acquired a GRiD 1109 laptop from 1983(?), but the screen mostly shows only every-other scan line.
Schematics may help, but I haven't found any.
Does anyone have a screen (or more) to donate?
Thanks-
Steve.
P.S. The 1109 circuit boards are different than those of the 1101.
Anyone know the differences between the two?
From: "Jeff Walther" <trag at io.com>
Subject: Re: Seeking reverse-engineers - Apple II VisiCalc
What I find particularly irritating, is that the loss of the source code,
arguably, defeats the implicit reason that copyright and patent protection
exists in the first place. The U.S. constitution states:
"To promote the progress of science and useful arts, by securing for
limited times to authors and inventors the exclusive right to their
respective writings and discoveries;"
Now one could argue that securing the exclusive rights promotes progress
all by itself. But the fact that it is meant to be for a limited time,
implies to me that at some point the full benefit of that advancement
should become available to everybody. If no copy of the source code is
required to be filed with the government, then the copyright and/or patent
laws are not securing the benefits of that progress for society at the end
of the exclusive period.
Patents have become similarly lame. Chips get patented with no
description language at any level required to be filed. Sigh.
Bad congress. Bad bad congress. No cookie.
Jeff Walther
I don't think it ever occurred to our founding fathers that "authors"
would copyright something with no intent of ever publishing it. Or, in
the case of software, publishing the binaries, but not the sources.
Even the pre-1976 requirement of copyright registration was perverted in
the case of software. The Copyright Office allows you to submit only a
fraction of what was being copyrighted, and you can block out parts that
you consider trade secrets. So much for the public good.
--Tim
> I guess people aren't really collecting Apollo workstation stuff.
DN3xxx et. al. are just coming out of the bottom of the bathtub curve.
Same with VME Sun 3 and 4.
Most of the mid-80's workstations have been recycled now.
There is also the little problem of software for them, if you don't want
to run NetBSD.
To be honest, the first lot with the disk controller and network card
were of more use than the memory and video card.
Keeping Apollo gear going is going to be tricky. At least the Sun 3 hardware
docs have mostly leaked out. I've heard of very little detailed Apollo HW
info out there. A couple of years ago, I was trying to get the guy who was
working adding more driver support to BSD to get the info he had reverse
engineered, but didn't get anywhere.
I've been in contact with the person responsible for Apollo product support
at HP about what hardware info they got for the machines, and it doesn't sound
like much made it out there from the east coast.
Similar things happened when HP took over the 68k-based 1500 product line from
TI.