> From: John Wilson
> I used battery-backed SRAM in the Unibus RAM card I prototyped a while
> back (and just recently got working and have been finishing the XMOS
> firmware for).
UNIBUS RAM cards? Neato-keeno!! When will they be available, and how do I
order some? :-)
BTW, what's an 'XMOS'? Google didn't enlighten me...
> From: Ethan Dicks
> As much as I would like one (or two), what's the actual market for such
> a thing?
Oh, probably almost as large as all the other custom UNIBUS/PDP-11 cards
people are building these days... :-)
> I'd rather have a faster machine while I'm using it.
Somehow, I'm thinking that if it's speed we're after, a hardware PDP-11 isn't
where I'd turn... :-)
Noel
> From: Johnny Billquist
> But this is still way too little to actually know for sure how things
> works.
Even if you don't have the documentation, it's possible that the ENABLE at
Update can answer some questions for us. Does Update still have their ENABLE?
Is it still plugged into a machine, or has it been pulled (and is now sitting
on a shelf somewhere, perhaps)? If the latter, are there any pictures of it
in the machine?
Thanks!
Noel
By now, many have seen the 2100A on ebay (item # 141602578927). Those are
truly wonderful machines and a great example of HP engineering at the time.
IMHO, the best (usability) front panel of any machine I've ever touched. It
looks to be in good shape and from what little I can tell from the pictures
it looks to be complete (foggy memory makes me think there was an A9 card as
well, but don't recall for sure, probably optional). Only downside is it has
8K (give HP-IPL/OS a try), no terminal board, and no disc controller; the
only thing missing that is really essential is the terminal board (either
12531 {HS TERMINAL} or 12966 {BACI} is what it needs). I suspect it will go
for "substantially" more than the current bid ($290). Note that by and
large, I/O boards for the 1000 series (21MX M/E/F) are compatible with it.
The auction states there is no key, I have a whole box full of keys for the
2100 if someone here gets it. I have several 2100's, plus a couple spare
machines, so I have no dog in that hunt. Hope someone gives it a great home.
Whoever gets it - there is a chance I have a spare set of rails for it, not
sure.
Also of note is the 7970E tape drive (ebay item # 141603907013). I can't
really tell from the pictures, but careful inspection of them makes me
wonder if there isn't some corrosion present. Of particular concern is the
condition of the capstan surface. It may be completely fine, but the grainy
picture raises that question. On the bright side, the seller says the load
button produces the expected results which is a fair sign of some amount of
life. Bidders should be aware that the electrical interface for this drive
is "HP Only", not a common standard. I asked the seller to get a picture
inside the unit, particularly so I could see the date code and options
placard but didn't get a response. At the least it would be nice to know
what speed the drive is and more importantly if it is a "slave only" unit
(requiring a master). Lastly, can't tell from the pictures, but I'm guessing
it does not include the oddball HP mounting bracket. It is unlikely you'd be
able to mount this thing in a rack at all without that bracket. If someone
here gets this unit, contact me off-list as I did actually get one extra
bracket manufactured in the recent order that is unspoken for. I was going
to bid on this unit because if it arrived and was in poor condition - it
would be a complete spare board set for my other two units. However, the
bidding has already gone above what I was willing to pay for a spare
boardset J Again, hope someone gives this a good home!
Best,
J
On Mon, 16 Mar 2015, John Foust wrote:
> I'm trying to understand at a low level how some early computers
> and game consoles generated a non-standard form of NTSC.
>
> The Wikipedia http://en.wikipedia.org/wiki/Low-definition_television says:
>
> "Older video game consoles and home computers generated a nonstandard NTSC
> or PAL signal which sent a single field type which prevented fields from
> interlacing. This is equivalent to 240p and 288p respectively, and was
> used due to requiring less resources and producing a progressive
> and stable signal."
[...]
This has absolutely *nothing* to do with NTSC or PAL (or SECAM or
whatever). NTSC etc. are colour encoding standards and don't describe in
any way how a image signal is generated (fields, syncs, timing). They only
describe how to put colour information into the signal.
Christian
> From: John Wilson
> I think Guy's MEM11 is going to be way cooler. ... I'll be doing a new
> rev one of these months ... and then I'll certainly make them
> available, but not seriously expecting anyone to order one. Guy's MEM11
> is nicer!
Yeah, but for some machines I wouldn't mind having pure memory boards.
> it plugs into the A/B positions of a MUD/SPC slot, which makes it
> useless on an 11/20 which doesn't have those (right? unless you add a
> BA11K?)
I haven't checked, but I suspect there might be a way to power like a DD11-C
through some sort of conversion plug, but I'm not up on 11/20 power (would
have to read the H720 manual, which I'm too lazy to do).
> Naturally I've gotten way sidetracked writing that firmware ...
> Totally out of hand.
Hah, what else is life for? :-)
> it sounds (from the MS11P manual) as if the 11/24 and 11/44 extended
> Unibus would be easy to support as an option (seems like the four extra
> address bits on AN1, AP1, BE1, and BE2 are all that's new
I'm pretty sure. If you look at the MS11-M prints (FMPS #742, pg. 4), they
have a jumper called 'UNIBUS/Extended UNIBUS' and basically all it does is
disable listening to those 4 extra bus address lines. (It also affects CSR
stuff, but not the basic memory operation, other than disabling the 4 extra
address lines.)
I've got some MS11-P cards (which are now really cheap, compared to real
UNIBUS MOS memory) here, and I'm planning on hacking them so they are UNIBUS
cards, via a similar hack. (I'm not going to use MS11-M cards because they
use some wierd voltage that's only easily available in the 11/44; the
MS11-P's use +5V only.)
Noel
> From: John Wilson
> But for 18-bit machines, emulating the Enable thingy might be fun for a
> tiny handful of people, which is always enough to justify months of
> work in my book.
D'accord! :-)
> But thinking about how it must work hurts my head.
OK, let me give you my best understanding/recollection of how it works.
The UNIBUS from the CPU is pretty much only used as a CPU<->ENABLE bus. The
CPU does reads/writes (which all go to the ENABLE) on it, and interrupts from
devices come in on it, but that's all. (I don't think the CPU did NPR
arbitration any more.)
The CPU's internal PARs are used to distribute various chunks of CPU address
space across that UNIBUS' address space. Most code set up that mapping
statically at startup, and afterwards played only with the PARs in the ENABLE
(which could map chunks of the UNIBUS space to the 22-bit address space) from
then on. With a total of 256KB of UNIBUS address space, that means it will
hold a full-sized Kernel I+D, and a full-sized User I+D. There is therefore no
Supervisor (I or D), _unless_ you skimp on one of the other 4, or dynamically
re-allocate the address space in the CPU<->ENABLE UNIBUS (e.g. when switching
>from User to Super).
The Enable had two (maybe three) other bus connections: one was a device
UNIBUS in/out (for all DMA, and possibly other, devices), one was the 22-bit
address memory bus, and the potential third was the bus to the optional cache.
(Except I think maybe the latter two were combined into one; see below.) In
theory you could put non-DMA devices on the CPU<->ENABLE UNIBUS, but I don't
know if anyone did.
The second UNIBUS had a UNIBUS map on the end of it inside the ENABLE,
through which all incoming DMA cycles were fed to the 22-bit memory. So, NPR
cycles on it acted just like those on the 11/70's UNIBUS (they even used the
same register locations/etc, so programming-wise an 11 with the ENABLE looked
just like an 11/70, as far as the UNIBUS went).
There are code/.h files which give all the register locations, bits in the
CSR, etc so it should be possible to build a replica (so that existing code
for it still works).
If you look at a picture of an ENABLE (there's one in the Product Summary),
it's a hex card which has i) the normal edge connector, ii) a pair of DuPont
headers (which are, I'm pretty sure, the cache connector), and iii) a UNIBUS
connector stuck on the top edge of the card. I think one UNIBUS came in the
edge fingers (but I could be wrong, that's just a guess); the other clearly
used the one of the top of the card.
I don't know if it plugged into a 'normal' Extended UNIBUS system unit, or if
it was a special backplane that Able supplied. I suspect the latter, because
one way or another, that backplane had to have normal UNIBUS on either the
input or output A/B slots, and I can't see how that would work with EUB
memory cards plugged into that backplane. But maybe I'm missing something?
(This is why I'd really like to have the documentation - to see how it was
hooked up. How it worked, I can tell from looking at the software.)
It's possible the cache connector doubled as the memory bus; all memory cycles
would have been sent out that connector to the optional cache card, and if it
hit, cycle done; if not, it went out (over the backplane?) to the EUB
memory. So maybe if there was no cache, there was a different 'null' card
there with a connector for the ribbon cable, and minimal circuitry, to connect
up to the EUB - but that's a pure guess. Another possibility is that only the
cache used the DuPont connectors, and memory cycles went out other 'fingers'
on the edge connectors. (Grr! Wish we had installation instructions!!)
It would really help to know if the ENABLE needed a special backplane. Maybe
someone can look at the one at Update, and see what kind of backplane it's
plugged into? That could also tell us whether the UNIBUS connector on the back
edge was the 'in' or 'out' UNIBUS. (And of course they should make sure their
card looks like the one in the Product Summary brochure!)
> It's emulating Unibus memory at the same time that it's emulating the
> Unibus map -- i.e. CPU accesses (which should be relocated through the
> onboard PARs) are coming over the same bus as DMA (which should be
> relocated using the Unibus Map).
Nope. Two separate UNIBI.
> Does it need to tap into each model of CPU somehow (like how a
> Microverter gets at MMR3)?
AFAIK, it doesn't connect up to the CPU at all.
> And what if there's a cache, like the KK11A, that doesn't know about
> the outboard PARs?
Good question! Probably you should pitch the KK11A, and use Able's optional
cache for the ENABLE. Or flush the KK11A whenever you change the mapping
(does the KK11A have a register to do that)?
The one thing I'm still confused about is that I'm pretty sure that on our
11/45, with the ENABLE and its cache, running 'mips' produced 3. But could it
really get that much speed out of the UNIBUS? I had thought that somehow the
one we had plugged into the FastBus on the 11/45, but maybe my memory is
(somehow) playing tricks on me?
Noel
On 2015-Mar-16, at 7:20 AM, John Foust wrote:
> I'm trying to understand at a low level how some early computers
> and game consoles generated a non-standard form of NTSC.
>
> The Wikipedia http://en.wikipedia.org/wiki/Low-definition_television says:
>
> "Older video game consoles and home computers generated a nonstandard NTSC
> or PAL signal which sent a single field type which prevented fields from
> interlacing. This is equivalent to 240p and 288p respectively, and was
> used due to requiring less resources and producing a progressive
> and stable signal."
>
> Another source says this was true for the "NTSC Atari 2600, Apple II
> family, Commodore 64, Nintendo Entertainment System, Sega Master
> System, and the vast majority of games for NTSC Genesis, Super NES,
> PlayStation, and Nintendo 64."
>
> This page http://www.hdretrovision.com/240p/ calls it a "special timing
> signal" and gives examples of how contemporary flat-panel TVs can
> misinterpret the old signal. The issue has spawned the creation of
> dozen of devices to give the retro look on new TVs.
If you're just referring to the interlaced vs. 'progressive' scan issue, it comes down to the relationship between the vertical and horizontal scan rates.
The standard RS-170/NTSC sync-pulse frequencies of V=60Hz and H=15,750Hz [*], give an H/V ratio of 262.5, which of course is the number of lines which will be scanned during the vertical scan period. The half fraction results in the vertical sync ' interrupting' the last line of half the scan fields half way through the line and the first line of the other half of the fields starting halfway through the line so the fields are vertically offset slightly and thus interlaced.
(Multiplying 262.5 by 2 gives the proper 525 NTSC lines per frame (and of course notice it's an odd number)).
When ones looks at the V and H sync pulses in relation to each other, they are alternating/oscillating in relative phase to each other.
In the properly-implemented standard, that alternating phase relationship necessitated equalizing pulses in the signal at twice the H rate around the V sync/retrace period to keep the old analog-implemented sync-separators happy.
If the H/V ratio is adjusted slightly off the standard to an integral relation, for example by setting the H scan rate to 15,720Hz to give 262 (lines), the H & V sync pulses are always in the same phase relationship, and there's no interlacing.
The altered scan rates were still within the sync-lock range of the analog TVs of the day, perhaps needing a slight tweaking of the horizontal-hold control.
I was trying to find what the -exact- frequencies are for some of those early computer/game systems but nobody seems to want to readily present them on the interwebs.
[*] In NTSC, the rates were adjusted slightly from the original B&W spec with the introduction of colour, to, 59.94 & 15,734; IIRC, to deal with the colour information in the signal displaying artifacts when displayed on existing B&W TVs.
Ok,
I will scan in this way...
I just ordered an used semi-pro HP scanner with front/back ADF... I hope
it will arrive sooner.
In the end, when the documents will be ready, I will but them on dropbox.
Whom should I send the link then?
Andrea
The VCFMW hotel room group rate is active! Follow the Holiday Inn
link under "location" on the main vcfmw.org page or mention "vintage
computer festival" or group code "CCC" when calling 1 (877) 834-3613.
The rate is $84/night, only $5 more than last year for a finer venue.
That rate covers either the single-King or double-double "executive"
room, which means you get a microwave and mini-fridge for your
leftovers.
The block is held until 8/7, so there is plenty of time yet if you're
not sure you can make it. But if you are, book soon so we have an
idea of how many are coming and whether we need to expand the block.
See you in August!
