On 6/3/22 08:55, Bill Gunshannon via cctalk wrote:
On 6/3/22 08:46, Antonio Carlini via cctalk wrote:
It's predecessor, the DEQNA, was "Digital ETHERNET Q-Bus Network
Adapter", according to its user guide, or "broken", according to most
people :-)
I see comments like this all the time bu
On 12/6/21 17:45, Mike Katz wrote:
If I may8 ask a question. I have never had boards made before. How do
I find a good board house that is reasonable and how do I specify the
board especially for the PDP-8 Omnibus which should have gold fingers
on the edge connectors?
I was planning to try
On 12/6/21 10:36 AM, Mike Katz via cctalk wrote:
> Each LED requires 24 bits of data. That would be 3,456 bits. The
> WS2812B has a 300uS low start indication and 1.25 uS per bit. That
> would mean it would take. 4.62mS to update the all of the LEDs.
If I'd known about those when I designed
On 12/6/21 10:13 AM, Henk Gooijen via cctalk wrote:
> If this RK11-C “blinkenlight” panel would also become available in a 60%
> scaled format,
> I would buy it immediately. It would be an “übercool” addition to the
> PiDP-11/70 and
> my 60% scaled (“working”) RK05 drive. I only modified the fi
On 12/5/21 4:43 PM, Henk Gooijen via cctalk wrote:
> I am definitely interested. Never saw the RK-11C (except once on eBay some 15
> years ago)!
> However, I have *two* DX11 front panels with the 144 lamps & 4 ”paddle”
> connections boards.
> I developed a 100x160 mm (Euro-card size) PCB with a
On 12/5/21 3:24 PM, Ethan Dicks via cctalk wrote:
> This would be really cool as a debugging tool
> more than just as amazing lights.
A great lead-in to my story. I was working away on the RK11
implementation in the QSIC and when I felt like taking a break but still
wanted to get something done
On 2/1/21 1:59 PM, John Ames via cctech wrote:
> This one has always boggled me, because it's the one aspect of the
> Endian Wars where there's a simple, straightforward answer grounded in
> basic mathematics - base ^ digit-number only gives the correct
> place-value when the lowest-order bit is
On 8/28/20 4:00 PM, Chuck Guzis via cctalk wrote:
Plenty of code libraries out there. Why dink around when silicon is
cheap? MCUs are everywhere; in many cases cheaper than discrete logic.
Might have been better but I had the FPGA there anyway for other reasons
so I just connected a few pi
On 8/28/20 3:31 PM, Warner Losh wrote:
There's some other speed increase (UHS) that comes along with also
dropping from 3.3V down to 1.8V. I don't know how to program
FPGAs to
do that or even know if they can.
I thought it was going from SPI mode to MMC mode that did this, not
On 8/28/20 1:10 PM, Paul Koning wrote:
SD is a packet based storage device on a serial interconnect, minimally one
lane wide but it can also be four lanes (and that's typically how you use it).
Apparently it starts out in a SPI compatible mode, interesting. Also, SD
requires a rather comple
> in an online search - the CFADPTHD seems like it's close to what I'd want,
> except it's Compact Flash; I'd have preferred SD but I guess converting
> their interface to IDE is more work.
Yeah, I think Compact Flash actually uses the IDE protocol just with a
different form-factor while SD car
On 5/20/20 10:22 PM, Jay Jaeger via cctech wrote:
> I'd be interesting in hearing from folks what toolsets they have used
> for HDL (VHDL in particular).
I've been using Verilog rather than VHDL but I started with Quartus for
a little while then moved over to Vivado which I like a little better.
On 11/16/19 19:56, W2HX via cctalk wrote:
> Is the BBB not fast enough to do Qbus? Meaning, for qbus, would a FPGA be
> necessary? Or was this just the op's choice among many possible options?
I'd think that PRU in the BBB ought to be able to handle the QBUS
easily. A state-machine in an FPG
On 11/15/19 20:53, Paul Koning wrote:
> I wonder if the UDA50 microcode can be found. That's a bitslice (2901 ALUs
> plus 2910 branch controller) which presumably would be pretty easy to emulate
> in a small FPGA.
If it used Am2901 series parts, I wonder if it used Am2908s too for the
bus driv
On 11/15/19 3:26 PM, Nigel Johnson via cctalk wrote:
> I think you will win a lot of friends if you can make something that
> will emulate MSCP devices on the QBus - I have a micro11 and microVax
> sans disk due to only having ESDI ate ST506 controllers!
>
> cheers es 73 to the hams amongst us de
On 11/15/19 3:01 PM, W2HX via cctalk wrote:
> LOVE the ideas, loved it when I first heard of it. But I'm a QBUS guy! Put me
> on the list when (if) you ever make one for qbus. GREAT idea!
> Eugene
Along these lines, it's been a long time since we've updated the list
regarding the QSIC project.
On 9/17/19 15:00, Ed Groenenberg via cctalk wrote:
> Hello.
>
> I'm looking for a PCB layout file / template of a 2 slot Unibus card,
> which I want to use in KiCad.
>
> Can someone help me with this?
Here's a KiCad template for a double-height QBUS card. I haven't
verified it or cleaned it up b
Obviously that message wasn't supposed to go to the list. I forget how
the list re-writes the message headers like that. Sorry about that.
Dave
On 7/6/19 8:46 AM, Noel Chiappa via cctalk wrote:
> So here's one I'm not sure anyone else will catch: TFTP has an email mode!
I knew about that one. :-) Did anyone other than CSR ever use it?
Not much airplane news. I've spent some time chasing down wheels and
brakes for the Galaxie. The d
On 11/12/18 5:04 PM, Paul Koning wrote:
> The name of the font translates to "Bold Extended". DIN 1451 is a family of
> fonts, see Wikipedia. You're looking at one of the members of the family,
> the bold wide one. It's not all that bold, judging by the pictures; if you
> need something bold
> > "DIN 1451 Fette Breitschrift 1936". That is probably the
> > font next to the knob on the right and the bit numbers above the
> > switches.
>
> Yeah, that latter is the one we're looking for (mostly).
I was able to download a version of that one that worked but I don't
think I
Hey, glad to hear of some improvement on GCC for the PDP-11. Last
spring I ended up side-tracked on the QSIC project and working more on
FPGA issues than writing PDP-11 code but that's going to change here at
some point. I still want to put a soft PDP-11 into the FPGA as an I/O
controller and wil
> Imagine our chagrin when days of trying to correct the
> problem led to the conclusion that the diagnostic was incorrect.
I may have a situation like this in working on my FPGA PDP-10. The
Processor Reference Manuals seem quite clear that the rotate
instructions take E mod 256. One of the man
> That sounds pretty awesome. Good job there!
Thanks. Feeling good today after a bit of frustration with development
not going faster.
> Do you know how hard it would be to take this design and make a UNIBUS
> version? I have an 11/34 languishing under the bench in my hardware
> lab and one o
> FWIW, so does RT11, and in the case of writes, it requires the rest of the
> block to be zero-filled. Not everything depends on this, but some parts do;
> I think Fortran is one.
I did implement that too. Unix doesn't need it but I had to fill the
block with something and it wasn't that har
For those of you who are following along with our QSIC project, today we
booted v6 Unix successfully for the first time. We'd first tried this a
week or two back but discovered that Unix does use partial block reads
and writes after all and I hadn't implemented those yet. We're running
this on an
> So why are reels of DECtape selling for unbelievable prices on eBait? See,
> e.g. here:
I had those on my watch-list and just shake my head at the astonishing
prices for the things.
I've wondered if you might not make DECtape tape from 3/4" video tape.
I know that DECtape has mylar on both si
On 1/2/18 15:38, Toby Thain via cctalk wrote:
> Err.. could be my mistake... I meant wherever you posted your last
> technical note about QBus quirks. (I didn't look up the reference)
Oh, that paper I wrote about how bus arbitration works on the Unibus and
QBUS. I'd thought of it as just a way o
On 01/02/2018 02:05 PM, Toby Thain via cctalk wrote:
>> Oh, I hadn't thought of Toby possibly meaning that. Yeah, I'm unlikely
>> to write up much documentation on the internals of the QSIC for people
>> who want to add other devices. However, not only will the source be
> Yes, that's what I mea
On 01/02/2018 02:07 PM, Toby Thain via cctalk wrote:
> On 2018-01-02 1:57 PM, David Bridgham via cctalk wrote:
>> The link didn't work for me but I definitely have that paper -- good
>> stuff indeed. I should collect my library in one place so I don't lose
>> t
The link didn't work for me but I definitely have that paper -- good
stuff indeed. I should collect my library in one place so I don't lose
track of what I have.
On 01/02/2018 01:54 PM, Toby Thain via cctalk wrote:
> In this vein, Ivan Sutherland's Turing Award lecture, "Micropipelines",
> might
On 01/01/2018 08:06 PM, Paul Koning wrote:
> Neat. I found this 2011 paper that's interesting:
> http://www.cs.columbia.edu/~nowick/nowick-singh-ieee-dt-11-published.pdf
Thanks for this paper, Paul. I'm quite interested in the idea of
asynchronous circuit design and I hadn't come across those
On 01/02/2018 01:13 PM, Noel Chiappa via cctalk wrote:
> If you mean the 'software' for additional controllers - that would be a _lot_
> harder (plus to which it's an entirely different tool-chain, yadda-yadda).
> 'Use the source, Luke!', I'm probably afraid...
Oh, I hadn't thought of Toby possi
On 01/02/2018 12:45 PM, Toby Thain via cctalk wrote:
> If the documentation is good enough, people in the community will be
> able to provide the software.
The quick answer is that it's pretty simple. We take the
cylinder/head/sector addresses and consider them a Linear Block
Address. Then we l
On 01/01/2018 03:33 PM, Noel Chiappa via cctalk wrote:
> > From: Paul Koning
>
> > The only asynchronous computer I can think of is the Dutch ARRA 1
>
> Isn't the KA10 basically asynchronous? (I know, it has a clock, but I'm
> not sure how much it is used for.)
This was my understanding,
Even though I've been quiet, I have been making slow progress on the
QSIC in the background. For those who've forgotten what the QSIC
project is about, here's the description:
http://pdp10.froghouse.org/qsic/html/overview.html
We've been working away on getting communications with the SD card
wo
On 12/19/2017 05:36 PM, Josh Dersch via cctalk wrote:
> See the pictures at the below link:
>
> https://1drv.ms/f/s!Aqb36sqnCIfMotpQIuc2-tDUva3iBw
>
> It looks to be fairly straightforward; the plastic "ball on post" brackets
> are mounted to the rack rails, and there are metal brackets that screw
On 11/28/17 13:27, emanuel stiebler via cctalk wrote:
> Dave has a KV10 already in verilog, so why not port it to the uengine?
> ;-)
Once the QSIC is far enough along that I go back to working on the KV10,
I expect I'll do just that.
On 8/5/17 04:29, emanuel stiebler wrote:
>> Xilinx Artix 7. More specifically, we're using a ZTEX 2.13 FPGA module
>> for our prototyping. Unless some good reason came up, I was thinking to
>> stick with the same FPGA.
>
> Artix 7? Nice, use them a lot.
>
> Vivado or ISE?
Vivado. Another huge
On 8/4/17 11:25, emanuel stiebler wrote:
> http://ww1.microchip.com/downloads/en/DeviceDoc/1678B.pdf
> that the one I use a lot...
Oh, a USB PHY chip. Yeah, that might be the way to go now that we're
not counting I/O pins.
>> 1:1 block mapping. I'm going to have enough fun with trying to
>
On 8/4/17 11:16, emanuel stiebler via cctalk wrote:
> Use the memory as disk cache locally. Otherwise you need to write
> drivers for all different versions of OSs out there. Transparent cache,
> write through ...
>
> Then no changes are needed on the system
Well, we are going to make the RAM loo
On 8/4/17 10:46, emanuel stiebler via cctalk wrote:
>> > USB with 480MHz is fast enough
>>
>> I think our plan was to skip that speed, and go with the next one down,
> Probably sufficient for a start ...
> > on
>> the grounds that the analog part at that speed would be too tricky
>> for us.
>
On 8/4/17 09:26, Paul Koning wrote:
>> So my question is: do industrial SD cards exist?
> Yes; we've been using them for years now in the products I work on. While
> you can still wear them out if you beat on them hard enough, they do have
> good reliability.
Okay, that's good news then. Any
On 8/4/17 05:49, systems_glitch via cctalk wrote:
> Going with SLC/"industrial" Flash is indeed the key to avoiding random
> failures. I have many deployed systems using industrial Flash modules (IDE
> DOMs)
As Noel said, he initially talked using an IDE interface for the QSIC.
I proposed SD car
It's been a while since I've sent an update on the QSIC project and
since work is currently on-hold while I'm in Alaska for my summer job,
this is a good time. With the QBUS protocol pieces all working from the
previous winter, last winter's work was to get some sort of storage
medium working. SD
> Don't trust ANYTHING! Recent Xilinx FPGAs have permanent "weak
> keepers" on all pins, they can not be turned off.
> What this is is a non-inverting receiver on the pad, that is driving
> back to the pad with about a 50K Ohm resistor.
> Plays hob with analog stuff like crystal oscillators. The
> It's not clear C-coupling is what's going on here (the wave shape looks
> pretty sharp for what I understand of the circuit/layout).
> Notably though, C-coupling would remove any DC bias, but David's screen shot
> indicates a DC bias on the line.
>
> Is this line currently connected to the FPG
And I think this picture is the smoking gun.
http://pdp10.froghouse.org/qsic/pic_24_2.gif
Again, the bottom trace is the CS signal in question and the upper trace
is now one of the QBUS DAL lines (after the bus transceiver and level
converter) that's running across the ribbon cable near the CS si
> There are few things that come to mind here. The op seemed to indicate the
> lines are terminated. If they are not terminated in the characteristic
> impedance of the source and the transmission line, it is very unlikely he
> would be seeing nice square waves at either end. The reflections wo
> 270k seems like a rather strange value, it certainly can't be a termination
> and it isn't a plausible pulldown either. The SD spec should explain what is
> expected; I knew it at one time but forgot by now.
I'll agree that 270k is a strange value. The idea is that the SD card
contains an i
> 1v across 270K represents 3.7 microamps, which isn't much, particularly
> at 25MHz. (I assume that you're using SPI to access the card, but the
> observation still holds).
Yup, I'm planning to use the SD card in SPI mode (at least for now).
And this line is the CS/CD line, so it's not even run
On 01/05/2017 08:13 PM, allison wrote:
> Lots of ifs, mights, and maybes. My knowledge is from actually owning
> and maintaining a Cessna since 1979 and so far that has not been an issue.
Yup, that's just how the discussion in the aircraft community went. One
group would point out that Simple
On 01/05/2017 12:22 PM, j...@cimmeri.com wrote:
>
> It's very mild and has been aluminum safe for me (think, aluminum
> wheels on cars).
This question of whether Simple Green was aluminum safe came up in the
aircraft world a few years back and the answer turned out to be that
some ingredient in th
On 12/17/2016 08:14 AM, Noel Chiappa wrote:
> I'm can't quite remember, although I'm pretty sure neither DM or ML had any
> -11's.
I thought I'd heard that the 10s were connected to the Chaosnet through
11s running MINITS.
On 12/05/2016 11:51 AM, Mouse wrote:
>> Middle-endian FTW
> That makes me wonder: was there any hardware that used an endianness
> such that conversion didn't loop with period 2?
Not quite the same thing but weren't longwords on the PDP-11
little-endian for the bytes within the word but big-e
On 12/05/2016 12:17 PM, Chuck Guzis wrote:
> Or how about architectures not using a word length that's an integral
> number of bytes?
You mean like any 36-bit machine?
On 11/29/2016 01:47 PM, Peter Coghlan wrote:
> A single chip plus tranceivers solution would be ideal but I couldn't see it
> being that easy :-)
I have a single chip plus transceivers solution but my single chip is a
Xilinx Artix 7 FPGA. Maybe that's cheating but it does implement
register read
On 10/24/2016 01:37 PM, allison wrote:
> The voltages are based on TTL levels. What are the unique voltages?
The QBUS spec from the 1979 Bus Handbook (the Unibus levels are the same):
Input low voltage (maximum): 1.3 V
Input high voltage (minimum): 1.7 V
And from the TI datasheet for the 74LS7
On 10/24/2016 04:30 PM, Paul Koning wrote:
> I don't see any max slew rate spec in the driver specs in the peripherals
> handbook.
For the QBUS from the PDP11 Bus Handbook 1979, page 125:
AC Specifications
Bus driver output pin capacitive load: Not to exceed 10 pF
Propagation delay: Not to exce
On 10/24/2016 12:01 PM, Paul Koning wrote:
> I don't know about the receiver part, but I'd expect that the drivers could
> very easily be done with a simple transistor circuit.
Agreed. However ...
> As for slew rates, unless you have antique transistors, that's not going to
> be an issue give
On 10/22/2016 12:44 PM, shad wrote:
> What kind of bus transceivers did you used for the QSIC, specially
> because you have
> to go from 5V open-drain logic to 3.3V logic?
To add to Noel's answer, here's a picture of our current prototype board.
http://pdp10.froghouse.org/qsic/qsic-wirewrap.
> Oh that blinkenlights panel is excellent! All emulators should have
> one! :-)
Yeah, isn't that fun? Once I got it running, I just sat and watched it
for about fifteen minutes while it ran our disk exercising program. And
then I noticed a bug. It apparently wasn't causing a problem but the
On 10/20/2016 04:27 PM, Paul Koning wrote:
> I would treat this as an analog problem, putting some op amps and comparators
> to work. It doesn't seem to rise to the level where D/A devices are needed.
> :-)
Clearly op amps and comparators could do the job, probably really
nicely, but it seems
On 10/19/2016 06:48 PM, shad wrote:
>
> One of my retrocomputing dream is to design an Unibus universal board,
> probably based on FPGA because of precise timing requirements,
> to emulate one or more disk/tape interfaces, and possibly something more.
> The real storage could be based on SD car
On 9/15/16 23:13, ben wrote:
> PS: Ternary arithmetic I can understand, but Ternary Logic needs Mr
> Spock to figure out.
Ternery logic would seem to be useful for implementing an asynchronous
design instead of, say, dual rail encoding.
On 03/16/2016 10:29 AM, Mouse wrote:
> That doesn't help [...]
You're right. I was thinking of stack overruns, not general buffer
overruns. Just need to stop programming in C for that last one.
On 03/17/2016 11:59 AM, Noel Chiappa wrote:
> > Each segment
> > is in it's own address space; any memory reference was, per force, a
> > segment number and offset.
>
> In this last sentence, is that referring to Multics?
>
> If so, that is exactly how the x86 _hardware_ works,
He mi
On 03/16/2016 09:55 AM, Mouse wrote:
> As for buffer overruns, the point there is that a buffer overrun
> clobbers memory addressed higher than the buffer. If the stack grows
> down, this can overwrite stack frames and/or callers' locals. If the
> stack grows up, all it can overwrite is locals f
On 03/08/2016 05:47 PM, Phil Budne wrote:
> CIRC is an MIT/ITS instruction; ISTR a flavor of "rotate"
It's a double-word rotate like ROTC except the two registers rotate in
opposite directions. The instruction
CIRC AC, 36.
will swap AC and AC+1 and reverse both of their bit orders.
On 11/24/15 18:21, Phil Budne wrote:
> I suppose "host" ports can used to support physical USB dongles of
> various sorts (serial, ethernet), but I guess my orientation is "why
> connect extra hardware that can be simulated?"
We talked about this and put it in the category of "the hardware can do
On 11/23/15 19:51, Paul Koning wrote:
> I can understand that, but surely that's an off the shelf item?
An implementation of the host side of the USB mass storage protocol? In
what form: an IC, IP for the FPGA, software? I'm sure the last one
exists but if either of the first do, I don't know a
On 11/23/2015 07:11 PM, Rich Alderson wrote:
> Be careful with the RH11 (and other Massbus interfaces): DEC lied in their
> published descriptions of the signals. In particular, 2 important ones are
> interchanged in the tables.
Ugh. No doubt I'll learn far more of these sorts of little tidbit
On 11/23/2015 07:05 PM, Paul Koning wrote:
> Then again, multiplying by a constant is trivial, and in a modern HDL you
> just write the expression you need. The synthesis will construct some adds
> and shifts out of that. In fact, even if you want to supply the geometry
> values from a table (
> Otherwise it's the RM05 at 256 Meg, if I remember right. But all those
> disks are also expected to expose the actual geometry of the disk. While
> fairly straight forward, it do expose you to a rather low level
> interface, where you need to do a lot of calculations all the time.
All those o
> For a classic/straightforward programming interface, the Massbus disks (RP04
> and successors) are a good choice. That will take you just over 500 MB, if
> you emulate the layout of the RP07.
Current thinking (at least my current thinking) is RK11 first then
probably RP11, both optionally ext
> This is great news, Noel. Are you on keeping bits and/or status for these
> projects on github or anywhere else that might encourage participation and
> contribution? I'd be glad to pitch in if I can. Actually, I (and I bet
> others) would love to see an up to date wiki entry or somesuch listi
> As Tom Lehrer not-so-delicately put it "more, more, more! I'm still not
> satisfied ..." :->.
We'll do our best. How about we add indicator panels?
> My thanks to you and Bridgham (who has a second name, perhaps)!
My second name is David but it comes first. I'm just funny that way.
Wow. A pretty board indeed. Thanks for showing it off. This is also
interesting to me since a friend and I have been talking about building
something rather similar (and entirely different at the same time, we're
just focusing on the mass storage function and using an FPGA). I'm
curious about
78 matches
Mail list logo
