QSIC update
Hey, all, a quick update on recent progress. I now have a working prototype to match Dave's (although he's still doing all the real work), and we've made a minor improvement in them (re-wired things so we can use shorter cables to the FPGA daughter-card). I got my indicator panel working, it looks quite nice: http://ana-3.lcs.mit.edu/~jnc/tech/QSIC/jpg/DasBlinken2F.jpg http://ana-3.lcs.mit.edu/~jnc/tech/QSIC/jpg/DasBlinken2NF.jpg The inlay is an original from a TS08 that I happened to have lying around; Rod S has made us a large batch of new blanks, but silk-screening of the captions on the front of those is yet to happen. The bezel is also an original. (I have a large stock of those, so it'll be a while before we need to work out how to make new ones - probably resin casting, although 3D printing will be an option too.) However, the guts are all new, and as you can see, the result looks just like the real originals. Dave has also worked out how to connect up the RKV12 (our name for the 22-bit RK controller, by analogy with the RLV11/RLV12) to the internal 'block' RAM in the FPGA, and then did the stuff to connect it to both the uSD card and the internal RAM at the same time, with one drive connected to the RAM, so things like swapping, etc don't 'waste' uSD writes. Both of these are working quite reliably; the exciser/tester runs until we get tired of the noise, and turn the machines off! :-) His current project is to work out how to talk to the larger external RAM on the FPGA daughter-board (the internal RAM isn't large enough for even a single complete RK pack). I'm so looking forward to putting swapping, /tmp, pipes, etc all on different platters, so as the system (Unix V6, natch :-) runs I can watch the lights and see _exactly_ what's going on! After that: turning the RK into an 'RPV12' (which should be pretty easy, the RK11 and RP11 are very similar), and adding a mux so that the two controllers can share the storage devices, etc. Those should both be done soon after the external RAM (and maybe before, if Dave needs a break from that :-). We also intend to do an 'extended RP11' (name not yet chosen, although I like 'RPV-12D - DEC's last was the RP11-C), which extends all the disk address fields in the register to use the unused bits, giving us pretty massive storage capability. With 16 bits of cylinder (up 7), 8 bits of surface (up 3), 4 bits of sector, that gives 28 bits of block number per drive; and with 8 drives per extended RP11, that's a total of 31 bits of block number per controller. Convert the blocks to bytes, that's 9 bits more, so 2^40 bytes per extended RP11, or 1TB! Very shortly now we'll need to turn to starting on the design of the 'production' hardware. Noel
Re: QSIC update - v6 Unix boots and runs
> On Jan 29, 2018, at 6:03 PM, Noel Chiappa via cctalk > wrote: > > ... >> (actually, this should work with Q18 QBUS systems as well) > > Goodness, never thought of that. Hmmm.. it's probably enough hassle to mod > the software (who ever heard of a 'QBUS map' on a QBUS -11 - but you'd need > it to give DMA devices access to high memory) ... No, there is no such thing as a QBUS map. Q18 systems are like 18 bit Unibus systems such as the 11/45: they have a max of 124 kW of memory so 18 bits address all available memory. paul
Re: QSIC update - v6 Unix boots and runs
> From: David Bridgham > Our plan is to produce a Unibus board as well, we just chose the QBUS > first. For no particularly strong reasons; I had working QBUS machines, and prototyping cards, etc, etc. > (actually, this should work with Q18 QBUS systems as well) Goodness, never thought of that. Hmmm.. it's probably enough hassle to mod the software (who ever heard of a 'QBUS map' on a QBUS -11 - but you'd need it to give DMA devices access to high memory) that it's probably just easier to go out and get Q22 hardware. Does anyone even have a Q18 /23? I think that was only the A model, right? I've never seen one. > we plan to also implement the Able ENABLE+ functionality In other words, a 'USIC' with Able ENABLE functionality added in. > This will, of course, require you to modify your OS to support this > non-standard memory. We should be programming compatible with the ENABLE, so for OS's where ENABLE support already exists, it should be a compile-and-go. > Noel has already done so for v6 Unix. Back in the day, with a real hardware ENABLE. PWB1, actually (pretty much V6). It wasn't too much work; one just changes the address definitions for the User and Kernel PARs from the DEC addresses to the Able ones, and recompiles all the kernel modules that touch them. One then has to set up the DEC User and Kernel PARs (which I did in the assembler startup, which was the only source module that took any serious changes). (If your OS uses Supervisor mode, well, err... :-) There are some other minor tweaks needed, e.g. this comment: / these routines are used to access /dev/kmem and look at possible / NXM locations in the system. The reason it uses this mechanism / is that some locations to be examined are on the bus before the / ABLE map, and thus cannot be examined by playing with the ABLE / map regs, e.g. using the standard u access routines .globl_fkbyte, _skbyte .globl_fkword, _skword Noel
Re: QSIC update - v6 Unix boots and runs
> 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 of the principal reasons for the languishing is that I > don't have any drives to go with it. Our plan is to produce a Unibus board as well, we just chose the QBUS first. A Unibus version of the hardware ought to be a fairly straightforward adaptation of the QBUS board while the QBUS modules in Verilog will just have to be replaced with Unibus versions. The busses work pretty similarly so we're expecting that to also be relatively straightforward. Yeah, I've told myself that before. :-) For the Unibus (actually, this should work with Q18 QBUS systems as well), we plan to also implement the Able ENABLE+ functionality which would give 11/70 size memory. We'll have some SDRAM onboard that we'll use for RAM disks but we'll carve out 4MB of that for machine memory and include mapping tables to access it. This will, of course, require you to modify your OS to support this non-standard memory. Noel has already done so for v6 Unix.
Re: QSIC update - v6 Unix boots and runs
> On Jan 29, 2018, at 1:57 PM, Phil Blundell via cctalk > wrote: > > On Mon, 2018-01-29 at 16:06 -0500, David Bridgham via cctalk wrote: >> 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 11/23 using the QSIC with an SD card emulating a couple >> RK05s. > > That sounds pretty awesome. Good job there! > > 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 of the principal reasons for the languishing is that I > don't have any drives to go with it. It’s the UMF11 (or some derivative thereof) that I’ve been working on/off for several (many?) years. It’s been languishing at the moment because work has demanded most of my time. I had gotten to the point where most of it was working in simulation and I have almost all of the uCode written for it and debugged. The uCode is written in Forth. TTFN - Guy
Re: QSIC update - v6 Unix boots and runs
On Mon, 2018-01-29 at 16:06 -0500, David Bridgham via cctalk wrote: > 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 11/23 using the QSIC with an SD card emulating a couple > RK05s. That sounds pretty awesome. Good job there! 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 of the principal reasons for the languishing is that I don't have any drives to go with it. p.
Re: QSIC update - v6 Unix boots and runs
> 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 hard to zero out the value. I figured something would come along that required it. There is still a whole lot of the RK11 functionality I need to implement, much having to do with handling and properly reporting error conditions. It's still pretty cool to boot up Unix and type commands at it. Doubly cool to watch the indicator panel blink away while I run programs. By the way, that indicator panel has been ridiculously valuable for debugging this thing. I did it initially just because I thought it would be fun and I needed to take a break from some frustrating bug but it's turned out to be far easier to use than the logic analyzer (which I've never hooked up). I just generate a custom FPGA load that displays some register I think will tell me what's going on or even sometimes create additional counters with specific triggers that can monitor the internals of my implementation.
Re: QSIC update - v6 Unix boots and runs
> On Jan 29, 2018, at 4:06 PM, David Bridgham via cctalk > wrote: > > 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. 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 remember this because I had to handle it in the driver for the RC11, since it has a 64 byte blocksize. paul
Re: QSIC update - v6 Unix boots and runs
> From: David Bridgham > today we booted v6 Unix successfully for the first time. As in, the OS image was loaded from the SD card, then started up using only the SD card for 'disk'. So this is a pretty major milestone. It's been a long road (I just looked, and we started on this in the summer of 2015), but we're finally getting there! The Unix file system, including the OS and all the various bits and pieces needed, like /bin/sh, etc, was prepared on a simulator (stock V6 won't run on a /23, which has no switch register), and then loaded into the SD card using 'dd' running on a Linux box. Our emulated RK11 doesn't do a perfect job of emulating an RK11 yet (e.g. for some reason we haven't yet looked into, the BDV11 ROM code won't load the bootstrap off the 'disk'; Dave had to manually load in an RK bootstrap using ODT), but enough is now working to let Unix load and run. > Unix does use partial block reads and writes after all For swapping, not for file-system I/O (which is all block-based). > We're getting close to the time when we need to think about making our > own circuit board rather than using the wire-wrap prototype we've been > having fun with so far. At which point we'll be able to supply them to anyone who wants one... It will be a while yet, but I think we are 'over the hump' on the project, with the OS booting and running properly. Noel
QSIC update - v6 Unix boots and runs
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 11/23 using the QSIC with an SD card emulating a couple RK05s. Moving on to a small RAM disk next so we don't have to swap off the flash memory. After that, either a larger RAM disk using the SDRAM or an RP11 to get larger disks than RK05s. We're getting close to the time when we need to think about making our own circuit board rather than using the wire-wrap prototype we've been having fun with so far.
Re: QSIC update and request, 11/04 microcode
On 2018-01-01 13:42, David Bridgham via cctalk wrote: I'd rather not get diverted by yet another substantial development project so I'm looking for a decent little FPGA implementation of a PDP-11 that I could just pick up use for this purpose. Something that's already debugged. I'm thinking closer to an 11/04 than an 11/70 and likely just running out of block RAM on the FPGA. is the 11/04 microcode somewhere as a binary? So far I found only the print in the MPS ...
Re: QSIC update and request
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 of passing on information I'd learned to the community about something I thought was interesting but you're right, it also serves to document some of the internals of the QSIC since that's where I took it from.
Re: QSIC update and request
On 2018-01-02 3:00 PM, David Bridgham via cctalk wrote: > 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 meant. In fact I thought that was the point of the >> device :) > > Well, I guess I thought the point was to produce a working replacement > for the disk drives that are nearly unobtainable but if it turns out > that lots of people are seriously interested in developing for the QSIC > itself, then I'll have to revisit that supposition. In that case, I'd > probably write up more internals documentation than I would otherwise. > >> Hope so. And there's always the blog? > > Blog? Is there a blog about the QSIC that I don't know about? I'm not > much of a blogger but if you get me started talking about things that > interest me I tend to rattle on to excess. > > Err.. could be my mistake... I meant wherever you posted your last technical note about QBus quirks. (I didn't look up the reference) --Toby
Re: QSIC update and request
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 meant. In fact I thought that was the point of the > device :) Well, I guess I thought the point was to produce a working replacement for the disk drives that are nearly unobtainable but if it turns out that lots of people are seriously interested in developing for the QSIC itself, then I'll have to revisit that supposition. In that case, I'd probably write up more internals documentation than I would otherwise. > Hope so. And there's always the blog? Blog? Is there a blog about the QSIC that I don't know about? I'm not much of a blogger but if you get me started talking about things that interest me I tend to rattle on to excess.
Re: QSIC update and request
On 2018-01-02 1:17 PM, David Bridgham via cctalk wrote: > 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 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 meant. In fact I thought that was the point of the device :) > available, I'll be around (hopefully) and will be quite willing to > answer questions. Shoot, if anyone shows interest I'll probably talk > their ear off about it. > > Hope so. And there's always the blog? --Toby
Re: QSIC update and request
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 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 available, I'll be around (hopefully) and will be quite willing to answer questions. Shoot, if anyone shows interest I'll probably talk their ear off about it.
Re: QSIC update and request
> From: Toby Thain > If the documentation is good enough, people in the community will be > able to provide the software. You mean, host drivers? Yeah, that documentation will be pretty trivial: 'there's this extra register, just like the one in the RLV12; the top 6 bits of the DMA memory address go in there - the bottom two bits are mirrored into the two extended memory bits in the CSR'. For the 'extended' RP11, not much more than that. 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... Noel
Re: QSIC update and request
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 look around the device registers and pick up a few more bits that were unused in the RP11 and we end up with a 28-bit Linear Block Address which works out to a ridiculously huge disk for any PDP-11 ever conceived. But yeah, we'll document it. There will also be an entirely new programming interface into the QSIC itself, mainly having to do with configuration (like whether or not the RP11 implementation is stock or extended and how portions of the SD cards are mapped to various disk packs mounted on the emulated disk drives). I intend to write that up too so that people are able to write programs for their favorite OS that drive the device however they wish. I may joke about pointing people to the source to figure out how it works (it was hard to write, it should be hard to read) but I actually quite like well-done documentation and will endeavor to produce some.
Re: QSIC update and request
On 2018-01-02 9:01 AM, Noel Chiappa via cctalk wrote: > > From: Mark J. Blair > > > I wonder if it might also be useful in any of the QBUS MicroVAXen? > > Hardwarewise, it should be fine. Softwarewise... well... > ... > Anyway, you can see where this is going. For people who can tweak their > drivers, no biggie. The changes aren't major - a line or two. For people who > want to run stock software... If the documentation is good enough, people in the community will be able to provide the software. > > ... > Getting around this is all, of course, a SMOP (Small Matter of Programming), > since a new FPGA load, with support for more emulations, can be installed on > an existing QSIC at any time. It seems that you aimed at producing a "platform" all along, so that's just a natural effect. --T > > Now, whether Dave would be interested in supporting later devices, or whether > someone else could be convinced to emulate something more modern ... who > knows? > > Noel >
Re: QSIC update and request
> From: Mark J. Blair > I wonder if it might also be useful in any of the QBUS MicroVAXen? Hardwarewise, it should be fine. Softwarewise... well... The issue is that we're currently only planning to emulate the RK11 and RP11, because we're not up for the hassle involved in emulating more recent controllers. (That's not an issue for the systems we want to run.) We looked at the RP04, and _full_ emulation even of that one is a significant amount of work. (I stress the 'full' because a partial, simple emulation might not be too bad, but since we have no idea what various OS's will expect to be there, it's not clear how much use such a partial emulation would be.) However, that presents a problem. There are no 22-bit versions of either (in fact, there's no QBUS RP11 at all; and the QBUS RK11 is restricted to Q16, for reasons that surpass me). 22-bit operation is needed to make them really useable as mass storage under Unix, for swapping (because all file system access is buffered through low memory, purely file system use would be OK without Q22 support) - at least on -11's with more than 256KB of memory. (Probably DEC OS's too, but I know nothing of them.) So, in addition to the dead-stock emulations of the two, we will also support slightly 'adjusted' versions of the controllers, to have an 'address extension' register (in exactly the same way the RLV12 has an extra register over the RLV11). (And we're also going to have an adjusted version of the RP11, which extends the size of the disk, using unused bits/values in the disk address registers, to allow up to 1TB on an 'RP11-D', as we're calling it. Hey, if you're going to change the controller _at all_... But I digress.) Anyway, you can see where this is going. For people who can tweak their drivers, no biggie. The changes aren't major - a line or two. For people who want to run stock software... I don't know enough about how the QBUS VAX systems use their disks. Will uVAX OS's run with only an RKV11-D for mass storage? Somehow I doubt it.. I assume on the later ones (the ones with the private memory bus so they can have more than 4MB of memory) there's some sort of QBUS map, to map from the QBUS' 22-bit address space, to the full memory. But does the hardware and software expect to use the entire 22-bit address space, or are they prepared to limit it (e.g. for working with an RKV11-D), or what? I suppose we could add the RLV12 to the list of things we emulate; that's not _that_ complicated a controller. The problem is that RL's aren't that big (10MB), and that gets to be an issue with later OS's. And even then VAX OS's might not run off an RLV12 - I just don't know. Getting around this is all, of course, a SMOP (Small Matter of Programming), since a new FPGA load, with support for more emulations, can be installed on an existing QSIC at any time. Now, whether Dave would be interested in supporting later devices, or whether someone else could be convinced to emulate something more modern ... who knows? Noel
Re: QSIC update and request
This looks pretty interesting! I think I've managed to miss previous discussion of it. I wonder if it might also be useful in any of the QBUS MicroVAXen? -- Mark J. Blair, NF6X http://www.nf6x.net/
Re: QSIC update and request
> From: David Bridgham > I could ask for a lot more really but that's pretty good. IMO we're 'over the hump' on the prototype phase of the project. The complete QBUS interface (including DMA and interrupts) are done, and very thoroughly tested, and now we have the SD interface up and running too. Once we get all this running reliably, IMO the remaining work (configuration, simulating the RP11, etc) will be relatively simple and straightforward. Then we get to the next major lump - turning out the production unit. > Here's a picture to my test setup: Looking at that brings up another piece of progress to report; that paper version of the indicator panel inlay is just about obsolete; we have produced blank inlays (the correct shape to fit into the bezel, but with just the back black layer with all the holes), and the next move is to produce ones with the white captions silk-screened on the front, just like the originals: http://ana-3.lcs.mit.edu/~jnc/tech/DECIndicatorPanels.html So 'very soon' we should have a complete working indicator panel! A lot slower, overall, than we had hoped, but we're getting there! Noel
QSIC update and request
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 working and that's basically there now. It initializes and reads and writes blocks. I've also connected it through an async FIFO to the minimal RK11 controller I had working before and that's mostly working. That is, it can read and write blocks under control from the QBUS PDP-11 as if it were a real RK11/RK05. What more could you ask for? Well, I could ask for a lot more really but that's pretty good. There's a lot of RK11 functionality that I haven't implemented yet and all sorts of configuration options we need to get in there. Also, there's a bug where it sometimes scrambles data so it's not quite ready to boot and run a real OS yet but it's getting awfully close. Here's a picture to my test setup: http://pdp10.froghouse.org/qsic/qsic-setup.jpg And a picture of a test of some spray-on glass frosting used as a light diffuser on the indicator panel. In this picture you can also see the new LEDs I found that are a much better color match to the old incandescent bulbs than the LEDs I picked for my first attempt. http://pdp10.froghouse.org/qsic/frosting.jpg Now for the request. I've decided that I'd like to put a soft-processor in the FPGA to handle a bunch of things (configuration duties and the USB protocol being two of the big ones). My preference would be for this soft-processor to be a PDP-11. Surely there's hack value in using a PDP-11 as the I/O processor for a PDP-11 but there are practical advantages to this as well. For one, we're already familiar with it and have a suite of development tools. Also, I can re-arrange the I/O devices I intend to give to this soft-11 and put them directly on the QBUS instead and do initial development there. I'd rather not get diverted by yet another substantial development project so I'm looking for a decent little FPGA implementation of a PDP-11 that I could just pick up use for this purpose. Something that's already debugged. I'm thinking closer to an 11/04 than an 11/70 and likely just running out of block RAM on the FPGA. Thanks for any pointers to such an implementation and thanks to everyone who's given support and assistance as Noel and I have poked along on this project. Dave
QSIC Update
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 cards seemed the right first choice so that was the task. After a few months of staring at a state machine implementation and having nothing click for me, I set that aside and considered the idea of building a micro-coded machine. Noel and I kicked it around, came up with a design, he wrote up a micro-assembler and I did the Verilog. This was my first micro-machine but it worked out pretty well, I think. Anyway, we got the design running the SD card through its initialization sequence. Pretty pleased with that. The next step is transferring data blocks but I ran out of time. Also this winter I finally got myself a Github account and moved the code up there. Look for dabridgham/QSIC if you're interested. The webpage describing the QSIC project is http://pdp10.froghouse.org/qsic/html/overview.html. In related news, as we were working through the QBUS implementation Noel and I had a bunch of discussions about bus arbitration. I think we ended up with a decent understanding and so I decided to write it up for anyone else playing around with QBUS or Unibus designs. Yeah, I know, there aren't likely to be too many of us. Anyway, the paper is here: http://www.froghouse.org/~dab/papers/bus-arbitration/bus-arbitration.html There's a pdf version too but the formatting left off the overbar over Q in one section so it might be a bit confusing. Dave
Re: QSIC update
> From: Henk Gooijen >> He's now starting in on interrupt cycles; once those work, he >> effectively has emulation of a minimal small RK > sounds very good - nice progress! Interrupts are now working, and as of yesterday (when I finally managed to get all the bugs out of my diagnostic - we can't use the DEC ones since it doesn't yet emulate a full RK drive) it will sit and read and write blocks as long as we let it, interrupting after each transfer. I'm about to upgrade the diagnostic to test more features, such as multi-block transfers, etc. Dave is about to start work on SD card support. > When you get to it, that will be a fast swap drive ;-) Indeed! It seems to transfer a complete sector in about 600 usec, when running a 'disk' in RAM - it's only even that 'slow' because for some reason, which Dave is investigating, the CPU (an 11/73) seems to take about 1usec to do a DMA grant after the previous cycle, even when it and the QBUS are idle (the CPU is in a WAIT instruction while the transfer is happening, with my diagnostic). Each individual word seems to take about 900 nsec; not great, but not bad. Dave's going to look at that in some detail, too. And of course there are zero seek and rotational delays, so it will be pretty zoomy (although of course the SD 'disk' will also have that characteristic, but we don't yet know if the SD will support the full QBUS bandwidth, the way the RAM certainly will). But even if it is that fast, it's still probably worth having the RAM disk, because it will avoid putting write cycles on the SD card memory. (I myself plan to put /tmp, and pipes, on a RAM disk, for just that reason. In V6 Unix, at least, a system call to move pipes off the root disk is one line of code... :-) Noel
Re: QSIC update
-Oorspronkelijk bericht- From: Noel Chiappa Sent: Saturday, March 05, 2016 2:01 PM To: cctalk@classiccmp.org Cc: j...@mercury.lcs.mit.edu Subject: Re: QSIC update > So here's a quick update on where Dave Bridgham and I are with the > QSIC ... We have the first of two wire-wrap prototype QBUS motherboards > more or less (see below) done .. the hardware is 'mostly' working; most > of the work from here on out will be FPGA, etc, programming. There > _are_ a few additional QBUS lines used for bus master (DMA) and > interrupts which we haven't used yet, and one of the first things done > now is to get those two kind of bus cycles working > ... > With that in hand, we can do the first controller (RK11), using memory > in the FPGA to simulate a small disk. Well, Dave has made a big step down that road; he has DMA working (both the bus arbitration cycle for DMA, as well as master-mode transfers to and from QBUS slave memory). He's now starting in on interrupt cycles; once those work, he effectively has emulation of a minimal small RK (he already has all the registers, since he needs them to control the DMA to and from the RAM disk). At that point I should be able to test it by making it the swap drive on a Unix V6 load. Noel - sounds very good - nice progress! When you get to it, that will be a fast swap drive ;-) - Henk
Re: QSIC update
> So here's a quick update on where Dave Bridgham and I are with the > QSIC ... We have the first of two wire-wrap prototype QBUS motherboards > more or less (see below) done .. the hardware is 'mostly' working; most > of the work from here on out will be FPGA, etc, programming. There > _are_ a few additional QBUS lines used for bus master (DMA) and > interrupts which we haven't used yet, and one of the first things done > now is to get those two kind of bus cycles working > ... > With that in hand, we can do the first controller (RK11), using memory > in the FPGA to simulate a small disk. Well, Dave has made a big step down that road; he has DMA working (both the bus arbitration cycle for DMA, as well as master-mode transfers to and from QBUS slave memory). He's now starting in on interrupt cycles; once those work, he effectively has emulation of a minimal small RK (he already has all the registers, since he needs them to control the DMA to and from the RAM disk). At that point I should be able to test it by making it the swap drive on a Unix V6 load. Noel
Re: QSIC update
> From: Al Kossow > Have you guys thought about a panel that would connect to the KM11 > connector slots of real rk11/tc11 controllers? Umm, Guy sells KM11 clones? (I just bought a pair, they look really nice.) Or did you mean something else? Speaking of things Guy has, Dave is talking about adding a switch that would turn a QSIC+indicator panel into a QAV-11... :-) Noel
Re: QSIC update
On 2/15/16 5:05 AM, Noel Chiappa wrote: Anyway, we think getting slave cycles working was a major milestone (for a couple of software guys :-) yay! Have you guys thought about a panel that would connect to the KM11 connector slots of real rk11/tc11 controllers? At one point, I thought about a cable that would let you run virtual KM11's on a laptop screen.
QSIC update
So here's a quick update on where Dave Bridgham and I are with the QSIC, since I think we have reached a significant milestone. We have the first of two wire-wrap prototype QBUS motherboards more or less (see below) done, and working to do slave cycles on the QBUS. (I.e. we implemented a simple register, and can write it, and read the contents back.) A test program to write all 2^16 possible values, and read them back and check them, ran several thousand complete passes with no errors. To get there, we (Dave, really - he bore the brunt of the work on this problem, and finally conquered it) had to tackle and fix some major noise issues: the way the prototype is done (a wirewrap QBUS mother-board with bus transceivers, level converters, etc, connected to an FPGA prototyping card with flat cables), we think we had cross-talk problems in the cables (since the connector pinout on the FPGA card, which we can't change, didn't alternate ground and signal lines). Anyway, it's working now; that means the hardware is 'mostly' working; most of the work from here on out will be FPGA, etc, programming. There _are_ a few additional QBUS lines used for bus master (DMA) and interrupts which we haven't used yet, and one of the first things done now is to get those two kind of bus cycles working; a) we have to get them done anyway, and b) that will verify that the QBUS interface hardware is full working. With that in hand, we can do the first controller (RK11), using memory in the FPGA to simulate a small disk. We'll then try and get to the larger RAM on the FPGA, to do full-size RAM disks. Next up after that is probably to hook up some SD cards (we already have produced the small PCB daughter-cards, which will mount on sockets on the wire-wrap mother-board, to hold the SD cards - we still need to add those sockets and wire them up, hence the comment that the wire-wrap mother-boards are "almost done"), at which point we'll have a fully-functional prototype. Dave has also produced prototype PCB's for the indicator panel, and one has been stuffed, and Dave's about to try and hook that up, and get it running; that will require yet a bit more work on the mother-board (install 3 sockets to hold the driver chips for the signal lines in the interface to the indicator panel). Blinkenlitz are a priority because, i) just because ;-), and ii) being able to display data from inside the FPGA will be a big debugging help. Anyway, we think getting slave cycles working was a major milestone (for a couple of software guys :-), And we think (_hope_ :-) that progress will now be pretty rapid, so hopefully more soon. Noel
