Re: Ultrix 3.0 VAX
Dennis, It sounds like you are looking for an Ultrix 3.0 standalone boot tape. While I found a number of people who claim to have a physical tape, with some claiming to have imaged the tape, I was unable to find an image on-line. That being said, it’s possible to use the Ultrix 2.0 standalone bootable tape (AQ-JU00C, available from bitsavers.org) with a couple of edits at the end - I did this to get 2.2 up and running. Since Ultrix 2.0 only supports a limited number VAX processors, the first stage has to be run on one of those processors, I always use microvax2. Subsequent stages may be run on any processor supported by Ultrix 3.0. Stage 1: I use the following .ini file: # Boot from standalone tape. This MUST be performed on a microvax2 instance. set rl dis set ts dis set rq0 ra81 att rq0 system.dsk att tq0 AQ-JU00C-BE_ULTRIX-32_2.0_SA_87.tap set tti 7b set tto 7b boo Attach the Ultrix 3.0 supported tape to tq0 when it asks. This stage will create the root partition and restore from the tape. No special handling at this point, just answer the questions as for a normal install. Stage 2: Use the VAX simulator for the target system (I used vax780) and boot rq0. After answering some questions it will fail trying to create a file system on /dev/rra0 which doesn’t exist - you need to edit /.minidevice as follows: # ed .minidevice 22 1 RA81 ra 0 TK50 tms 0 s/0/0g RA81 ra 0g TK50 tms 0 w 23 q Reboot the system and it will create a file system on /dev/ra0g, copy the base packages along with any you have selected and build a custom kernel. After all this reboot again and it will drop you into single user mode after complaining about "Can't stat /dev/ra0ga”. Edit /etc/fstab: # ed /etc/fstab 54 1 /dev/ra0ga:/:rw:1:1:ufs:: s/0g/0 /dev/ra0a:/:rw:1:1:ufs:: w 53 q Reboot again and you should have a functioning system. John.
Re: Televideo 925 character rom dump
On Wed, Apr 24, 2019 at 8:51 PM Al Kossow via cctalk wrote: > > > > The keyboard controller is an 8049. Firmware not readable. > > It may actually be compatible with the 955 keyboard, which I was able to > read. > Key layout is the same, though the manuf is different > The 924 should be the same as a 955 keyboard. There seemed to be two compatible types of the keyboard - an older thicker keyboard (shipped the TS-803 et al, and looks like an enhanced 925/950 keyboard), and a newer thinner profile keyboard used on later terminals. >From what I've figured out, the 955 uses a 6-pin connector at 9600 baud with both Tx and Rx used, and a reset line and +12V power. The 925/950 use a 4-pin connector, replaces the Tx to keyboard line with a speaker connection, drops the reset line, and runs at 1200 baud as compared to the 955 keyboard. The keyboard should be the same between the 905, 955, 970, TS-803, and some others with the possible difference of some legends on keycaps. The TS-802, 800A, 925, and 950 use the same keyboard +/- some legends. Later terminals like the 965 use a 4-pin connector with a different pinout, and +5V supply instead of +12V, but still at 9600 baud with the same codes as the 970/etc. I believe that the transmitted codes are the same for all of them, but the older 925/950 keyboard is missing some keys than the later 970/955/etc have. The TPC-I, TPC-II, TS-1605 all use a PC/XT-like keyboard interface, but with a +12V power supply instead of +5V. I haven't quite verified if one can swap them with XT keyboards with an alternate power supply yet, but it may be possible. It seems like they should be compatible since the TS-1605/TPC-II are fairly compatible with PC/XTs. Pat
TSX-Plus help needed!
OK, I have figured out how to modify TSGEN.MAC, use PUTR to make a disk image, load it in SIMH, reassemble, relink, and *finally* send it to an RL02 pack via vtserver! TIme-consuming but doable. I've been wrestling with this all day. BUT - TSX+ 6.50 just will not run. At all. Using RT-11SJ (5.01), after typing "R TSX" I can hear the disc access for a few seconds, a pause, a few more accesses... then nothing. It just hangs. Nothing on the console either., no response to . When starting it in SIMH (the same disk image), I get the error message ?TSX-F-Computer line clock is not working. Figured that was just a SIMH thing. But the address/vector is correct in TSGEN.MAC... and when checking TIME in RT-11, the seconds advance in real-time like it should. On the real hardware, the error message doesn't display, and the clock is running... My old version of TSX+ is 6.16 and it runs fine on console and SLU 2, just needs rebuilt to use different serial cards than the original system. So where should I start looking first? RT-11 version incompatibility? Any TSX+ experts online? Thanks for any help. This is driving me nuts!
Re: Televideo 925 character rom dump
The keyboard controller is an 8049. Firmware not readable. It may actually be compatible with the 955 keyboard, which I was able to read. Key layout is the same, though the manuf is different
Re: Televideo 925 character rom dump
On 04/24/2019 08:47 PM, Al Kossow via cctalk wrote: > > On 4/24/19 5:46 PM, allison via cctalk wrote: > >> The 8049 is readable just like the 8048 save for 2k device. I worked >> for NEC back then and had access to intel parts too. > is that true for "HC" parts or just NMOS? > > All! The HC were different lower power process thats all. if it were 8051 thats different. My samples include NMOS, NMOSII, and HCMOS. and the NEC parts through CMOS Allison
Re: VTserver problem (bug?)
And even more bizarrely... it crawled its way up to the 7400K block, and now it's going at normal speed again! 10MB should be done soon. I have no idea what could be causing this major slowdown from 6.6-7.4 MB. It's not the drive because two different ones do the same thing (and they work perfectly otherwise)... Hopefully I won't have to go through the (edit, reassemble, relink, PUTR transfer to an image, vtserver to the disk) loop too many times, attempting to get my DHV11/16D to function with TSX+ 6.50... I had somehow inserted a couple of characters that didn't belong there while editing (bumped the keyboard maybe?) so I'm on the second pass. Also I found what looks like a typo in the TSGEN.MAC file if anyone's interested.
Re: Televideo 925 character rom dump
On 4/24/19 5:46 PM, allison via cctalk wrote: > The 8049 is readable just like the 8048 save for 2k device. I worked > for NEC back then and had access to intel parts too. is that true for "HC" parts or just NMOS?
Re: Televideo 925 character rom dump
On 04/24/2019 07:55 PM, Guy Dunphy via cctalk wrote: > At 08:14 AM 24/04/2019 -0700, you wrote: >> >> On 4/24/19 5:39 AM, Guy Dunphy wrote: >> >>> The keyboard controller is an 8049. Firmware not readable. >> 8049s aren't protected. they are 2k versions of the 8048 >> and can be read as 8749s > I did try reading it as an 8749. By 'not readable' I meant it read as all FF. > Using a Topmax device programmer; a fairly good brand. > Interestingly when I selected Intel 8749 it actually hung on reading. > Repeatably. Never seen that happen before. > Selecting NEC 8749, it read, but got all FFs. > Considering there's something odd going on, I was quite relieved to verify > the chip still works afterwards. > I hadn't gone as far as getting out the databooks and checking whether 8049 > should be readable. > I thought they are, but the absense of '8049' type in the chip programmer > seemed to suggest otherwise. Unless they > were 'induced' to leave it out to hinder copying? > Shall look into it further. > > Guy > The 8049 is readable just like the 8048 save for 2k device. I worked for NEC back then and had access to intel parts too. If you can't read it its your programmers fault, FYI the set up is nearly the same as 8749 but the voltage for the read function is lower. Here is except of page 2-19 of the intel MCS48 family manual july 78... "The processor is placed in the READ mode by applying a high voltage (+25V for the 8748, +12V for the 8048/8049) to the EA pin and +5V to the TO (8748 only) input pin. RESET must be at OV when voltage is applied to EA. The address of the location to be read is then applied to the same lines (TTL levels) of BUS and Port 2 which output the address during single step (see below), The address is latched by a "0" to "1" transition on RESET and a high level on RESET causes the contents of the program memory location addressed to appear on the eight lines of BUS." It is possible that the devices is being used with external rom/eprom the test for that is pin7 EA, if EA is high then program access is external. it was very common to use any 8048/49 in place of 8035/39 in a system and often cheaper due to misprogrammed parts that can still be used with external rom. FYI there are no "protection bits". Allison
Re: VTserver problem (bug?)
-Original Message- But there is some kind of bug that always appears at the same point, in the middle of the next 100K block after "6600K written". The data transfer stops (no more head motion/ready light flicker on the RL02), and the character that vtserver uses to indicate a write operation just repeats endlessly and rapidly until I kill it. More information and a correction: I let it run on, and it is still reading and writing, but at a much slower and intermittent rate than the first 6.6 MB. The filler character is just a time marker of some kind, since I can still see the "r" indicating a read from the .dsk image, and the light on the RL02 flickers after a few of those. So it's slowed way down, but not stopped! Even more mysterious. Anyway, this disk has 13800 blocks out of 20800 used. If RT-11 stores data (including the directory structure) starting from block 0, I may be able to kill the writes after 7 MB. (Unfortunately I think I neglected to squeeze the image before sending it to the RL - and naturally the important TSX files are near the end - which means I have to wait for most of it). If I have to do it again, I'll squeeze and then kill it after 7 MB and see what I got!
Re:
But there is some kind of bug that always appears at the same point, in the middle of the next 100K block after "6600K written". The data transfer stops (no more head motion/ready light flicker on the RL02), and the character that vtserver uses to indicate a write operation just repeats endlessly and rapidly until I kill it. More information and a correction: I let it run on, and it is still reading and writing, but at a much slower and intermittent rate than the first 6.6 MB. The filler character is just a time marker of some kind, since I can still see the "r" indicating a read from the .dsk image, and the light on the RL02 flickers after a few of those. So it's slowed way down, but not stopped! Even more mysterious. Anyway, this disk has 13800 blocks out of 20800 used. If RT-11 stores data (including the directory structure) starting from block 0, I may be able to kill the writes after 7 MB. (Unfortunately I think I neglected to squeeze the image before sending it to the RL - and naturally the important TSX files are near the end - which means I have to wait for most of it). If I have to do it again, I'll squeeze and then kill it after 7 MB and see what I got!
Re: Televideo 925 character rom dump
Thanks, I'll check that. At 07:48 AM 24/04/2019 -0500, wrco...@wrcooke.net wrote: > >> On April 24, 2019 at 7:39 AM Guy Dunphy via cctalk >> wrote: >> > >> I haven't dumped the chargen chip yet, because I don't know what it is, and >> suspect it's more complex than just a ROM. >> 24 pin character gen ROM/? at U10 is marked: >> >> VTi (logo) >> 350 RN 118 >> 2333-5006 >> 8000142 >> (c)TELEVIDEO 1983 >> KOREA-AE >> >> >> Guy > >Likely an MOS Tech 2333 ROM chip. >http://www.bitsavers.org/components/mosTechnology/_dataBooks/1982_MOS_Technology_Data_Catalog.pdf >See page 2-145 > >Will
Re: Televideo 925 character rom dump
At 08:14 AM 24/04/2019 -0700, you wrote: > > >On 4/24/19 5:39 AM, Guy Dunphy wrote: > >> The keyboard controller is an 8049. Firmware not readable. > >8049s aren't protected. they are 2k versions of the 8048 >and can be read as 8749s I did try reading it as an 8749. By 'not readable' I meant it read as all FF. Using a Topmax device programmer; a fairly good brand. Interestingly when I selected Intel 8749 it actually hung on reading. Repeatably. Never seen that happen before. Selecting NEC 8749, it read, but got all FFs. Considering there's something odd going on, I was quite relieved to verify the chip still works afterwards. I hadn't gone as far as getting out the databooks and checking whether 8049 should be readable. I thought they are, but the absense of '8049' type in the chip programmer seemed to suggest otherwise. Unless they were 'induced' to leave it out to hinder copying? Shall look into it further. Guy
VTserver problem (bug?)
I sometimes use vtserver to download disk images to the RL02's on my PDP-11/23+. Takes quite a while at 9600 baud, too :) But there is some kind of bug that always appears at the same point, in the middle of the next 100K block after "6600K written". The data transfer stops (no more head motion/ready light flicker on the RL02), and the character that vtserver uses to indicate a write operation just repeats endlessly and rapidly until I kill it. Does anyone else encounter this limitation, and if so, how did you fix it? Fortunately I haven't wanted to image a disk that's more than 2/3 full so far... I make sure to squeeze the disk in SIMH before transferring the image. But it'd be nice to be able to image a full (10 MB) RL02 and not have to worry about it failing. Any ideas? thanks Charles
Re: SIMH question
On Wed, 24 Apr 2019 at 05:08, Charles via cctalk wrote: > Thanks... unfortunately I'm running 64-bit Windows and just discovered PUTR > will only run on a 32-bit (or even older) machine. 32-bit code _should_ run on 64-bit Win7/8.x/10. 16-bit code won't. Win7 has "XP Mode", which is a free download. It is MS VirtualPC plus a preinstalled, preactivated Win XP VM. It is possible to download run this VM image separately and run it under other hypervisors -- I described how here: https://www.theregister.co.uk/Print/2014/04/10/how_to_run_xp_on_new_windows/ What I dodged around is that you need a licence. Cracking it is also an option, of course. It just ended this month but there is also a legal hack to get another 5y of updates for XP. https://www.theregister.co.uk/2014/05/26/german_tinkerer_gets_around_xpocalypse/ Personally I used a 3rd party "distro" of XP called TinyXP (I used r9) for years. I would not recommend this any more, TBH, but it's possible. The same person, "eXPerience", who made TinyXP also made a Tiny7. It works but SP2 won't install, at which point they gave up. You _could_ run 32-bit Win10 under VirtualBox. I've done it. It works well, the ISO is a free download from Microsoft, and it's perfectly usable without activation. -- Liam Proven - Profile: https://about.me/liamproven Email: lpro...@cix.co.uk - Google Mail/Hangouts/Plus: lpro...@gmail.com Twitter/Facebook/Flickr: lproven - Skype/LinkedIn: liamproven UK: +44 7939-087884 - ČR (+ WhatsApp/Telegram/Signal): +420 702 829 053
Re: SIMH question
On 4/24/19 10:14 AM, Paul Koning via cctalk wrote: On Apr 24, 2019, at 11:05 AM, Noel Chiappa via cctalk wrote: From: Glen Slick when I wanted to assemble some code with the RT-11 assembler but wanted to edit the source code elsewhere and then transfer the code into a SIMH disk image. Someone should write the SIMH equivalent of Ersatz-11's 'DOS device' (which allows the -11 access to the file system on the host - and also the ability to send arbitrary commands to the emulator). Alternatively, a newer PUTR. I started such a thing as an extension to flx.py a while ago but only did a few small bits. For RT11 (and TSX+) filesystem images I have used pyRT11 - https://gitlab.com/NF6X_Retrocomputing/pyRT11
Re: SIMH question
> On Apr 24, 2019, at 11:05 AM, Noel Chiappa via cctalk > wrote: > >> From: Glen Slick > >> when I wanted to assemble some code with the RT-11 assembler but wanted >> to edit the source code elsewhere and then transfer the code into a >> SIMH disk image. > > Someone should write the SIMH equivalent of Ersatz-11's 'DOS device' (which > allows the -11 access to the file system on the host - and also the ability > to send arbitrary commands to the emulator). Alternatively, a newer PUTR. I started such a thing as an extension to flx.py a while ago but only did a few small bits. paul
Re: Televideo 925 character rom dump
On 4/24/19 5:39 AM, Guy Dunphy wrote: > The keyboard controller is an 8049. Firmware not readable. 8049s aren't protected. they are 2k versions of the 8048 and can be read as 8749s
RK611 Technical Manual needed
Anyone have a copy of the RK611 Technical Manual (EK-RK611-TM-001 is the version that's attested)? It's not online. (I have a copy in my fiche set, but my fiche reader died - no, it's not the bulb, already changed that! :-) Noel
Re: Infocom mystery binary
At 05:14 AM 4/24/2019, David Griffith via cctalk wrote: >When I first noticed that the binary wasn't stripped, I tried poking around >with assorted disassemblers and decompilers hoping to get something resembling >C code out of it. And you found what? - John
Re: Televideo 925 character rom dump
> On April 24, 2019 at 7:39 AM Guy Dunphy via cctalk > wrote: > > I haven't dumped the chargen chip yet, because I don't know what it is, and > suspect it's more complex than just a ROM. > 24 pin character gen ROM/? at U10 is marked: > > VTi (logo) > 350 RN 118 > 2333-5006 > 8000142 > (c)TELEVIDEO 1983 > KOREA-AE > > > Guy Likely an MOS Tech 2333 ROM chip. http://www.bitsavers.org/components/mosTechnology/_dataBooks/1982_MOS_Technology_Data_Catalog.pdf See page 2-145 Will "A designer knows he has achieved perfection not when there is nothing left to add, but when there is nothing left to take away." -- Antoine de Saint-Exupery "The names of global variables should start with // " -- https://isocpp.org
Re: Televideo 925 character rom dump
At 04:34 PM 23/04/2019 -0700, you wrote: > > >On 4/23/19 3:35 PM, Guy Dunphy via cctalk wrote: [my Televideo 924] > >I have maint manuals for the 925. > >Some photos of the boards and dumps of the keyboard firmware and controller >would be nice to add to bitsavers, since I've not come across one. See pics and ROM images at http://everist.org/pics/televideo_924/ I haven't dumped the chargen chip yet, because I don't know what it is, and suspect it's more complex than just a ROM. 24 pin character gen ROM/? at U10 is marked: VTi (logo) 350 RN 118 2333-5006 8000142 (c)TELEVIDEO 1983 KOREA-AE See http://everist.org/pics/televideo_924/20190424_3338_chargen.jpg The keyboard controller is an 8049. Firmware not readable. Guy
Re: Infocom mystery binary
My reply is at the bottom. Please put your reply there too. On Wed, 24 Apr 2019, Ethan Dicks wrote: On Tue, Apr 23, 2019 at 9:58 PM David Griffith via cctalk wrote: In one of the repositories of Infocom game source code recently uploaded to Github, there's an executable that appears to have come from an m68k Unix machine of some sort. It's at https://github.com/historicalsource/zork-german/blob/master/zap. Over at intfiction.org[1], it was initially claimed to be from a Macintosh. Then I suggested it was from a pre-Sparc Sun machine. Then someone else suggested it was from A/UX. Does anyone know anything more conclusive? Doing file(1) on it, I get... $ file zap zap: mc68k COFF object not stripped (demand paged) I also happen to have another version (not from github) $ file sun/zap mc68020 demand paged dynamically linked executable not stripped _That_ one is a Sun3 binary. I see. Mystery solved! Oooo... Where did that one come from? When I first noticed that the binary wasn't stripped, I tried poking around with assorted disassemblers and decompilers hoping to get something resembling C code out of it. -- David Griffith d...@661.org 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?
