Rob
2024-01-10 22:22:48 UTC
Hello! Please let me know if this is too off topic!
As not to bury the lede, I'd ideally like some general "things to watch
out for" style pointers for using DEC C, for someone used to a [ahem]
slightly more modern ANSI C. I also have some rather low-level technical
questions on the Alpha architecture, specifically as to how I would best
go about compiling my own (lightly) modified PALcode and SRM console on
a modified AlphaPC eval board system I have recently acquired.
Before I get too much further, *just so it stays VMS-related*, I will
say that I've got it to bootstrap OpenVMS, loading from CD while showing
me the copyright notice before freezing. I am fairly skilled in the
principles of embedded systems development, but there's only so far I
can get on my own, despite how incredibly powerful the SRM console
happens to be.
The system in question is a canon branded ZX-series Fiery print
controller. The system developers left an unmodified floppy connector,
so I am able to use the failsafe booter to load images. The SROM
debugger does not seem to be present but I also have no way of knowing
whether the 6-pin connector present where the debug port would be is
still "Normal", in that it has buffers that will keep RS232 signal
levels from popping anything.
The in-built flash claims to have ARC in it but it also seems to need
you to have a pre-made image handy, with the extra partition already
present. I do not have an SCA->50 pin adapter or a SCSI emulator handy
so that'll have to wait.
For some reason the system is detected as a model 164SX, despite seeming
to have a 21164A (according to the stock firmware diagnostics on the
front panel of the system), a symbios SCSI chip and one of those "Mega
IO" ISA peripheral controller chips, implying that this is based on an
LX or UX model alphaPC motherboard. I doubt it's a UX because the
jumpers act like it's an LX, there's four memory slots and the technical
manual implies the UX does all sorts of weird stuff with shift registers
to save cost so I doubt I'd get any prompt were that the case.
Because I have nobody telling me what I can't and shouldn't be doing I
ended up cutting the boot block off the SX164 update image, cutting the
header off the compressed SX164 SRM ROM image and concatinating the boot
block with the ROM file. This gives me what seems to be a bootable,
mostly functional SRM console, save for the lack of access to the flash
chip. Other NVRAM appears unaffected. How elated I was to see that
particular shade of blue flash across *my* monitor for the first time.
As an aside, the version of the SX164 SRM ROM file I've found online
seems to have a very interesting undocumented command, that being
"xcmd", which claims to let me copy a file to memory over serial. I
suspect I need to use the xload or maybe uload tool from the SDK to use
this, and then also modify them slightly, but I've yet to be arsed. It's
not xmodem, I know that much for sure.
From there, I'm able to bootstrap OpenVMS, Tru64 and Linux from CD, but
OpenVMS freezes on the copyright notice and Tru freezes many several
lines after booting the kernel, which is very cool but is not very
helpful. Linux does a little better, able to get as far as doing an
isapnp probe but then immediately kernel panics. This tells me I might
be able to boot linux on this thing as-is by turning off isapnp support
from kernel parameters, but what in the world kind of fun is that????
Unfortunately, I am unable to directly access the firmware stored in
flash memory. The flash chip, or perhaps the bus transceiver it's
attached to for bank switching aren't being properly asserted so the
data bus remains floating. This is what I suspect is making the system
unbootable. This could be due to an incorrect flash chip driver (intel
28F008SA vs AMD 29LV800), an incorrect ISA peripheral chip driver (669
vs 969) or due to unknown modifications elsewhere.
The SX model's flash chip access seems to be a lot simpler than
whatever's going on here. There is an EPM7128 which I do hope is only
modified with additions and not with any explicit efforts to prevent
flash memory access. I can only assume there's been modifications, as I
suspect this CPLD has to do with DMA boundary scan stuff, since the
technical reference manual for the LX164 mentions an EPM7032 for such a
task.
Finally we come to my reason for being here. I have determined several
options but most of them would require help from an Expert(tm), and
since I don't have any haunted video terminals to do a seance with, I
have little choice but to bother you all with my nonsense.
My first impulse is to use the alphaPC development kit materials to
adjust what peripherals are compiled in. I'm convinced that if I can
compile some new PALcode with the correct drivers loaded in, I'll be in
business. I think I maybe might have managed to get a debug monitor ROM
compiled, but I have yet to make it boot. This is all rather difficult
without a functional debugger or an additional working system. At very
least a proper terminal....
Another option that seems semi-viable is to cut apart the segments of
the LX and SX and replace the SX image's PALcode. This is rather
difficult when I am not sure how I might do that, when the image
segments are all compressed individually and then joined in a way which
is unclear. The only reason I feel confident about this is because the
final location of the various segments when they are loaded into memory
is pretty well documented, and the layout of these files seems very
straightforward, not at all meant to be obfuscatory.
The third and most aggressive option I have is to desolder the flash
chip and dump it myself, then disassemble what is on there to find out
just what exactly is being done to activate the flash memory. That one I
can probably manage on my own. I feel comfortable saying the Alpha
architecture's the nicest one I've interacted with sofar. Very tidy.
Shame I was a child in its hayday.
If you made it this far, thanks for taking the time to read my very
long, very first post to the User's Network! Please tell me I'm in the
right place!
-Rob
As not to bury the lede, I'd ideally like some general "things to watch
out for" style pointers for using DEC C, for someone used to a [ahem]
slightly more modern ANSI C. I also have some rather low-level technical
questions on the Alpha architecture, specifically as to how I would best
go about compiling my own (lightly) modified PALcode and SRM console on
a modified AlphaPC eval board system I have recently acquired.
Before I get too much further, *just so it stays VMS-related*, I will
say that I've got it to bootstrap OpenVMS, loading from CD while showing
me the copyright notice before freezing. I am fairly skilled in the
principles of embedded systems development, but there's only so far I
can get on my own, despite how incredibly powerful the SRM console
happens to be.
The system in question is a canon branded ZX-series Fiery print
controller. The system developers left an unmodified floppy connector,
so I am able to use the failsafe booter to load images. The SROM
debugger does not seem to be present but I also have no way of knowing
whether the 6-pin connector present where the debug port would be is
still "Normal", in that it has buffers that will keep RS232 signal
levels from popping anything.
The in-built flash claims to have ARC in it but it also seems to need
you to have a pre-made image handy, with the extra partition already
present. I do not have an SCA->50 pin adapter or a SCSI emulator handy
so that'll have to wait.
For some reason the system is detected as a model 164SX, despite seeming
to have a 21164A (according to the stock firmware diagnostics on the
front panel of the system), a symbios SCSI chip and one of those "Mega
IO" ISA peripheral controller chips, implying that this is based on an
LX or UX model alphaPC motherboard. I doubt it's a UX because the
jumpers act like it's an LX, there's four memory slots and the technical
manual implies the UX does all sorts of weird stuff with shift registers
to save cost so I doubt I'd get any prompt were that the case.
Because I have nobody telling me what I can't and shouldn't be doing I
ended up cutting the boot block off the SX164 update image, cutting the
header off the compressed SX164 SRM ROM image and concatinating the boot
block with the ROM file. This gives me what seems to be a bootable,
mostly functional SRM console, save for the lack of access to the flash
chip. Other NVRAM appears unaffected. How elated I was to see that
particular shade of blue flash across *my* monitor for the first time.
As an aside, the version of the SX164 SRM ROM file I've found online
seems to have a very interesting undocumented command, that being
"xcmd", which claims to let me copy a file to memory over serial. I
suspect I need to use the xload or maybe uload tool from the SDK to use
this, and then also modify them slightly, but I've yet to be arsed. It's
not xmodem, I know that much for sure.
From there, I'm able to bootstrap OpenVMS, Tru64 and Linux from CD, but
OpenVMS freezes on the copyright notice and Tru freezes many several
lines after booting the kernel, which is very cool but is not very
helpful. Linux does a little better, able to get as far as doing an
isapnp probe but then immediately kernel panics. This tells me I might
be able to boot linux on this thing as-is by turning off isapnp support
from kernel parameters, but what in the world kind of fun is that????
Unfortunately, I am unable to directly access the firmware stored in
flash memory. The flash chip, or perhaps the bus transceiver it's
attached to for bank switching aren't being properly asserted so the
data bus remains floating. This is what I suspect is making the system
unbootable. This could be due to an incorrect flash chip driver (intel
28F008SA vs AMD 29LV800), an incorrect ISA peripheral chip driver (669
vs 969) or due to unknown modifications elsewhere.
The SX model's flash chip access seems to be a lot simpler than
whatever's going on here. There is an EPM7128 which I do hope is only
modified with additions and not with any explicit efforts to prevent
flash memory access. I can only assume there's been modifications, as I
suspect this CPLD has to do with DMA boundary scan stuff, since the
technical reference manual for the LX164 mentions an EPM7032 for such a
task.
Finally we come to my reason for being here. I have determined several
options but most of them would require help from an Expert(tm), and
since I don't have any haunted video terminals to do a seance with, I
have little choice but to bother you all with my nonsense.
My first impulse is to use the alphaPC development kit materials to
adjust what peripherals are compiled in. I'm convinced that if I can
compile some new PALcode with the correct drivers loaded in, I'll be in
business. I think I maybe might have managed to get a debug monitor ROM
compiled, but I have yet to make it boot. This is all rather difficult
without a functional debugger or an additional working system. At very
least a proper terminal....
Another option that seems semi-viable is to cut apart the segments of
the LX and SX and replace the SX image's PALcode. This is rather
difficult when I am not sure how I might do that, when the image
segments are all compressed individually and then joined in a way which
is unclear. The only reason I feel confident about this is because the
final location of the various segments when they are loaded into memory
is pretty well documented, and the layout of these files seems very
straightforward, not at all meant to be obfuscatory.
The third and most aggressive option I have is to desolder the flash
chip and dump it myself, then disassemble what is on there to find out
just what exactly is being done to activate the flash memory. That one I
can probably manage on my own. I feel comfortable saying the Alpha
architecture's the nicest one I've interacted with sofar. Very tidy.
Shame I was a child in its hayday.
If you made it this far, thanks for taking the time to read my very
long, very first post to the User's Network! Please tell me I'm in the
right place!
-Rob