Re: [Simh] how to set language number for VAX VMB
On Saturday, December 15, 2018 at 9:08 PM, Ron Young wrote: > I'm playing with the latest version of the microvax 3900 and > 4.3BSD-Quasijarus0c and would like to set default language > in VMB to 5 (us english). If I remember correctly there used > to be a "set language 5" command to do this on real hardware. > > Any idea how to do this on simh? At the boot ROM >>> prompt type HELP: KA655-B V5.3, VMB 2.7 Performing normal system tests. 40..39..38..37..36..35..34..33..32..31..30..29..28..27..26..25.. 24..23..22..21..20..19..18..17..16..15..14..13..12..11..10..09.. 08..07..06..05..04..03.. Tests completed. >>>help Following is a brief summary of all the commands supported by the console: UPPERCASE denotes a keyword that you must type in | denotes an OR condition [] denotes optional parameters <> denotes a field that must be filled in with a syntactically correct value Valid qualifiers: /B /W /L /Q /INSTRUCTION /G /I /V /P /M /STEP: /N: /NOT /WRONG /U Valid commands: DEPOSIT [] [ []] EXAMINE [] [] MOVE [] SEARCH [] [] SET BFLG SET BOOT [:] SET HOST/DUP/UQSSP [] SET HOST/DUP/UQSSP [] SET HOST/MAINTENANCE/UQSSP/SERVICE SET HOST/MAINTENANCE/UQSSP SET LANGUAGE SHOW BFLG SHOW BOOT SHOW DEVICE SHOW ETHERNET SHOW LANGUAGE SHOW MEMORY [/FULL] SHOW QBUS SHOW RLV12 SHOW UQSSP SHOW VERSION HALT INITIALIZE UNJAM CONTINUE START REPEAT X FIND [/MEMORY | /RPB] TEST [ []] BOOT [/R5: | /] [[:]] NEXT [count] CONFIGURE HELP >>> Notice the SET LANGUAGE command. The argument to the SET LANGUAGE command is the number you are prompted with when you see a language inquiry prompt like this: KA655-B V5.3, VMB 2.7 1) Dansk 2) Deutsch (Deutschland/�sterreich) 3) Deutsch (Schweiz) 4) English (United Kingdom) 5) English (United States/Canada) 6) Espa�ol 7) Fran�ais (Canada) 8) Fran�ais (France/Belgique) 9) Fran�ais (Suisse) 10) Italiano 11) Nederlands 12) Norsk 13) Portugu�s 14) Suomi 15) Svenska (1..15): So your memory is correct. Meanwhile, in order for this to persist across invocations of the simulator, you need to save the setting in the same persistent place where it was stored on the original hardware. The original system maintained these type of persistent settings (SET LANGUAGE, SET BOOT, SET BFLG) in the small amount of battery backed up RAM. We simulate this battery backed up RAM by adding something like the following to your configuration file: sim> ATTACH NVR somefilespec Good Luck. - Mark ___ Simh mailing list Simh@trailing-edge.com http://mailman.trailing-edge.com/mailman/listinfo/simh
[Simh] how to set language number for VAX VMB
Hi: I'm playing with the latest version of the microvax 3900 and 4.3BSD-Quasijarus0c and would like to set default language in VMB to 5 (us english). If I remember correctly there used to be a "set language 5" command to do this on real hardware. Any idea how to do this on simh? thanks -ron === Ron Young r...@embarqmail.com ___ Simh mailing list Simh@trailing-edge.com http://mailman.trailing-edge.com/mailman/listinfo/simh
Re: [Simh] VAXELN clock
My question is... how does the TODR get reset from the value read by the ROM to the ELN value with no intervening write? Did it wrap around? Seems unlikely; it shouldn't wrap around before next year. I suspect it's the "OS agnostic mode" that was added in 4.X. According to the writeup, . This mode is enabled by attaching the TODR to a battery backup state file for the TOY clock (i.e. sim> attach TODR TOY_CLOCK). When operating in OS Agnostic mode, the TODR will initially start counting from 0 and be adjusted differently when an OS specifically writes to the TODR. On the first OS boot with an attached TODR VMS will prompt to set the time unless the SYSGEN parameter TIMEPROMPTWAIT is set to 0. So I'd like to see what the behavior is the clock file attached. Or you can post a pointer to the disk image you're using, and I'll try it on 3.10. I saw the ELN kits on 9track.net, but I don't know which one to use. /Bob On 12/15/2018 3:08 PM, simh-requ...@trailing-edge.com wrote: DBG(1041144)> CLK REG: todr_rd(ROM) - TODR=0xC3AA5B84 DBG(7056415)> CLK REG: todr_rd() - TODR=0x132A4 DBG(7056419)> same as above (1 time) DBG(9598293)> CLK REG: todr_rd() - TODR=0x133F0 DBG(11998428)> CLK REG: todr_rd() - TODR=0x13526 DBG(14398563)> CLK REG: todr_rd() - TODR=0x1365C ___ Simh mailing list Simh@trailing-edge.com http://mailman.trailing-edge.com/mailman/listinfo/simh
Re: [Simh] VAXELN, rtVAX-1000, WTC, time
Not really. :-) This gives the technical explanation on how the system works. Bottom line is that you have a TOY clock, and it continues working even with power off. The battery is just the power source of the TOY when main power is off. What is needed to be understood is how the TODR register works. And to clarify things more to the OP, the TOY is then responsible for updating the TODR. So TODR should always continue counting even if power is off. So if you always see low values, it would seem that it gets reset at some point. The TODR have no further meaning. It is just a free running counter incrementing every 10 ms. It's up to the OS to do something clever with it. I don't remember exactly how VMS or anything else use it, but it is used in combination with some information stored in the file system to figure out what the current time is at boot. Johnny On 2018-12-15 22:25, Wilm Boerhout wrote: The few actual reads of the TODR during ELN's execution are returning low values (since nothing actually set the clock yet). Do you get the same result if you don't attach the CLK device? If the result is the same, then it would seem that ELN doesn't care to use the hardware clock for much of anything. Maybe there is some setting within ELN that could influence more direct use of the clock. - Mark This from the rtVAX 1000 System User's Guide (1985) When the system is off, the battery backup unit (BBU) (internal) provides power to the time-of-year (TOY) clock chip on the KA620-A. The code for the user's language is stored in RAM on this chip and is lost if the BBU fails. For more information, see the rtVAX KA620A CPU Module User's Guide That guide is not to be found on line. So what we're really looking for, is a battery. :-) ___ Simh mailing list Simh@trailing-edge.com http://mailman.trailing-edge.com/mailman/listinfo/simh -- Johnny Billquist || "I'm on a bus || on a psychedelic trip email: b...@softjar.se || Reading murder books pdp is alive! || tryin' to stay hip" - B. Idol ___ Simh mailing list Simh@trailing-edge.com http://mailman.trailing-edge.com/mailman/listinfo/simh
Re: [Simh] SimH - PDP8 non existent io devices
On Sat, Dec 15, 2018 at 12:21 PM Harold Bell wrote: > I am mucking around with focal69 Which version? There are two major versions, the paper tape version and the OS/8 version. I assume there are more versions floating around beyond those two. Can you point us to the source of the media images you're using? If it's the paper tape version, please also point us at the instructions you're using for loading it. You may be interested in the PiDP-8/I software distribution: https://tangentsoft.com/pidp8i/ It is known to run on many more types of system than just the Raspberry Pi with the PiDP-8/I board attached: https://tangentsoft.com/pidp8i/wiki?name=OS+Compatibility In fact, the upcoming version has a mode to drop the PiDP-8/I specific extensions to the simulator entirely, allowing it to run faster. We're hoping to get that out before Christmas. Yes, Christmas *this year*. :) If you don't want to use our entire software distribution, we also have pre-built OS/8 RK05 media that you can use with your existing copy of SIMH's PDP-8 simulator: https://tangentsoft.com/pidp8i/#os8 This media includes U/W FOCAL V4E, a significantly more powerful implementation of the language than DEC's original offering. We've got a lot of documentation on this in the project repository, much of it either unique to our project or hand-converted and cleaned up by us, then stored in our repository in web-accessible formats. The cleaned up documents come from OCR'd PDFs you can find elsewhere, but the OCR job on some of them is terrible, making them difficult to search. Start with our U/W FOCAL Manual Supplement and then branch out from there: https://tangentsoft.com/pidp8i/doc/trunk/doc/uwfocal-manual-supp.md If you really want DEC FOCAL 69 for some reason, we also offer that by configuration when building the PiDP-8/I software distribution from source: https://tangentsoft.com/pidp8i/doc/trunk/README.md#enable-os8 You can have it installed alongside U/W FOCAL or instead of it. Keep in mind that an RK05 disk pack is only 2.5 MB, and OS/8 divides it into two logical devices due to the way it addresses the sectors, so you have to be careful how much software you load onto the system half of your OS/8 RK05 boot media. when it initailizes it seems to refer to non existent io device numbers The PDP-8 architecture refers to devices by number in IOT instructions which set aside 6 of their 12 bits for the device number. If you aren't using a pre-configured simulator, such as our PiDP-8/I software distribution, you have to configure SIMH to have the needed devices. The PDP-8 supplement to the SIMH manual tells you what devices are currently available in SIMH, and the main SIMH manual tells you how to enable them in the simulator: https://tangentsoft.com/pidp8i/uv/doc/simh/main.pdf https://tangentsoft.com/pidp8i/uv/doc/simh/pdp8.pdf Those are PDFs converted from the Word DOC files shipped by the SIMH v4 project on GitHub. They were updated less than a week ago, so if there's any discrepancy in the docs vs the simulator you're running, it's that your simulator is too old to have all of the features described. :) Because there are only 64 unique device code in the PDP-8 architecture, and the PDP-8 was one of the most popular computers of all time, some of them got reused. This is most common in the case of "replacement" devices: the TD8E DECtape transport controller effectively replaced the earlier TC08 on PDP-8/e computers, so it reused its predecessor's device code, 77. You therefore have to be careful to supply not only *a* device 77 in your SIMH configuration, but also the *right* device 77. PDP-8 software is often hard-coded to assume one particular device, since there isn't enough core memory space to have fallback implementations for every possible device. Sometimes you have software like OS/8 which lets you re-build it with a different set of devices, but the basic point is the same: at any one time, OS/8 supports only one device 77 type. You have to rebuild the OS to get it to use a different type. > I can't find any google references to. You can search the bitsavers document collection on archive.org. Beyond that, adding "pdp-8" to your search often helps. ___ Simh mailing list Simh@trailing-edge.com http://mailman.trailing-edge.com/mailman/listinfo/simh
Re: [Simh] VAXELN, rtVAX-1000, WTC, time
The few actual reads of the TODR during ELN's execution are returning low values (since nothing actually set the clock yet). Do you get the same result if you don't attach the CLK device? If the result is the same, then it would seem that ELN doesn't care to use the hardware clock for much of anything. Maybe there is some setting within ELN that could influence more direct use of the clock. - Mark This from the rtVAX 1000 System User's Guide (1985) When the system is off, the battery backup unit (BBU) (internal) provides power to the time-of-year (TOY) clock chip on the KA620-A. The code for the user's language is stored in RAM on this chip and is lost if the BBU fails. For more information, see the rtVAX KA620A CPU Module User's Guide That guide is not to be found on line. So what we're really looking for, is a battery. :-) ___ Simh mailing list Simh@trailing-edge.com http://mailman.trailing-edge.com/mailman/listinfo/simh
Re: [Simh] VAXELN, rtVAX-1000, WTC, time
Mark Pizzolato schreef op 15-12-2018 om 21:42: On Saturday, December 15, 2018 at 12:09 PM, Wilm Boerhout wrote: [...] DBG(1041144)> CLK REG: todr_rd(ROM) - TODR=0xC3AA5B84 This line ^^^ and all above it are done by the MicroVAX 3900 boot ROM and have nothing to do with ELN. DBG(7056415)> CLK REG: todr_rd() - TODR=0x132A4 DBG(7056419)> same as above (1 time) DBG(9598293)> CLK REG: todr_rd() - TODR=0x133F0 DBG(11998428)> CLK REG: todr_rd() - TODR=0x13526 DBG(14398563)> CLK REG: todr_rd() - TODR=0x1365C Simulation stopped, PC: 800066EE (BEQL 800066EA) sim> quit Goodbye NVR: writing buffer to file CLK: writing buffer to file Eth: closed tap0 The few actual reads of the TODR during ELN's execution are returning low values (since nothing actually set the clock yet). Do you get the same result if you don't attach the CLK device? If the result is the same, then it would seem that ELN doesn't care to use the hardware clock for much of anything. Maybe there is some setting within ELN that could influence more direct use of the clock. - Mark Thanks Mark for clatifying this. That might well be the case. That is why I'm interested how a real rtVAX preserves its clock. Maybe it didn't, and you had to enter the right time on every boot. In which case simh would be right. These systems would sometimes run for years. Documentation is scarce, however. I havesome leads th real rtVAX-systems, but not very soon. Anyway, with MV3900 the behaviour doesn't change when I do not attach the CLK device. System time starts at VMS Zero. Let's let it rest. I will go out on this thing called The Internet and look better for docs. *Wilm* ___ Simh mailing list Simh@trailing-edge.com http://mailman.trailing-edge.com/mailman/listinfo/simh
Re: [Simh] VAXELN, rtVAX-1000, WTC, time
Mark Pizzolato schreef op 15-12-2018 om 19:10: Hi Wilm, On Saturday, December 15, 2018 at 3:45 AM, Wilm Boerhout wrote: I'm trying to get my head around VAXELN and system time. Before I cry "Wolf" and accuse any innocent program(mer) of instruction obstruction, I want to know how things are supposed to work here (i.e. as on a real rtVAX with VAXELN) I have built a VAXELN system image and can download this into the simh rtVAX. Whatever simh setting I use, the VAXELN system clock always starts at 0, starting time after boot on 17-NOV-1858. I can set the time manually, but it is not preserved across boot. Should it be? simh ini file: echo rtVAX-1000 set CPU diag=MIN 16M idle=ELN conhalt autoboot set WTC time=STD set DZ disable set LPT disable set RL disable set TS disable set TQ disable att -e NVR /opt/ka620.nvr set RQ0 rd54 att -e RQ0 /vdisk/VAXELN.vdisk set XQ type=DEQNA mac=08:00:2B:13:01:92 att XQ TAP:tap0 set DEBUG /opt/ka620.debug set WTC DEBUG boot contents of ka620.debug after booting and shutdown (well, no shutdown on ELN, so ctrl/E) /opt/rtvax1000.ini-20> set DEBUG /opt/ka620.debug Debug output to "/opt/ka620.debug" Debug output to "/opt/ka620.debug" at Sat Dec 15 11:57:42 2018 rtVAX1000 (KA620) simulator V4.0-0 Current git commit id: c2b45a26 /opt/rtvax1000.ini-23> boot Loading boot code from internal ka620.bin DBG(146257)> WTC REG: wtc_rd(pa=0x200B801A [CSRD], data=0x80) VALID1 Simulation stopped, PC: 800066EA (TSTL 8900) sim> quit Goodbye NVR: writing buffer to file Eth: closed tap0 From the debug log it is clear that, although the CSRD register was read and the time it contained was indicated as being VALID, no other references were made by the running system to anything that contained time data so it isn't surprising that the time is 0. Try running ELN with the MicroVAX3900 simulator and see if you get different behavior. - Mark Overall behaviour is the same with the MicroVAX 3900. After booting ELN, time is "VMS Zero", even after setting it to today, then quitting and restarting simh. MV3900 ini file: set CPU 16M idle=ELN conhalt noautoboot att -e CLK /opt/ka655.toy set DZ disable set LPT disable set RL disable set TS disable set TQ disable att -e NVR /opt/ka655.nvr set XQ type=DEQNA mac=08:00:2B:13:01:92 att XQ TAP:tap0 set DEBUG /opt/ka655.debug set CLK debug boot DEBUG output: root@raspi2-old ~ # cat /opt/ka655.debug /opt/pi3k9.ini-19> set DEBUG /opt/ka655.debug Debug output to "/opt/ka655.debug" Debug output to "/opt/ka655.debug" at Sat Dec 15 21:00:59 2018 MicroVAX 3900 simulator V4.0-0 Current git commit id: c2b45a26 /opt/pi3k9.ini-22> boot Loading boot code from internal ka655x.bin DBG(34)> CLK REG: todr_rd(ROM) - TODR=0xC3AA5A39 DBG(961145)> CLK REG: todr_rd(ROM) - TODR=0xC3AA5B6A DBG(962890)> same as above (436 times) DBG(962894)> CLK REG: todr_rd(ROM) - TODR=0xC3AA5B6B DBG(966023)> same as above (781 times) DBG(966027)> CLK REG: todr_rd(ROM) - TODR=0xC3AA5B6C DBG(969151)> same as above (781 times) DBG(969155)> CLK REG: todr_rd(ROM) - TODR=0xC3AA5B6D DBG(972281)> same as above (781 times) DBG(972285)> CLK REG: todr_rd(ROM) - TODR=0xC3AA5B6E DBG(975413)> same as above (782 times) DBG(975417)> CLK REG: todr_rd(ROM) - TODR=0xC3AA5B6F DBG(978541)> same as above (781 times) DBG(978545)> CLK REG: todr_rd(ROM) - TODR=0xC3AA5B70 DBG(981673)> same as above (782 times) DBG(981677)> CLK REG: todr_rd(ROM) - TODR=0xC3AA5B71 DBG(984801)> same as above (781 times) DBG(984805)> CLK REG: todr_rd(ROM) - TODR=0xC3AA5B72 DBG(987933)> same as above (782 times) DBG(987937)> CLK REG: todr_rd(ROM) - TODR=0xC3AA5B73 DBG(991061)> same as above (781 times) DBG(991065)> CLK REG: todr_rd(ROM) - TODR=0xC3AA5B74 DBG(994193)> same as above (782 times) DBG(994197)> CLK REG: todr_rd(ROM) - TODR=0xC3AA5B75 DBG(997321)> same as above (781 times) DBG(997325)> CLK REG: todr_rd(ROM) - TODR=0xC3AA5B76 DBG(1000453)> same as above (782 times) DBG(1000457)> CLK REG: todr_rd(ROM) - TODR=0xC3AA5B77 DBG(1003581)> same as above (775 times) DBG(1003585)> CLK REG: todr_rd(ROM) - TODR=0xC3AA5B78 DBG(1006710)> same as above (780 times) DBG(1006714)> CLK REG: todr_rd(ROM) - TODR=0xC3AA5B79 DBG(1009842)> same as above (782 times) DBG(1009846)> CLK REG: todr_rd(ROM) - TODR=0xC3AA5B7A DBG(1012972)> same as above (781 times) DBG(1012976)> CLK REG: todr_rd(ROM) - TODR=0xC3AA5B7B DBG(1016100)> same as above (781 times) DBG(1016104)> CLK REG: todr_rd(ROM) - TODR=0xC3AA5B7C DBG(1019232)> same as above (782 times) DBG(1019236)> CLK REG: todr_rd(ROM) - TODR=0xC3AA5B7D DBG(1022360)> same as above (781 times) DBG(1022364)> CLK REG: todr_rd(ROM) - TODR=0xC3AA5B7E DBG(1025492)> same as above (782 times) DBG(1025496)> CLK REG: todr_rd(ROM) - TODR=0xC3AA5B7F DBG(1028620)> same as above (781 times) DBG(1028624)> CLK REG: todr_rd(ROM) - TODR=0xC3AA5B80 DBG(1031752)> same as above (782 times) DBG(1031756)> CLK REG:
Re: [Simh] SimH - PDP8 non existent io devices
On 2018-12-15 20:20, Harold Bell wrote: I am mucking around with focal69 and when it initailizes it seems to refer to non existent io device numbers I can't find any google references to. What is the normal procedure when the cpu runs into a reference to an io device that does not exist? Thanks for any guidance. What do you mean? Is the question about what the CPU does if it tries to do operations on a non-existing device, or how you would figure out what type of the device the code is trying to muck around with, or something else? Johnny -- Johnny Billquist || "I'm on a bus || on a psychedelic trip email: b...@softjar.se || Reading murder books pdp is alive! || tryin' to stay hip" - B. Idol ___ Simh mailing list Simh@trailing-edge.com http://mailman.trailing-edge.com/mailman/listinfo/simh
[Simh] SimH - PDP8 non existent io devices
I am mucking around with focal69 and when it initailizes it seems to refer to non existent io device numbers I can't find any google references to. What is the normal procedure when the cpu runs into a reference to an io device that does not exist? Thanks for any guidance. Regards Buddy Bell ___ Simh mailing list Simh@trailing-edge.com http://mailman.trailing-edge.com/mailman/listinfo/simh
Re: [Simh] VAXELN, rtVAX-1000, WTC, time
Hi Wilm, On Saturday, December 15, 2018 at 3:45 AM, Wilm Boerhout wrote: > I'm trying to get my head around VAXELN and system time. > > Before I cry "Wolf" and accuse any innocent program(mer) of instruction > obstruction, I want to know how things are supposed to work here (i.e. > as on a real rtVAX with VAXELN) > > I have built a VAXELN system image and can download this into the simh > rtVAX. Whatever simh setting I use, the VAXELN system clock always > starts at 0, starting time after boot on 17-NOV-1858. I can set the time > manually, but it is not preserved across boot. Should it be? > > simh ini file: > > echo rtVAX-1000 > > set CPU diag=MIN 16M idle=ELN conhalt autoboot > set WTC time=STD > > set DZ disable > set LPT disable > set RL disable > set TS disable > set TQ disable > > att -e NVR /opt/ka620.nvr > > set RQ0 rd54 > att -e RQ0 /vdisk/VAXELN.vdisk > > set XQ type=DEQNA mac=08:00:2B:13:01:92 > att XQ TAP:tap0 > > set DEBUG /opt/ka620.debug > set WTC DEBUG > > boot > > contents of ka620.debug after booting and shutdown (well, no shutdown on > ELN, so ctrl/E) > > /opt/rtvax1000.ini-20> set DEBUG /opt/ka620.debug > Debug output to "/opt/ka620.debug" > Debug output to "/opt/ka620.debug" at Sat Dec 15 11:57:42 2018 > rtVAX1000 (KA620) simulator V4.0-0 Current git commit id: c2b45a26 > /opt/rtvax1000.ini-23> boot > Loading boot code from internal ka620.bin > DBG(146257)> WTC REG: wtc_rd(pa=0x200B801A [CSRD], data=0x80) VALID1 > > Simulation stopped, PC: 800066EA (TSTL 8900) > sim> quit > Goodbye > NVR: writing buffer to file > Eth: closed tap0 From the debug log it is clear that, although the CSRD register was read and the time it contained was indicated as being VALID, no other references were made by the running system to anything that contained time data so it isn't surprising that the time is 0. Try running ELN with the MicroVAX3900 simulator and see if you get different behavior. - Mark ___ Simh mailing list Simh@trailing-edge.com http://mailman.trailing-edge.com/mailman/listinfo/simh
Re: [Simh] MicroVAX II diagnostics tape retrieved
On 2018-12-15 14:07, Wilm Boerhout wrote: Johnny Billquist schreef op 25-10-2018 om 22:44: On 2018-10-25 22:11, Johnny Billquist wrote: On 2018-10-24 15:58, Wilm Boerhout wrote: I found a TK50 cartridge with label -- AQ-GL5AC-DN MF1603 MVII DIAG CUST TK50 Copyright 1985 Digital Equipment Corp. -- and thought it might be useful to someone in the community. It appears to have been stored adequately. I am now looking for a TK50/70 drive to read it. I am in the Netherlands. I have one that says AR-GL5AJ-BN MF1539 MVII DIAG CUST TK50 here. Not sure if it is newer or older. It's a copy someone made at some point, so the label is handwritten, and have no date on it. I am sure I have used it in the past, but I seem to maybe never have made a copy, and as I try to read it on my TK70 right now, I'm getting read errors... :-( Actually, I just remembered that I might have broken that drive a year or two ago... I should try to locate another TK70 drive. Johnny I have finally been able to investigate the tape I acquired, and am sorry to say that the tape broke after the first load. I opened up the cartridge, and apart from the break about a foot from the leader, a section in the middle looks "crumpled" with sections of tape sticking out. I will try and fix the part near to the leader, but don't get your hopes up... Ok. All the more reason for me to get a working TK70 then. I'll see if I can arrange that during Xmas. Johnny -- Johnny Billquist || "I'm on a bus || on a psychedelic trip email: b...@softjar.se || Reading murder books pdp is alive! || tryin' to stay hip" - B. Idol ___ Simh mailing list Simh@trailing-edge.com http://mailman.trailing-edge.com/mailman/listinfo/simh
Re: [Simh] MicroVAX II diagnostics tape retrieved
Johnny Billquist schreef op 25-10-2018 om 22:44: On 2018-10-25 22:11, Johnny Billquist wrote: On 2018-10-24 15:58, Wilm Boerhout wrote: I found a TK50 cartridge with label -- AQ-GL5AC-DN MF1603 MVII DIAG CUST TK50 Copyright 1985 Digital Equipment Corp. -- and thought it might be useful to someone in the community. It appears to have been stored adequately. I am now looking for a TK50/70 drive to read it. I am in the Netherlands. I have one that says AR-GL5AJ-BN MF1539 MVII DIAG CUST TK50 here. Not sure if it is newer or older. It's a copy someone made at some point, so the label is handwritten, and have no date on it. I am sure I have used it in the past, but I seem to maybe never have made a copy, and as I try to read it on my TK70 right now, I'm getting read errors... :-( Actually, I just remembered that I might have broken that drive a year or two ago... I should try to locate another TK70 drive. Johnny I have finally been able to investigate the tape I acquired, and am sorry to say that the tape broke after the first load. I opened up the cartridge, and apart from the break about a foot from the leader, a section in the middle looks "crumpled" with sections of tape sticking out. I will try and fix the part near to the leader, but don't get your hopes up... *Wilm* ___ Simh mailing list Simh@trailing-edge.com http://mailman.trailing-edge.com/mailman/listinfo/simh
[Simh] VAXELN, rtVAX-1000, WTC, time
I'm trying to get my head around VAXELN and system time. Before I cry "Wolf" and accuse any innocent program(mer) of instruction obstruction, I want to know how things are supposed to work here (i.e. as on a real rtVAX with VAXELN) I have built a VAXELN system image and can download this into the simh rtVAX. Whatever simh setting I use, the VAXELN system clock always starts at 0, starting time after boot on 17-NOV-1858. I can set the time manually, but it is not preserved across boot. Should it be? simh ini file: echo rtVAX-1000 set CPU diag=MIN 16M idle=ELN conhalt autoboot set WTC time=STD set DZ disable set LPT disable set RL disable set TS disable set TQ disable att -e NVR /opt/ka620.nvr set RQ0 rd54 att -e RQ0 /vdisk/VAXELN.vdisk set XQ type=DEQNA mac=08:00:2B:13:01:92 att XQ TAP:tap0 set DEBUG /opt/ka620.debug set WTC DEBUG boot contents of ka620.debug after booting and shutdown (well, no shutdown on ELN, so ctrl/E) /opt/rtvax1000.ini-20> set DEBUG /opt/ka620.debug Debug output to "/opt/ka620.debug" Debug output to "/opt/ka620.debug" at Sat Dec 15 11:57:42 2018 rtVAX1000 (KA620) simulator V4.0-0 Current git commit id: c2b45a26 /opt/rtvax1000.ini-23> boot Loading boot code from internal ka620.bin DBG(146257)> WTC REG: wtc_rd(pa=0x200B801A [CSRD], data=0x80) VALID1 Simulation stopped, PC: 800066EA (TSTL 8900) sim> quit Goodbye NVR: writing buffer to file Eth: closed tap0 contents of ka620.nvr: pi@raspi2-old ~ $ hexdump /opt/ka620.nvr 000 0220 010 fe00 00ff fe00 020 00ff fe00 00ff 4548 5041 030 040 ___ Simh mailing list Simh@trailing-edge.com http://mailman.trailing-edge.com/mailman/listinfo/simh
