http://odl.sysworks.biz/disk$vaxdocjun961/decw$book/d474aaa5.p77.decw$book Keyways Inc. 937-847-2300 this fellow has 2 available for sale. He is a commercial dealer in OH. -----Original Message----- From: cctalk-bounces at classiccmp.org [mailto:cctalk-bounces at classiccmp.org] On Behalf Of Zane H. Healy Sent: Thursday, December 13, 2012 9:29 AM To: General Discussion: On-Topic and Off-Topic Posts Subject: Re: rtVAX 300. At 8:13 AM +0100 12/13/12, Holm Tiffe wrote: That's seriously interesting. I *think* I've heard of them, but can't remember for sure. I'll be watching this thread with interest. Unless someone like Ethan knows something your best bet is going to be the comp.os.vms newsgroup. Zane -- | Zane H. Healy | UNIX Systems Administrator | | healyzh at aracnet.com | OpenVMS Enthusiast | | | Photographer | +----------------------------------+----------------------------+ | My flickr Photostream | | http://www.flickr.com/photos/33848088 at N03/ | | My Photography Website | | http://www.zanesphotography.com | ----- No virus found in this message. Checked by AVG - www.avg.com Version: 2013.0.2805 / Virus Database: 2634/5954 - Release Date: 12/12/12 ----- No virus found in this message. Checked by AVG - www.avg.com Version: 2013.0.2805 / Virus Database: 2634/5954 - Release Date: 12/12/12

On Thu, 13 Dec 2012 15:59:58 +0000 David Brownlee <abs at absd.org> wrote: IIRC the rtVAX CPUs have a slightly different (only one level?) TLB / page table layout and thus are not able to run *nix. At least not without adapting the VM subsystem. See the KA620 CPU board. -- \end{Jochen} \ref{http://www.unixag-kl.fh-kl.de/~jkunz/}

Jochen Kunz wrote: I've found a thread in the netbsd lists about this: (http://osdir.com/ml/os.netbsd.ports.vax/2002-11/msg00073.html) ...so may be it is possible to run *nix or VMS on a rtVAX 300. I will have both boards next time (KAV30 is laying around here, but I've not tried to power on this thing jet. There are two 500MB SCSI discs too which have the software on it that was running on this VME System. No other Parts CPUs in a external storage). The other thing is this ISA Board on the picture, this can't be a KAV30 but it seems to be very similar. Hope I get my hands on it today... Regards, Holm PS: (Jochen your discs aren't forgotten, hope I have time for them between christmas and new year..) -- Technik Service u. Handel Tiffe, www.tsht.de, Holm Tiffe, Freiberger Stra?e 42, 09600 Obersch?na, USt-Id: DE253710583 www.tsht.de, info at tsht.de, Fax +49 3731 74200, Mobil: 0172 8790 741

Holm Tiffe wrote: I now hold the ISA Board in my Hands. This thing is labeled "AEON Systems Incorporated, ISA300, Made in U.S.A." ...anything known about this? It seems that there is still a company named AEON Systems on the net, mostly selling some IBM Stuff. Maby I should aske there nicely... Regards, Holm -- Technik Service u. Handel Tiffe, www.tsht.de, Holm Tiffe, Freiberger Stra?e 42, 09600 Obersch?na, USt-Id: DE253710583 www.tsht.de, info at tsht.de, Fax +49 3731 74200, Mobil: 0172 8790 741

Dave McGuire wrote: What's wrong with the picture my friend made and sent me? (http://www.tiffe.de/images/11122012114.jpg) This link was already in my first post. Nothing special on the backside, Two MMJ connectors, 2 pushbutton Switches ( Reset, Halt?) and a single TIL311 are on the bracket side.. In what you are specially interested? I'll try to power up that thing tomorrow.. Regards, Holm -- Technik Service u. Handel Tiffe, www.tsht.de, Holm Tiffe, Freiberger Stra?e 42, 09600 Obersch?na, USt-Id: DE253710583 www.tsht.de, info at tsht.de, Fax +49 3731 74200, Mobil: 0172 8790 741

prolly pluged into a isa only backplane On Fri, Dec 14, 2012 at 3:59 PM, Benjamin Huntsman < BHuntsman at mail2.cu-portland.edu> wrote:

Adrian Stoness wrote: [..] ...not in this Case. My friend sayd that he found it in a 486 System with an SCSI Controller and a Comtrol Rocket Port Serial Card. Connected to the PC-SCSI Controller was a 500MB SCSI drive, the SCSI on the rtVAX Card wasn't connected at all. Hee keeped the Disk, since they still run old HP Stuff for control and the small SCSI Disks are getting scarce. But he will send me a dd dump from the disk next time. BTW @Dave: I've contaced those guys: http://www.aeonsecuritysystems.com/Business_Security.htm ...but they are foundet in 2004 and have nothing todo with that board. Regards, Holm -- Technik Service u. Handel Tiffe, www.tsht.de, Holm Tiffe, Freiberger Stra?e 42, 09600 Obersch?na, USt-Id: DE253710583 www.tsht.de, info at tsht.de, Fax +49 3731 74200, Mobil: 0172 8790 741

On 12/14/2012 04:25 PM, Holm Tiffe wrote: Oh I'm sorry Holm, somehow I missed that part of your first post. My AEON VME board has nearly the same complement of buttons and connectors, and a TIL311. One difference seems to be your board's two MMJs and my board's single RJ45. My board also has an AUI Ethernet connector. Sounds good. I'm interested to know how you make out. -Dave -- Dave McGuire, AK4HZ New Kensington, PA

Dave McGuire wrote: Hmmm... Powered it up.. I've got the stairways down to a room where I store seldum used things and grabbled out an PC that I'm build to read/write 8 Inch Floppies, it is a PIII/500 or so.. Opened it up, and put in The rtVAX Card in one of the two ISA Slots from the Motherboard. Switched it on, Saw an "E" on the TIL311 and than BOOOM, white flash out of the PSU.., Fuse for the Mains circuit blown. (not really, it is a resettable 16A 230V device). Ok, pulled the broken PSU (Source for some colored DC Cables) and mounted another one.. maybe there is something true on that urban Legend that one should let cold devices acclimate a little before switching them on...Ok, maybe next time.. Ok, switched on again, Selftest on The TIL311 from F down to 5 and there it sits for ever. Pulled out a cable adapter from MMJ to DB9 that I used in conjunction with an DECServer 300.. Nothing on the line, same with the other MMJ Connector. Switched off and dismounted the Card. At first, that are no MMJ Receptacles there, that are normal symmetric Telephone like Receptacles with 6 prongs 8in them. Looked closer to the board and founf a 75C1406, Datasheet archive ... aha. Found the following connection for the two Receptacles: 1 - NC 2 - GND 3 - RxD 4 - TxD 5 - GND 6 - NC Ok, made an Adapter to DB9 again an looked to the Seyon Terminal: rtVAX 300 V1.2 E...D ...and there it sits for a while... Finally E...D...C...B...A...9...8... Whow. Here we go.. DEPOSIT [{ /B | /W | /L }] [{ /P | /V | /I }] [/U] [/N:<n>] [{ <addr> | <sym> | + | - | * | @ } [<datum>]] EXAMINE [{ /B | /W | /L }] [{ /P | /V | /I }] [/U] [/N:<n>] [{ <addr> | <sym> | + | - | * | @ }] SET BOOT <ddau> SET BFLG <bflg> SET HALT <1-3> SET TRIG <0-1> SHOW { BOOT | BFLG | ETHER | HALT | MEM | TRIG } INITIALIZE UNJAM BOOT [/[R5:]<bflg>] { EZA0 | PRA0 | PRBx | CSBx } CONTINUE START <addr> REPEAT <cmd> TEST <n> FIND [{ /MEM | /RPB }] XFER <addr> <cnt> ... HALT HELP 01000000 00000000 00FFA600:00FFFFFF .... ?23 ILL CMD ?23 ILL CMD ID 00-00-F8-50-93-14 Hmm.. have to connect something I think... Is there someone that thinks that he know that the Pinout of the Ethernet Connector ist the same as on a DELQA for example? There is an Ethernet Transformer on The board next to the connector...no AUI at all? I think the Transformer is part of a PHY already... Regards, Holm -- Technik Service u. Handel Tiffe, www.tsht.de, Holm Tiffe, Freiberger Stra?e 42, 09600 Obersch?na, USt-Id: DE253710583 www.tsht.de, info at tsht.de, Fax +49 3731 74200, Mobil: 0172 8790 741

Alexandre Souza - Listas wrote: ..please answer at bottom.. no one can maintain a thread where people answering at top, at bottom or in the middle at the same time... ...things are getting more complicated now. Altough the rtVAX300 should have an integrated SCSI Controller, the 50 Pin can't be SCSI.. I've connected some disks, but the rtVAX isn't booting anymore, regardless of what disk is connected. There is a 74F373 that has some wirings to that connector and an EPM5032 is connected too. There is no row of GND Pins on that connector. The Ethernet Connector has 16 Pins and is a Berg type connector too. It seems as that is a somewhat translated AUI Connector, the one of the DELQA has 20 Pins, so it isn't the same at all. Maybe it should 1:1 connected to a DB15 receptacle with one Pin left free.. I think the next thing that I have todo is to reverse engeneer that Ethernet Interface so that I can try to boot that thing diskless with mopd. The Firmware shows that booting from the following devices should be possible: BOOT [/[R5:]<bflg>] { EZA0 | PRA0 | PRBx | CSBx } EZA0 must be the Ethernet Interface, what could the other Abbrevations mean? I think that there is a mechanism to use the devices of the Host the card lives in so that it can use the Disk from the Host trough some bridging software. I have to look what I could find in the disk dump if I get it. As I wrote before the system was a 486PC with an Adaptec 1542CF and a Comtrol 4 Port Serial Card. Don't know more ... Regards, Holm -- Technik Service u. Handel Tiffe, www.tsht.de, Holm Tiffe, Freiberger Stra?e 42, 09600 Obersch?na, USt-Id: DE253710583 www.tsht.de, info at tsht.de, Fax +49 3731 74200, Mobil: 0172 8790 741

Holm Tiffe wrote: Ok, I managed to get the ethernet part working in the meantime, the connector is really a one to one replacement for an AUI Connector, pin 16 left free. I found some game port connector with a strip in my dumpster, connected it and it works. I can boot netbsd's loader (mopboot) with the command "b eza0" from my freebsd machine, but it doesn't work at all. I don't currently know what version this is exactly, but I booted a cardstack with a KA630 a year (or two?) before from it. I used netbsd to install quasijarus on the disk (needed partitioning, and installing the filesystems). I wanted to have a somewhat classic BSD running on it but it seems there isn't any development in the direction anymore. I've mailed with M. Sokolov a little but nothing has changed since 2004 on his website. http://ifctfvax.harhan.org/Quasijarus/releases/ NetBSD as such has dropped the VAX so far as I know and even the last Releases aren't working anymore on a uVAXII vor example. I think I had to use some 5.x Release to get it booted from a DEQNA/DELQA at all. I'm pretty sure the loader works as such un the rtVAX, the networki interface should be supported so far as I've read, but I think the SLU's are not and so there is nothing to see... 83 BOOT SYS -EZA0 2..1..0.. ..Thats all Folks. It stalls there. Roger Ivie wrote in the ports vax mailinglist: ...so I think the Console SLU is the problem, one needs a decent documentation for the rtVAX300 that includes the programming manual for the SLUs and the NetBSD source to make the Console driver work. That shouldn't be to much work. As long as I'm not finding a person that's a little bit involved in VAX Assembler and is using NetBSD on VAXen, my trip ends here. Maybe Dave is interested since he has at least such a rtVAX Card. I've wrote some Turbopascal on CP/M and later MSDOS, but I forgot almost all about Pascal in the meantime... so VAXELN might not be of much use to me. I'm having Problems with VMS too, installed it successfully on my VS4000/90 but it seems to not really "my thing"... don't switched it on for a year now.. Nevertheless I'll going to read some of the linked in documentation now, lets see if I can get some infos about the SLUs in that black box. Regards, Holm -- Technik Service u. Handel Tiffe, www.tsht.de, Holm Tiffe, Freiberger Stra?e 42, 09600 Obersch?na, USt-Id: DE253710583 www.tsht.de, info at tsht.de, Fax +49 3731 74200, Mobil: 0172 8790 741

emanuel stiebler wrote: I couldn't tell you that exactly since I read that at least a year before (when I tried the uVAXII). Maybe it was only the netbooting or such, or it was something with the controllers (Emulex UC07/08) that I was using. Sorry about that. I've downloaded the last release to this time, but I had to go back. Regards, Holm -- Technik Service u. Handel Tiffe, www.tsht.de, Holm Tiffe, Freiberger Stra?e 42, 09600 Obersch?na, USt-Id: DE253710583 www.tsht.de, info at tsht.de, Fax +49 3731 74200, Mobil: 0172 8790 741

On 12/15/2012 12:26 PM, Holm Tiffe wrote: I don't see a 2681 on mine. Interestingly, I don't see any recognizable UART on mine at all. I seem to recall that the rtVAX-300 module has an onboard console UART; is that the one you're connecting to when you interact with the ROM? Also, in case it is of any interest, my AEON VME board also contains a WD SCSI host adapter chip, and I have another (very thick) VME board contains a smallish SCSI hard drive and a floppy drive. FYI (and for the archives), my board is model VME-300E. According to Manx, DEC publication EK-383AA-PG is the rtVAX-300 Programmers Guide. I've not been able to find a copy online. This page gives some specifications on the AEON VME300E board, as well as the DEC KAV30, which seems to be a similar product; https://mail.encompasserve.org/anon/htnotes/note?f1=INDUSTRY_NEWS&f2=55… This seems to be some source code for an rtVAX-300 on a VME module, http://www.slac.stanford.edu/accel/ilc/codes/ATF2/control-software/epics-3.… The one interesting thing here is map_sm.c, which is code to access the VMEbus from the rtVAX-300. Of course this isn't relevant to your ISA card, but I found it interesting. In its comments, it references an object library supplied by AEON that is specific to the VME300 board. That is somewhat discouraging. I note that on my AEON board, the rtVAX-300 module is mounted in a socket. Nice! I can see building a really sweet VMS laptop around that. B-) I need to find some time to power this up. On your board, you've found that you've got a VAXELN system in ROM. I wonder if it would be worth disassembling the initialization code there to figure out how to talk to the console. -Dave -- Dave McGuire, AK4HZ New Kensington, PA

On Sat, 15 Dec 2012 17:59:07 +0100 Holm Tiffe <holm at freibergnet.de> wrote: No. Surely not! What brings you to this assumption? That is the problem. There is some strange bug in the (network) boot loader. Maybe a GCC bug. Therefore netbooting has been broken for quite some time. As nobody with the required skils cares it stays there. After all NetBSD is a voluntary project. But you can use an older version of the bootloader to boot release-6 or even -current. -- \end{Jochen} \ref{http://www.unixag-kl.fh-kl.de/~jkunz/}

I've posted some older Computer History Museum docent training videos from when the museum was located at Moffett Field before moving into the current building in Mountain View. http://www.youtube.com/watch?v=VdktCQqnpQ8 http://www.youtube.com/watch?v=qy_FNzRhlYI http://www.youtube.com/watch?v=i-CD5g711vQ ? Lafarr Stuart on Lehmer Sieve http://www.youtube.com/watch?v=967BCgwKVSw ?John Greene on Seymour Cray http://www.youtube.com/watch?v=Br6NRrUDUTE http://www.youtube.com/watch?v=mbIjwLqLEz0 Enjoy! ? Lee Courtney

His prices are...high. -- Will

On Dec 22, 2012 10:26 AM, "mc68010" <mc68010 at gmail.com> wrote: is just dumping the stuff now. Portland Craigslist is probably not the best place for making money on card readers. Bongs and used bicycles maybe. Who knows though. Maybe someone different is selling this stuff now. It's also listed on eBay. Example: http://www.ebay.com/itm/190774217184

On Dec 22, 2012 9:45 AM, "mc68010" <mc68010 at gmail.com> wrote: this a a fellow list member? If not sounds like he should be from the linked website. If you are and read this hope you don't mind the posting. http://www.gold-snipper.com/tjo/vintagecomputers/ I haven't noticed any eBay activity from that dealer in years. I thought he might have gotten out of the business. I have an HP 1000 2117F that was lacking an FPP box and I bought one from him in person at his Portland warehouse years ago. The place was full of interesting stuff. -Glen

David Brownlee wrote: 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 :-( 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)... The NetBSD 6 netboot makes a trap: 83 BOOT SYS -EZA0 2..1..0.. ?06 HLT INST PC = 00001801 ...so it isn't working any better as it is. Regards, Holm -- Technik Service u. Handel Tiffe, www.tsht.de, Holm Tiffe, Freiberger Stra?e 42, 09600 Obersch?na, USt-Id: DE253710583 www.tsht.de, info at tsht.de, Fax +49 3731 74200, Mobil: 0172 8790 741

... ... Mine is pretty close to that. I converted the data you gave to a binary file (8K, based at 0x20040000), and after a few moments with the disassembler, here's what I get. (The .space pseudo-directives are space that exists in my 8K file but which you didn't give values for. The end of the disassembly is three .bytes because it's only part of an instruction.) Note the syntax is more Unix than DEC. If you prefer the DEC way, change $ into # and * into @, and probably throw in a few other tweaks I've forgotten. (It's been a very long time since I used MACRO-11.) # coresize = 0x2000 # corebase = 0x20040000 20040000: .space 68 20040044: .ptr 0x200418ad 20040048: .ptr 0x2004c359 2004004c: .ptr 0x20041881 20040050: .ptr 0x2004539c 20040054: .ptr 0x20041887 20040058: .ptr 0x2004e4a0 2004005c: .ptr 0x20041890 20040060: .ascii "****************************************" 20040088: .ascii "************************" 200400a0: .space 6157 200418ad: entry mask: r5 r4 r3 r2 200418af: pushl $000000ef 200418b5: calls $1,0x20045120 200418ba: movab 0x200418c8,r2 200418bf: clrl r0 200418c1: movzbl *$2004000c,r1 200418c8: cmpb r0,r1 200418cb: beql 0x200418d0 200418cd: brw 0x200419fe 200418d0: movab 0x200418df,r2 200418d5: movzbl $1,r0 200418d8: movzbl *$2004000d,r1 200418df: cmpb r0,r1 200418e2: beql 0x200418e7 200418e4: brw 0x200419fe 200418e7: movab 0x200418f6,r2 200418ec: movzbl $2,r0 200418ef: movzbl *$2004000e,r1 200418f6: cmpb r0,r1 200418f9: beql 0x200418fe 200418fb: brw 0x200419fe 200418fe: movab 0x2004190d,r2 20041903: movzbl $3,r0 20041906: .byte 9a 20041907: .byte 9f 20041908: .byte 0f 20041909: .space 1783 /~\ The ASCII Mouse \ / Ribbon Campaign X Against HTML mouse at rodents-montreal.org / \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B

On Dec 15, 2012, at 5:36 PM, Mouse wrote: Well, the 8530 is a bit of an oddball amongst UARTs. The PDP-11 standard console SLU is extremely simple and doesn't even provide any real buffering; my assumption from its design is that it's meant to be implemented with minimal hardware and used with minimal software (e.g. ODT, which is generally implemented in the microcode). I imagine the VAX, which is very much a spiritual descendant of the PDP-11, would use basically the same hardware (if it ain't broke, don't fix it). - Dave

Mouse wrote: Ok, now it is only the question if you all want to help a VAX Noob to get his machine working.. We are talking about the rtVAX300, this black brick on that boards: http://www.tiffe.de/images/11122012114.jpg http://www.tiffe.de/images/KAV30-AD-1.jpg http://www.tiffe.de/images/KAV30-AD-2.jpg http://www.tiffe.de/images/KAV30-AD-3.jpg I've tried to netboot netbsd or at least its loader but it is writing nothing out to the console. David Brownlee gave the hint, that the loader uses ROM Code to write out something and that he thinks that putting an other Board in one of the case switches here my do the trick: http://cvsweb.netbsd.org/bsdweb.cgi/src/sys/arch/vax/boot/boot/consio.c?rev… So I looked at the rom contents from the adresses there, that's what you have disasssembled. The KA630 Address is in a Header file (KA630_NVR_ADRS 0x200B8024) but there is no memory on this address on the ISA board from above. I'm trying to find rom_putchar and rom_getchar.. The rtVAX board has no DC319 chip, it uses the SCN2681 Double Uart fpr the Console and the auxilary Port. I've looked closer at that chip some time before and his register layout is pretty much different than the Standard DC319 Chip. (besides that you can do anything if you have 3 big Altera PLDs on the Board) Regards, Holm -- Technik Service u. Handel Tiffe, www.tsht.de, Holm Tiffe, Freiberger Stra?e 42, 09600 Obersch?na, USt-Id: DE253710583 www.tsht.de, info at tsht.de, Fax +49 3731 74200, Mobil: 0172 8790 741

On 12/16/2012 01:20 PM, Tony Duell wrote: They are. I checked the KA630 print set; it uses a DC319 DLART. -Dave -- Dave McGuire, AK4HZ New Kensington, PA

David Brownlee wrote: Ahh, ok, I'll look into that using my FreeBSD 8 here... Started do download some tgz's.. 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 Yes, this is NetBSD 6.0 ..installation/netboot/boot (or so..) 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) Oh yes please, I'll try them as fast as possible (to keep things somewhat interresting at least) 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 -- Technik Service u. Handel Tiffe, www.tsht.de, Holm Tiffe, Freiberger Stra?e 42, 09600 Obersch?na, USt-Id: DE253710583 www.tsht.de, info at tsht.de, Fax +49 3731 74200, Mobil: 0172 8790 741

[no-trimming damage repaired manually] It's a long shot, but it might be worth typing in a small test program that uses IPRs 32-35, because if they work you don't need to go through a ROM code trampoline. Here's an example, including assembled binary. (This was hand-assembled; I thought I had a VAX assembler but can't seem to find it. But I checked by disassembling.) movb $'x,r0 90 8f 78 50 movab 9f,sp 9e af 31 5e bsbb 1f 10 06 3: bsbb 2f 10 0f bsbb 1f 10 02 brb 3b 11 fa 1: mfpr $34,r1 db 22 51 tstb r1 95 51 bgeq 1b 18 f9 mtpr r0,$35 da 50 23 rsb 05 2: mfpr $32,r1 db 20 51 tstb r1 95 51 bgeq 2b 18 f9 mfpr $33,r0 db 21 50 rsb 05 .align 4 .space 16 9: The code is PIC, so you can base it anywhere you like. At 0, for example, you might d/l/p 0 50788f90 d/l/p 4 5e31af9e d/l/p 8 0f100610 d/l/p c fa110210 d/l/p 10 955122db d/l/p 14 daf91851 d/l/p 18 db052350 d/l/p 1c 51955120 d/l/p 20 21dbf918 d/l/p 24 00000550 Then start it. My memory of VAX console is fuzzy, but I think that would be something like (again, based at 0) d pc 0 d psl 041f0000 g If MFPR/MTPR console access works, it should print an x and then echo back whatever is typed at it. I haven't been able to test this; none of my VAXen are in runnable shape right now. But I'm moderately sure the code is right; it's pretty simple. Perhaps someone with a KA630 set up to run can test it. On my emulator, it prints the x but nothing more - but, as far as I can tell from reading the code, that emulator doesn't support console input at all, so that's hardly surprising. /~\ The ASCII Mouse \ / Ribbon Campaign X Against HTML mouse at rodents-montreal.org / \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B

Okay, I guess it's not g - at least not on your machine. That's probably what I wanted. This might do it too, but it also might want to find an RPB or an entry mask or some such. I'm not surprised. You might try using continue instead, but, really, this was a long shot; my impression is that the more recent a VAX is the less likely MTPR/MFPR console is to work on it. I'll have a look and see if I can figure anything out. Certainly the text strings imply so. /~\ The ASCII Mouse \ / Ribbon Campaign X Against HTML mouse at rodents-montreal.org / \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B

On 12/16/2012 04:25 PM, Holm Tiffe wrote: The monitors on the VAXen are not done in microcode, they are actually VAX code. The microcode-based ODT is particular to the LSI-11, F11, and J11-based PDP-11s. (any others?) -Dave -- Dave McGuire, AK4HZ New Kensington, PA

I'm not sure why you named me, but in case it was a suggestion that I do something with it, that's highly unlikely to happen. Most briefly, I don't do Windows; to go into more detail would turn this email longer than I think appropriate (but of course I can if anyone cares). However, I also note that I don't see any indication what terms it is licensed under, which would make many people (those who care about such things, at least) hesitate to do anything at all with it. /~\ The ASCII Mouse \ / Ribbon Campaign X Against HTML mouse at rodents-montreal.org / \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B

Mouse wrote: [..] If I would try to find the putc call myself, is the most used calling convention on the VAX putting the character on the stack or should I put it in R0 or something? Regards, Holm -- Technik Service u. Handel Tiffe, www.tsht.de, Holm Tiffe, Freiberger Stra?e 42, 09600 Obersch?na, USt-Id: DE253710583 www.tsht.de, info at tsht.de, Fax +49 3731 74200, Mobil: 0172 8790 741

On 12/17/2012 2:26 PM, Mouse wrote: I am totally unprepared to help, but when we had problems like this we had to code up small runtime routines to scan the memory space for what were JMP and JMP indirect instructions in our Microdata 1621 object code to find out who was connected to what. Maybe if holme had such a routine he could run it and find the runtime setup ones. Or maybe if one is lucky, the code you have at 0x04c8 is a table and could just be dumped to continue the hunt. Also hopefully there are not more layers between the printf and the output routines. At least once you find the output side and the registers, you can then possibly scan for the register references if you are lucky and find the input character or string code. Did this version of uart possibly have buffering and DMA, or was it interrupt char / char most likely. Impossibly to know w/o finding it of course. Now days most serial devices I find even for consoles have DMA and buffering that makes the deciphering and subsequent coding of quite difficult. Happily I've not had to do so, and the code is open and quite available now days. Jim

Mouse wrote: I'm qouting from Roger Ivie (comp.sys.dec): I am currently holding the following documents in my grubby little fingers: - Two copies of a rather hefty document titled "rtVAX 300 Hardware Information Kit: Hardware User's Guide" (EK-382AB-UG-002). - One copy of the depressingly slim "rtVAX 300 Hardware Information Kit: Programmer's Guide" (EK-383AA-PG-001), which seems to be all about writing VAXeln device drivers. - One copy of the even slimmer "rtVAX 300 Release Notes" (EK-417AA-RN-001) According to Chapter 6 (Console and Boot ROM Interface): "The rtVAX 300 processor module does not contain an internal console serial-line unit (SLU); however, 16 console registers are reserved in the rtVAX 300 processor reserved space to select and program an external Signetics 2681 console dual universal asynchronous receive/transmitter (SCN 2681 DUART). These regosters occupy physical locations 201000000 to 2010003F. The built-in firmware of the rtVAX 300 programs and communicates with the external SCN 2681 DUART, which implements these console registers." It then refers to table 3-13 for a list of the registers. That table says: 20100000 Channel A mode registers (MRA1, MRA2) (R/W) 20100004 Channel A status register (R) Channel A clock select register (CSRA) (W) 20100008 Reserved (R) Channel A command register (CRA) 2010000C Channel A receive holding register (RHRA) (R) Channel A transmit holding register (THRA) (W) 20100010 Input port change register (IPCR) (R) Auxiliary control register (ACR) (W) 20100014 Channel A/B interrupt status register (ISR) (R) Channel A/B interrupt mask register (IMR) (W) 20100018 Counter/timer interval register upper (CTU) (R) Counter/timer interval register upper (CTUR) (W) 2010001C Counter/timer interval register lower (CTL) (R) Counter/timer interval register lower (CTLR) (W) 20100020 Channel B mode register (MRB1, MRB2) (R/W) 20100024 Channel B status register (SRB) (R) Channel B clock select register (CSRB) (W) 20100028 Reserved (R) Channel B command register (CRB) (W) 2010002C Channel B receive holding register (RHRB) (R) Channel B transmit holding register (THRB) (W) 20100030 Reserved (R/W) 20100034 Input port register (R) Output port configuration register (OPCR) (W) 20100038 Start counter command register (R) Set output port bits command register (W) 2010003c Stop counter command register (R) Reset output port bits commnad register (W) -- roger ivie rivie at ridgenet.net ...so the SCN2681 seems to be the normal way to get some SLU's on a rtVAX300 System and Dave should have one of them somwhere on his board also. Test: A B C :-) Don't have much time the next days (mother in law is getting 60 today), will test further after jan 1. I wish you a happy new year... Regards, Holm -- Technik Service u. Handel Tiffe, www.tsht.de, Holm Tiffe, Freiberger Stra?e 42, 09600 Obersch?na, USt-Id: DE253710583 www.tsht.de, info at tsht.de, Fax +49 3731 74200, Mobil: 0172 8790 741

On 2012-12-30 07:56, Holm Tiffe wrote: Did you read the internal EEPROMs out already?

Are they socketed? You _probably_ can read them with e/l/p from the console, with suitable addresses - I think that's how I dumped my KA630's ROM. The problem, of course, is determining the "suitable addresses". In the case of the KA630 I dealt with, the manual says: EK-KA630-UG-001 says, on page 3-2, that the ROM appears twice in physical address space (once at 20040000-2004FFFF and again at 20050000-2005FFFF). I seem to recall someone mentioning upthread that manual contents are known for the hardware in question; if you're lucky, they may have similar language. If not, you might be able to get somewhere by just scanning physical address space...you'd probably want to start with a probe every 32K or 64K or some such so you don't try doing billions of attempted accesses (which would get slow - even if done from software rather than the console, taking failure traps for most of them would be time-consuming). /~\ The ASCII Mouse \ / Ribbon Campaign X Against HTML mouse at rodents-montreal.org / \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B

Okay, as you say, there's clearly something there. It's moderately likely to be where the ROM lives on your machine. As a first tentative guess, I would start picking this apart assuming the CPU starts executing it at 2004a531. If you can dump the whole thing (you might be able to do binary search to figure out how large it is) someone can probably disassemble it. If you aren't up to converting it to binary, I could take a big blob of text capture from something like "e/l/p/n:3fff 20040000" (or whatever n: value gives you the correct amount for its size) and convert it to a binary file easily enough. I might even have the time to do some preliminary investigation, though I can't really promise anything there. /~\ The ASCII Mouse \ / Ribbon Campaign X Against HTML mouse at rodents-montreal.org / \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B

I'll be looking forward to those! I'd be interested in getting a copy in any case. Those pictures make this look like really cute hardware.... /~\ The ASCII Mouse \ / Ribbon Campaign X Against HTML mouse at rodents-montreal.org / \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B

On Sun, 2012-12-30 20:36:49 +0100, Holm Tiffe <holm at freibergnet.de> wrote: This is the start of the system ROM, as used with the usual 3100 / 4000 class of machines. My reading of this (I've dumped a good number of ROMs) is that the firmware is provided by four ROMs, each supplying one byte of a longword. [...] You usually have some header, containing a JMP to the ROM's actual start address. These ROMs are usually 64, 128, 256 or 512KB. Usually, the last part of the ROM isn't used (and thus filled with all-0x00 or all-0xff), except the very last four bytes, which often hold a checksum. That way, it's quite easy finding the correct length. Just jump the contents of the supposed end addresses and see if it's all zeroes (except a 4-byte checksum that's probably there.) I'd be _highly_ interested in getting a ROM dump! I once wrote a firmware dumper helper, that reads the ROM byte-by-byte (slow using a serial link, but it works.) You can find it at http://vax-linux.org/gitweb/?p=firmware_dumper.git;a=summary For a VAX, you probably need to start it like this: $ ./dumper --target vax --device /dev/ttyS0 --speed 9600 --bits 8 \ --parity N --stop 1 --outfile rtVAX300.bin --start 0x20040000 \ --len 524288 --scheme 3 MfG, JBG -- Jan-Benedict Glaw jbglaw at lug-owl.de +49-172-7608481 Signature of: Fortschritt bedeutet, einen Schritt so zu machen, the second : da? man den n?chsten auch noch machen kann.

Isn't at least one of those on the list? Or am I thinking of a different list? http://www.linkedin.com/profile/view?id=9497225&authType=NAME_SEARCH&am… hToken=q9mS&locale=en_US&srchid=f93c81c4-d0ad-49cd-9bfb-43927e463f18-0&s rchindex=1&srchtotal=65&goback=%2Efps_PBCK_*1_Mike_Moroney_*1_*1_*1_*1_* 2_*1_Y_*1_*1_*1_false_1_R_*1_*51_*1_*51_true_*2_*2_*2_*2_*2_*2_*2_*2_*2_ *2_*2_*2_*2_*2_*2_*2_*2_*2_*2_*2_*2&pvs=ps&trk=pp_profile_name_link Antonio arcarlini at iee.org

Holm Tiffe wrote: [..] In the meantime I've compared the binaries from both readouts, they are identical so I think both attempts have worked. @Mouse: it seems that the Console Code in the rom is at 2004685a and upward. The only two occurences of the SCN2681 Register Adresses ( ) are in that region, but again, there are a mass of instructions where the mnemonic sys nothing to me, I have to lookup every single instruction in the VAX Assembly language manual.. that's not much of fun when one tries to understand what happens there. 20046855: movp $10,$4,$3c 20046859: halt 2004685a: subl2 $24,sp 2004685d: movl $1,r5 20046860: moval 04(ap),r4 20046864: movl (r4),r1 20046867: bisb2 $8,1003(r1) 2004686c: bicb2 $2,1003(r1) 20046871: bicb2 $4,1003(r1) 20046876: movl $a,1034(r1) 2004687b: movzwl $0320,102c(r1) 20046882: mtpr $15,$12 20046885: mtpr $00000040,$18 2004688c: movl 0000(r4),r3 20046891: movab 0x20044f66,r2 20046898: pushl r3 2004689a: calls $1,0x20046620 200468a1: movl *$20100004,r0 200468a8: blbc r0,0x200468e8 200468ab: bicl3 $ffffff00,*$2010000c,r0 200468b7: cmpl r0,$3 200468ba: bneq 0x200468e8 -------- Addr 2004685a disas> Are you able to find somthing like putchar() and getchar() there so that I can call those routines from netbsd's bootloader? I think the rtVAX300 will boot at least the loader, know, the real work comes next... Regards, Holm -- Technik Service u. Handel Tiffe, www.tsht.de, Holm Tiffe, Freiberger Stra?e 42, 09600 Obersch?na, USt-Id: DE253710583 www.tsht.de, info at tsht.de, Fax +49 3731 74200, Mobil: 0172 8790 741

Mouse wrote: Cool. I don't even know what the heck an entry mask is. Sorry, never done assembler on such an "big" machine. There are two occurences of "0c 00 10 20" in the code, at 200468b2 and 20046932. 0x201000C is the Address of the SCN2681 Transmit Buffer/Receiver Holding register so I think the routines should be there. The Address ofi the Channel A Status Register 20100004 is also appearing in this area (200468a3, 20046923, later at 20046c82, 20046cca and 2004c43c). Regards, Holm -- Technik Service u. Handel Tiffe, www.tsht.de, Holm Tiffe, Freiberger Stra?e 42, 09600 Obersch?na, USt-Id: DE253710583 www.tsht.de, info at tsht.de, Fax +49 3731 74200, Mobil: 0172 8790 741

You might want to read up on VAX machine/assembly language, then, before you try to dig too much deeper into picking apart this binary blob. You can learn a lot without, it's true, but it will help substantially. As for entry masks in particular...the VAX has two different kinds of routine calls. There's the simple sort, which call with BSBB, BSBW, or JSB, and return with RSB. These are pretty close to the kind of call most RISC hardware has, a call being "do a jump, but push what would otherwise be the next instruction's PC on the stack first" and a return being "pull an address off the stack and jump to it". (The differences among the three call instructions is how the target instruction is addressed.) I'll call these `JSB calls'. Arguments, if any, can be passed pretty much anywhere: in registers, on the stack, in fixed locations, whatever the caller and the callee agree on. There's also the complex sort, which call with CALLS or CALLG and return with RET. These not only transfer flow-of-control but do a bunch of other stuff, too, notably meddling with AP and FP. They take the argument list in memory - on the stack for CALLS, anywhere in memory for CALLG. CALLS also removes the args from the stack automatically on return - the stack frame created by CALL[SG] includes a bit that tells RET whether to pop the arglist. I'll call these `CALLx calls'. JSB calls are substantially cheaper, but provide less assist. Most VAX toolchain and development software (compilers, debuggers, etc) assumes CALLx calls; in particular, stack frames are generally assumed to look like what CALLS/CALLG generate. As for entry masks, one of the things CALLS/CALLG do is save callee-used registers (and potentially, do a few other things, such as turning integer-overflow traps on or off). The entry mask says what registers to save on entry (and restore on exit); it's a 16-bit bitmask. (There are a few bits that would otherwise correspond to registers that it doesn't make any sense to save and restore, such as PC; these are the bits that control things like integer overflow trap enables.) The entry point address passed to CALLS/CALLG is that of the entry mask; execution starts two bytes further along. When running for the VAX, the e command disassembles two bytes as an entry mask (there's a note late in the README about this). Each of those appears to be real. I'm currently annotating every mfpr/mtpr instruction, or at least those with constant register number operands, as to which register it's referring to; once that's done I'll search out all the 201000xx references and annotate them. I'll make the disassembler save file and the resulting text version available.... /~\ The ASCII Mouse \ / Ribbon Campaign X Against HTML mouse at rodents-montreal.org / \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B

Mouse wrote: Hmm... I've got the files and tried to build a netbsd-boot thats saying something..but no luck jet.. I don't understand what's going wrong here, since it seems that the code in boot.c isn't reached at all, every time I'm trying to boot from eza0 I get this: 83 BOOT SYS -EZA0 2..1..0.. ?06 HLT INST PC = 00001801 G 00000000 20042F75 G 00000001 00FFEA00 G 00000002 00001000 G 00000003 00FFBA00 G 00000004 00000000 G 00000005 00000000 G 00000006 FFFFFFFF G 00000007 FFFFFFFF G 00000008 00000800 G 00000009 00001800 G 0000000A 00001800 G 0000000B 00000000 G 0000000C 00000200 G 0000000D FFFFFFFF G 0000000E 00001800 G 0000000F 00001801 ?26 ILL ADR The Startup code in boot/common/srt0.S looks like this: #include "../include/asm.h" /* * Auto-moving startup code for standalone programs. Can be loaded * (almost) anywhere in memory but moves itself to the position * it is linked for. Must be started at first position, recommended * is phys addr 0 (boot loads programs at 0, but starts them at the * position set in a.out header. */ .globl nisse # pass -e nisse to ld gives OK start addr .set nisse,0 ALTENTRY(start) nop;nop; movl $_C_LABEL(start), %sp # Probably safe place for stack pushr $0x1fff # save for later usage subl3 $_C_LABEL(start), $_C_LABEL(edata), %r0 movab _C_LABEL(start), %r1 # get where we are movl $_C_LABEL(start), %r3 # get where we want to be cmpl %r1,%r3 # are we where we want to be? beql relocated # already relocated, skip copy movc3 %r0,(%r1),(%r3) # copy subl3 $_C_LABEL(edata), $_C_LABEL(end), %r2 movc5 $0,(%r3),$0,%r2,(%r3) # Zero bss movpsl -(%sp) pushl $relocated rei relocated: # now relocation is done !!! movl %sp,_C_LABEL(bootregs) # *bootregs calls $0, _C_LABEL(Xmain) # Were here! halt # no return So is should call Xmain after the relocation is done. I hacked a little in boot.c: void Xmain(void) { int io; int j, nu; unsigned char * ucp; u_long marks[MARK_MAX]; extern const char bootprog_rev[]; ucp=(unsigned char *)0x201ffffe; //LED Register io = 0; skip = 1; *ucp=0; l1: goto l1; autoconf(); ..it should loop before doing something (besides of displaying an "F" in the LED Display (~0), but every time it halts on 1800.. I'm trying to compile this with the older netbsd (5.2?) Regards, Holm -- Technik Service u. Handel Tiffe, www.tsht.de, Holm Tiffe, Freiberger Stra?e 42, 09600 Obersch?na, USt-Id: DE253710583 www.tsht.de, info at tsht.de, Fax +49 3731 74200, Mobil: 0172 8790 741

Mouse wrote: ... yes, there is something nasty going on while booting from the network. I had this day free, and fiddeled the entire day on this thing, not to much luck. I've setup a cross build environment for Netbsd 4.0.1, 5.2 and 6.0 (used a remote machine that's a lot faster than mine at home). Hacked in the files that's building the boot programm, as far as I now know, that thing thinks that it is getting loaded eighter to zero or 2f0000 in the booting host, while it is linked to 2f0000. I've build a binary now that dissassembled looks like this: boot4: file format elf32-vax Disassembly of section .text: 002f0000 <.text>: 2f0000: 01 nop 2f0001: 01 nop 2f0002: d0 8f 43 00 movl $0x00000043,r2 2f0006: 00 00 52 2f0009: 16 9f 23 4f jsb *0x20044f23 2f000d: 04 20 2f000f: d0 8f 44 00 movl $0x00000044,r2 2f0013: 00 00 52 2f0016: 16 9f 23 4f jsb *0x20044f23 2f001a: 04 20 2f001c: 01 nop 2f001d: 01 nop 2f001e: 00 halt ..... other (real) stuff from netbsds boot comes here. When I depoist those bytes per hand in to 2f0000 and start it, I get this: CD ?06 HLT INST PC = 002F001F CD ?06 HLT INST PC = 002F001F ... all like it should be. (that 20044f23 is your cons_A_TX w/o that leading blbc 1001(r11),0x20044f32 (don't know what that bis should do, so I left it aside) But when I try to boot that file with mop it dos an 83 BOOT SYS -EZA0 2..1..0.. ...and hangs until I press the halt switch. Examining the memory at 2f0000 is showing this: P 002F0000 01 P 002F0001 01 P 002F0002 D0 P 002F0003 8F P 002F0004 00 P 002F0005 00 P 002F0006 2F P 002F0007 00 P 002F0008 5E P 002F0009 C3 P 002F000A 8F P 002F000B 00 P 002F000C 00 P 002F000D 2F P 002F000E 00 P 002F000F 8F P 002F0010 5C P 002F0011 EA P 002F0012 2F P 002F0013 00 P 002F0014 50 P 002F0015 9E P 002F0016 AF P 002F0017 E8 P 002F0018 51 P 002F0019 D0 P 002F001A 8F P 002F001B 00 P 002F001C 00 P 002F001D 2F P 002F001E 00 P 002F001F 53 P 002F0020 28 P 002F0021 50 P 002F0022 61 P 002F0023 63 P 002F0024 C3 P 002F0025 8F P 002F0026 5C P 002F0027 EA P 002F0028 2F P 002F0029 00 P 002F002A 8F P 002F002B F4 P 002F002C 10 P 002F002D 30 P 002F002E 00 P 002F002F 52 P 002F0030 2C P 002F0031 00 P 002F0032 63 P 002F0033 00 P 002F0034 52 P 002F0035 63 P 002F0036 16 P 002F0037 AF P 002F0038 00 P 002F0039 D0 P 002F003A 8F P 002F003B 41 ... I don't have any clue where this is coming from. Since I can only look at this after hlating the system, I don't know what is going on when the rom loader is actually starting my code.. That's not looking any better: P 00000000 00 P 00000001 00 P 00000002 00 P 00000003 00 P 00000004 00 P 00000005 00 P 00000006 00 P 00000007 00 P 00000008 00 P 00000009 00 P 0000000A 00 P 0000000B 00 P 0000000C 00 P 0000000D 00 P 0000000E 00 P 0000000F 00 P 00000010 00 P 00000011 18 ... So the question of today is what the bootloader for the SGEC (eza0) is doing with the booted file on that board. Not really, both programs realize the never come back :-) It is a netbsd ELF File 00000000 7f 45 4c 46 01 01 01 00 00 00 00 00 00 00 00 00 |.ELF............| 00000010 02 00 4b 00 01 00 00 00 00 00 00 00 34 00 00 00 |..K.........4...| 00000020 ac f5 00 00 00 00 00 00 34 00 20 00 01 00 28 00 |??......4. ...(.| 00000030 08 00 07 00 01 00 00 00 60 00 00 00 00 00 2f 00 |........`...../.| 00000040 00 00 2f 00 9c e5 00 00 8c 10 01 00 07 00 00 00 |../..?..........| 00000050 10 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| 00000060 01 01 d0 8f 43 00 00 00 52 16 9f 23 4f 04 20 d0 |..?.C...R..#O. ?| 00000070 8f 44 00 00 00 52 16 9f 23 4f 04 20 01 01 00 d0 |.D...R..#O. ...?| 00000080 8f 00 00 2f 00 5e bb 8f ff 1f c3 8f 00 00 2f 00 |.../.^?.?.?.../.| 00000090 8f 9c e5 2f 00 50 9e ef c4 ff ff ff 51 d0 8f 00 |..?/.P.?????Q?..| 000000a0 00 2f 00 53 d1 51 53 13 1f 28 50 61 63 c3 8f 9c |./.S?QS..(Pac?..| 000000b0 e5 2f 00 8f 8c 10 30 00 52 2c 00 63 00 52 63 dc |?/....0.R,.c.Rc?| 000000c0 7e dd 8f 68 00 2f 00 02 d0 5e ef 11 0a 01 00 fb |~?.h./..?^?....?| 000000d0 00 ef 82 03 00 00 00 01 01 01 01 01 01 01 01 01 |.?..............| 000000e0 00 00 fb 00 ef ff 3e 00 00 da 1f 12 da 00 18 d0 |..?.??>..?..?..?| 000000f0 ac 04 56 d0 ac 14 59 dd ac 08 dd ac 10 9e ef b1 |?.V??.Y??.??..??| 00000100 08 01 00 5a dd 5a 78 09 aa 4c 58 d0 03 5b d4 5a |...Z?Zx.?LX?.[?Z| 00000110 fb 03 66 00 00 00 c2 04 5e 00 04 01 c0 00 c2 04 |?.f...?.^...?.?.| 00000120 5e 9f ef ed c7 00 00 9e ef d5 90 00 00 57 fb 01 |^.???...??...W?.| 00000130 67 d0 ef 81 c9 00 00 50 13 1d 9e ef 78 c9 00 00 |g??.?..P...?x?..| 00000140 56 dd a6 08 dd 50 9f ef d3 c7 00 00 fb 03 67 c0 |V??.?P.???..?.g?| 00000150 0c 56 d0 66 50 12 ea 04 c0 01 9e ae 98 5e db 3e |.V?fP.?.?..?.^?>| 00000160 51 78 8f e8 51 50 d1 50 02 13 03 31 72 01 78 8f |Qx.?QP?P...1r.x.| file boot4 boot4: ELF 32-bit LSB executable, Digital VAX, version 1 (SYSV), statically linked, stripped ..an I wondered myself how a VAX can boot a .elf at all. But I found now way to build a special "netboot" file with netbsd, maybe I missing something here? That may be the case... Only one of the two are realy mine, the other one is borrowed or such, I should try to do something with it. I do have the two disks that where connected to the VME Board before too, but haven't looked at them. That thing has build something like a sea map reader, like a flatbed plotter with a lamp from the bottom of the map, pointing at the actual location of a ship on that map. Don't know how this may be called in english... Regards, Holm -- Technik Service u. Handel Tiffe, www.tsht.de, Holm Tiffe, Freiberger Stra?e 42, 09600 Obersch?na, USt-Id: DE253710583 www.tsht.de, info at tsht.de, Fax +49 3731 74200, Mobil: 0172 8790 741

Seeburg Tisch Regards ? Rod Smallwood ? -----Original Message----- From: cctech-bounces at classiccmp.org [mailto:cctech-bounces at classiccmp.org] On Behalf Of jim s Sent: 02 January 2013 20:17 To: General Discussion: On-Topic and Off-Topic Posts Subject: Re: rtVAX 300. On 1/2/2013 11:52 AM, Holm Tiffe wrote: Ship position or Course indicator. The course indicator would included if there were a ship symbol or some sort of indication on the map as to the orientation of the ship. If just a lighted blip, then just position indicator. Jim

On 2013-01-02 14:06, Holm Tiffe wrote: What about putting this discussion to port-vax at netbsd.org? (you have to sign in ...) I really don't mind having this discussion here, actually I love it, but at the port-vax you get more help booting a vax on netbsd ;-)

On Thu, 3 Jan 2013 09:38:06 +0100 Holm Tiffe <holm at freibergnet.de> wrote: Worked well with 6.0 last time I tried and this was last April. -- \end{Jochen} \ref{http://www.unixag-kl.fh-kl.de/~jkunz/}

On Fri, 2013-01-04 00:44:11 +0100, Alexander Schreiber <als at thangorodrim.de> wrote: Some guy started to hack support for Qemu. I don't know the innards of Qemu, but IIRC he told me that it's driving something like a just-in-time-recompilation approach. If it ever gets to a useable state (ie. the ISA is implemented and enough devices to boot something useful), that might be *quite* fast. MfG, JBG -- Jan-Benedict Glaw jbglaw at lug-owl.de +49-172-7608481 Signature of: Wenn ich wach bin, tr?ume ich. the second :

On Jan 3, 2013, at 10:05 PM, Jonathan Katz <jon at jonworld.com> wrote: I found the following C version of Dhrystone 1.1 at the following URL: http://classes.soe.ucsc.edu/cmpe202/benchmarks/standard/dhrystone.c I have simh-780 running BSD 4.3 found via these instructions: http://gunkies.org/wiki/Installing_4.3_BSD_on_SIMH It's hosted on an OpenBSD VM on my MacBook Pro. It has one CPU assigned: cpu0: Intel(R) Core(TM) i7-3615QM CPU @ 2.30GHz, 2278.19 MHz I used the BSD 4.3 compiler (not gcc), HZ=60, TIMES, and I did NOT use the register setting. According to the source code similar software configurations on a true 11/780 did around 1400 Dhrystones (the version 1.0 of the code had an error, so I'm going off of the 1.1 results in the file.) kremvax# ./dhry Dhrystone(1.1) time for 500000 passes = 12 This machine benchmarks at 40376 dhrystones/second I upped it to LOOPS at 50000000 to get a number that may make more sense, since we're comparing GHZ to MHZ and I think CPUs these days have more on-die cache than some of these systems had in RAM. kremvax# ./dhry Dhrystone(1.1) time for 50000000 passes = 1266 This machine benchmarks at -17034 dhrystones/second OOPS! I think I need to go find a long I left behind somewhere. OK, one more time with LOOPS set to 5000000. ./dhry Dhrystone(1.1) time for 5000000 passes = 133 This machine benchmarks at 37425 dhrystones/second OK, interesting. Finally, I did one more with the REGS setting. kremvax# ./dhry Dhrystone(1.1) time for 5000000 passes = 119 This machine benchmarks at 41811 dhrystones/second So we're looking at 29 times faster. -Jon

On Thu, 3 Jan 2013, Jonathan Katz wrote: Just for grins I compiled and ran this on a Thinkpad T42 and I got this: $ ./drynr ; ./dryr Dhrystone(1.1) time for 500000000 passes = 85 This machine benchmarks at 5882352 dhrystones/second Dhrystone(1.1) time for 500000000 passes = 90 This machine benchmarks at 5555555 dhrystones/second Did I top out the limits of Dhrystone? -- David Griffith dgriffi at cs.csubak.edu A: Because it fouls the order in which people normally read text. Q: Why is top-posting such a bad thing? A: Top-posting. Q: What is the most annoying thing in e-mail?

On Jan 3, 2013, at 11:55 PM, David Griffith <dgriffi at cs.csubak.edu> wrote: Probably hit a limit with the size of the 'int' type or similar with 1.1. There is a 2.0/2.1 package out there which will run on more modern gear, but I couldn't get it to compile with the standard C compiler under BSD 4.3.

On 03/01/13 10:05 PM, Jonathan Katz wrote: Dhrystone was never a great benchmark; it was a poor workload mix and manufacturers famously gamed it, tweaking their runtimes or even their hardware for it. This one is better, and figures are published for quite old machines: http://homepages.cwi.nl/~tromp/c4/fhour.html It does however take a few megabytes of RAM. --Toby

On Wed, 2 Jan 2013 22:06:49 +0100 Holm Tiffe <holm at freibergnet.de> wrote: MOPCOPY(1) General Commands Manual MOPCOPY(1) NAME mopcopy -- Create MOP image from another executable format SYNOPSIS mopcopy infile outfile DESCRIPTION mopcopy is used to convert a file from another executable format to a MOP image. Elf32 and a.out VAX images are currently supported. SEE ALSO mopchk(1), mopprobe(1), moptrace(1), a.out(5), elf(5), mopd(8) AUTHORS Lloyd Parkes Jason R. Thorpe NetBSD 6.0_STABLE June 6, 2002 NetBSD 6.0_STABLE -- \end{Jochen} \ref{http://www.unixag-kl.fh-kl.de/~jkunz/}

Holm Tiffe wrote: Things are getting more interresting lately: 83 BOOT SYS -EZA0 2..1..0..Register contents: r0: 20042f75 r1: ffea00 r2: 1000 r3: ffba00 r4: 0 r5: 0 r6: ffffffff r7: ffffffff r8: 800 r9: 1800 r10: 1800 r11: 0 r12: 200 Regards, Holm -- Technik Service u. Handel Tiffe, www.tsht.de, Holm Tiffe, Freiberger Stra?e 42, 09600 Obersch?na, USt-Id: DE253710583 www.tsht.de, info at tsht.de, Fax +49 3731 74200, Mobil: 0172 8790 741

On Thu, 3 Jan 2013 07:51:09 +0100 Holm Tiffe <holm at freibergnet.de> wrote: Now, IIRC, mopd internaly detects ELF and converts the executable "on the fly" into something MOPable. Ahhhhm. Yes. ;-) -- \end{Jochen} \ref{http://www.unixag-kl.fh-kl.de/~jkunz/}

Jochen Kunz wrote: ...but that's not congruent with what I found out now :-( Jaja... Gru?, Holm -- Technik Service u. Handel Tiffe, www.tsht.de, Holm Tiffe, Freiberger Stra?e 42, 09600 Obersch?na, USt-Id: DE253710583 www.tsht.de, info at tsht.de, Fax +49 3731 74200, Mobil: 0172 8790 741

Mouse wrote: That was for testing purposes only, yes you can see that I know nothing about VAX Assembler... This was only the try to execute some code as early as possible to see that damn thing doing something... The Startup Code in that Binary is in common/srt0.S where I hacked in this 2 charackter outs, there was nothing before at all. The relocation code was later and I wasn't interested what it would do since I placed 2 nops and a halt after the two putchars. After the mopcopy it worked as it should: 2..1..0..CD ...Halt (or something like this) Ok, I read something in the rtVAX User Manual about such a console Bit, than this is it. Yes, but it was still in the memory from tests with that old "mopboot" file, this wasn't the code I'm tried to download on that rtVAX, the MOP simply stalled before it got the code loaded b'cause the file format wasn't the expected Mop Format ... no error message was displayed. As I already wrote, suspicios to me also, but in NetBSD Distribution the file format changed w/o any notice, so I tought it may be working. It where possible to let mopd convert such things on the fly.. Ok, I hacked up that mopcopy from NetBSD (src/usr.sbin/mopd...) so I could compile it with some hand work (normally integrated in NetBSDs makefile structure) and I have at least no a working FreeBSD/I386 binary that is able to build something that boots.. Now the hard work, that booted NetBSD Loader doesn't do anything, at least I see nothing with tcpdump, so I have further to investigate what is going on with that SGEC and the VAX Busses/Adresses/Vectors and such things. At least the SGEC is supported in the Bootcode as boot/if_ze.c (Standalone routine for the SGEC Ethernet controller.) Some Timers may work too since I see the countdown for the autoboot on the Terminal... Regards, Holm -- Technik Service u. Handel Tiffe, www.tsht.de, Holm Tiffe, Freiberger Stra?e 42, 09600 Obersch?na, USt-Id: DE253710583 www.tsht.de, info at tsht.de, Fax +49 3731 74200, Mobil: 0172 8790 741

Holm's email which I was excerpting included two lines (which I didn't quote) which made it clear that disassembly was done with my disassembler, which is capable of recording, for each byte in the file, what it is: instruction, entry mask, data, text string, etc. It also supports annotating the disassembly with comments; it is specifically designed for making sense out of an otherwise undocumented binary (it was first written to deal with a captured piece of malware). /~\ The ASCII Mouse \ / Ribbon Campaign X Against HTML mouse at rodents-montreal.org / \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B

There are two places. The most up-to-date version is available as a git repo; the thing you would want to git clone is git://git.rodents-montreal.org/Mouse/disas. It's also available by anonymous FTP from ftp.rodents-montreal.org in /mouse/disas/src/. (You should be able to cd /mouse/disas and ask for src.tar or src.tar.bz2; the FTP server can tar (and bzip2) on the fly for you.) If you have trouble with it, I can probably help; I also infer that at least one other listmember has got it working and thus might be able and willing to help. /~\ The ASCII Mouse \ / Ribbon Campaign X Against HTML mouse at rodents-montreal.org / \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B

The former depends at least somewhat on the OS in question. But I've added an include of <string.h> everywhere I have an include of <strings.h>. I've also done two other things: (1) I turned VFLAG off entirely in the Makefile, since I usually don't want it these days and this helps others slightly, and (2) I had thought I'd put in a goto workaround for the one place I had labeled control structure, but your remark prompted me to check, finding it had crept back in in the PPC support. So I removed the goto workaround from disas.c, since, since anyone building it needs to have some form of LCS support now, I'd rather go with the more maintainable version of that code. The git repo and the FTPable copy have been updated. /~\ The ASCII Mouse \ / Ribbon Campaign X Against HTML mouse at rodents-montreal.org / \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B

How interesting! For the sake of curiosity, has bigger/better photos? :)

That's true, a disassembler isn't going to be much use unless you have some idea of the assembly language in question. And, yes, VAX assembly language is a relatively powerful one. I don't have a softcopy VAX assembly-langauge reference to point you at, but I have a dead-tree copy of the architecture reference manual, and the parts of it you're likely to care about are in my head as well, so I can answer individual questions easily enough. CMPC3 and CMPC5 aren't the worst of it. There's a lot of stuff that's always looked to me like COBOL support - instructions that, for example, do packed-decimal arithmetic. EDITPC is perhaps the most complex single instruction - it's an overstatement to call it "printf in an instruction", but not by all that much; CVTLP and EDITPC, with suitable operands of course, is the guts of printf's %d format. Originally this stuff was in microcode. But in more recent VAXen have taken to omitting them. Some of them (eg, the KA630) implement them as traps through the SCB, but not normal "unimplemented instruction" traps; I think (the memory is fuzzy) that the KA630 traps oddly: it not only uses a different vector, it runs in the mode of the trapping instruction rather than on the interrupt stack. AIUI, This is so that the kernel can contain a `macrocoded' implementation of the instruction without needing to simulate all the operand fetch/store steps (which are relatively complex on the VAX) to be sure to avoid being a memory-access security hole. I think CMPC3, and maybe CMPC5, are among the instructions done in hardware/microcode on even the more recent hardware, so they're usable /~\ The ASCII Mouse \ / Ribbon Campaign X Against HTML mouse at rodents-montreal.org / \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B

I've sent a few copies to people who've asked for it. I've also put it up at: http://rapidshare.com/files/1542362390/RTVAX300.7z (archived with 7-zip, which hopefully is available to most people). Antonio arcarlini at iee.org

I've no problem with that at all. Regards, Antonio arcarlini at iee.org