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
51 matches
Mail list logo