On 15 December 2012 19:24, Holm Tiffe <holm at freibergnet.de> wrote:
David Brownlee wrote:
If the rtVAX ROM console is 'close
enough' to a normal VAX then it may
be a simple case of adding its boardtype to the switch statement. If
docs are not available it may even be worth adding a 'default' to each
of them in turn to see if it matches any of them (I'd start with a 630
Hmm ...sounds interesting.
...and it sounds as I have to put eighter the KA630 back in my BA23 where
currently A 11/83 lives or I have to put a 2nd disk into my 4000/90 to have
at least a kind of NetBSD development system to compile something :-(
While it would be helpful to have a normal VAX to hand to sanity check
builds (or at least a simh-vax instance), the NetBSD build system is
designed to be relatively easy to cross build on posix compliant hosts
(Well, certainly most BSDs, Linux & OS X hosts).
You should be able to download a source tree, then run './build.sh -m
vax distribution'. It first builds a set of cross compiler & other
tools, so after the above (or just a './build.sh -m vax tools') you
should be able to go into any directory in the tree and run the
nbmake-vax from the tools build.
I'm fascinated from those machines but I've
done alsmost nothing in the
direction of wirting software from them. (But I used the soldering iron
often and repaired the machines (more the Boards that build them since I
gote never a complete machine). I do even own a russian 11/03 (something
like that, metrical Q-Bus, RX02 like Floppies) that is working again.
I don't think that The KA630 code will work, (ok, maybe for the loader)
since the KA630 is using standard SLUs like the PDP11s. The SCN2681 however
is a real serial chip with it's own register layout, I remember that I have
programmed an 68681 sometimes in the past (which ist mostly the same)...
If we have a compatible ROM entry point [*] we can ignore the specific
chip implementation for the loader, and once we can output something
to the console future debugging becomes much easier...
[*] eg: ka630_rom_putchar() and friends from
http://cvsweb.netbsd.org/bsdweb.cgi/src/sys/arch/vax/boot/boot/consio2.S?re…
The NetBSD 6 netboot makes a trap:
>> b eza0
83 BOOT SYS
-EZA0
2..1..0..
?06 HLT INST
PC = 00001801
>>
...so it isn't working any better as it is.
Is that the stock boot on the rtVAX? I would certainly expect that to
choke as without a vax_boardtype case no console will be assigned. Of
course its possible that the code to determine vax_boardtype is
choking, which would make things potentially more entertaining.
If it would be of any interest I can drop a couple of versions of boot
with default added to the other cases. It *probably* won't Just Work,
but its quick to change & test.
Of course if we have the bootloader generating output the real fun of
getting support for devices & the alternate VM setup can start :)