10 Nov
2007
10 Nov
'07
12:43 p.m.
That recent discussion on the CRC chip got me to thinking about something that
I hadn't thought of for some years now...
My Bigboard II has a bit of interesting code in the EPROM, that does a sort
of sanity check on itself. Some sort of a CRC algorithm (I'd have to dig out
the code for exact details, and have NO idea of where I'd find it at this
point).
This thing had six sockets altogether, only 24-pin, so I couldn't put any
bigger than a 2732 in them, and one of the nifty features in the code in
that one that came with it was that it'd check the _second_ socket the same
way. That way, if you had an appropriately-coded chip in there it'd just
hand off to it. Seems handy to me as a way to just get the darn thing to
boot a disk without you having to tell it to do so.
Unfortunately, I have *no* idea how one would make an eprom have the
appropriate CRC results. I suspect that one of the important details would
be the exact polynomial used to generate the CRC in the first place, and I
don't have that handy at the moment, have to figure out just where the heck
that is...
But any suggestions as to where I might research this further would be
appreciated.
For some reason, in spite of me having seen lots and lots of full-page ads in
Micro-Cornucopia and elsewhere during that time, I can find almost nothing
on the machine on the 'net these days. Which is a shame, as it's a nice
board, in a lot of ways...
--
Member of the toughest, meanest, deadliest, most unrelenting -- and
ablest -- form of life in this section of space, ?a critter that can
be killed but can't be tamed. ?--Robert A. Heinlein, "The Puppet Masters"
-
Information is more dangerous than cannon to a society ruled by lies. --James
M Dakin
10 Nov
10 Nov
1:58 p.m.
On 10 Nov 2007 at 12:43, Roy J. Tellason wrote:
My Bigboard II has a bit of interesting code in the
EPROM, that does a sort
of sanity check on itself. Some sort of a CRC algorithm (I'd have to dig out
the code for exact details, and have NO idea of where I'd find it at this
point).
Take a snapshot of the code and post it. I'll be happy to
disassemble it and tell you what's going on--particuarly if it's only
a 2732. It's got to be easier than disassembling a couple of
27256s...
Cheers,
Chuck
3:24 p.m.
On Saturday 10 November 2007 13:58, Chuck Guzis wrote:
On 10 Nov 2007 at 12:43, Roy J. Tellason wrote:
I will, if I can find it somewhere...
At this point the board is in a box, the PS is in storage, and I'd need to
rig something up with a terminal and PS to get at it, unless I can find a
listing somewhere. I have been poking around since I posted that and there's
a bit more on the 'net now than last time I looked, including some docs on
bitsavers, which I've downoaded, but that's more assembly instructions and
hardware info than code listings. That was linked from a wikipedia
page. :-)
Best I can remember, the code did a bunch of 16-bit math that seemed to
implement some kind of a polynomial (just a bit beyond me when I read it) and
ran this over the contents of the EPROM, looking for a zero result. I
guessed at that time that you'd have to put *something* into the EPROM to
give that result, but how to do so and get the right result wasn't something
my assembler skills were quite up to at the time. It'd vary depending on the
contents of the EPROM I suppose.
I ran across a box recently, too, that I'd been looking for for quite some
time. In it were several disks that a guy in Australia (!) had sent me, in
Kaypro single-sided format -- best I could deal with at that time since what
I had was only my Osborne Exec -- that listed a bunch of BIOS code and
alternate EPROM code, setting for example different frequencies for the
onboard video, something I'd probalby find useful if I wanted to use that
onboard stuff because the composite-input monitors I had at the time didn't
seem to be too happy with the default rate (of what, 18 KHz? Something like
that?)... At this point I don't have room to set up another monitor anyhow,
and would probably just use a serial cable and a terminal program on one of
these linux boxes instead, assuming I can find someplace to put the BBII in
the first place.
Just lookingat the picture in that file I retrieved makes me want to play with
that thing a bit. :-) I think, though, that instead of the 2 5.25"
drives I was originally intending to use with it (and which are buried
somewhere in storage at this point, I have no idea where), I'd like to
maybe have a go at interfacing a 3.5" drive to it. And maybe one of
the "smaller" (2G?) SCSI drives I have around here. Think that's possible?
--
Member of the toughest, meanest, deadliest, most unrelenting -- and
ablest -- form of life in this section of space, ?a critter that can
be killed but can't be tamed. ?--Robert A. Heinlein, "The Puppet Masters"
-
Information is more dangerous than cannon to a society ruled by lies. --James
M Dakin
My Bigboard II has a bit of interesting code in
the EPROM, that does a
sort of sanity check on itself. Some sort of a CRC algorithm (I'd have
to dig out the code for exact details, and have NO idea of where I'd
find it at this point).
Take a snapshot of the code and post it. I'll be happy to
disassemble it and tell you what's going on--particuarly if it's only
a 2732. It's got to be easier than disassembling a couple of
27256s... 
4:41 p.m.
From: rtellason at verizon.net
---snip---
Best I can remember, the code did a bunch of 16-bit math that seemed to
implement some kind of a polynomial (just a bit beyond me when I read it) and
ran this over the contents of the EPROM, looking for a zero result. I
---snip---
Hi
If it is a crc the math will just be xors with the polynomial
and a shift. Doing a crc is not that complicated. Finding
the correct polynomials is a little more complicated. Most
computer application use the same polynomial for 16 bit
but there are a few variations.
Dwight
_________________________________________________________________
Climb to the top of the charts!? Play Star Shuffle:? the word scramble challenge with star
power.
http://club.live.com/star_shuffle.aspx?icid=starshuffle_wlmailtextlink_oct
4:51 p.m.
On 10 Nov 2007 at 15:24, Roy J. Tellason wrote:
Just lookingat the picture in that file I retrieved
makes me want to play with
that thing a bit. :-) I think, though, that instead of the 2 5.25"
drives I was originally intending to use with it (and which are buried
somewhere in storage at this point, I have no idea where), I'd like to
maybe have a go at interfacing a 3.5" drive to it. And maybe one of
the "smaller" (2G?) SCSI drives I have around here. Think that's possible?
Certainly the SCSI drive is possible, given the interface on the BBII
(Doesn't have a SASI-ready interface or two already?) Not wide-SCSI,
but certainly 8-bit SCSI. Your biggest problem is how to deal with
2GB efficiently with CP/M-80.
3.5" floppy is easy, but a 3.5" PATA drive is more problematical,
given the 16-bit interface for data. Of course, one could throw away
half the data or even treat the drive as two units to accommodate 8-
bit transfers.
Best I can remember, the code did a bunch of 16-bit
math that
seemed to implement some kind of a polynomial (just a bit beyond me
when I read it) and ran this over the contents of the EPROM,
looking for a zero result.
Could even be XORing the contents with a LFSR. Hard to say without
seeing it.
Cheers,
Chuck
5:42 p.m.
On Saturday 10 November 2007 16:51, Chuck Guzis wrote:
Hopefully I'll either find that loose-leaf binder and it'll be in there or
I'll come across it out there somewhere on the 'net.
--
Member of the toughest, meanest, deadliest, most unrelenting -- and
ablest -- form of life in this section of space, ?a critter that can
be killed but can't be tamed. ?--Robert A. Heinlein, "The Puppet Masters"
-
Information is more dangerous than cannon to a society ruled by lies. --James
M Dakin
On 10 Nov 2007 at 15:24, Roy J. Tellason wrote:
There is indeed a "SASI port" on the board, and in fact one of the questions
I had when I put it together was whether that 220/330 terminator pack (a DIP)
which was connected to that port was supposed to get warm like that. :-) I
saw mention somewhere today about the possibility of _two_ SASI connections,
but attempting to follow that got me nowhere, there were references to
stuff that wasn't there any more.
Just lookingat the picture in that file I
retrieved makes me want to play
with that thing a bit. :-) I think, though, that instead of the 2
5.25" drives I was originally intending to use with it (and which are
buried somewhere in storage at this point, I have no idea where), I'd
like to maybe have a go at interfacing a 3.5" drive to it. And maybe one
of the "smaller" (2G?) SCSI drives I have around here. Think that's
possible?
Certainly the SCSI drive is possible, given the interface on the BBII
(Doesn't have a SASI-ready interface or two already?) Not wide-SCSI,
but certainly 8-bit SCSI. Your biggest problem is how to deal with 2GB
efficiently with CP/M-80.
Indeed. Assuming that I run CP/M-80, that is. This strikes me as a nice
opportunity to do some hacking, and to maybe start out with that but to end
up with something a little further along, given the constraints of the
hardware (address space, etc.). ZCPR has some nice ideas, for example,
but I'm not sure I like the way some of those things got implemented. Ah
well, first thing I need to do is figure out how I'm going to use it, stuff
it in a box with PS, and hook it up with a serial cable. Then go on from
there.
3.5" floppy is easy, but a 3.5" PATA drive
is more problematical,
given the 16-bit interface for data. Of course, one could throw away
half the data or even treat the drive as two units to accommodate 8-
bit transfers.
PATA? I do have some small number of older drives, but I think that the
smallest of those is probably 80MB or so, going on up to a gig or so and a
bunch in between. OTOH, those 2G SCSI drives I mention I have a whole
*bunch* of here.
Best I can
remember, the code did a bunch of 16-bit math that
seemed to implement some kind of a polynomial (just a bit beyond me
when I read it) and ran this over the contents of the EPROM,
looking for a zero result.
Could even be XORing the contents with a LFSR. Hard to say without
seeing it.
6:03 p.m.
On 10 Nov 2007 at 17:42, Roy J. Tellason wrote:
Hopefully I'll either find that loose-leaf binder
and it'll be in there or
I'll come across it out there somewhere on the 'net.
As Al's posted the image of the EPROM source, it's pretty obvious at
a glance that a CRC is used. Look for the routine "CRCGEN".
Cheers,
Chuck
7:40 p.m.
On 10 Nov 2007 at 17:42, Roy J. Tellason wrote:
Indeed. Assuming that I run CP/M-80, that is. This
strikes me as a nice
opportunity to do some hacking, and to maybe start out with that but to end
up with something a little further along, given the constraints of the
hardware (address space, etc.). ZCPR has some nice ideas, for example,
but I'm not sure I like the way some of those things got implemented. Ah
well, first thing I need to do is figure out how I'm going to use it, stuff
it in a box with PS, and hook it up with a serial cable. Then go on from
there.
Doesn't anyone hack into "Freecycle" giveaway TVs anymore for video
monitors? True, they're probably hot-chassis, but an optoisolator or
three will take care of that. My TV Typewriter used an old tube-type
Zenith portable TV for a couple of years until I glommed onto a real
monitor (some surplus Four-Phase units).
Cheers,
Chuck
8:22 p.m.
On Saturday 10 November 2007 19:40, Chuck Guzis wrote:
On 10 Nov 2007 at 17:42, Roy J. Tellason wrote:
It's been a *really* long time since I considered the idea of converting a tv
to a monitor... These days monitors are *not* a problem. :-) Back then,
I didn't have much in the way of monitors kicking around, and had not (yet)
heard of freecycle. We're talking over 15 years ago here.
Indeed. Assuming that I run CP/M-80, that is.
This strikes me as a
nice opportunity to do some hacking, and to maybe start out with that
but to end up with something a little further along, given the
constraints of the hardware (address space, etc.). ZCPR has some nice
ideas, for example, but I'm not sure I like the way some of those
things got implemented. Ah well, first thing I need to do is figure out
how I'm going to use it, stuff it in a box with PS, and hook it up with
a serial cable. Then go on from there.
Doesn't anyone hack into "Freecycle" giveaway TVs anymore for video
monitors? True, they're probably hot-chassis, but an
optoisolator or three will take
care of that. My TV Typewriter used an old tube-type Zenith portable TV for
a couple of years until I glommed onto a real monitor (some surplus
Four-Phase units).
I'm sure that as far as that goes I can manage something. It's figuring out
some of this other stuff that has me stalled for now. CRC? BIOS? Hooking
up 3.5" drives? A HD? We'll see how far I get...
--
Member of the toughest, meanest, deadliest, most unrelenting -- and
ablest -- form of life in this section of space, ?a critter that can
be killed but can't be tamed. ?--Robert A. Heinlein, "The Puppet Masters"
-
Information is more dangerous than cannon to a society ruled by lies. --James
M Dakin
11 Nov
11 Nov
1:37 p.m.
From: cclist at sydex.com
---snip---> >
Could even be XORing the contents with a LFSR. Hard to say without > seeing it. >
Hi
Of course, a CRC is just a special polynomial LFSR that has
a large field of zeros so that it cna be used for burst correction.
It seems the code is CRC. The code may just do a bit at a time
or may have a table lookup to do a byte at a time. I've even seen
nibble at a time.
If it were doing a real CRC, one could even locate a burst
of bit errors and fix the EPROM if one knew the polynomial
used.
To my knowledge, I don't know if any of the assemblers had
a CRC calculator built in. The final check number was most
likely calculated after the assembly and just added to the code.
If in the listing, this may have been a second pass through
the assembler.
Dwight
_________________________________________________________________
Windows Live Hotmail and Microsoft Office Outlook ? together at last. ?Get it now.
http://office.microsoft.com/en-us/outlook/HA102225181033.aspx?pid=CL1006269…
2:11 p.m.
On 11 Nov 2007 at 10:37, dwight elvey wrote:
To my knowledge, I don't know if any of the
assemblers had
a CRC calculator built in. The final check number was most
likely calculated after the assembly and just added to the code.
If in the listing, this may have been a second pass through
the assembler.
MAC certainly didn't have one. I assume that the last 2 bytes of the
ROM were the zero-CRC-makers. The "quick and dirty way" to get a
zero sum is to compuate the CRC for the first n-2 bytes of the size n
ROM, then iterate through the 65536 possible 16-bit combinations of
the "corrector" stopping when a zero CRC is hit. It shouldn't take
long, particularly if you're using an emulator on a modern PC.
You could also work out the reverse polynomial, but that sounds like
too much work for what probably will amount to a one-off deal.
Cheers,
Chuck
10 Nov
10 Nov
4:33 p.m.
From: rtellason at verizon.net
---snip---
Unfortunately, I have *no* idea how one would make an eprom have the
appropriate CRC results. I suspect that one of the important details would
be the exact polynomial used to generate the CRC in the first place, and I
don't have that handy at the moment, have to figure out just where the heck
that is...
But any suggestions as to where I might research this further would be
appreciated.
Hi
It is most likely a simple checksum and not a crc. Still, making a crc
come out to zero is not hard. It is about the same as a checksum resulting in zero.
If it was doing a 16 bit crc, it would need 2 bytes to be the check bits.
Still, most ROM checks that I've seen are simple checksums.
Dwight
_________________________________________________________________
Help yourself to FREE treats served up daily at the Messenger Caf?. Stop by today.
http://www.cafemessenger.com/info/info_sweetstuff2.html?ocid=TXT_TAGLM_OctW…
4:39 p.m.
dwight elvey wrote:
Hi
It is most likely a simple checksum and not a crc. Still, making a crc
come out to zero is not hard. It is about the same as a checksum resulting in zero.
If it was doing a 16 bit crc, it would need 2 bytes to be the check bits.
Still, most ROM checks that I've seen are simple checksums.
Dwight
Checksums have a problem when used to check prom space in that a common
error in function can just
misorder the bytes or location of the eproms in memory space, and a
checksum won't catch that.
CRC's can be constructed which will only work well if the bytes are in
the correct order thru the entire
space.
Jim
4:45 p.m.
From: jwstephens at msm.umr.edu
dwight elvey wrote:
Hi
This is true that a crc is better. It is just that most of the
code that I've seen is a simple checksum and not a crc.
If it were my code, I'd most likely us a crc.
Dwight
_________________________________________________________________
Windows Live Hotmail and Microsoft Office Outlook ? together at last. ?Get it now.
http://office.microsoft.com/en-us/outlook/HA102225181033.aspx?pid=CL1006269…
Hi
It is most likely a simple checksum and not a crc. Still, making a crc
come out to zero is not hard. It is about the same as a checksum resulting in zero.
If it was doing a 16 bit crc, it would need 2 bytes to be the check bits.
Still, most ROM checks that I've seen are simple checksums.
Dwight
Checksums have a problem when used to check prom space in that a common
error in function can just
misorder the bytes or location of the eproms in memory space, and a
checksum won't catch that.
CRC's can be constructed which will only work well if the bytes are in
the correct order thru the entire
space.
5:32 p.m.
On Saturday 10 November 2007 16:33, dwight elvey wrote:
Nope, it was definitely more complicated than that. I know it's been quite
some time since I saw that code, but they were doing all sorts of shifting
and adding and whatnot, and I distinctly recall "polynomial" (?) being
mentioned in there somewhere.
From:
rtellason at verizon.net
---snip---
Unfortunately, I have *no* idea how one would
make an eprom have the
appropriate CRC results. I suspect that one of the important details
would be the exact polynomial used to generate the CRC in the first
place, and I don't have that handy at the moment, have to figure out just
where the heck that is...
But any suggestions as to where I might research this further would be
appreciated.
Hi
It is most likely a simple checksum and not a crc. Still, making a crc come out to zero is not hard. It
is about the same as a
checksum resulting in zero. If it was doing a 16 bit crc, it would need 2
bytes to be the check bits.
Right. So you'd need some way to give the assembler instructions to look at
its own output? Or look at it, figure out the right value somehow (and how
I'm not at all clear about), and stuff that value in there at the end of
your code, then? This is where I got confused, I think.
--
Member of the toughest, meanest, deadliest, most unrelenting -- and
ablest -- form of life in this section of space, ?a critter that can
be killed but can't be tamed. ?--Robert A. Heinlein, "The Puppet Masters"
-
Information is more dangerous than cannon to a society ruled by lies. --James
M Dakin
6099
days inactive
6100
days old
14 comments
4 participants
participants (4)
-
cclist＠sydex.com -
dkelvey＠hotmail.com -
jwstephens＠msm.umr.edu -
rtellason＠verizon.net