25 Nov
2018
25 Nov
'18
6:32 p.m.
Firstly, my goal: to run MazeWar on something other than a NeXT.
I thought this would be fairly straightforward, starting with getting SunOS
4.1.3 booting with QEMU. Turns out, I've not had much luck. I get different
error messages depending on what machine type I'm emulating. I can start
booting from the .iso running this command:
$ qemu-system-sparc -bios ss5.bin -M SS-5 -m 64M -drive
file=sunos413.img,if=scsi,bus=0,unit=3,media=disk -drive
file=SunOS_4.1.3_sparc.iso,format=raw,if=scsi,bus=0,unit=6,media=cdrom,readonly=on
-boot d
and get a near immediate panic:
machine type 0x80 in NVRAM
panic: No known machine types configured in!
Data Access Exception
ok
Okay, how about trying the default BIOS and SS-20? It definitely gets
further, but no dice...
Boot: vmunix
Size: 843776+2315672+64016 bytes
SuperSPARC/SuperCache: PAC ENABLED
SunOS Release 4.1.3 (MUNIX) #3: Mon Jul 27 16:47:33 PDT 1992
Copyright (c) 1983-1992, Sun Microsystems, Inc.
cpu = SUNW,SPARCstation-20
mod0 = TI,TMS390Z55 (mid = 8)
mem = 49020K (0x2fdf000)
avail mem = 44707840
Ethernet address = 52:54:0:12:34:56
espdma0 at SBus slot f 0x400000
esp0 at SBus slot f 0x800000 pri 4 (onboard)
sd2: non-CCS device found at target 2 lun 0 on esp0
sd2 at esp0 target 2 lun 0
sd2: <QEMU 0 blocks>
sd2: Vendor 'QEMU', product 'QEMU', (unknown capacity)
sd3: non-CCS device found at target 0 lun 0 on esp0
sd3 at esp0 target 0 lun 0
sd3: corrupt label - wrong magic number
sd3: Vendor 'QEMU', product 'QEMU', (unknown capacity)
ledma0 at SBus slot f 0x400010
le0 at SBus slot f 0xc00000 pri 6 (onboard)
zs0 at obio 0x100000 pri 12 (onboard)
zs1 at obio 0x0 pri 12 (onboard)
SUNW,fdtwo0 at obio 0x700000 pri 11 (onboard)
BAD TRAP: cpu=0 type=29 rp=f00daba4 addr=0 mmu_fsr=0 rw=0
MMU sfsr=0: No Error
regs at f00daba4:
psr=40400cc7 pc=f00a0968 npc=f00a096c
y: 20000 g1: f00c1e78 g2: 40900ce6 g3: fb005ff0
g4: 2c g5: f00db000 g6: 0 g7: 30000000
o0: 1 o1: 8 o2: f00dac00 o3: f0076e50
o4: 0 o5: 0 sp: f00dabf0 ra: f1000000
(unknown): bad trap = 41
rp=0xf00daba4, pc=0xf00a0968, sp=0xf00dabf0, psr=0x40400cc7, context=0x0
g1-g7: f00c1e78, 40900ce6, fb005ff0, 2c, f00db000, 0, 30000000
Begin traceback... sp = f00dabf0
Called from f00c1eb8, fp=f00dac58, args=ff009000 f00dacbc 0 f0314a70 1000
1000
Called from f00a7d34, fp=f00dacc0, args=ff009000 0 ff009000 fb002098
f0314a70 ff009000
Called from f00a7708, fp=f00dad20, args=1080000 d f0102d50 f0102db3 0 2
Called from f00a74e0, fp=f00dad80, args=f0305bd4 f0102d50 fb001000 fb001050
0 0
Called from f00a5028, fp=f00dade0, args=f00fc000 fefe0014 0 0 f0102d50
f0305bd4
Called from f00ac084, fp=f00dae40, args=72 1000 1 1 86 800000
Called from f0015f7c, fp=f00daef8, args=800000 100000 fb000000 2fdd 2000 2
Called from f000539c, fp=f00daf58, args=f00dafb4 f00076c0 10801522 821020ff
200 f00ce600
Called from 403f0c, fp=0, args=4000 3ffd60 1 235598 4000 0
End traceback...
panic: trap
rebooting...
Then I thought, why not use The Machine Emulator to emulate a Sun 3 and
play with something even older? I can't get that to build using clang under
OS X 10.9. I've changed a few lines of source already to get it further
along in the compilation process, but now I'm stuck:
In file included from module.c:48:0:
module.c: In function 'tme_module_init':
module.c:93:3: error: 'lt_preloaded_symbols' undeclared (first use in this
function); did you mean 'lt_dlloader_remove'?
LTDL_SET_PRELOADED_SYMBOLS();
^
Okay, now I'm tired of trying to emulate it (actually, I still would like
to play with QEMU or TME...), so I pulled a SS-20 off the shelf and threw a
SCSI2SD card in it. I didn't have a means of burning a CD, so I used the
SCSI2SD to also emulate a CDROM drive at device 6, and unplugged the
existing CDROM drive. I can boot off of it just fine, and I get now even
further along the process of installation, and am able to format the hard
drive. Right when I think things are going well, I get this:
esp0: Target 6.0 reverting to async. mode
sr0: SCSI transport failed: reason 'data_ovr': giving up
m partition number 3
fastread: can't read label on /dev/rsr0:I/O error
ERROR while loading miniroot disk: /dev/rsd0b
#
Any ideas?
Thanks,
Kyle
25 Nov
25 Nov
6:46 p.m.
Well, got the last problem solved rather quickly: I tried using 512 byte
sectors for the emulated CDROM instead of SCSI2SD's default of 2048 for a
CDROM, and that did the trick. Working my way through the SunOS 4.1.3
installation process now on the SS-20.
If anyone has some advice on how to get QEMU or
TME working, I'd still be
all ears.
Thanks,
Kyle
7:14 p.m.
Well, got the last problem solved rather quickly: I
tried using 512 byte
sectors for the emulated CDROM instead of SCSI2SD's default of 2048 for a
CDROM, and that did the trick. Working my way through the SunOS 4.1.3
installation process now on the SS-20.
Was just thinking the 512 byte thing might be an issue. Early Toshiba
Cd-ROMs had a solder jumper that would switch this, and is was needed for
some early systems. SGI Indigo R3000 and below was one, and I guess Sun
was another. I think NeXT also requires the 512 byte block CD-ROM.
Since you said QEMU, you are emulating this? If on the real hardware, is
the NVRAM memory dead? Looks like it doesn't know what kind of hardware it
is. Real hardware will loose nvram battery and need to be replaced and
reprogrammed, or you can file it down and jumper a battery into it.
There is also probably a bunch of environment variables in the NVRAM as to
the CD-ROM SCSI path and OS scsi path and stuff on the Sun. It's been a
long time since Sun boxes for me, so unfortuantely I've forgotten a lot of
it. But if it's all reset or non-existant it could be a source of issues
if my memory is right (It definitely is on SGI hardware.)
--
: Ethan O'Toole
7:39 p.m.
On Sun, Nov 25, 2018 at 9:14 PM <ethan at 757.org> wrote:
Since you said QEMU, you are emulating this? If on the
real hardware, is
the NVRAM memory dead? Looks like it doesn't know what kind of hardware it
is. Real hardware will loose nvram battery and need to
be replaced and
reprogrammed, or you can file it down and jumper a battery into it.
I was hoping to just emulate it for now to avoid potentially bad hardware,
but seems like I need to use the real hardware to avoid potentially bad
software! :)
The NVRAM is totally dead; I've been reloading the IDPROM contents each
time. I've already ordered replacement NVRAMs from China; we'll see how
they do. Otherwise, I'll be going with the filing/coin cell trick.
There is also probably a bunch of environment variables in the NVRAM as to
the CD-ROM SCSI path and OS scsi path and stuff on the
Sun. It's been a
long time since Sun boxes for me, so unfortuantely I've forgotten a lot of
it. But if it's all reset or non-existant it could be a source of issues
if my memory is right (It definitely is on SGI hardware.)
Not sure; but, I can say, I've got SunOS 4.1.3 finally installed, and am
now looking at a sparse SunView desktop.
Trying to build MazeWar results in:
ld: Undefined symbol
___bb_init_func
DREG_SEG
*** Error code 2
Not sure yet what to look for, but the source does say it was tested on
SunOS 3.1 and 3.4. So, I am trying to compile it on something a bit later.
Thanks,
Kyle
7:49 p.m.
I was hoping to just emulate it for now to avoid
potentially bad hardware,
but seems like I need to use the real hardware to avoid potentially bad
software! :)
Ah cool. I was at a friend's brother's house on a work trip out to Silicon
Valley. One of his friends was there, with something amazing running in
QEMU. It was a work in progress, but he said that there were a lot of
issues because QEMU was too accurate in emulating the MIPS procressors and
in addition to this, there was bugs in his former employer's hardware that
had software work-arounds in the real OS. So when trying to run that OS on
the emulated system the accuracy worked against him.
The NVRAM is totally dead; I've been reloading the
IDPROM contents each
time. I've already ordered replacement NVRAMs from China; we'll see how
they do. Otherwise, I'll be going with the filing/coin cell trick.
Interesting. Are they no longer made? I should get one for my Voyager.
Not sure; but, I can say, I've got SunOS 4.1.3
finally installed, and am
now looking at a sparse SunView desktop.
Very cool
Trying to build MazeWar results in:
ld: Undefined symbol
___bb_init_func
DREG_SEG
*** Error code 2
Not sure yet what to look for, but the source does say it was tested on
SunOS 3.1 and 3.4. So, I am trying to compile it on something a bit later.
Sun compiler I assume and not a GCC?
--
: Ethan O'Toole
8:30 p.m.
On 11/25/18 7:49 PM, Ethan via cctalk wrote:
They are still made. I usually get M48T08s or M48T18s from Mouser.
In the long run, it is probably a good idea to mod the IDPROM to use an
external, replaceable battery, Glitch Works makes a board that one can
solder on to do that
(https://www.tindie.com/products/glitchwrks/gw-48t08-1-repair-board-module/).
alan
The NVRAM is totally dead; I've been
reloading the IDPROM contents each
time. I've already ordered replacement NVRAMs from China; we'll see how
they do. Otherwise, I'll be going with the filing/coin cell trick.
Interesting. Are they no longer made? I should get one for my Voyager.
26 Nov
26 Nov
2:08 p.m.
They're still made, but the new ones don't always work in place of the old
ones -- not 100% anyway. It's been my experience that, on sun4c and sun4m,
new 48T02s and 48T08s aren't 100% compatible. I've mentioned others'
suggestions on what the differences are in my Tindie listings, and on the
writeup on my site. That's why I designed the rebuild modules I've got
available, I had around 50 48T02s to process! Writeup here:
http://www.glitchwrks.com/2017/08/01/gw-48t02-1
(it's for the 48T02, but the process is the same...just the GW-48T08-1 is a
little longer)
The "not 100% compatible" symptom is that the clock fails power-on
diagnostics, and some machines will drop to OpenBoot/firmware monitor
prompt when that happens. NVRAM settings will be retained, but the clock
may or may not run, and some machines won't auto-boot.
I don't have any spare modules to rebuild, so I don't have premade
replacements up at the moment. I've been rebuilding them for people when
they send in their dead modules, but I'd guess most people here can do the
rebuild themselves, time permitting. I wouldn't cut into the encapsulation
with a powered tool like a Dremel, unless you're going to wear a face mask.
I use a hacksaw with Lenox fine kerf blades. Any blade will do if you're
only rebuilding a few NVRAMs.
Thanks,
Jonathan
On Sun, Nov 25, 2018 at 11:30 PM Alan Perry via cctalk <
cctalk at classiccmp.org> wrote:
On 11/25/18 7:49 PM, Ethan via cctalk wrote:
They are still made. I usually get M48T08s or M48T18s from Mouser.
In the long run, it is probably a good idea to mod the IDPROM to use an
external, replaceable battery, Glitch Works makes a board that one can
solder on to do that
(
https://www.tindie.com/products/glitchwrks/gw-48t08-1-repair-board-module/
).
alan
The NVRAM is totally dead; I've been
reloading the IDPROM contents each
time. I've already ordered replacement NVRAMs from China; we'll see how
they do. Otherwise, I'll be going with the filing/coin cell trick.
Interesting. Are they no longer made? I should get one for my Voyager.
2:20 p.m.
On 11/26/18 2:08 PM, systems_glitch wrote:
I don't have any spare modules to rebuild, so I don't have premade
replacements up at the moment. I've been rebuilding them for people
when they send in their dead modules, but I'd guess most people here
can do the rebuild themselves, time permitting. I wouldn't cut into
the encapsulation with a powered tool like a Dremel, unless you're
going to wear a face mask. I use a hacksaw with Lenox fine kerf
blades. Any blade will do if you're only rebuilding a few NVRAMs.
Don't have any spare modules? What happened to the half dozen that I
sent you? :)
alan
P.S. Out of my dozen Sun systems, almost all of them are using new IDPROMs.
2:35 p.m.
Don't have any spare modules? What happened to the
half dozen that I sent
you? :)
In the queue somewhere! They'll likely go to replace the modules I'd stolen
from other machines over the years, as I get around to
fixing them.
Also, to anyone buying NVRAMs on eBay, don't expect anything from China to
actually be new NVRAMs. I've bought a bunch to disassemble, in the course
of making repair boards for a number of different NVRAMs/RTCs, and every
single one has been a relabel. All had low battery voltages, on the few
where I actually totally destroyed the encapsulation to examine the
innards, the batteries often carried dates 10+ years old, even though the
outside markings suggested it was a year or two old. Not that fakes/remarks
from China should be a surprise.
Thanks,
Jonathan
On Mon, Nov 26, 2018 at 5:20 PM Alan Perry via cctalk <cctalk at classiccmp.org>
wrote:
On 11/26/18 2:08 PM, systems_glitch wrote:
I don't have any spare modules to rebuild, so I don't have premade
replacements up at the moment. I've been rebuilding them for people
when they send in their dead modules, but I'd guess most people here
can do the rebuild themselves, time permitting. I wouldn't cut into
the encapsulation with a powered tool like a Dremel, unless you're
going to wear a face mask. I use a hacksaw with Lenox fine kerf
blades. Any blade will do if you're only rebuilding a few NVRAMs.
Don't have any spare modules? What happened to the half dozen that I
sent you? :)
alan
P.S. Out of my dozen Sun systems, almost all of them are using new IDPROMs.
2:42 p.m.
I'm not sure, I don't personally see it as something worthwhile to
investigate when you can just rebuild the old NVRAMs. Even if you do use a
SNAPHAT type replacement, you're still stuck with proprietary batteries
that will one day no longer be made, versus an extremely common CR1225
cell. I've made total replacements for NVRAMs that are not easily rebuilt,
such as the Dallas DS1244:
http://www.glitchwrks.com/2018/03/17/gw-1244-1
But, that's a lot more effort and expense than just sawing the top off a
dead 48T02, gluing on one of my repair boards, and soldering the leads :P
Thanks,
Jonathan
On Mon, Nov 26, 2018 at 5:40 PM <ethan at 757.org> wrote:
Also, to
anyone buying NVRAMs on eBay, don't expect anything from China
to
actually be new NVRAMs. I've bought a bunch
to disassemble, in the course
Are any of the SMD NVRAMs with the battery caps compatible? Throw them on
a DIP to SOIC PCB?
- Ethan
--
: Ethan O'Toole
4:03 p.m.
On 11/26/18 2:42 PM, systems_glitch via cctalk wrote:
I'm not sure, I don't personally see it as
something worthwhile to
investigate when you can just rebuild the old NVRAMs.
What is the best way to decap 28 pin parts? 24-pin ones come apart pretty
easily but they don't leave a gap on the 28 pin ones.
27 Nov
27 Nov
4:33 a.m.
For fully potted parts like the 48T59, I make four cuts along the sides of
the encapsulation, on the short ends I cut until I hit metal (pins coming
up from the IC to the crystal/battery). On the long ends I just cut deep
enough to get through the pot shell and into the potting compound a little.
Then I put a small chisel or large screwdriver in one of the cuts on the
short ends, and strike it with a small ball peen hammer. This will usually
split the encapsulation right off, but sometimes you have to flip it over
and do the same on the other short end.
I probably need to do a writeup on fully potted parts, like the 48T59 and
DS1287.
Thanks,
Jonathan
On Tue, Nov 27, 2018 at 6:52 AM Al Kossow via cctalk <cctalk at classiccmp.org>
wrote:
On 11/26/18 2:42 PM, systems_glitch via cctalk wrote:
I'm not sure, I don't personally see it
as something worthwhile to
investigate when you can just rebuild the old NVRAMs.
What is the best way to decap 28 pin parts? 24-pin ones come apart pretty
easily but they don't leave a gap on the 28 pin ones.
1 Dec
1 Dec
2:47 p.m.
On Tue, 27 Nov 2018, systems_glitch via cctalk wrote:
I probably need to do a writeup on fully potted parts,
like the 48T59 and
DS1287.
See a photo documentary here:
<ftp://ftp.linux-mips.org/pub/linux/mips/people/macro/ds1287/> for my
proposal of a DS1287 rework.
I actually had a nasty surprise trying to rework a DS1287A, with a date
code indicating a clearly faked marking. After removing the integrated
coin cell the marking on the embedded IC revealed showed it wasn't even a
DS1287A originally as the IC was a DS12B885. This is a part I haven't
heard of existing, so I enquired Maxim, but they had no clue about it. I
suspect the DS12B885 was the core of the DS12B887 (wired differently from
both DS12887 and DS12887A), and the DS12B885 has never been marketed as a
part on its own.
Maciej
2:59 p.m.
I'm not sure what the 'B' in the middle means (silicon rev?), but the
DS12885 has been around for decades. I use them the JR-IDE project.
-Alan
On 2018-12-01 17:47, Maciej W. Rozycki via cctalk wrote:
On Tue, 27 Nov 2018, systems_glitch via cctalk wrote:
I probably need to do a writeup on fully potted
parts, like the 48T59
and
DS1287.
See a photo documentary here:
<ftp://ftp.linux-mips.org/pub/linux/mips/people/macro/ds1287/> for my
proposal of a DS1287 rework.
I actually had a nasty surprise trying to rework a DS1287A, with a
date
code indicating a clearly faked marking. After removing the integrated
coin cell the marking on the embedded IC revealed showed it wasn't even
a
DS1287A originally as the IC was a DS12B885. This is a part I haven't
heard of existing, so I enquired Maxim, but they had no clue about it.
I
suspect the DS12B885 was the core of the DS12B887 (wired differently
from
both DS12887 and DS12887A), and the DS12B885 has never been marketed as
a
part on its own.
Maciej
2 Dec
2 Dec
3:10 a.m.
On Sat, 1 Dec 2018, alan--- via cctalk wrote:
I'm not sure what the 'B' in the middle
means (silicon rev?), but the DS12885
has been around for decades. I use them the JR-IDE project.
Yes, the DS12885 is a standard part, still in production (with a trailing
+ marking RoHS compliance).
According to its datasheet the DS12B887 has an NC pin actually present in
the position where the DS12885 has the RESET# line, while the remaining NC
positions are absent due to the respective pins having been bent up (or
"are missing by design", as the datasheet puts it). So either a different
core had to be used with the DS12B887 or the datasheet has an error.
However RESET# would have to be connected to VCC for normal operation and
there is no mention of an internal pull-up on RESET# with the DS12885, so
I take it the DS12B887 had to use a different core and a DS12B885 seems
like a logical match.
The placement of RESET# right in the middle between VBAT and GND makes it
highly unlikely an internal discrete connection has been made in the
DS12B887 package between RESET# and VCC, as a shortage to the embedded
lithium cell from that pin if bent up and soldered to would be virtually
unavoidable.
Maciej
27 Nov
27 Nov
7:44 a.m.
On Sun, Nov 25, 2018 at 9:50 PM <ethan at 757.org> wrote:
Yes, the Sun compiler. At some point, I'll see if I can get my 3/60 booted,
but I'm lacking the right SCSI cable, I think. I also don't know how well
SCSI2SD will work emulating a streaming tape device, if at all.
Does anyone have a 3/60 hard disk image of SunOS 3.4 or 3.5, by chance?
Thanks,
Kyle
Ah cool. I was at a friend's brother's house on a work trip out to Silicon
Valley. One of his friends was there, with something amazing running in
QEMU. It was a work in progress, but he said that there were a lot of
issues because QEMU was too accurate in emulating the MIPS procressors and
in addition to this, there was bugs in his former employer's hardware that
had software work-arounds in the real OS. So when trying to run that OS on
the emulated system the accuracy worked against him.
Yikes! I've been thinking, since the Previous (NeXT) emulator works so
well, what would it take to turn it into a Sun emulator? I haven't looked
at the Previous source yet, but it seems like that would be a good starting
point.
Trying to build MazeWar results in:
ld: Undefined symbol
___bb_init_func
DREG_SEG
*** Error code 2
Not sure yet what to look for, but the source does say it was tested on
SunOS 3.1 and 3.4. So, I am trying to compile it on something a bit
later.
Sun compiler I assume and not a GCC?
8:22 a.m.
On Tue, Nov 27, 2018 at 10:44 AM Kyle Owen via cctalk
<cctalk at classiccmp.org> wrote:
Does anyone have a 3/60 hard disk image of SunOS 3.4
or 3.5, by chance?
I'll check. I was playing with TME earlier this year but I'm
forgetting which version of SunOS I was working on. I had a need to
test out some ancient SunOS m68k binaries (and was ultimately
successful). It might be 4.1.1, which might not help you so much.
I'm on the road this week so I won't have access to that platform
until the weekend, but I will check when I get home.
-ethan
1981
days inactive
1987
days old
17 comments
8 participants
participants (8)
-
aek＠bitsavers.org -
alan＠alanlee.org -
aperry＠snowmoose.com -
ethan.dicks＠gmail.com -
ethan＠757.org -
kylevowen＠gmail.com -
macro＠linux-mips.org -
systems.glitch＠gmail.com