Re: Help on a 1998 Award BIOS chip

[Curious Marc via cctalk]

Actually the TL866A universal programmer comes with a PLCC-32 adapter included 
for about $50, including slo-mo shipment from the other end of the world and 
the extra tariff for the Chinese steel that must be hiding in it. And probably 
sharing a ride in the same boat, I should get some W29C020P’s. Which might 
chooch or not, on account of them containing either real or fake chips. In the 
latter case I will only will have lost a few American rupees and I can leave a 
blistering negative comment to further sink the already alarmingly low rating 
of my seller before he switches identity. So odds are in my favor. All 
electro-magically transacted on ePay based on fuzzy pictures for the gullible 
and funny money from PayBuddy. Oh the miracles of your new world economy. 

Marc

 

From: cctalk  on behalf of 
"cctalk@classiccmp.org" 
Reply-To: geneb , "cctalk@classiccmp.org" 

Date: Tuesday, April 17, 2018 at 7:09 AM
To: "cctalk@classiccmp.org" 
Subject: Re: Help on a 1998 Award BIOS chip

 

On Mon, 16 Apr 2018, Curious Marc via cctalk wrote:

 

 

 

On Apr 16, 2018, at 6:31 PM, Chuck Guzis via cctalk  
wrote:

 

On 04/16/2018 06:11 PM, CuriousMarc via cctalk wrote:

And lifting the sticker reveals the BIOS chip is just a W29C020P-12, a

regular 256k x 8 Flash memory, 5V chip. Duh. Mystery solved. Of course way

newer and with many more address lines than my DataIO 29B can read and

program. Time has come to buy a small, modern, cheap, infinitely capable

Chinesium EEPROM programmer. Read: the kind of practical, affordable,

sensical and useful equipment I usually steer away from. Ebay here I come.

Or make a programmer with an Arduino, since it's 5V.

 

Hmmm, you don't happen to be a subscriber to AvE's Youtube channel, perhaps?

 

--Chuck

 

Why... Would that be good or would that be bad?

Keep your disk in a vice!

:-)

Marc

 

Just make sure that the programmer you get chooches properly. ;)

 

g.

 

-- 

Proud owner of F-15C 80-0007

http://www.f15sim.com - The only one of its kind.

http://www.diy-cockpits.org/coll - Go Collimated or Go Home.

Some people collect things for a hobby.  Geeks collect hobbies.

 

ScarletDME - The red hot Data Management Environment

A Multi-Value database for the masses, not the classes.

http://scarlet.deltasoft.com - Get it _today_!

 

Re: Scanned paperback book "RSX A User's Guide"

[Al Kossow via cctalk]

On 4/16/18 7:54 PM, Mark Matlock via cctech wrote:

>I’d like to make it available online

it is online now

http://bitsavers.org/pdf/dec/pdp11/rsx11/Pieper_RSX_A_Guide_For_Users_1987.pdf

Re: Scanned paperback book "RSX A User's Guide"

[Jason T via cctalk]

On Wed, Apr 18, 2018 at 12:04 PM, Al Kossow via cctech
 wrote:
> it is online now
>
> http://bitsavers.org/pdf/dec/pdp11/rsx11/Pieper_RSX_A_Guide_For_Users_1987.pdf

D'oh - I was already working on trimming up Mark's copy and OCRing it.
I got the cover scans from him as well.  My document is here:

http://chiclassiccomp.org/docs/index.php?dir=%2Fbooks%2FComputing/OperatingSystems

-j

One wafer-thin mint (VAX 4000-200 for sale)

[Bill Degnan via cctalk]

The VAX 4000-200 I exhibited two years ago at VCF East is up for sale:

Restoration Notes:
http://www.vintagecomputer.net/browse_thread.cfm?id=608

I don't need it as much anymore now that it's pretty much a completed
project.  It's very upgrade-able though if you have the desire to boost
performance and ports, etc.

The provenance of this machine, I believe, was as part of WVLink a West
Virginia email/gopher/USNET type ISP server in the early-mid 1990's.

I have it set up for telnet communications if interested.  Contact me via
http://www.vintagecomputer.net/contact.cfm

Bill

RE: Scanned paperback book "RSX A User's Guide"

[Kevin Lee via cctalk]

Thanks for this great contribution.. it really gives me a heads up 
To rsx that I might need in the coming months.

Cheers


-Original Message-
From: cctech  On Behalf Of Al Kossow via cctech
Sent: Wednesday, 18 April 2018 19:05
To: cct...@classiccmp.org
Subject: Re: Scanned paperback book "RSX A User's Guide"



On 4/16/18 7:54 PM, Mark Matlock via cctech wrote:

>I’d like to make it available online

it is online now

http://bitsavers.org/pdf/dec/pdp11/rsx11/Pieper_RSX_A_Guide_For_Users_1987.pdf

Re: 8085 Dissasembly?

[Mark J. Blair via cctalk]

> On Apr 18, 2018, at 2:50 AM, Torfinn Ingolfsen via cctech 
>  wrote:
> 
> Since it has not been mentioned yet: NF6X's dismantler supports the
> 8085 (and a couple of other CPUs): https://github.com/NF6X/dismantler
> It is written in Python, so it should run on any platform where Python
> is available. From the description "semiautomatic code recognition"
> and "allows binary files to be disassembled from the command line".

My main motivation for writing dismantler was that I was intrigued by 
recursive-descent disassemblers such as IDA (which I had seen in use in videos, 
blog posts and presentations), but didn't want to pay for IDA at the time. I've 
recently purchased IDA Starter, so I may not use my own disassembler any more 
for future reverse engineering projects. Dismantler is a pale shadow of IDA, 
but it's still a big improvement over the simple disassemblers I've used in 
previous reverse engineering projects.

Some of the future reverse engineering projects I have on my to-do list involve 
the CDP1802 processor, which IDA presently doesn't support. When I get to them 
I'll have to decide whether to use dismantler vs. learning how to add CDP1802 
support to IDA. I'm leaning towards the latter, because IDA is so much fancier 
than dismantler is.

-- 
Mark J. Blair, NF6X 
http://www.nf6x.net/

Re: Int 13h buffer 64k boundaries

[Chuck Guzis via cctalk]

Really?  64K boundary issues cropping up in MS-DOS?

Egad, that would have been known in DOS 1.0.  Certainly, for anyone
writing his/her own low-level disk I/O, it was obvious.

Now, I'll add that if you wrote your own specialized device driver, DOS
did not guarantee handing your driver a buffer that obeyed the 64K
boundary rule.  I suspect that some DOS errors were reported to MS
because of third-party driver bugs.

And if you wrote a low-level driver that used 16-bit I/O, the magic
number was 128K.

But even in the earlies DOS 2.0 device drivers that I wrote, I included
code to split the transfer up to get around the 64K problem if needed.

--Chuck

Re: Int 13h buffer 64k boundaries

[Chuck Guzis via cctalk]

On 04/18/2018 09:20 PM, Fred Cisin via cctalk wrote:
>>> I always found it amusing that many programs (even FORMAT!) would fail
>>> with the wrong error message if their internal DMA buffers happened to
>>> straddle a 64K block boundary.  THAT was a direct result of failure to
>>> adequately integrate, or at least ERROR-CHECK!, the segment-offset
>>> kludge
>>> bag.  Different device drivers and TSRs could affect at 16 byte
>>> intervals
>>> where the segment of a program ended up loading.
>>> It was NOT hard to normalize the Segment:Offset address and MOVE the
>>> buffer to another location if it happened to be straddling.
> 
> On Wed, 18 Apr 2018, Charles Anthony wrote:
>> Huh. I would guess that this is the source of a DOS bug that I found back
>> in the day, reported to MS, and never heard back.
>> . . . A buffer boundary straddling error certainly sounds like the
>> issue I was
>> seeing; it feels very odd to see a plausible explanation 35 years later.
> 
> I'm learning a lot these days that would have been handy back then!
> 
> Segment:Offset hides it until you normalize the resulting address.
> IIRC, INT13h should return a code of 09h if the DMA straddles a 64K
> boundary.
> But, not all code checks for that, or knows what to do when it happens.
> Looking at the value of ES:BX? can work, or, if it happens, swap your
> DMA buffer with one that is not used for DMA (and doesn't happen to be
> 64K away :-)  In my code, I happened to have buffers for several
> purposes, so that was easy to do.
> If operating above Int 13H (DOS calls), then you are dependent on DOS
> error checking.  "Can you trust THAT?"
> If operating below Int 13h, then be careful where your DMA ends up, work
> without DMA, or simply watch for occurrence.
> 
> And, of course, a lot of C code can't tell the difference between end of
> file and a disk error.
> #define EOF (-1)    /* depending on implementation */
> while ((ptr2++ = fgetc(fp2)) != EOF); /* does not differentiate between
> error and end of file */ fgets() returns a null pointer for EITHER
> end-of-file OR error!
> and therefore assumes total reliability and any failure to read is
> assumed to be EOF.
> IFF available, feof(fp2) is much better.
> 
> 
> You certainly did the right thing, narrowing it down to load address. 
> The final conclusion would have been to systematically try many/all load
> addresses, and see whether it was consistent for given ones, and what
> the failing ones had in common.
> 
> Yes, the "solution" for the extraneous FORMAT failure was "add or remove
> TSRs and device drivers"!
> 
> When I first hit it, I used a P.O.S.T. card, and put in minimal code to
> output values until I realized that DS was the key, and that I had
> mishandled error #9.  Eventually I realized that even for code not my
> own, I needed to write a TSR intercepting Int 13H calls.
> (For exampole, the critical error handler in certain early versions of
> PC-Tools was more concerned with protecting their pretty display than
> success of writes!)
> 
> 
> Microsoft's response to error reporting was amusing.
> 
> I was in the Windows 3.10 Beta, and encountered the SMARTDRV write
> caching problem.  There was apparently a flaw on one of my drives, that
> neither SPINRITE nor SSTOR could find.  But, during Windoze
> installation, a write would fail, and with write caching ON (Windoze
> installation did NOT give you a choice), there was no way to recover
> from a write error!
> (SMARTDRV had already told SETUP that it had been successful, so now,
> when the error occured, there was no way to (I)gnore the error (figure
> out which file copy had failed, rename the failed copy "BADSECS", and go
> back later to copy that one manually).  All you could do was (R)etry
> which didn't work, or (A)bort, which cancelled the entire setup before
> it ever wrote the directory entries for the files that had worked. By
> loading a bunch of space filler files on the disk, I was able to get the
> installation to be in a working area.
> Once I finally determined WHERE the bad track was, I put in a filler
> file to keep it from being used.  (SPINRITE tried to return it to use
> when I just marked it as BAD!)
> 
> Microsoft's response was, "YOU have a HARDWARE problem.  NOT OUR PROBLEM."
> I was unable to either convince them that CORRECT response to a hardware
> problem was a responsibility of the OS, NOR that SMARTDRV with
> write-caching was going to cause a lot of data losses that they would
> get blamed for, inspite of it not be narrowed down to SMARTDRV, and that
> it would end up costing them a lot.
> 
> Sho'nuff, COMPRESSION got blamed for the data losses.
> 
> DOS 6.2x had to be put out for FREE to fix "the problems with compression".
> The "problems with compression" were fixed by having SMARTDRV NOT
> default to write caching ON, have SMARTDRV NOT rearrange writes for
> efficiency (it wasn't writing DIRectory sectors until later), and having
> SMARTDRV NOT returning a DOS prompt until its buffers 

Re: 8085 Dissasembly?

[Charles Anthony via cctalk]

On Tue, Apr 17, 2018 at 1:49 PM, Fred Cisin via cctalk <
cctalk@classiccmp.org> wrote:

>
>>>
> I always found it amusing that many programs (even FORMAT!) would fail
> with the wrong error message if their internal DMA buffers happened to
> straddle a 64K block boundary.  THAT was a direct result of failure to
> adequately integrate, or at least ERROR-CHECK!, the segment-offset kludge
> bag.  Different device drivers and TSRs could affect at 16 byte intervals
> where the segment of a program ended up loading.
> It was NOT hard to normalize the Segment:Offset address and MOVE the
> buffer to another location if it happened to be straddling.
>
>
Huh. I would guess that this is the source of a DOS bug that I found back
in the day, reported to MS, and never heard back.

Working on a large application, ground out a new release, got a call from
the production (the guy that ran the floppy duplicator) that his quality
control tests were failing -- the application on the floppies wouldn't
start. I grabbed one, it ran on my machine ok, wouldn't run on production's
test machine. Confiscated that machine and started swapping out hardware,
nothing helped. Tried adding tracing code to the application to see if I
could narrow down the failure point, but discovered that changing the
executable would change the behavior -- a heisenbug. Eventually worked that
the crash was related to the address that the executable was loaded at,
which was dependent on the various TSRs that were loaded -- with the
production test machine driver configuration, the load address would
reliably crash the application. If I adjusted the load address to match on
my machine, I would get the same crash.

To figure out what the crash was about, I ended up writing a small TSR that
set the "break on every instruction bit", and would push the PC and opcode
out the serial port, and collected the data streams for the crashing and
non-crashing configurations. Diffed the data streams to find where they
were diverging.

The application was large enough to have overlays -- as the program was
starting up, an overlay with run-once initialization code  would be read
from disk and jumped into; in the crash configuration, the overlay code
seemed not to be being read, or read incorrectly -- the first opcode in the
overlay was wrong.

Wrote a simple program that read a data file of the same size as the
overlay into different locations in memory and verified that the data was
read, demonstrating that DOS was failing for one buffer address but not
another, documented it, and send it off to MS and told management that the
bug was MS and there really wasn't anything we could do.

Never heard back from them, and have actively avoided MS software ever
since.

A buffer boundary straddling error certainly sounds like the issue I was
seeing; it feels very odd to see a plausible explanation 35 years later.

-- Charles

Re: Kaypro II keyboard fault / keyswitches wanted

[Jules Richardson via cctalk]

On 04/18/2018 06:01 PM, Jules Richardson via cctalk wrote:

However, the keyboard appears unresponsive. Pressing keys (with the
exception of caps-lock, the two shifts, and ctrl) results in a buzz/click
from within the keyboard - if I'm interpreting the schematics right, the
click is actually driven by the system in response to a keypress, which
suggests that my keyswitches are OK (I believe these use a foam disc
approach, which are prone to deterioration) and that keyboard data is being
received OK (at least on some low level).


And we're good. It was a simple cable fault. Turns out that while the 
system does have the ability to make noise by sending data out to the 
keyboard, the keyboard click noise is generated solely within the keyboard 
unit - so although my +5V and ground lines on the keyboard cable were fine, 
the data line was not, and nothing was ever getting through to the system.


I need to find a better replacement cable - the phone handset cord I'm 
using right now is too short - but at least the system seems healthy. Onto 
the cosmetics...


cheers

Jules

Re: Kaypro II keyboard fault / keyswitches wanted

[Randy Dawson via cctalk]

Here you go:


https://www.ebay.com/itm/Victor-9000-SIRIUS-1-Keyboard-repair-Foam-Pads-for-KeyTronic-Keyboards/121266887970?hash=item1c3c11dd22:g:HRYAAOSw91NTtPPK


[https://i.ebayimg.com/images/i/121266887970-0-1/s-l1000.jpg]

Victor 9000 / SIRIUS 1 Keyboard repair, Foam Pads for KeyTronic Keyboards | 
eBay
www.ebay.com
Besteht aus einem Schaumstoff Pad, dass nun nach rund dreißig Jahren sein 
Lebensende erreicht hat. Der Schaumstoff. Die Pads bestehen aus einem 
doppelseitig mit Klebefolie ausgestatteten Schaumstoff. | eBay!



You still have to add the Mylar foil to them.  I cut up some dollar store 
silver balloons.



From: cctalk  on behalf of Jim Brain via cctalk 

Sent: Wednesday, April 18, 2018 4:02 PM
To: cctalk@classiccmp.org
Subject: Re: Kaypro II keyboard fault / keyswitches wanted

On 4/18/2018 6:01 PM, Jules Richardson via cctalk wrote:
>
> Hey all,
>
> I snagged a Kaypro II a short while ago which I finally got around to
> looking at. After some minor TLC to the drives, it's booting.
>
> However, the keyboard appears unresponsive. Pressing keys (with the
> exception of caps-lock, the two shifts, and ctrl) results in a
> buzz/click from within the keyboard - if I'm interpreting the
> schematics right, the click is actually driven by the system in
> response to a keypress, which suggests that my keyswitches are OK (I
> believe these use a foam disc approach, which are prone to
> deterioration) and that keyboard data is being received OK (at least
> on some low level).
>
> Any suggestions for possible things to investigate? It doesn't feel
> like a memory fault, given that it's using 64kx1 ICs and booting as
> far as a prompt, but I suppose it's possible.
>
> On the back of this, I'm in need of three keyswitches, if anyone
> happens to have a parts machine and would be willing to sell any. A
> student of the machine's previous owner dropped the keyboard years ago
> and broke three of the keys off. I have the keycaps, but the switch
> stems are broken and it would probably be easier to replace the entire
> stem portions rather than attempting to glue things back together.
>
> cheers
>
> Jules

Can't help on the diag, but wanted to stay tuned in if keyswitches are
available.  Been hunting for a few for a few years.

Jim

--
Jim Brain
br...@jbrain.com
www.jbrain.com
The Brain Trust - Things Worth Mentioning
www.jbrain.com
Howdy. Welcome to The Brain Trust! Thanks for dropping by! Feel free to join 
the discussion by leaving comments, and stay updated by subscribing to the RSS 
feed.See ya around!

Re: Speed now & then

[ben via cctalk]

On 4/18/2018 4:47 PM, Eric Smith via cctalk wrote:

On Tue, Apr 17, 2018 at 8:18 PM, Fred Cisin via cctalk <
cctalk@classiccmp.org> wrote:


thousands of movies and TV episodes will fit on a 2TB drive.
I am anxiously awaiting higher capacity thin 2.5" SATA.



You can get an 8TB drive in 2.5" form factor, but it doesn't contain
spinning rust, and it costs around $6000.


At one time you could get a $39 aerial up and get free TV like
Dr Who.. Progress seems to be getting rind of the good old
and bringing in the $$$.
While I admit the new TV's are better res, I can not say much
about what is being broadcast today is better than back then.
Ben.
As for the BBC and other TV networks, we seem to be getting
a lot of high priced episodes that have like 3 shows per season
with a 2 part Christmas special mixed in with 90% reality TV.
Sigh.
BTW the hardest part on my latest computer design is having
a working front panel.

Re: Kaypro II keyboard fault / keyswitches wanted

[Jim Brain via cctalk]

On 4/18/2018 6:01 PM, Jules Richardson via cctalk wrote:


Hey all,

I snagged a Kaypro II a short while ago which I finally got around to 
looking at. After some minor TLC to the drives, it's booting.


However, the keyboard appears unresponsive. Pressing keys (with the 
exception of caps-lock, the two shifts, and ctrl) results in a 
buzz/click from within the keyboard - if I'm interpreting the 
schematics right, the click is actually driven by the system in 
response to a keypress, which suggests that my keyswitches are OK (I 
believe these use a foam disc approach, which are prone to 
deterioration) and that keyboard data is being received OK (at least 
on some low level).


Any suggestions for possible things to investigate? It doesn't feel 
like a memory fault, given that it's using 64kx1 ICs and booting as 
far as a prompt, but I suppose it's possible.


On the back of this, I'm in need of three keyswitches, if anyone 
happens to have a parts machine and would be willing to sell any. A 
student of the machine's previous owner dropped the keyboard years ago 
and broke three of the keys off. I have the keycaps, but the switch 
stems are broken and it would probably be easier to replace the entire 
stem portions rather than attempting to glue things back together.


cheers

Jules


Can't help on the diag, but wanted to stay tuned in if keyswitches are 
available.  Been hunting for a few for a few years.


Jim

--
Jim Brain
br...@jbrain.com
www.jbrain.com

Re: Speed now & then

[Eric Smith via cctalk]

On Tue, Apr 17, 2018 at 8:18 PM, Fred Cisin via cctalk <
cctalk@classiccmp.org> wrote:

> thousands of movies and TV episodes will fit on a 2TB drive.
> I am anxiously awaiting higher capacity thin 2.5" SATA.
>

You can get an 8TB drive in 2.5" form factor, but it doesn't contain
spinning rust, and it costs around $6000.

AlphaServer 300 4/266

[mark--- via cctalk]

Good condition AlphaServer 300, always been stored in dry conditions.
Photos: https://photos.app.goo.gl/5N66yIlEUCYkuh012

It has a TGA based DEC graphics card that will do 1280x1024 24 bit (it's a
ZLXp-E2 PBXGA-BA) - manual included.
Ultrawide 16-bit SCSI card
Brand new Seagate Cheetah 15K.4 36.7GB,Internal,15000RPM,3.5" (ST336754LW)
HDD
Ultraplex SCSI CDROM drive.

Running OpenVMS Alpha 8.3 with CDE. Can also run tru64 5.x.

All working as it should be. Very quiet system. Can provide copies of media
if required.

£175 + postage at cost.
I can supply an LK461 keyboard and mouse for an additional £25.

Datatronics battery powered 2400P modem

[mark--- via cctalk]

I have one of these, see the photos:
https://photos.app.goo.gl/CnLnSKTCzHETzpOo1

 

It was bought new by myself a few years back. It can run off a PP9 battery.

£10 shipped in the UK if anyone is interested.

 

Regards, Mark.

 

Re: 8085 Dissasembly?

[Torfinn Ingolfsen via cctalk]

For the simulator part, perhaps GNUSim8085 can be used:
https://gnusim8085.github.io/
Again, I have no personal experience with it (yet).


HTH
-- 
Regards,
Torfinn Ingolfsen