David Brownlee wrote:
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.
Ahh, ok, I'll look into that using my FreeBSD 8 here...
Started do download some tgz's..
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…
Yes I understand this, but in the KA630 Rom region is no memory assigned
on the rtVAX 300 board, I get a memory fault if I try to access this
region. The VAX_BTYP_43 case is looking better so far...see the snipped i
posted and mouse disassemlbed..
t
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?
Yes, this is NetBSD 6.0 ..installation/netboot/boot (or so..)
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.
That old boot code I had from the KA630 experiments in the mop dirctory
worked better so far .. it has done nothing visible, but the TIL311 was
displaying a zero, which means that the "OS" is running..
(Yes, I know, an endless loop around a console ready bit in a register
is doing the same)
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.
Oh yes please, I'll try them as fast as possible (to keep things
somewhat interresting at least)
Of course if we have the bootloader generating output the real fun of
getting support for devices & the alternate VM setup can start :)
I don't expect much work in the VM area, from that what I've read DEC
dropped the KA620 way and released a fully working CVAX in that thing.
Got a hint from VAXman in the meantime (German VAx freak, friend of mine)
he heard that the rtVAX was put in the guidance computer from the cruise
missile .. may be the DOD wanted a working CPU..
The Network device should already be supported from netbsd..
Regards,
Holm
Ok, got the netbsd sources and crosscompiled them, modified consio.c
to have a default:
#ifdef notdef
case VAX_BTYP_630:
case VAX_BTYP_650:
case VAX_BTYP_9CC:
case VAX_BTYP_60:
put_fp = pr_putchar;
get_fp = pr_getchar;
break
#endif
default:
put_fp = rom_putchar;
get_fp = rom_getchar;
test_fp = rom_testchar;
rom_putc = 0x20040058; /* 537133144 */
rom_getc = 0x20040044; /* 537133124 */
break;
}
return;
....................
Same as those lines
case VAX_BTYP_43:
case VAX_BTYP_410:
case VAX_BTYP_420:
put_fp = rom_putchar;
get_fp = rom_getchar;
test_fp = rom_testchar;
rom_putc = 0x20040058; /* 537133144 */
rom_getc = 0x20040044; /* 537133124 */
break;
....
But this changes nothing.
I found out, that the mopbootfile from NetBSD 6.0 that I used yesterday
evening must ben defective, a new file ends like the previus (Netbsd 5.x)
versions:
83 BOOT SYS
-EZA0
2..1..0..
..........................
Without any printout.
Other rom adresses from the code above wouldn't work, this pair:
rom_putc = 0x20040068;
rom_getc = 0x20040054;
Touches at least not so useful mem contents in the rtVAX300:
P 20040048 2004C359
P 2004004C 20041881
P 20040050 2004539C
P 20040054 20041887
P 20040058 2004E4A0
P 2004005C 20041890
P 20040060 2A2A2A2A
P 20040064 2A2A2A2A
P 20040068 2A2A2A2A <--- rom_putc
P 2004006C 2A2A2A2A
Those from VAX_BTYP_43 are looking a lot better but I got no output.
Here a little more ROM Space:
P 20040000 0004A531
P 20040004 09110002
P 20040008 6E6E6E6E
P 2004000C 03020100
P 20040010 55555555
P 20040014 AAAAAAAA
P 20040018 33333333
P 2004001C 00000000
P 20040020 200452B6
P 20040024 200452EF
P 20040028 200452C2
P 2004002C 20045145
P 20040030 2004559C
P 20040034 2004770C
P 20040038 20045308
P 2004003C 00000000
P 20040040 2004539C
P 20040044 200418AD
P 20040048 2004C359
P 2004004C 20041881
P 20040050 2004539C
P 20040054 20041887
P 20040058 2004E4A0
P 2004005C 20041890
P 20040060 2A2A2A2A
P 20040064 2A2A2A2A
P 20040068 2A2A2A2A
P 2004006C 2A2A2A2A
P 20040070 2A2A2A2A
P 20040074 2A2A2A2A
P 20040078 2A2A2A2A
P 2004007C 2A2A2A2A
P 20040080 2A2A2A2A
P 20040084 2A2A2A2A
P 20040088 2A2A2A2A
P 2004008C 2A2A2A2A
P 20040090 2A2A2A2A
P 20040094 2A2A2A2A
P 20040098 2A2A2A2A
P 2004009C 2A2A2A2A
P 200400A0 2A2A2A2A
P 200400A4 2A2A2A2A
P 200400A8 2A2A2A2A
P 200400AC 092A0A0D
P 200400B0 09090909
P 200400B4 09090909
P 200400B8 20202020
P 200400BC 2A0A0D2A
P 200400C0 6F432020
P 200400C4 69727970
P 200400C8 20746867
P 200400CC 393120A9
P 200400D0 09093039
P 200400D4 09090909
P 200400D8 20202009
P 200400DC 0A0D2A20
P 200400E0 4420202A
P 200400E4 54494749
P 200400E8 45204C41
P 200400EC 70697571
P 200400F0 746E656D
P 200400F4 726F4320
P 200400F8 61726F70
P 200400FC 6E6F6974
P 20040100 614D202C
P 20040104 72616E79
P 20040108 4D202C64
P 2004010C 2E737361
P 20040110 20090909
P 20040114 2A202020
P 20040118 202A0A0D
P 2004011C 09090909
P 20040120 09090909
P 20040124 20202009
P 20040128 0A0D2A20
P 2004012C 5420202A
P 20040130 20736968
P 20040134 74666F73
P 20040138 65726177
P 2004013C 20736920
P 20040140 6E727566
P 20040144 65687369
P 20040148 6E752064
P 2004014C 20726564
P 20040150 696C2061
P 20040154 736E6563
P 20040158 6E612065
P 2004015C 616D2064
P 20040160 65622079
P 20040164 65737520
P 20040168 6E612064
P 2004016C 63202064
P 20040170 6569706F
P 20040174 2A202064
P 20040178 202A0A0D
P 2004017C 6C6E6F20
P 20040180 69202079
P 20040184 6120206E
P 20040188 726F6363
P 2004018C 636E6164
P 20040190 77202065
The KA630 defines (from ka630.h)
#define KA630_NVR_ADRS 0x200B8024
/* Definitions for various locations in the KA630 console page */
#define KA630_PUTC_POLL 0x20
#define KA630_PUTC 0x24
#define KA630_GETC 0x1C
#define KA630_ROW 0x4C
#define KA630_MINROW 0x4D
#define KA630_MAXROW 0x4E
#define KA630_COL 0x50
#define KA630_MINCOL 0x51
#define KA630_MAXCOL 0x52
..pointing to not existent memory regions:
... more Ideas?
It where really good to know where te putc and getc routines in the
KAV30 are..
Regards,
Holm
--
Technik Service u. Handel Tiffe,
, Holm Tiffe,
Freiberger Stra?e 42, 09600 Obersch?na, USt-Id: DE253710583