All —
I mostly lurk on the list now, but I am looking for a manual for the Lomas LightningOne 8086 CPU board. There doesn’t seem to be a good archive of manuals for the Lomas boards (and what’s out there is only partial). I have a project I’m working on with Lomas boards so looking to collect info, etc.
Thanks!
Rich
--
Rich Cini
http://cini.classiccmp.org
All —
I lurk mostly on the list now, but I’m looking for a copy of the manual for the Lomas LightningOne 8086 CPU card and schematics. It doesn’t seem to be anywhere on-line so if someone has a copy they’d be willing to scan, it’d be greatly appreciated.
Thanks!
Rich
--
Rich Cini
http://cini.classiccmp.org
Hi,
As some of you may recall, a few years ago I asked for assistance
reading a 9 track tape containing IBM S/360 source for Martinus
Veltman's computer algebra program, Schoonschip
(https://en.wikipedia.org/wiki/Schoonschip). With Chuck's assistance,
we recovered all the code from the tape. After working with the
principals involved, I am pleased to announce that the source code is
now publicly available at:
https://vsys.physics.lsa.umich.edu/
Actually, I was always more interested in the original CDC 6600 source
code, as that is the more historically significant code. While that
was not contained on the 9 track tape, I did receive a copy from the
Veltman family, and that is also available from the above website.
I have limited experience with big iron, but I had very good success
getting Schoonschip compiled and running on dtCyber. Veltman also
provided example Schoonschip programs (YNGLING), and as far as I can
tell they run perfectly in CDC Schoonschip on dtCyber. However, I
have not been fully successful in getting IBM Schoonschip to run on
hercules under OS/360 MVT. The main issue I had was that the Fortran
part of Schoonschip uses REAL*16, which apparently requires the H
extended Fortran compiler that does not seem to be freely available.
I did patch the Fortran code to avoid extended precision and managed
to get Schoonschip running, but it would sometimes crash on some input
files. I do not know if that is a problem with my patches or an
actual bug in the original code (as the IBM version of Schoonschip was
still a work in progress at the time development stopped).
In any case, anyone who is interested is welcome to have their own go
at the code. The third evolution of Schoonschip (m68k code, which was
written after Veltman came to the University of Michigan) is also
available at the same website.
- jim
--
James T. Liu, Professor of Physics
3409 Randall Laboratory, 450 Church Street, Ann Arbor, MI 48109-1040
Tel: 734 763-4314 Fax: 734 763-2213 Email: jimliu(a)umich.edu
Well, if you are into this kind of stuff (I am)... Stross is an s-f
author, formerly a programmer (ages ago but I think it still shows -
perhaps he secretly writes his own tools in Perl) and he has a
blog. This time, he explores the idea that internet "bub" delivered on
its promises, rather than sucking investors up.
http www.antipope.org charlie/blog-static/2024/04/the-radiant-future-of-1995.html
Of course, readers make comments, so it gets a bit more interesting.
--
Regards,
Tomasz Rola
--
** A C programmer asked whether computer had Buddha's nature. **
** As the answer, master did "rm -rif" on the programmer's home **
** directory. And then the C programmer became enlightened... **
** **
** Tomasz Rola mailto:tomasz_rola@bigfoot.com **
In case anyone is interested in poking their cg14/sx in new and
exciting ways :-p
---------- Forwarded message ---------
From: Michael <macallan1888(a)gmail.com>
Date: Tue, 23 Apr 2024 at 07:55
Subject: CG14 and 16bit colour
To: <port-sparc(a)netbsd.org>
Hello,
I did a lot of work on the cgfourteen, sx and xf86-video-suncg14
drivers, one thing I didn't expect was people asking for 8bit
acceleration in X, mostly because with a 4MB cg14 you're limited to
1152x900 in 24bit colour, in 8bit you could go all the way to
1920x1200. So I wrote code for that.
Looking at the headers files, it looks like at least the DAC supports
16bit colour as well, which would allow 1600x1200 in more than 8bit
colour.
Getting SX to deal with 16bit quantities is not difficult, at least for
basic stuff like copy, fill and ROP operations. Xrender would be more
difficult since there is no easy way to separate / re-unite the colour
channels of a 16bit pixel. For 32bit it's trivial, SX has instructions
to split 32bit accesses to four registers, even lets you pick which
byte to take. So we wouldn't get xrender acceleration.
Then again, we don't have that in 8bit either.
The DAC is an Analog Devices ADV7152, and I just found the datasheet -
in 16bit mode we get R5G5B5, nothing unusual here.
That said, cg14 seems to use the DAC only for gamma correction, we
don't mess with it at all even when switching to 8bit, so who knows
what exactly cg14 feeds it when we set pixel mode to 16bit.
Shouldn't be difficult to figure out though.
I guess what I'm getting at is - does anyone particularly care about
this? I don't mind doing this as yet another Just Because I Can(tm)
project but if anyone cares I'd welcome their input.
have fun
Michael
Mike, any tips or guidelines for running an emulated PDP on a Raspberry Pi ?
Regards,
Tarek Hoteit
> On Apr 21, 2024, at 08:08, Mike Katz via cctalk <cctalk(a)classiccmp.org> wrote:
>
> Well my PDP-8 was built in 1974 and is still running (with careful maintenance). My PiDP-8/I has been up and running continuously with a Raspberry PI 3B running it for about 5 years now. My PiDP-11 has been up and running with a PI-4B for more than 4 years continuously.
>
> Though I agree with your comment that the PDP-8 was built to last (just ignore the disintegrated foam used between the motherboard and the case or on the case top) I have PCs that are more than 10 years old that are still running.
>
> As for the RP2040 being cheap crap, I beg to differ with you. It is a solid chip, produced in 10s of millions at least. And, I would bet, a better quality chip than your Z-80, if due only to improved IC manufacturing technologies.
>
> Just because it's old doesn't make it good. I worked on a 32KHz 4 Bit CPU (about 20 years ago) where the development hardware was very unstable and the tool chain not a whole lot better.
>
> Early Microsoft and Lattice C compilers for the PC were buggy as hell. If you want I can list a few bugs from each of them in another thread.
>
> One of the biggest features of the Z-80, the extra register set, was rarely used in open source software in order to maintain compatibility with the 8080.
>
> Some of the early Z-80 CP/M tools did not work because they were derived from 8080 tools. After time the tools got better. That is the case with any piece of software. If it doesn't become obsolete and if maintained it will get better over time.
>
>
>
>> On 4/21/2024 1:09 AM, ben via cctalk wrote:
>>> On 2024-04-20 8:33 p.m., Mike Katz via cctalk wrote:
>>> For anything more sophisticated than your coffee pot the RP2040 from Raspberry Pie is a fantastic little chip, dual core 133 MHz Cortex M0+ with 8 PIO engines, 264K of RAM, ADC, UART, SPI, I2C all for under a dollar. I designed a fully functional RP2040 with 16 Mb flash for under $2.00. In large enough quantities that's encroaching on 8 bit PIC territory at over 1000 times the memory and CPU power.
>>
>> I am wishing for a Quality Product, cheap crap is not always better.
>> USB comes to mind.
>> 256Kb ram is only 32K 64 bit words. Cache memory never works.
>> My $5 internet toaster, just exploded after 3 days.
>> So what? Just buy the new model that works with windows 12.
>> Download a buggy new tool chain. The Z80 tools worked.
>>
>>
>> The PDP8 was built to last. 50+ years and going strong.
>> NOT the crappy PI PDP-8 or PDP-10. I give it 2 years max.
>> Now a PI style computer with compact FLASH x 2, NO USB
>> and 2 MEG ram , real serial and printer ports that will work
>> in a noisy industrial setting, would be quite usefull.
>> I'd pay even $3 for it. :)
>>
>>
>>
>>
>
Mostly to Bill, but also anyone else hanging out here who's got a surfeit
of 8-bit Apple stuff:
If you're planning on selling the Apple II, and it's not a ][+, I'd be
interested in buying. Not, perhaps, at optimistic eBay prices, but I have
a lot of ][+s and //es, most of them in working shape, some of which are
parts machines; however, I don't have either a II or a //c .
Also happy to trade if I've got things you want. I don't have anything
super-exotic, but feel free to HMU and ask.
Adam
Was reading the Wikipedia article on Drum memories:
https://en.wikipedia.org/wiki/Drum_memory#External_links
And came across this tidbit.
As late as 1980, PDP-11/45 machines using magnetic core main memory
and drums for swapping were still in use at many of the original UNIX
sites.
Any thoughts on what they are talking about? I could see running the
RS03/RS04 on a 11/45 with the dual Unibus configured so the RS03's talk
to memory directly instead of the Unibus, but that's not quite the same
as true drum memory.
Closest thing I remember was the DF32 on a pdp8 which could be addressed
by word as opposed to track/sector.
Thoughts?
C
Fred Cisin wrote
> In 1970 or 1971, Wang had a tiny desktop calculator that had a card
> reader! The card reader was an external peripheral, that clam-shell > closed on individual port-a-punch cards (perforated normal sized >
> cards using every other column)
It was actually available before 1970. It was Wang Laboratories' 300-Series of electronic calculators.
The "tiny" part was the visible part, which was just the keyboard and Nixie tube display. It connected to an electronics package which was usually put under a desk or sometimes even quite a distance from the keyboard/display unit.
The punched card programming peripheral sat between the keyboard/display and the calculator electronics package, and effectively "pressed keys" on the keyboard designated by the punches on the card, at high speed.
On all but the 370 and 380 keyboard devices, the programs punched into the cards were simple linear programs without test & branch capability, or looping. Looping could be manually done by just restarting the program at the beginning, and continuing to do so until the answer converged on the final result.
There were also the somewhat larger 360KT and 360KR keyboards that had built-in diode ROM programs that calculated trig functions by sending the keycodes to the electronics package to carry out the operations necessary to perform the trig functions.
There were a number of different electronics packages that were available, with the low-end model (the 300E) having access to only the basic four math functions. The 310E added square root and x^2, the 320E added natural logarithm and e^x functions to the 310. The 360E added four store/recall memory registers along with the functions of the 320E.
The last of the 300-series was the 362E electronics package that provided access to ten memory registers, each of which could be split in half to store two five-digit numbers, along with the math functions of the 360E.
Then there were the SE type electronics packages. To my knowledge, there were the 310SE, 320SE, and 360SE.
The SE electronics packages took the core calculating logic of the 310E/320E/360E and stuffed some multiplexing logic around it, allowing up to four keyboard/display units to be connected up to it that operated in a round-robin timesharing mode.
The 370 Programmer Keyboard Unit included a similar punched card reader, but there was extra logic inside the keyboard that allowed conditional testing and branching capability. Up to four of these card readers could be daisy-chained to the 370 keyboard to allow programs up 320 steps.
The program codes consumed 6 bits, so each column of the 40 column card (a standard IBM punched card, but with pre-scored holes every other column) could contain two instructions, allowing 80 instruction steps per card.
The 380 Programmer Keyboard Unit was similar to the 370 in terms of capability, but instead of using punched cards for "storing" the program, the program steps were recorded on what was essentially an 8-Track tape cartridge that was inserted into a slot on the back panel of the 380. The tape in the cartridge was in a loop, and was positioned by a rather noisy ratcheting system akin to a stepping relay that moved the tape forward. Branching was accomplished by moving the tape forward until the target location was found. Depending on where the branch was targeted, the tape could have to move to the end of the program, then continue moving until the beginning of the program is found, then searching for the loop target. This operation could consume quite a bit of time. The tape cartridge allowed for considerably larger programs, but was quite slow in terms of tape positioning for branching and looping.
The initial announcement of the 300-series calculator occurred in 1965, with the 300E/310E/320E electronics units, and 300K, 310K, 320K keyboard units, along with the CP-1 punched card reader, of which up to four could be connected daisy-chain style between the keyboard unit and the electronics unit.
Later the 360E electronics package was added, and the 360K keyboard unit for the 360E added keys to access the four memory registers.
A bit later, the 360KT and 360KR trig keyboards were introduced, with the 360KT accepting arguments and results in Degrees, and the 360KR in Radians.
The 310SE and 320SE four-user electronics packages came out sometime in 1967.
The 360SE four-user electronics package came out in 1968, and also the 370 Programmer and 371 card reader as well as the 380 Programmer.
Lastly, sometime in late '68 or early '69, the 362E electronics package came out, and a 362K keyboard (which was identical to a 360K keyboard but with different keycap legends for the memory keys) was introduced with the 362E. The 362E marked the end of the 300-Series.
There were a lot of peripheral devices that were available for the 370 and 380 programmers, including a Teletype interface that connected a Model 33ASR Teletype to the calculator, with ability to accept input from the Teletype and print output to the Teletype, as well as being able to read program steps from the Teletype's punched paper tape reader, add-on memory units for more register storage.
There was also an Item Counter that connected between any of the keyboard units and the electronics package that would count depressions of various keys on an electromechanical counter to aid in calculations such as averages, etc. There was also a simple column printer that would provide printed output of the number in the calculator's display that was also connected between any keyboard unit and the electronics package. A specially modified IBM Selectric typewriter that had Wang-made solenoids and linkages to actuate the keys and functions of the typewriter was also available that could print output from calculations. There are also some peripherals that
could be used to interface the calculators to external digital devices such as test and measurement equipment made by other manufacturers of such equipment.
Wang also would OEM the electronics package guts to other manufacturers. One company even made a general purpose computer system that used one of the 300-series electronics packages as its arithmetic unit. Wang also offered a modular computer system called the 4000 (originally named the 390, but was changed before introduction) that used a standardized bus structure to connect the logic of an electronics package as the arithmetic unit, along with other modules that would contain storage, programming capability, and I/O interfaces.
For quite some time, Wang Labs were the only calculator manufacturer that provided built-in calculation of logarithmic functions that were /not/ pre-coded sequences of keypresses that were executed like a program, but were actually hard-coded algorithms in the calculator's logic that provided almost instantaneous results. Dr. Wang invented the logic to do this, and got a patent for it. It was quite ingenious, and was able to calculate logarithms to twelve digit accuracy using only addition/subtraction and shift operations, and do so in an average of about 300 milliseconds.
The weird part about the calculators in the 300-series is that they used logarithms to perform multiplication and division (which simplified the operations into addition of logarithms of the operands, then an anti-logarithm to get the result of a multiplication, and subtraction of the logarithm of the second operand from the logarithm of the first operand, followed by an anti-logarithm to derive the result. The issue with this is that most logarithms are not able to be 100% accurately represented in the 14 digit (10 digits displayed) capacity of the logic, and as a result, some multiplication and division operations that would normally result in an integer answer providing an answer that was not quite accurate. For example, 3 X 3 would equal 8.999999998, but a bit of additional logic for multiply and divide would round the result up to 9.000000000 .
In some cases, the error was enough that the rounding wouldn't give the integer answer expected, though. All of the answers provided, even with slight errors due to imperfect representation of the logarithms were within most tolerances for engineering and scientific calculations.
The logic of the machines was completely transistorized, using diode-transistor gates. No integrated circuits anywhere.
The working memory of the calculators was stored in a magnetic core array in the electronics package.
The electronics packages consisted of a backplane (hand-wired in earlier machines, later on a circuit board) with a bunch of small (roughly 3x5-inch) circuit boards packed with components.
The power supply was a conventional linear power supply with Zener/transistor regulation.
The basic keyboard units just contained a board with transistor drivers for the Nixie tube displays, and diode encoding for the keys on the keyboard. The key switches were standard micro-switch units with a ring pressed onto the key-stalk that would press down on the actuator for the micro-switch. Key travel was very short, but had a positive "click" as the micro-switch closed when the key was depressed.
The 300-Series electronic calculators put Wang Laboratories on the map as a leader in higher-end electronic calculators, and made a fortune for the company and its shareholders.
In 1968, when HP introduced the 9100A, Dr. An Wang, the founder and CEO of Wang Labs was secretly shown a production version of the 9100A before it was introduced. The presentation of the machine was provided to Dr. Wang by Dave Hewlett, one of the founders of HP. When Dr. Wang saw what the HP 9100A could do, he was visibly shaken. When the presentation was over, he left the room saying "We've got to get to work", meaning that it was clear that the 300-Series was now completely obsoleted by the 9100A, and that Wang Labs had better get busy with a new generation of calculators to counter HP's amazing calculator that was much smaller, much more capable, had computer-like programming capability, and was still made only with transistors and magnetic core memory. Wang did not have their counter to the HP 9100A/B calculators ready until mid-1970, the Wang 700-Series. The 700-Series calculators were serious machines, very computer-like, with large amounts of core memory, very high speed using DTL and TTL small-scale integrated circuit logic, and large I/O expansion capabilities. They were a solid match for the HP 9100A/B, but by the time they got them to market, HP had already introduced it's 9800-series machines, which had the essence of a computer as their main logic, with a "program" that made the machines run. The computer at the heart of the 9800 series was a somewhat slimmed down, bit-serial version of HP's first minicomputer, the HP 2116A. The 9800-series were larger machines than the 9100A/B, but offered extensive expandability and I/O capabilities. The pinnacle of the 9800 series was the 9830A, which was programmable by the user in the BASIC computer language, and was more a computer than a calculator, but HP still considered it a calculator to make it more marketable because the term "computer" had connotations of being a very expensive piece of capital equipment, while a calculator was basically an expense item.
You can learn more about the Wang 300-Series calculators by going to
https://oldcalculatormuseum.com/calcman.html#MFG-WANG . There is also information on HP's 9100B, as well as most of the 9800-series that can be found by scrolling up on that same page, as well as many other electronic calculators exhibited in the Old Calculator Museum website, as well as physically in the Old Calculator Museum.
Rick Bensene
The Old Calculator Museum
https://oldcalculatormuseum.com
Beavercreek, Oregon USA
P.S. Some of the dates above may not be exactly correct, and there may be some other minor errors or missing information because I typed this strictly straight out of my head without access to any reference material. The website has the correct information to the greatest extent possible given the amount of time that has elapsed since these machines were new.
