- cctalk - classiccmp.org

by Kurt Nowak

Hey all - I came across a big box of 12 of these disks which my dad acquired through work back in the 70s, and squirreled them away in the attic after they had copied the data. 4 of them have a broken metal access door. I opened one of the broken ones (in a clean of an environment as possible) to see what was going on inside. It looks like the door is held on by plastic divets that have broken off. They might be able to be repaired with small screws. I have no idea if these are functional or not. I am offering them up for free for anyone that can use them. I'm willing to ship or you pick up in San Diego. Here is a link to photos of them: https://drive.google.com/drive/folders/1wnzqjAtiq44MGU-wDJR-AQdzu-Mkyii8?us… -Kurt

14 hours, 7 minutes

15
30
0 0

Stewart Cheifet from The Computer Cronicles passed Dec 28th 2005

by Christian Liendo

https://obits.goldsteinsfuneral.com/stewart-cheifet He came to VCF East, this was his presentation https://youtu.be/Ncnje4DdRxE.

16 hours, 3 minutes

1
0
0 0

Re: Philips P2000C disk format

by Francis Massen

To use Greaseweazle with a 640kB drive (5.25, 80 track, DSDD) use the acorn.adfs.640 definition (diskdefs); it works like a charm ! More here: https://computarium.lcd.lu/literature/COMPUTARIUM_CREW/MASSEN/HANDLING_VINT… Francis PS: I am looking for a Kermit version usable with my P2000C (it is the 2010-1 model, very similar to the 2012); everything I tried until now did not work correctly...

1 day, 17 hours

2
2
0 0

i8008 and interrupts

by Robert Armstrong

Can someone explain how the Intel 8008 (yes, the 8008, NOT the 8080!) handled saving and restoring the flags during an interrupt? The 8008 has four flag bits - CZS&P - but there doesn't seem to be any explicit equivalent to the PSW register nor any "PUSH PSW" or "POP PSW" type instructions. Other than testing the flag bits with the JUMP/CALL/RET instructions there doesn't seem to be any way to access them. Interrupts work pretty much like the 8080 - during the interrupt response the peripheral forces an instruction onto the bus, typically an RST opcode but in theory it could be anything. RST and CALL however only appear to save the PC on the internal stack, and RET only restores the PC. So how do you save and restore the flag bits? It seems like interrupts would be pretty much useless without this, so I must be missing something. Thanks,

5 days, 16 hours

5
8
0 0

Re: i8008 and interrupts

by trp

I didn’t see anyone post this clever way to save and restore flags in interrupt for the 8008. This is from https://stevemorse.org/8086history/8086history.pdf APPENDIX 1 SAVING AND RESTORING FLAGS IN THE 8008 Interrupt routines must leave all processor flags and registers unaltered so as not to contaminate the processing that was interrupted. This is most simply done by having the interrupt routine save all flags and registers on entry and restore them prior to exiting. The 8008, unlike its successors, has no instruction for directly saving or restoring flags. Thus 8008 interrupt routines that alter flags (practically every routine does) must conditionally test each flag to obtain its value and then save that value. Since there are no instructions for directly setting or clearing flags, the flag values must be restored by executing code that will put the flags in the saved state. The 8008 flags can be restored very efficiently if they are saved in the following format in a byte in memory. Most significant bit = bit 7 bit 7 = original value of CARRY bit 6 = original value of SIGN bit 5 = original value of SIGN bit 4 = 0 bit 3 = 0 bit 2 = complement of original value of ZERO bit 1 = complement of original value of ZERO bit 0 = complement of original value of PARITY With the information saved in the above format in a byte called FLAGS, the following two instructions will restore all the saved flag values: LDA FLAGS ;load saved flags into accumulator ADD A ;add the accumulator to itself This instruction sequence loads the saved flags into the accumulator and then doubles the value, thereby moving each bit one position to the left. This causes each flag to be set to its original value, for the following reasons: The original value of the CARRY flag, being in the leftmost bit, will be moved out of the accumulator and wind up in the CARRY flag. The original value of the SIGN flag, being in bit 6, will wind up in bit 7 and will become the sign of the result. The new value of the SIGN flag will reflect this sign. The complement of the original value of the PARITY flag will wind up in bit 1, and it alone will determine the parity of the result (all other bits in the result are paired up and have no net effect on parity). The new setting of the PARITY flag will be the complement of this bit (the flag denotes even parity) and therefore will take on the original value of the PARITY flag. Whenever the ZERO flag is 1, the SIGN flag must be 0 (zero is a positive two's- complement number) and the PARITY flag must be 1 (zero has even parity). Thus an original ZERO flag value of 1 will cause all bits of FLAGS, with the possible exception of bit 7, to be 0. After the ADD instruction is executed, all bits of the result will be 0 and the new value of the ZERO flag will therefore be 1. An original ZERO flag value of 0 will cause two bits in FLAGS to be 1 and will wind up in the result as well. The new value of the ZERO flag will therefore be 0. The above algorithm relies on the fact that flag values are always consistent, i.e., that the SIGN flag cannot be a 1 when the ZERO flag is a 1. This is always true in the 8008, since the flags come up in a consistent state whenever the processor is reset and flags can only be modified by instructions which always leave the flags in a consistent state. The 8080 and its derivatives allow the programmer to modify the flags in an arbitrary manner by popping a value of his choice off the stack and into the flags. Thus the above algorithm will not work on those processors. A code sequence for saving the flags in the required format is as follows: MVI A,0 ; move zero in accumulator JNC L1 ; jump if CARRY not set ORA 80H ; OR accumulator with 80 hex (set bit 7) L1: JZ L3 ; jump if ZERO set (and SIGN not set and PARITY set) ORA 06H ; OR accumulator with 06 hex (set bits 1 and 2) JM L2 ; jump if negative (SIGN set) ORA 60H ; OR accumulator with 60 hex (set bits 5 and 6) L2: JPE L3 ; jump if parity even (PARITY set) ORA 01H ; OR accumulator with 01 hex (set bit 0) L3: STA FLAGS ; store accumulator in FLAGS

5 days, 17 hours

1
0
0 0

Re: Hot Video Shift Register on VT100

by Rob Jarratt

I found some time to look at this again today. A few answers below. > -----Original Message----- > From: Martin Bishop <mjd.bishop(a)emeritus-solutions.com> > Sent: 30 November 2025 23:12 > To: rob(a)jarratt.me.uk; General Discussion: On-Topic and Off-Topic Posts > <cctalk(a)classiccmp.org> > Subject: RE: [cctalk] Re: Hot Video Shift Register on VT100 > > A short ground lead is 10 mm, from probe tip to ground spring see eg > https://www.aliexpress.com/item/1005007465068388.html > > However, ground springs require ground planes surrounding test points, or > test / ground point PEC layouts - very unlikely on a volume PCB. > > A 100 mm ground lead is neither short nor likely to be free of ringing. To > eliminate CRO probe ringing seriously short grounds are essential. > I pre-emptively bought an oscillator (24MHz and not 24.07342Mz) and tried it on a breadboard. This gave me the same signal with a negative spike on the falling edge. Although I don't have a ground spring I managed to shorten the ground connection considerably and this did indeed clear up the signal and it looked a lot squarer, without the negative spike. I lifted the original oscillator, but the leads on it are too short to work on my breadboard so I can't verify the same behaviour, but it seems highly likely that you are right that the negative spike is not real. That leaves me with the 74S299 still getting hot for reasons I don't understand. Maybe it is just the design, but the same chip in a VT102 doesn't get nearly so hot. Someone else suggested replacing it with a 74F299, so maybe I will try this now that I have socketed it. Regards Rob > Regarding some of the other points raised: > - 24.072 MHz is likely to be a magic number for video rates, with 24 MHz > YMMV > - the negative excursion may be clamped somewhere by diode(s) to gnd, > hence -1v2 .. - 1v4 excursion > - fast edges can be softened by a series resistor (22 .. 33 R say) following the > driver, triksy to retrofit > - are the power rails clean, on a scope, only pertinent if the spikes are > asynchronous to the signal(s) > > HtH; Martin >

5 days, 23 hours

6
13
0 0

Editing files in VMS over a telnet connection

by Peter Ekstrom

I feel like I have tried everything, although I'm sure I haven't... I have my real MV 3100 up and running with a serial terminal on the console port. It works great but I don't want to sit by the machine all the time to do stuff. I have DECnet running and am able to connect to it. I have an old raspberry pi running a minimal linux setup with the decnet stuff installed. So I ssh to the pi (named gatewy) and from there I use dnlogin to talk DECnet and connect to the machines. This way I can connect to my PDP-11 machines running RSX11M and M+ and use EDT to edit files in screen mode. When I try the same under VMS, EDT starts, loads the file and enters screen mode but just shows a blank screen with the cursor in the top-left corner. If I go to line mode I can walk through the file and edit using line mode. But as soon as I go back to the screen mode (the change command) I just get the blank screen. I have made sure TERM in each shell is vt100 and I have tried forcing VMS to VT100 but it stays with a vt200_series terminal. I also have a SIMH MV3100 also running VMS 5.3-1 (they both run on that version) and it acts the same way as the hardware MV3100. If I go onto the console connection in SIMH EDT works fine, as on the physical terminal on the real machine. Anyone have any pointers or ideas I can try? - Peter

6 days, 15 hours

7
15
0 0

Early delivery from Santa's sleigh

by Brian L. Stuart

So Santa had his sleigh out for some test drives tonight. For ballast (the real gifts won't be loaded until Wed night), he used a big stack of engineering drawings from the 1940s. Fortunately for us, his "spirited" driving included one turn that was too tight and out flew the drawings, where they landed on my lap. For anyone who's as eager as I am to geek out over 1940s computer design, I share them with you here: http://cs.drexel.edu/~bls96/eniac/drawings/ There are over 900 drawings in the set. Most of these images come from scans of microfilm taken of the patent trial exhibits. There are also about 100 copies that the Smithsonian had imaged and put up on their web site. I've processed them all to approximate something like we remember from our technical drawing classes in college (well those of us old enough to have taken them). The quality varies widely, but a large subset are readable down to the measurements for the panels and the component values in the circuits. If you've read Kathy Kleiman's excellent book (Proving Ground) about the original ENIAC programmers, you may have found yourself wondering what the block diagrams from which they figured out how to program the machine looked like. Well, those are among the drawings here. So feel free to try your hand at figuing out how to program it from them. One subset of the drawings is conspicuous by its absence, the PX-15 series. From what I can tell, those were drawings of a delay line memory unit that was never built. Those drawings were not part of the trial exhibits and were not microfilmed. However, some physical copies do exist, and I am hoping to get back into the archives to scan them at some point in the future. Beyond that, there are a number of drawing numbers that are skipped, and I suspect that these are drawings that do (or did) exist, but were not microfilmed for whatever reason. So if anyone has or comes across any drawings that are not on this list, or better copies of those that are, feel free to send scans my way. For anyone wanting to grab copies of the full set, it should be pretty easy to extract a file name list from the index.html file. I'll leave the sed command for extracting the list as an exercise for the reader. For printing, all of them are sized in the PDF files for 8.5x11 or 11x17 paper. Be warned, printing all of them without duplexing and folding the 11x17s to fit into a normal binder, ends up filling 2 4-inch binders. By the way, if anyone has access to the adapter shown in drawing PX-4-119, I think there's an error in the drawing and I'd like to check to see if either there really is or if I'm missing something. Thanks and have fun, BLS

6 days, 18 hours

3
7
0 0

DEC VT05 available in Germany

by hupfadekroua

Hi all, there is a DEC VT05 available in Germany. Please look at kleinanzeigen.de and search for DEC VT05. I already talked to the seller and he‘ll ship worldwide. Best

1 week, 1 day

5
8
0 0

Re: IBM 2315 Cartridges

by brian＠quarterbyte.com

> No. The only DEC drive that had removable plus fixed on the same spindle > was the RC25. > If I remember correctly it was Diablo that sold an RK05-compatible drive with one fixed platter and one removable cartridge. I encountered it on a PDP 11/34 running Mini Unix and then, hmmm, Unix v<something small>. (Or maybe had to move to a larger disk system when we moved up from Mini Unix. The details have gotten hazy.)

1 week, 1 day

7
13
0 0

2026

2025

2024

2023

2022

cctalk