Hello,
I'm an employee with the National radio astronomy observatory here in Socorro New Mexico.
As part of our NGVLA upgrades, we are seeking to get rid of old data tapes from the tape reel days of Computing. These contain things such as the boot loaders, OS, specific collection programs and antenna movement programs.
I personally would hate to see these just wind up in the literal dumpster and would like to see them sent out to a museum or an archiving body that can preserve them and keep them safe as a dynamic part of history.
If anyone is interested or knows someone who would be interested in the VLAs data tape library please let me know.
V/R
Danielle Werts
Front end engineer
VLA Socorro New Mexico
One of the greatest joys of classic computing was running what you wanted
on your own computer. What has happened in the intervening years? Have
‘software walls’ created a computing environment that benefits software
gate-keepers(owners of computing technology) by monopolizing creativity,
freedom to program and establishing a defacto ‘true ownership’. Will the
future be this or will it be more like the earliest years of
microcomputing?
Murray 🙂
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,
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
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...
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
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
>
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
