[Info-vax] Architecture questions.

Rob novles.r at gmail.com
Wed Jan 10 17:22:48 EST 2024


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



More information about the Info-vax mailing list